[レポート] マルチリージョンのアクティブ構成アーキテクチャ #ARC213 #reinvent

本記事はAWS re:Invent 2019のセッション「ARC213-R - [REPEAT] Architecture patterns for multi-region active-active」についてレポートします。

セッション情報

スピーカー

• Girish Dilip Patil - Senior Architect, Amazon Web Services
• Jonathan Dion - Senior Technical Evangelist, Amazon Web Services
• Thomas Jackson - Head of Core & Data Infrastructure, Wish (ContextLogic)

セッション概要

With global business, there is an ever-growing need to be able to implement multi-region active-active architecture. However, this requires first-order thinking and attention not just to app and database design but also to DNS, monitoring, traffic shaping, and so on. Furthermore, architecture complexity can increase rapidly, so multiple design trade-offs need to be made. In this session, we discuss challenges and solutions using various AWS services, like Amazon DynamoDB global tables, as well as open source products.

グローバルビジネスでは、マルチリージョンのアクティブ/アクティブアーキテクチャを実装できるようにする必要性が常に高まっています。 ただし、これにはアプリとデータベースの設計だけでなく、DNS、監視、トラフィックシェーピングなどにも一次的な考え方と注意が必要です。 さらに、アーキテクチャの複雑さは急速に増大する可能性があるため、複数の設計上のトレードオフを行う必要があります。 このセッションでは、Amazon DynamoDBグローバルテーブルなどのさまざまなAWSサービス、およびオープンソース製品を使用した課題とソリューションについて説明します。

レポート

なぜマルチリージョンアクティブ/アクティブ構成が必要か？

• "Everything fails, all the time" - Werner Vogels (CTO Amazon.com)
  • すべてのものはいつか壊れるため、それに備える必要がある。
• 障害の影響範囲を減らす必要がある

従来のDRソリューションの問題点はなにか？

• 本番とDR環境で同期がずれる
• 大きな費用がかかる

マルチリージョンアクティブ/アクティブアーキテクチャの設計原則とは

• ネットワークの耐性
  • あるリージョンで問題が発生しても、別のアプリケーションで障害が発生することがない
  • リージョンで独立してサービスが提供できるようにしておく
    • リージョン間のブロッキングAPIまたはデータベース呼び出しを最小限にする
    • ネットワーク障害時のサービスの適切な縮退
• 最小限のデータ同期要件
  • すべてのデータをレプリケートする必要があるか？
  • 必要な場合、同期でのレプリケートが必要か？
  • すべてのデータを継続的にレプリケートする必要があるか？
• データを分類する。下記は上ほど量は少なく重要なデータ、下は量は多いが重要度は低い。
  1. トランザクション：支払データなど
  2. カタログ情報：商品詳細
  3. イベント、オブジェクト：クリックストリーム
  4. サーバログ：HTTPSログ
• 同期と非同期レプリケーション
  • 同期
    • Pros: 一貫性を保証
    • Cons: ネットワークとターゲットに依存
  • 非同期
    • Pros: ネットワークとターゲットに依存しない
    • Cons: データベースが同期しなくなる可能性がある
• 理想的なレプリケーションシステム
  • レプリケーション遅延の報告
  • レコードオフセットの報告
  • 失敗したレコードのレプリケーションをリトライできること

アーキテクチャパターン

パターン1：Read local, write global

• 読込みはユーザに近いリージョンから行う
• 書き込みは1つのリージョンに固定
• 同期は一方向で行う

パターン2：Read local, write local

• 読込み、書き込みともにユーザに近いリージョンで行う
• 同期は双方向で行う
• マルチマスター構成

• 分散システム設計のベストプラクティス

  • Idempotency
  • Exponential backup

マルチリージョンアクティブ/アクティブアーキテクチャの基本的な柱

• 高信頼性 -
• データレプリケーション
  • S3クロスリージョンレプリケーション
  • DynamoDB Global Tables
  • Amazon RDSクロスリージョンレプリケーション
  • Amazon Kinesis Data Streamsを使った複数リージョンのログ統合
• ネットワーク
  • VPC
  • AWSグローバルインフラストラクチャ
  • インターリージョンVPCピアリング
• トラフィックルーティング
  • Route53
    • レイテンシに基づくルーティング
    • 地理的近接性ルーティングポリシー
    • フェイルオーバールーティングポリシー
  • AWS Global Accelerator
  • CloudFront + Lambda@Edgeによるルーティング
• 管理
  • AWS Config Rules
  • AWS Systems Manager
  • Amazon CloudWatch
  • AWS CloudFormation StackSets

まとめ

• 信頼性と可用性のために、最初のステップとしてMulti-AZアーキテクチャを採用する
• マルチリージョンアクティブ/アクティブ構成は障害の影響範囲を制限する
• 複数リージョンを使うことによって、従来のディザスタリカバリアーキテクチャよりも高い信頼性があるが複雑さが増す
• シンプルにする
  • リージョン間のブロックする依存関係を最小限にする
  • リージョン間の同期レプリケーションを最小限にする
  • 接続の問題が発生した場合のグレースフルデグラデーション
• AWSはDynamoDB Global Tables、RDSクロスリージョンリードレプリカ、S3クロスリージョンレプリカなどレプリケーションソリューションを提供している
• 分析用のスタックは通常1つのリージョンに配置されます
• AWSのマネージドサービスはレプリケートにAWSグローバルインフラストラクチャを使用する
• 自身で管理するレプリケーションにはインターリージョンVPCピアリングを使用する
• トラフィックルーティングにはGlobal Accelerator、Route53、CloudFront + Lambda@Edgeの利用を検討する
• 環境の管理にはCloudFormation StackSetsなどのツールを検討する

さいごに

マルチリージョン構成を構築する上で検討すべき内容がよくわかりました。