マルチリージョンの基本 4: 運用準備について

マルチリージョンワークロードの運用は、マルチリージョンアーキテクチャに固有の運用上の課題を伴う複雑なタスクです。これには、 AWS アカウント 管理、デプロイプロセスの更新、マルチリージョンオブザーバビリティ戦略の作成、復旧プロセスの作成とテスト、コストの管理が含まれます。運用準備レビュー (ORR) は、1 つのリージョンで実行されているか、複数のリージョンで実行されているかにかかわらず、チームが本番稼働用のワークロードを準備するのに役立ちます。

4.a: AWS アカウント 管理

ワークロードを にデプロイするには AWS リージョン、アカウント内のすべてのAWS のサービス クォータにリージョン間でパリティがあることを確認してください。まず、アーキテクチャの一部 AWS のサービス であるすべての を特定し、スタンバイリージョンで計画された使用量を確認し、計画された使用量を現在の使用量と比較します。場合によっては、スタンバイリージョンを以前に使用したことがない場合は、デフォルトのサービスクォータを参照して開始点を理解できます。次に、使用するすべてのサービスで、Service Quotas コンソール (ログインが必要) または APIs。

各リージョンで AWS Identity and Access Management (IAM) ロールを設定し、オペレータ、オートメーションツール、スタンバイリージョン内のリソースへの AWS のサービス 適切なアクセス許可を付与します。マルチリージョンアーキテクチャのリージョン分離を実現するには、リージョンごとにロールを分離します。スタンバイリージョンで稼働する前に、アクセス許可が設定されていることを確認してください。

4.b: デプロイのプラクティス

マルチリージョン機能を使用すると、ワークロードを複数のリージョンにデプロイするのが複雑になる可能性があります。一度に 1 つのリージョンにデプロイする必要があります。たとえば、アクティブ/パッシブアプローチを使用する場合は、最初にプライマリリージョンにデプロイしてからスタンバイリージョンにデプロイする必要があります。 は、インフラストラクチャを単一または複数のリージョンにデプロイするAWS CloudFormationのに役立ちます。また、必要に応じてカスタマイズできます。 は、パイプラインがあるリージョンとは異なるリージョンへのデプロイを許可するクロスリージョンアクションを持つ継続的インテグレーション/継続的デリバリー (CI/CD) パイプラインを構築するAWS CodePipelineのに役立ちます。これをブルー/グリーンなどの堅牢なデプロイ戦略と組み合わせると、最小限の場合、ダウンタイムがゼロのデプロイが可能になります。

ただし、アプリケーションまたはデータの状態が永続的ストアに外部化されていない場合、ステートフル機能のデプロイがより複雑になる可能性があります。このような場合は、ニーズに合わせてデプロイプロセスを慎重にカスタマイズしてください。複数のリージョンに同時にデプロイするのではなく、一度に 1 つのリージョンにデプロイするデプロイパイプラインとプロセスを設計します。これにより、リージョン間で相関する障害が発生する可能性が低くなります。Amazon がソフトウェアデプロイを自動化するために使用する手法については、 AWS 「ビルダーライブラリ」の記事「安全なハンドオフデプロイの自動化」を参照してください。

4.c: オブザーバビリティ

マルチリージョンを設計するときは、各リージョンのすべてのコンポーネントのヘルスをモニタリングして、リージョンのヘルスを包括的に把握する方法を検討してください。これには、レプリケーションラグのメトリクスのモニタリングが含まれる場合がありますが、これは単一リージョンのワークロードに関する考慮事項ではありません。

マルチリージョンアーキテクチャを構築するときは、スタンバイリージョンからのワークロードのパフォーマンスも監視することを検討してください。これには、スタンバイリージョンからヘルスチェックと Canary (合成テスト) を実行して、プライマリリージョンのヘルスの外部ビューを提供することが含まれます。さらに、Amazon CloudWatch Internet Monitor を使用して、エンドユーザーの観点から外部ネットワークの状態とワークロードのパフォーマンスを把握できます。プライマリリージョンは、スタンバイリージョンをモニタリングするために同じオブザーバビリティを備えている必要があります。

