ファイブナイン (99.999%) 以上のシナリオで、復旧時間が 1 分未満

このアプリケーションの可用性目標を達成するには、ダウンタイムや一定時間内のデータロスがほぼゼロである必要があります。この可用性目標を持つアプリケーションには、非常に大きな収益を生み出すビジネスの中核となる、一部の銀行、投資サービス、ファイナンス、政府機関、その他の重要なビジネスアプリケーションなどがあります。求められているのは、極めて一貫性が高いデータストアと、全レイヤーにおける完全な冗長性です。当社では、SQL ベースのデータストアを選択しています。しかし、RPO を極端に短くすることが困難となるシナリオもあります。データをパーティションに分割すれば、データロスをなくすことができるかもしれません。そのためには、地理的に離れたロケーション間のデータの整合性を保つためにパーティション間でデータの移動またはコピーする機能を加える必要が出てくると共に、アプリケーションロジックとレイテンシーを加える必要が出てくるかもしれません。NoSQL データベースを使用した方が、このパーティション化は容易に行えるかもしれません。

さらに可用性を向上させるには、 Active-Active 複数の AWS リージョンにまたがるアプローチ。ワークロードは、 リージョン内で 静的に安定しているすべての希望するリージョンにデプロイされます (したがって、残りのリージョンは 1 つのリージョンが失われても負荷を処理できます)。A ルーティング 層は、トラフィックを正常な状態の地理的ロケーションに向け、そのロケーションに異常があれば自動的に宛先を変更したり、データレプリケーション層を一時的に停止させたりします。Amazon Route 53 では 10 秒間隔でヘルスチェックを行っており、TTL を最低 1 秒に設定することも可能です。

リソースをモニタリングする

スリーアンドハーフナインのシナリオと同じです。さらに、リージョンが異常であると検出され、トラフィックがそのリージョンからルーティングされた場合にアラームが送信されます。

需要の変化に対する適応方法

スリーアンドハーフナインのシナリオと同じです。

変更の実装

デプロイメントパイプラインには、パフォーマンス、負荷、障害注入テストなどの一連の完全なテストが含まれます。アップデート時には、Canary デプロイまたはブルーグリーンデプロイを用いて、分離された各ゾーンに対し1箇所ずつ順番にアップデートをデプロイし、1つのリージョンが完了してから別のリージョンで開始します。このデプロイを行う間は、ロールバックを高速化するために、旧バージョンが引き続きインスタンスで実行されます。これらの作業は、KPI に問題があった場合のロールバックを含め、完全に自動化されています。モニタリングは、問題発生時のアラートだけでなく、オペレーションが成功したときのメトリクスも対象です。

ランブックは、厳密なレポート要件とパフォーマンス追跡のためのものです。成功したオペレーションが、パフォーマンスまたは可用性の目標を達成できない傾向がある場合は、プレイブックを使用してトレンドの原因を特定します。プレイブックは、未発見の障害モードやセキュリティインシデントのためのものです。また、障害の根本原因を明らかにするためのプレイブックもあります。

ウェブサイトを構築するチームは、ウェブサイトの運用も行っています。このチームは、想定外の障害が発生した場合にその対応方法を決定し、実装後に適用する修正の優先順位付けをします。私たちは、Infrastructure Event Management の AWS Support とも連携しています。

データのバックアップ方法

スリーアンドハーフナインのシナリオと同じです。

弾力性のためのアーキテクト

このアプリケーションは、ソフトウェア / アプリケーションの回復パターンを使用して構築する必要があります。求められる可用性を実現するため、さらに多くのルーティングレイヤーが必要となる可能性があります。この実装の追加による複雑性は、過小評価してはいけません。このアプリケーションは障害が伝搬しないよう分離されデプロイされた各ゾーンに実装され、パーティション化してデプロイされ、顧客にリージョン規模の障害からの影響が顧客に及ばないようにしています。

回復力をテストする方法

私たちは、手順を逸脱することなくタスクを実行できるように、ランブックを使用しながら、ゲームデーを通してアーキテクチャを検証します。

