AWS のディザスタリカバリ (DR) アーキテクチャ、パート IV: マルチサイトアクティブ/アクティブ

このブログはSeth Eliot (Principal Reliability Solutions Architect with AWS Well-Architected)によって執筆された内容を⽇本語化したものです。原⽂はこちらを参照して下さい。

このシリーズの最初のブログ記事では、ディザスタリカバリ (DR) の 4 つの戦略を紹介しました。その後の投稿では、バックアップと復元、パイロットライト、ウォームスタンバイアクティブ/パッシブ戦略の詳細を共有しました。

この投稿では、ワークロードを実行し、2 つ以上の異なるサイトでリクエストを処理するアクティブ/アクティブ戦略を実装する方法について説明します。他のDR戦略と同様に、これにより、自然災害、技術的な障害、または人的な行為などの災害イベントが発生しても、ワークロードを使用可能な状態に保つことができます。

DR 戦略:マルチサイトアクティブ/アクティブ

おなじみのDR戦略図（図1）からわかるように、マルチサイトアクティブ/アクティブ戦略では、 RTO（目標復旧時間）とRPO（目標復旧時点）が最小になります。ただし、これは、複数のサイトでアクティブスタックを運用する際の潜在的なコストと複雑さを考慮する必要があります。

図 1.DR戦略

マルチサイトアクティブ/アクティブの実装

図 2 のアーキテクチャでは、複数の AWS リージョンをアクティブサイトとして使用し、マルチリージョンのアクティブ/アクティブアーキテクチャを構築しています。図に表示されているリージョンは 2 つだけです。これは一般的ですが、さらに多くのリージョンを使用できます。各リージョンは、可用性の高いマルチアベイラビリティーゾーン (AZ) ワークロードスタックを提供します。各リージョンでは、データはデータストア間でライブレプリケートされ、さらにバックアップも行われます。これにより、データの削除や破損といった災害時でも、データバックアップを使用して最後の正常な状態に復元することができます。

図 2.マルチサイトアクティブ/アクティブ DR 戦略

トラフィックルーティング

それぞれのリージョンのスタックは、本番トラフィックを処理します。トラフィックルーティングをどのように実装するかによって、特定のリクエストを受け取るリージョンが決まります。図 2 では、可用性が高くスケーラブルなクラウド型ドメインネームシステム (DNS) である Amazon Route 53 をルーティングに使用しています。Route 53 は複数のルーティングポリシーを提供します。たとえば、位置情報ルーティングポリシーやレイテンシールーティングポリシーは、アクティブ/アクティブなデプロイに適しています。位置情報ルーティングでは、リクエストの送信元の場所に基づいて、リクエストが送信されるリージョンを設定します。レイテンシールーティングの場合、AWS はラウンドトリップ時間が最も短いリージョンにリクエストを自動的に送信します。

データガバナンス戦略は、どのルーティングポリシーを使用するかを決定するのに役立ちます。位置情報ルーティングを使用すると、決定論的な方法でリクエストを分散できます。これにより、特定のユーザーのデータを特定のリージョン内に保持したり、書き込みオペレーションのルーティング先を制御して競合を防ぐことができます。パフォーマンスを最適化することが最優先事項である場合は、レイテンシルーティングが適しています。

読み取り/書き込みパターン

ローカル読み取り/ローカル書き込みパターン

あるリクエストがルーティングされたリージョンを、そのリクエストの「ローカルリージョン」と呼びます。低レイテンシーを維持し、ネットワークエラーの可能性を減らすには、マルチリージョンのアクティブ/アクティブアーキテクチャのローカルリージョン内ですべての読み取りおよび書き込みリクエストを処理します。

図 2 のアーキテクチャ例では Amazon DynamoDB を使用しています。DynamoDB グローバルテーブルは、テーブルを複数のリージョンにレプリケートします。任意のリージョンのテーブルへの書き込みは、1 秒以内に他のリージョンにレプリケートされます。これは、ローカル読み取り/ローカル書き込みパターンを使用する場合に適しています。ただし、異なるリージョンの同じアイテムに対してほぼ同時に更新が行われると、書き込み競合が発生する可能性があります。結果整合性を確保するために、DynamoDB グローバルテーブルは、最終書き込み者優先を使用して、同時更新間の調整を行います。この場合、最初の書き込み処理によって書き込まれたデータは失われます。アプリケーションがこれに対応できず、強い整合性が必要な場合は、別の書き込みパターンを使用して書き込み競合を回避します。

ローカル読み取り/グローバル書き込みパターン

グローバル書き込みパターンでは、グローバルな書き込み先となるリージョンを選択し、そのリージョンでのみ書き込みを受け付けます。DynamoDB グローバルテーブルは、引き続きデータをグローバルにレプリケートするための優れた選択肢です。ただし、ローカルで受信した書き込みリクエストがグローバル書き込みリージョンへリダイレクトされるようにする必要があります。