スタンバイリージョンの Canary は、ワークロードの全体的な状態を判断するために、カスタマーエクスペリエンスメトリクスをモニタリングする必要があります。これは、プライマリリージョンに問題がある場合、プライマリのオブザーバビリティが損なわれ、ワークロードの状態を評価する能力に影響する可能性があるため、必要です。

その場合、そのリージョンを外部から観察することでインサイトが得られます。これらのメトリクスは、各リージョンで使用できるダッシュボードと、各リージョンで作成されるアラームにロールアップする必要があります。CloudWatch はリージョン別サービスであるため、両方のリージョンでアラームを設定する必要があります。このモニタリングデータは、通話をプライマリリージョンからスタンバイリージョンにフェイルオーバーするために使用されます。

4.d: プロセスと手順

質問には、「いつフェイルオーバーすべきですか？」と答えるのが最適です。必要になるよりずっと前です。問題が発生する前に、人、プロセス、テクノロジーを含む復旧計画を定義し、定期的にテストします。リカバリの意思決定のフレームワークを決定しておきます。復旧プロセスが十分に実行されており、復旧までの時間が十分に理解されている場合は、RTO ターゲットを満たすフェイルオーバーを使用して復旧プロセスを開始できます。この時点は、プライマリリージョンのアプリケーションに関する問題が特定された直後か、リージョンのアプリケーション内の復旧オプションが使い果たされたときにさらにイベントになる可能性があります。

フェイルオーバーアクション自体は 100% 自動化する必要がありますが、フェイルオーバーをアクティブ化する決定は、通常は組織内の少数の事前定義された個人によって行われる必要があります。これらの担当者は、データの損失とイベントに関する情報を考慮する必要があります。また、フェイルオーバーの基準を明確に定義し、組織内でグローバルに理解する必要があります。これらのプロセスを定義して完了するには、ランブックを使用できますAWS Systems Manager 。ランブックを使用すると、end-to-endの完全な自動化が可能になり、テストとフェイルオーバー中に実行されるプロセスの一貫性が確保されます。

これらのランブックは、フェイルオーバーまたはフェイルバックプロセスを開始するために、プライマリリージョンとスタンバイリージョンで利用できる必要があります。この自動化が整ったら、定期的なテスト頻度を定義して実行します。これにより、実際のイベントが発生した場合、レスポンスは組織が信頼できる明確に定義された実践的なプロセスに従います。また、データ調整プロセスに対して確立された許容度を考慮することも重要です。提案されたプロセスが確立された RPO/RTO 要件を満たしていることを確認します。

4.e: テスト

テストされていない復旧アプローチを持つことは、復旧アプローチがないことと同じです。テストの基本レベルは、アプリケーションの運用リージョンを切り替える復旧手順を実行することです。これは、アプリケーションローテーションアプローチと呼ばれることがあります。リージョンを通常の運用体制に切り替える機能を構築することをお勧めします。ただし、このテストだけでは不十分です。

アプリケーションの復旧アプローチを検証するには、耐障害性テストも重要です。これには、特定の障害シナリオを挿入し、アプリケーションと復旧プロセスがどのように反応するかを理解し、テストが計画どおりに進まなかった場合に必要な緩和策を実装することが含まれます。エラーなしで復旧手順をテストしても、障害が発生したときにアプリケーションがどのように動作するかはわかりません。予想される障害シナリオに対して復旧をテストする計画を立てる必要があります。 AWS Fault Injection Serviceでは、開始するためのシナリオのリストが増えています。

これは、ビジネス継続性の目標を確実に達成するために厳格なテストが必要な高可用性アプリケーションにとって特に重要です。復旧機能をプロアクティブにテストすることで、本番環境で障害が発生するリスクが軽減され、アプリケーションが望ましい目標復旧時間を達成できるという確信が構築されます。定期的なテストでは運用上の専門知識も構築されるため、チームは停止が発生したときに迅速かつ確実に復旧できます。復旧アプローチのヒューマン要素またはプロセスを実行することは、技術的な側面と同様に重要です。

4.f: コストと複雑さ