災害対策 (DR) を計画する

Active-Active 完全なワークロードインフラストラクチャとデータが複数のリージョンにある、アクティブ/アクティブマルチリージョンデプロイ。ローカル読み取り、グローバル書き込みの戦略を使用して、1 つのリージョンがすべての書き込みのプライマリデータベースになり、他のリージョンへの読み取り用にデータがレプリケートされます。プライマリ DB リージョンに障害が発生した場合、新しい DB を昇格させる必要があります。ローカル読み取り、グローバル書き込みには、DB 書き込みが処理されるホームリージョンに割り当てられたユーザーがいます。これにより、ユーザーは任意のリージョンから読み書きできますが、異なるリージョンでの書き込み間で発生する可能性のあるデータの競合を管理するには、複雑なロジックが必要です。

リージョンが異常ありと検出された場合、ルーティングレイヤーはトラフィックを残りの正常なリージョンに自動的にルーティングします。手動による介入は必要ありません。

データストアは、潜在的な競合を解決できる方法でリージョン間のレプリケートを行う必要があります。レイテンシーの理由から、パーティション間でデータをコピーまたは移動して各パーティション内のリクエストまたはデータ量のバランスをとるために、ツールおよび自動化プロセスを作成する必要があります。データ競合解決のための修正には、運用のためのランブックも追加する必要があります。

可用性の設計目標

すべての復旧作業の自動化に多額の投資をすると、復旧は 1 分以内に完了すると想定しています。手動による復旧は想定しておらず、四半期ごとに最大 1 回の自動復旧があると想定しています。この場合は障害から復旧するまで 4 分かかることになります。アプリケーションはオンラインで常にアップデートされていると想定しています。これに基づくと、 可用性の設計目標 は 99.999% です。

要約

トピック	導入
リソースをモニタリングする	AWS リージョンレベルでのDNSのヘルスチェックやKPIを含む全レイヤーでのヘルスチェック、設定したアラームが作動した場合のアラート送信、すべての障害に対するアラート通知。傾向を検知し、目標設計を管理するために、運用ミーティングを厳格に実施。
需要の変化に対する適応方法	ウェブと自動スケーリングアプリケーション層の ELB。 Aurora RDSのアクティブまたはパッシブリージョンでの、複数のゾーンでのストレージとリードレプリカの自動スケーリング。静的安定性を実現するために AWS リージョン間で同期されたデータとインフラストラクチャ。
変更の実装	Canary またはブルー/グリーンによる自動デプロイと、KPI またはアラートによってアプリケーションに未検出の問題があることが示された場合の自動ロールバック。デプロイは、一度に 1 つの AWS リージョンの 1 つの分離ゾーンに対して行われます。
データのバックアップ方法	RPO の要件を満たすための RDS を使用した AWS リージョンごとの自動バックアップと、ゲームデ―で定期的に実践している自動復元。Aurora RDS および S3 データは、アクティブリージョンからパッシブリージョンに自動的かつ非同期的にレプリケートされます。
弾力性のためのアーキテクト	アプリケーションの障害切り離しゾーンを実装。Auto Scaling による自己修復可能なウェブとアプリケーション層の提供。Multi-AZ の RDS。リージョンのフェイルオーバーの自動化。
回復力をテストする方法	コンポーネントと分離ゾーンの障害のテストをゲームデーに定期的に運用スタッフと一緒にパイプラインで実践。不明な問題の診断のためのプレイブックと根本原因分析プロセスが存在。問題の内容とその修正方法または予防方法の通信経路。即時の実装とデプロイのために、RCA の修正を機能リリースよりも優先。
災害対策 (DR) を計画する	少なくとも 2 つのリージョンにデプロイされたアクティブ/アクティブ。インフラストラクチャは完全にスケーリングされ、リージョン間で静的に安定しています。データはリージョン間でパーティション分割され、同期されます。RDS 経由の暗号化されたバックアップ。リージョンの障害はゲームデーで実施され、AWS と連携します。復元中に、新しいプライマリデータベースへの昇格が必要になる場合があります。