可用性がスリーアンドハーフナイン (99.95%) で、復旧時間が 5～30 分
このアプリケーションの可用性目標を達成するには、非常に短いダウンタイムと、一定時間内のデータ消失を最小限に抑える必要があります。この可用性目標を持つアプリケーションには、銀行、投資サービス、緊急サービス、データキャプチャなどの分野のアプリケーションがあります。こういったアプリケーションの目標復旧時間および復旧時点は非常に短いです。
復旧時間をさらに短縮するには ウォームスタンバイ を 2 つの AWS リージョンにまたがるアプローチで使用します。パッシブサイトをスケールダウンし、すべてのデータの結果整合を保ちながら、ワークロード全体を両方のリージョンにデプロイします。両方のデプロイは リージョン内で 静的に安定した状態になります。このアプリケーションは、分散システムの回復パターンを使用して構築する必要があります。軽量の ルーティング コンポーネントを作成してワークロードの状態をモニタリングする必要があります。これは、必要に応じてトラフィックをパッシブリージョンにルーティングするように設定できます。
リソースをモニタリングする
ウェブサーバーの交換、データベースやリージョンのフェイルオーバーが発生した際には毎回アラートを発生させます。また、Amazon S3 で静的コンテンツの可用性をモニタリングし、利用不可になったときにアラートを出します。ログ記録の集約は、管理業務を容易にし、また各リージョンの根本原因の分析に役立ちます。
ルーティングコンポーネントは、アプリケーションの状態と、リージョンの強い依存関係の両方をモニタリングします。
需要の変化に対する適応方法
フォーナインのシナリオと同じ。
変更の実装
新しいソフトウェアの提供は、2～4 週間ごとの定期スケジュールで行われます。ソフトウェアの更新は、Canary デプロイやブルーグリーンデプロイパターンにより自動化されます。
ランブックは、リージョンのフェイルオーバーが発生した場合、これらのイベント中に発生した一般的な顧客の問題、通常のレポーティングのためにあります。
一般的なデータベースの問題、セキュリティ関連のインシデント、デプロイの失敗、リージョンのフェイルオーバーによる想定外の顧客の問題、問題の根本原因の究明に関するプレイブックもあります。根本原因がわかると、運用チームと開発チームが一体となってエラーの対応方法を決定し、その修正プログラムが完成したらデプロイを行います。
私たちは、Infrastructure Event Management の AWS Support とも連携しています。
データのバックアップ方法
99.99% のシナリオと同様に、RDS の自動バックアップを使用し、S3のバージョニングを使用しています。データは、アクティブリージョン内の Aurora RDS クラスターからパッシブリージョン内のクロスリージョンリードレプリカに自動的かつ非同期にレプリケートされます。S3 クロスリージョンレプリケーションは、データをアクティブリージョンからパッシブリージョンに自動的かつ非同期に移動するために使用されます。
弾力性のためのアーキテクト
フォーナインのシナリオと同じですが、リージョン間フェイルオーバーもできます。これは手動で管理されます。フェイルオーバーの間は、DNS フェイルオーバーによりリクエストを静的なウェブサイトにルーティングし、2 つ目のリージョンで復旧を行います。
回復力をテストする方法
フォーナインのシナリオと同じです。さらに、ランブックを使用してゲームデーを行い、アーキテクチャを検証します。即時の実装とデプロイのために、RCA の修正が機能リリースよりも優先されます。
災害対策 (DR) を計画する
リージョン間フェイルオーバーは手動で管理されます。すべてのデータは非同期にレプリケートされます。ウォームスタンバイの インフラストラクチャ はスケールアウトされます。これは、AWS Step Functions で実行されるワークフローを使用して自動化できます。Auto Scaling グループを更新してインスタンスのサイズを変更する SSM ドキュメントを作成できるため、AWSSystems Manager (SSM) もこの自動化に役立ちます。
可用性の設計目標
復旧を行うためには、少なくとも一部の障害では人間の判断が必要になると想定していますが、このシナリオでは自動化が進んでいるため、この判断が必要となるイベントは年間 2 回であると想定します。当社の推定では、復旧の実行を決定するまでに 20 分、復旧自体が 10 分以内に完了するとしています。この場合は障害から復旧するまでに 30 分かかることになります。年間で障害が 2 件発生すると仮定すると、その影響時間は年間 60 分と推定できます。
つまり、可用性の上限は 99.95% です。実際の可用性は、実際の障害発生率、障害の持続期間、各障害からの実際の復旧速度によっても異なります。このアーキテクチャでは、アプリケーションはオンラインで常に更新されていると想定しています。これに基づくと、 可用性の設計目標 は 99.95% です。
要約
| トピック | 導入 |
|---|---|
| リソースをモニタリングする | AWS リージョンレベルでのDNSのヘルスチェックやKPIを含む全レイヤーでのヘルスチェック、設定したアラームが作動した場合のアラート送信、すべての障害に対するアラート通知。傾向を検知し、目標設計を管理するために、運用ミーティングを厳格に実施。 |
| 需要の変化に対する適応方法 | ウェブと 自動スケーリング アプリケーション層の ELB; Aurora RDS のアクティブまたはパッシブリージョンでの、複数ゾーンのストレージとリードレプリカの自動スケーリング。静的安定性を実現するために AWS リージョン間で同期されたデータとインフラストラクチャ。 |
| 変更の実装 | Canary またはブルー/グリーンによる自動デプロイと、KPI またはアラートによってアプリケーションに未検出の問題があることが示された場合の自動ロールバック。デプロイは、一度に 1 つの AWS リージョンの 1 つの分離ゾーンに対して行われます。 |
| データのバックアップ方法 | RPO の要件を満たすための RDS を使用した AWS リージョンごとの自動バックアップと、ゲームデ―で定期的に実践している自動復元。Aurora RDS および S3 データは、アクティブリージョンからパッシブリージョンに自動的かつ非同期的にレプリケートされます。 |
| 弾力性のためのアーキテクト | 自動スケーリングによる自己修復可能なウェブおよびアプリケーション層の提供。Multi-AZ の RDS。フェイルオーバー時に提示された静的サイトを使用してリージョンのフェイルオーバーを実施。 |
| 回復力をテストする方法 | コンポーネントと分離ゾーンの障害のテストをゲームデーに定期的に運用スタッフと一緒にパイプラインで実践。不明な問題の診断のためのプレイブックと根本原因分析プロセスが存在。問題の内容とその修正方法または予防方法の通信経路。即時の実装とデプロイのために、RCA の修正を機能リリースよりも優先。 |
| 災害対策 (DR) を計画する | 別のリージョンにデプロイされたウォームスタンバイ。インフラストラクチャは、 AWS Step Functions または AWS Systems Manager ドキュメントを使用して実行されるワークフローを使用してスケールアウトされます。RDS 経由の暗号化されたバックアップ。2 つの AWS リージョン間のクロスリージョンリードレプリカ。Amazon S3 での静的アセットのクロスリージョンレプリケーション。現在の有効な AWS リージョンへの復元を AWS と連携してゲームデ―に実践。 |