マルチリージョンアーキテクチャのコストに与える影響は、インフラストラクチャの使用、運用のオーバーヘッド、およびリソース時間の上昇によって駆動されます。前述のように、スタンバイリージョンのインフラストラクチャコストは、事前プロビジョニング時のプライマリリージョンのインフラストラクチャコストと似ているため、合計コストが 2 倍になります。日常的なオペレーションには十分ですが、需要の急増を許容するために十分なバッファ容量を確保できるように容量をプロビジョニングします。次に、各リージョンで同じ制限を設定します。

さらに、アクティブ/アクティブアーキテクチャを採用する場合は、マルチリージョンアーキテクチャでアプリケーションを正常に実行するために、アプリケーションレベルの変更が必要になる場合があります。これらの変更は、設計と運用に時間がかかり、リソースを大量に消費する可能性があります。少なくとも、組織は各リージョンの技術的およびビジネス上の依存関係を理解し、フェイルオーバーとフェイルバックプロセスを設計するために時間を費やす必要があります。

また、チームは通常のフェイルオーバーとフェイルバックの演習を行って、イベント中に使用されるランブックに慣れる必要があります。これらの演習は、マルチリージョン投資から期待される成果を得るために不可欠ですが、機会コストを表し、他のアクティビティから時間とリソースを奪います。

4.g: 組織のマルチリージョンフェイルオーバー戦略

AWS リージョン は、相関障害を防ぎ、障害が発生したときの AWS のサービス 障害の影響を 1 つのリージョンに含む障害分離境界を提供します。これらの障害境界を使用して、各リージョンで独立した障害分離レプリカで構成されるマルチリージョンアプリケーションを構築し、共有された運命シナリオを制限できます。これにより、マルチリージョンアプリケーションを構築し、バックアップと復元、パイロットライト、アクティブ/アクティブなど、さまざまなアプローチを使用して、マルチリージョンアーキテクチャを実装できます。ただし、アプリケーションは通常単独では動作しないため、フェイルオーバー戦略の一環として使用するコンポーネントとその依存関係の両方を検討してください。一般的に、複数のアプリケーションが連携してユーザーストーリーをサポートします。これは、ソーシャルメディアアプリに写真や字幕を投稿したり、e コマースサイトでチェックアウトしたりするなど、エンドユーザーに提供される特定の機能です。このため、アプローチを成功させるために必要な調整と一貫性を提供する組織のマルチリージョンフェイルオーバー戦略を開発する必要があります。

マルチリージョンアプローチの指針として、組織が選択できる 4 つの大まかな戦略があります。これらは、最も詳細なアプローチから最も広範なアプローチまで一覧表示されます。

• コンポーネントレベルのフェイルオーバー

• 個々のアプリケーションのフェイルオーバー

• 依存関係グラフのフェイルオーバー

• アプリケーションポートフォリオ全体のフェイルオーバー

各戦略にはトレードオフがあり、フェイルオーバーの意思決定の柔軟性、フェイルオーバーの組み合わせをテストする機能、モーダル動作の存在、計画と実装における組織の投資など、さまざまな課題に対処します。各戦略の詳細については、 AWS ブログ記事「組織のマルチリージョンフェイルオーバー戦略の作成」を参照してください。

主なガイダンス

• すべての AWS のサービス クォータを確認して、ワークロードが動作するすべてのリージョンで同等であることを確認します。

• デプロイプロセスは、複数のリージョンを同時に含めるのではなく、一度に 1 つのリージョンをターゲットにする必要があります。

• レプリケーションラグなどの追加のメトリクスは、マルチリージョンシナリオに固有であり、モニタリングする必要があります。

• プライマリリージョンを超えてワークロードのモニタリングを拡張します。各リージョンのカスタマーエクスペリエンスメトリクスをモニタリングし、ワークロードが実行されている各リージョンの外部からこのデータを測定します。

• フェイルオーバーとフェイルバックを定期的にテストします。フェイルオーバープロセスとフェイルバックプロセス用に 1 つのランブックを実装し、テストイベントとライブイベントの両方に使用します。テストイベントとライブイベントのランブックは異なるものであってはなりません。

• フェイルオーバー戦略のトレードオフを理解します。依存関係グラフまたはアプリケーションポートフォリオ戦略全体を実装します。