ゾーンとリージョンをまたぐ可用性を選ぶ

利用者の操作から始める

高可用性（HA）は、コンポーネントが故障してもサービスを利用できる状態に保つことを目指します。アーキテクチャを選ぶ前に、利用可能とは何かを定めます。予約ページが開いても、すべての予約リクエストが失敗するなら、予約サービスは利用可能とはいえません。

重要な操作に対し、サービスレベル目標（SLO）を設定します。どのリクエストを数え、何を成功とし、どの期間を測るかを定めます。クラウドサービスのSLAは、提供者の約束を示します。自分たちのアプリで測定した可用性を示すものではありません。

例として、時間に基づく99.9%の可用性では、30日間の月に43.2分の利用不能時間を許容します。リクエストに基づくSLOでは、分母が異なります。どちらも、許容できるデータ損失量を示さず、個々の停止時間の上限も保証しません。

障害の範囲を理解する

AWS Availability Zone（AZ）は、リージョン内の分離されたインフラ拠点です。一つのリージョンに複数のAZがあります。マルチリージョン設計は、ワークロードのコンポーネントを複数のリージョンに分散します。他の提供者では、独自の境界とサービスの動作があります。選んだサービスを調べてください。

これは設計上の可能性であり、可用性の保証ではありません。構成の名前だけでは、必要なすべてのコンポーネントが意図した境界を使う証拠になりません。

リクエスト経路全体を追跡する

架空の予約サービスを考えます。Webレプリカは二つのAZで稼働しています。どちらも、AZ Aにある一つのデータベースと一つの外向きゲートウェイを使います。ゲートウェイは決済サービスの呼び出しに必要です。

AZ Aが故障すると、AZ BのWebレプリカは正常なままでも、予約に失敗する可能性があります。データベース、ネットワーク経路、IDプロバイダー、決済の依存先、ルーティングを評価する必要があります。マネージドデータベースの実際のモードを調べてください。レプリケーション、フェイルオーバー、読み取り側の動作は、製品と設定で変わります。

処理能力も確認します。残ったリソースが必要な負荷を処理できなければなりません。インシデント中に処理能力を追加する設計は、クォータ、利用可能なリソース、コントロールプレーンの操作に依存します。

範囲、停止条件、責任者を定めた管理下の演習を行います。決済の照合も含め、予約全体を検証します。失敗したリクエストと、利用できる状態に復旧するまでの時間を記録します。

別のリージョンで問題を解決できるか判断する

マルチリージョン運用では、データ転送、リソースの重複、デプロイの調整、運用作業が増えます。active/passiveは、一方の環境をトラフィックの受け入れに備えて待機させます。active/activeは、複数の環境でトラフィックを処理します。必要な準備状態とデータの動作は異なります。

予約サービスで並行して書き込むと、二つのリージョンが同じ座席を販売できてしまわないか、という問いが生じます。予約の確定権限と、レプリケーション中断時の動作を定めます。「データベースを複製する」だけでは、完全な答えになりません。

許可されたデータの保管場所、暗号鍵、証明書、DNS、シークレット、外部サービスを確認します。共有のIDサービスの障害や不適切なリリースは、複数のリージョンに影響する可能性があります。拠点を増やしても、共通原因がすべてなくなるわけではありません。

可用性と復旧を結び付ける

HAは、運用中の特定の障害を扱います。災害復旧は、大きな障害の後に利用可能なサービスとデータを復元します。マルチリージョンのサービスでも、削除やデータ破損に備える復旧計画が必要です。

対応する障害シナリオと、事業として受け入れるシナリオを文書化します。アプリの変化に合わせ、テストとインフラ定義の整合性を保ちます。次にRTO、RPO、災害復旧を学んでください。