Amazon Aurora は別の良い選択です。Aurora グローバルデータベースとしてデプロイすると、プライマリクラスターはグローバル書き込みリージョンにデプロイされ、読み取り専用インスタンス（Aurora レプリカ）は他の AWS リージョンにデプロイされます。データはこれらの読み取り専用インスタンスにレプリケートされ、通常のレイテンシーは 1 秒未満です。Aurora グローバルデータベースの書き込み転送 (Aurora MySQL 互換エディションで利用可能) により、セカンダリクラスターの Aurora レプリカは、書き込み操作をグローバル書き込みリージョンのプライマリクラスターに転送できます。これにより、すべてのリージョンの読み取り専用レプリカを読み取り/書き込み可能であるかのように扱うことができます。Aurora グローバルデータベースの書き込み転送を使用すると、リクエストはパブリックインターネットではなく AWS ネットワークを経由するため、レイテンシーが削減されます。

Amazon ElastiCache for Redis は、リージョン間でデータをレプリケートすることもできます。たとえば、セッションデータを保存するには、グローバル書き込みリージョンに書き込み、 Global Datastore を使用して、このデータが他のリージョンから読み取れるようにします。

ローカル読み取り/パーティション書き込みパターン

世界中にユーザーがいる書き込みの多いワークロードでは、書き込みのたびにグローバル書き込みリージョンへの往復が発生するため、グローバル書き込みパターンがアプリケーションに適していない場合があります。これを軽減するには、パーティション書き込みパターンを使用することを検討してください。このパターンでは、各アイテムまたはレコードごとにホームリージョンが割り当てられます。これは、最初に書き込みが発生したリージョンに基づいて行うことができます。または、レコード内のパーティションキー (ユーザー ID など) に基づいて、このキーの値ごとにホームリージョンを事前に割り当てることもできます。図 3 では、ユーザーのレコードはホームリージョンとして左側の AWS リージョンに割り当てられます。レコードを、ほとんどの書き込みリクエストの発生場所に近いホームリージョンへマッピングすることが理想です。

図 3.マルチサイトアクティブ/アクティブ DR 戦略のためのローカル読み取り/パーティション書き込みパターン

図 3 のユーザーが自宅を離れて旅行に出掛けた場合、読み取りはローカルリージョンで実行されますが、書き込みはホームリージョンへルーティングされます。通常、書き込みはホームリージョンの近くから来ることが予想されるため、長い往復はかかりません。各レコードに割り当てられたホームリージョンで書き込みを受け付ける必要があるため、すべてのリージョンで書き込みが可能な DynamoDB グローバルテーブルはここでも良い選択肢です。

フェイルオーバー

マルチリージョンアクティブ/アクティブ戦略では、ワークロードがあるリージョンで動作できない場合、フェイルオーバーによって災害の影響を受けるリージョンから正常なリージョンへトラフィックがルーティングされます。Route 53 で DNS レコードを更新することでこれを実現できます。DNS リゾルバが変更を素早く反映して RTO 目標を満たせるように、これらのレコードの TTL (time to live) を十分に低く設定してください。または、ルーティングとフェイルオーバーに AWS Global Accelerator を使用することもできます。これは DNS に依存しません。AWS Global Accelerator では 2 つの静的 IP アドレスが提供されます。そして、トラフィックダイヤルと重みに基づいて、ユーザトラフィックが送信されるリージョンを設定します。

グローバル書き込みパターンを使用していてグローバル書き込みリージョンが災害の影響を受けた場合、別のリージョンを新しいグローバル書き込みリージョンに昇格させる必要があります。パーティション書き込みパターンを使用している場合、災害の影響を受けるリージョンをホームとするレコードが残りのリージョンのいずれかに割り当てられるように、ワークロードのパーティションを再設定する必要があります。ローカル書き込みパターンを使用すると、すべてのリージョンが書き込みを受け入れることができます。このパターンはデータストレージレイヤーに変更を加える必要がないため最速（ほぼゼロ）の RTO になります。

まとめ

最短の復旧時間（最小の RTO ）と最小のデータ損失（最小の RPO ）で DR を実現する必要がある場合は、ワークロードのマルチサイトアクティブ/アクティブ戦略を検討してください。サイトを最も分離して完全に独立させたい場合や、グローバルで多様なロケーションのユーザーに対してワークロードへの低レイテンシーアクセスを提供する必要がある場合は、複数のリージョン（マルチリージョン）にまたがって実装することが良い選択肢となります。

また、トレードオフも考慮してください。特にマルチリージョンを使用したこの戦略の実装と運用は、他の DR 戦略よりも複雑でコストが高くなる可能性があります。AWS でマルチリージョンのアクティブ/アクティブを実装する場合、ワークロードに適したルーティングポリシーや読み取り/書き込みパターンを選択するためのリソースをご利用いただけます。

Amazon Web Services ブログ