99.99% のシナリオ - 信頼性の柱

99.99% のシナリオ

このアプリケーションの可用性目標を達成するには、アプリケーションはコンポーネント障害に対する耐性を持つ必要があります。アプリケーションは、追加のリソースを取得することなく障害を吸収できなければなりません。この可用性目標のレベルは、E コマースサイト、B to B ウェブサービス、または高トラフィックのコンテンツ/メディアサイトなど、企業にとって主要または重要な収益源となるミッションクリティカルなアプリケーションが対象です。

リージョン内で静的に安定しているアーキテクチャを使用することで、可用性をさらに 向上させる ことができます。この可用性目標のレベルでは、障害に耐えるためにワークロードの動作をコントロールプレーンで変更する必要はありません。たとえば、アベイラビリティーゾーンが 1 つ使用不可になっても耐えられるだけの十分な容量が必要です。Amazon Route 53 DNS の更新は必要ありません。S3 バケットの作成および変更、新しい IAM ポリシーの作成 (ポリシーの変更)、Amazon ECS タスク設定の変更などを問わず、新しいインフラストラクチャを作成する必要はありません。

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

モニタリングは、問題発生時のアラートだけでなく、オペレーションが成功したときのメトリクスも対象です。さらに、障害が発生したウェブサーバーがリプレイスしたときやデータベースがフェイルオーバーしたとき、またアベイラビリティゾーンに障害が発生したときには、アラートが出るようにします。

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

Amazon Aurora を RDS として使用して、リードレプリカの Auto Scaling を有効にします。これらのアプリケーションでは、プライマリコンテンツの書き込み可用性よりも読み取り可用性を優先して設計することも重要なアーキテクチャの判断となります。また、Aurora は、必要に応じて 10 GB 単位で最大 64 TB までストレージを自動的に拡張することもできます。

変更の実装

ここでは、Canary デプロイまたはブルーグリーンデプロイを用いて、分離した各ゾーンにそれぞれアップデートを展開します。このデプロイは、KPI に問題がある場合のロールバックをはじめ、完全に自動化されています。

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

ウェブサイトを構築および運用するチームは、想定外の障害が発生した場合にその対応方法を決定し、実装後にデプロイする修正の優先順位付けをします。

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

データのバックアップと復元には、Amazon RDS を使います。復旧要件を確実に満たすため、これはランブックを使用して定期的に実行されます。

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

このアプローチにはアベイラビリティーゾーンを 3 つ使用することを推奨します。3 つのアベイラビリティーゾーンをデプロイした場合、各ゾーンの静的キャパシティはピーク時の 50 %になります。アベイラビリティーゾーンを 2 つにすることも可能ですが、静的に安定した容量のコストが高くなります。これは両方のアベイラビリティーゾーンがピーク時と同じ 100% のキャパシティーである必要があるためです。ここでは Amazon CloudFront を追加して、地理的なキャッシュとアプリケーションのデータプレーン上のリクエストを削減します。

RDS として Amazon Aurora を使用し、3 つのゾーンすべてにリードレプリカをデプロイします。

アプリケーションは、すべてのレイヤーでソフトウェア / アプリケーションの回復パターンを使用して構築されます。

回復力をテストする方法

デプロイパイプラインには、パフォーマンス、負荷、障害注入テストなどの一連の完全なテストが含まれます

私たちは、手順を逸脱することなくタスクを実行できるように、ランブックを使用しながら、ゲームデーを通して障害復旧手順を定期的にテストします。ウェブサイトを構築するチームは、ウェブサイトの運用も行っています。

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

ランブックは、ワークロード全体の回復と共通レポートのためにあります。復旧では、ワークロードと同じリージョンに保存されているバックアップを使用します。復元手順は、ゲームデーの一環として定期的に実施されます。

可用性の設計目標

復旧を行うには、少なくとも一部の障害では人間の判断が必要になると想定していますが、このシナリオでは自動化が進んでいるため、この判断が必要となるイベントは年間 2 回であり、復旧対応は迅速に行うことができると想定します。当社の推定では、復旧の実行を決定するまでに 10 分、復旧自体が 5 分以内に完了するとしています。この場合は障害から復旧するまで 15 分かかることになります。年間で障害が 2 件発生すると仮定すると、その影響時間は年間 30 分と推定できます。

つまり、可用性の上限は 99.99% です。実際の可用性は、実際の障害発生率、障害の持続期間、各障害からの実際の復旧速度によっても異なります。このアーキテクチャでは、アプリケーションはオンラインで常に更新されていると想定しています。これに基づくと、 可用性の設計目標 は 99.99% です。

要約

トピック 導入
リソースをモニタリングする すべてのレイヤーと KPI に関するヘルスチェック、設定されたアラーム作動時にアラート送信、すべての障害時にアラート通知。傾向を検知し、目標設計を管理するために、運用ミーティングを厳格に実施。
需要の変化に対する適応方法 ウェブと自動スケーリングアプリケーション層の ELB; Aurora RDSの複数のゾーンでのストレージとリードレプリカの自動スケーリング。
変更の実装 KPI またはアラートがアプリケーション内の未検出の問題を示しているときは、自動デプロイ (カナリアまたはブルーグリーン) と自動ロールバックを実施。分離ゾーンでデプロイ。
データのバックアップ方法 RPO の要件を満たすための RDS を使用した自動バックアップ、ゲームデ―に定期的に自動復元を実践。
弾力性のためのアーキテクト アプリケーションの障害切り離しゾーンを実装。Auto Scaling による自己修復可能なウェブおよびアプリケーション層の提供。Multi-AZ の RDS。
回復力をテストする方法 コンポーネントと分離ゾーンの障害のテストをゲームデーに定期的に運用スタッフと一緒にパイプラインで実践。不明な問題の診断のためのプレイブックと根本原因分析プロセスが存在。
災害対策 (DR) を計画する ゲームデーで実践しているのと同じ AWS に RDS 経由で暗号化バックアップ。