AWS マルチリージョン高可用性アーキテクチャ構成図

AWS マルチリージョン構成図の多くは、同じ形で失敗しています。us-east-1 と eu-west-1 とラベルを付けた同じ箱が 2 つ並んでいて、その間には何もありません。高可用性に見えますが、レビュー担当者やオンコールのエンジニアが聞きたい質問には何も答えていません。書き込みはどこへ行くのか。データはどちらの方向にレプリケートされるのか。リージョンが劣化したとき、何がトラフィックを移し、誰が、あるいは何がそれを判断するのか。この記事では、構成図に何を描くべきか、active-active と active-passive が図の上でどう違うか、そして無料のサンプル図をもとに Archboard でどう描くかを説明します。

AWS マルチリージョン構成図に描くべきもの

リクエストが流れる順に、上から下へ読める図にします。

1. グローバルな入口：Route 53 と CloudFront

• Amazon Route 53 は、どちらかのリージョンの中ではなく、両リージョンの上に置きます。ルーティングポリシーはエッジのラベルに書きます。failover（health check に紐づくプライマリとセカンダリのレコード）、latency-based（各ユーザーをレイテンシが最も低いリージョンへ送る）、weighted などです。health check も描いてください。フェイルオーバールーティングは health check があって初めて機能します。
• Amazon CloudFront はリージョンごとのオリジンの前に置きます。origin failover を設定した origin group を使う場合は、両方のオリジンを描き、どちらがプライマリかを示します。CloudFront の origin failover が対象とするのは GET、HEAD、OPTIONS リクエストなので、書き込みには別の経路が必要です。

2. リージョンの入口：Application Load Balancer

ALB はリージョン単位のリソースで、有効にした Availability Zone にまたがります。リージョンごとに 1 つ、リージョンの境界の中に描き、ターゲットを少なくとも 2 つの AZ に配置します。

3. Availability Zone にまたがるコンピュート

Amazon ECS サービス、Amazon EKS のノードグループ、EC2 Auto Scaling グループなど、アプリケーションを動かしているものを、2 つまたは 3 つの AZ フレームにまたがって描きます。図で伝えるべき点は 1 つです。AZ の喪失はリージョン内で吸収し、リージョンの喪失はグローバル層で吸収する、ということです。

4. データ層は矢印付きで

多くの構成図が黙ってしまうのがここです。データストアごとにレプリケーションのモデルが異なり、矢印の向きがすべてを物語ります。

S3 のレプリケーションルールは新しいオブジェクトに適用され、ルール作成前から存在するオブジェクトには S3 Batch Replication が必要だという注記も添えてください。必ず誰かが質問します。

5. シークレットと設定

AWS Secrets Manager はシークレットを他のリージョンにレプリケートでき、AWS KMS はマルチリージョンキーをサポートしています。Systems Manager Parameter Store はリージョン単位です。各リージョンがシークレットと設定をどこから読むのかを描きます。アプリケーションがデータベースのパスワードを復号できなくなった時点で止まるフェイルオーバーは、フェイルオーバーとは言えません。

6. オブザーバビリティとコントロールプレーン

障害を何が検知し、何が対処するのかを示します。Route 53 の health check、各リージョンの CloudWatch アラーム、合成モニタリングの canary、リージョン横断のダッシュボードなどです。フェイルオーバーを Amazon Application Recovery Controller（ARC）の routing control や runbook で起動するなら、それも図に載せます。AWS Well-Architected の信頼性の柱 は、復旧時にはコントロールプレーンの変更ではなくデータプレーンの操作に頼ることを推奨しています。health check による DNS フェイルオーバーは前者の例です。どちらに依存しているかを示す場所として、構成図は最適です。

active-active と active-passive

AWS は 4 つのディザスタリカバリ戦略を挙げています。そのうち 3 つは 2 つ目のリージョンで何かを動かしており、どれを選ぶかで図に描くべき内容が変わります。

数値は自分たちで決めるものです。RTO と RPO の目標を戦略の横にキャンバス上で書いておけば、図とビジネス要件を照らし合わせて確認できます。

active-active が自動的に優れているわけではありません。昇格の手順はなくなりますが、各データストアが同時書き込みをどう扱うかを決める必要が出てきます。Aurora Global Database では一度に書き込めるのは 1 つのリージョンだけなので、その上に作った active-active 構成にも書き込みリージョンは 1 つしかありません。それをそのまま描いてください。

フェイルオーバー経路を明示する

エッジのスタイルを 3 種類使い、凡例で説明します。

• リクエスト経路：ユーザーから DNS、CDN、ALB、コンピュートへと続く実線の矢印。
• レプリケーション：データストア間の破線の矢印。方向とモード（async、multi-active）をラベルに書く。
• フェイルオーバー：プライマリリージョンが異常なときにトラフィックがどこへ向かうかを示す、独立したラベル付きの経路。

そのうえで、フェイルオーバーの手順をキャンバス上のノートに番号付きで書きます。

