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

99.9% のシナリオ

次に高いレベルの可用性が求められるのは、求められる可用性は高くても、短い期間であればサービス停止に耐えられるアプリケーションです。このタイプのワークロードは、通常、ダウンタイムによる影響を受けるのが従業員であるような内部運用で使用されます。ビジネスの収益性は高くありませんが、より長い復旧時間や復旧時点を許容できれば、このタイプのワークロードは顧客向けにもできます。このようなワークロードには、アカウント管理または情報管理のためのアプリケーションなどがあります。

アベイラビリティーゾーンを 2 つ使用してデプロイし、アプリケーションを個別の階層に分離することで、ワークロードの可用性を向上させることができます。

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

ホームページで HTTP 200 OK ステータスをチェックすると、モニタリング機能が拡張されてウェブサイト全体の可用性を監視します。さらに、ウェブサーバーを交換したとき、またはデータベースがフェイルオーバーしたときにはアラートを出します。また、Amazon S3 で静的コンテンツの可用性をモニタリングし、利用不可になったときにアラートを出します。ログ記録の集約は、管理業務を容易にし、また根本原因の分析に役立ちます。

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

自動スケーリング は、EC2 インスタンスの CPU 使用率をモニタリングし、インスタンスを追加または削除して CPU ターゲットを 70% に維持するように設定されていますが、アベイラビリティーゾーンごとに EC2 インスタンスが 1 つしかありません。RDS インスタンスの負荷パターンからスケールアップが必要であることが示されている場合、メンテナンスウィンドウ中にインスタンスタイプを変更します。

変更の実装

インフラストラクチャのデプロイテクノロジーは、前のシナリオと同じです。

新しいソフトウェアの提供は、2~4 週間ごとの定期スケジュールで行われます。ソフトウェアのアップデートは Canary デプロイ やブルーグリーンデプロイのパターンではなく、一括の置き換えによって自動化されます。ロールバックをする判断は、ランブックに従って行います。

問題の根本原因を特定するためにプレイブックがあります。根本原因がわかると、運用チームと開発チームが一体となってエラーの修正方法を特定します。修正は、それが開発された後で反映されます。

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

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

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

アベイラビリティーゾーンを 2 つ使用してデプロイメントを行い、アプリケーションを個別の階層に分離することで、アプリケーションの可用性を向上させることができます。AWS Key Management Service を介して暗号化されたストレージを備えた Elastic Load Balancing、Auto Scaling、Amazon RDS マルチ AZ などの複数のアベイラビリティーゾーンで動作するサービスを使用します。これにより、リソースレベルおよびアベイラビリティーゾーンレベルの耐障害性を持つことができます。

ロードバランサーは、正常なアプリケーションインスタンスにのみトラフィックをルーティングします。ヘルスチェックは、インスタンス上のアプリケーション機能を示すデータプレーン / アプリケーションレイヤーで行う必要があります。制御プレーンに対してこのチェックを行うことはできません。ウェブアプリケーションのヘルスチェック URL は、ロードバランサーと Auto Scaling による使用のために存在し設定されます。これにより障害が発生したインスタンスが削除および置き換えられます。Amazon RDS は、プライマリアベイラビリティーゾーンでインスタンスに障害が発生した場合に 2 番目のアベイラビリティーゾーンで使用できるアクティブなデータベースエンジンを管理し、修復して同じ弾力性に復元します。

サービスの階層を分離し、分散システムの回復パターンを適用します。例えばアベイラビリティーゾーンのフェイルオーバーでデータベースが一時的に使用不能になった場合でもアプリケーションを使用できるようにします。これにより、アプリケーション全体の信頼性を向上させます。

回復力をテストする方法

前のシナリオと同じように、機能テストを行います。ELB、Auto Scaling 、RDS フェイルオーバーの自己修復機能はテストしません。

私たちは、一般的なデータベースの問題、セキュリティ関連のインシデント、失敗したデプロイについてのプレイブックを持つことになります。

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

ランブックは、ワークロード全体の回復と共通レポートのためにあります。復旧では、ワークロードと同じリージョンに保存されているバックアップを使用します。

可用性の設計目標

私たちは、障害のなかには復旧作業を手動で行わざるを得ないケースもあると考えています。ただしこのシナリオでは自動化が進んでいるため、手動の作業が必要なイベントは年間に 2 回のみと想定しています。当社の推定では、復旧の実行を決定するまでに 30 分、復旧自体が 30 分以内に完了するとしています。この場合は障害から復旧するまで 60 分かかることになります。年間で障害が 2 件発生すると仮定すると、その影響時間は年間 120 分です。

つまり、可用性の上限は 99.95% です。実際の可用性は、実際の障害発生率、障害の持続期間、各障害からの実際の復旧速度によっても異なります。このアーキテクチャでは、プログラム更新のためにアプリケーションを一時的にオフラインにする必要がありますが、この更新作業は自動化されています。これについては年間 150 分、更新作業ごとに 15 分、年間 10 回と推定します。これによってサービスが利用できない時間は年間 270 分であるため 可用性の設計目標 は 99.9% です。

要約

トピック 導入
リソースをモニタリングする サイトのヘルスチェックのみ、ダウンのアラート送信。
需要の変化に対する適応方法 ウェブと Auto Scaling アプリケーション層の ELB、マルチ AZ RDS のサイズ変更。
変更の実装 一括自動デプロイ、ロールバックに関するランブック。
データのバックアップ方法 RPO の要件を満たすための RDS を使用した自動バックアップ、復元に関するランブック。
弾力性のためのアーキテクト Auto Scaling による自己修復可能なウェブおよびアプリケーション層の提供、マルチ AZ の RDS。
回復力をテストする方法 ELB、自己修復可能なアプリケーション、Multi-AZ の RDS、明示的なテストなし
災害対策 (DR) を計画する 同じ AWS リージョンへ RDS 経由で暗号化バックアップ