1. Route 53 health check on primary ALB fails
2. Route 53 failover record answers with the secondary region
3. Aurora secondary cluster is promoted to writer (global database failover)
4. ECS service / Auto Scaling group in the secondary region scales out
5. Alarms confirm traffic and error rates in the secondary region

手動の手順があれば誰が実行するかを書き、コントロールプレーンの API に依存する手順には印を付けます。

よくある間違い

• 同じリージョンを 2 回描いただけで、データの流れがない。 レプリケーションの矢印がない同じスタックの複製は、復旧について何も語りません。
• コントロールプレーンを隠す。 フェイルオーバーが起きるかどうかを決めるのは health check、routing control、runbook です。これらを省くと、フェイルオーバーできないシステムを描いていることになります。
• フェイルオーバーの矢印がない。 平常時のリクエスト経路は話の半分にすぎません。
• グローバルサービスをリージョンの中に描く。 Route 53 と CloudFront はグローバルなサービスです。リージョンのフレームに入れると、存在しない依存関係を示したり、実在する依存関係を隠したりします。
• AZ がない。 リージョンレベルの冗長性は AZ レベルの冗長性の代わりにはなりません。両方を描きます。
• 状態を忘れる。 キャッシュ、キュー、セッションストアもリージョン単位です。どこにあり、障害時にどうなるかを示します。

Archboard で作る

Archboard では、Cloud パックと Network パックのノードでこの図を作ります。ポートを持つ正式なノードに AWS のサービス名でラベルを付けるので、どの箱も役割と具体的なサービスの両方が一目で分かります。図の作り方は次のとおりです。

1. 無料テンプレートを確認します。 /examples/multi-region-cloud-ha を開きます。リージョンをまたぐ CDN、2 リージョンのロードバランサー、コンピュート、マネージドデータベースが描かれています。これを参考にするか、この事例を使うで自分のワークスペースにコピーしてから、上で説明したレイヤーを追加していきます。
2. リージョンと AZ の境界を作る。 Cloud パックの Region フレームを 2 つ追加し、us-east-1 (primary) と eu-west-1 (secondary) とラベルを付けます。それぞれの中に、AZ 用の Core の Frame 要素を置きます。
3. リージョンの上にグローバル層を置く。 ユーザーには Network パックの Internet、Route 53 (failover routing) とラベルを付けた Network パックの DNS、CloudFront とラベルを付けた Cloud パックの CDN を使います。
4. 各リージョンを埋める。 ALB とラベルを付けた Cloud パックの Cloud LB、各 AZ フレームに ECS service や EC2 Auto Scaling group とラベルを付けた Compute ノード（EKS なら Kubernetes Cluster ノード）、Aurora (writer) と Aurora (secondary, read-only) の Managed DB ノード、DynamoDB global table 用にもう 1 つ、そして S3 とラベルを付けた Object Storage を置きます。
5. ポートをつなぎ、すべてのエッジにラベルを付ける。 リクエスト経路、レプリケーションの方向とモード、フェイルオーバー経路です。ルーティングポリシーとレプリケーションの種類はエッジのラベルに書きます。
6. コントロールプレーンとノートを加える。 Secrets Manager、CloudWatch、health check には Core の Box ノード、番号付きのフェイルオーバー手順には Note、RTO と RPO の目標と選んだ戦略には Markdown ブロックを使います。

始める前にノード数を数えておきましょう。2 リージョンの完全なマップは、たいてい Free プランの図ごとの上限である 15 ダイアグラムノードを超えます（メモとテキストは別枠でカウントされ、最大 150 件です）。ノード無制限、ドキュメントサイトへの埋め込み、PDF エクスポートが使える Pro がぴったりです。そのほかのパターンはクラウドのユースケースページにあります。

よくある質問

Archboard で AWS の公式アイコンを使えますか？ Archboard の型付き Cloud ノードと Network ノードは特定のベンダーに依存しませんが、Core の Icon ノードで Iconify を検索して（たとえば logos:aws-route53）AWS のロゴを追加したり、公式の AWS Architecture Icons を画像としてアップロードしたりできます。各ノードに Route 53 や Aurora Global Database などの AWS サービス名でラベルを付ければ、AWS を知っている人なら誰でもはっきり読み取れる図になります。

リージョンと AZ の両方を描くべきですか？ はい。AZ はゾーン障害をどう乗り切るかを、リージョンはリージョン障害をどう乗り切るかを示します。障害の種類も仕組みも異なります。

active-active と active-passive のどちらにすべきですか？ RTO と RPO の目標、そしてデータモデルから考えます。メインのデータベースの書き込みリージョンが 1 つなら、active-passive（pilot light または warm standby）のほうが単純で実態に即した設計になることが多いです。決めた内容は図に書いておきます。

どうやって共有しますか？ SVG または PNG でエクスポートする（Free では透かし入り）、公開リンクを共有する、または Pro でドキュメントに埋め込むことができます。

無料で始める — 1 シート、クレジットカード不要