re:Invent 2023: AWSレジリエンスチームが語るFault Injection Serviceによるシステム強化
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2023 - Improve application resilience with AWS Fault Injection Service (ARC317)
この動画では、AWS Reliability TeamのAdrian HornsbyとIris Sheuが、システムのレジリエンス向上について語ります。ダウンタイムのコストや影響、障害分離境界の重要性、そしてAWS Fault Injection Serviceを使ったテスト方法を詳しく解説します。特に注目なのは、マルチAZアプリケーションとマルチリージョンアプリケーションをテストする新しいシナリオの紹介です。レジリエンスの構築に関心のあるエンジニアにとって、具体的な実践方法を学べる貴重な内容となっています。 ※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
本編
AWS Fault Injection Serviceの紹介と本セッションの概要
みなさん、こんにちは。お元気ですか？大丈夫ですか？このセッションの後もお元気でいられることを願っています。ここまでお越しいただき、ありがとうございます。MGMは他の場所からかなり離れていますので、ここまで来てくださった皆さん全員に10ポイント差し上げます。少なくとも私たちだけではないので、素晴らしいですね。
私はAdrian Hornsbyと申します。AWS Reliability Teamのプリンシパルエンジニアです。私たちはAWS Fault Injection Serviceを担当しています。11月15日までは Simulatorと呼ばれていましたが、より分かりやすくするためにServiceに名称変更しました。今日は私たちのチームのシニアプロダクトマネージャーであるIris Sheuも同席しています。彼女は本日の発表について少しお話しします。本日の発表をご覧になっていない方のために言いますと、マルチAZアプリケーションとマルチリージョンアプリケーションをテストするための一連のシナリオを立ち上げました。彼女がこれらについて詳しく説明します。
ダウンタイムのコストとその影響
これらの詳細に入る前に、レジリエンスの重要性と、なぜ今日これらのシナリオを立ち上げたのかについて少しお話ししたいと思います。まず、シンプルな質問から始めましょう。ダウンタイムのコストはいくらでしょうか？おおよそいくらかかるか、誰か想像がつく方はいますか？高いですね。非常に高額です。数百万ドルです。実際、最近の調査によると、企業の約91%で1時間のダウンタイムのコストは約30万ドルだそうです。そのうちの44%の企業では、100万ドルにまで上昇します。さらに18%の企業では、500万ドルを超えるそうです。ダウンタイムのコストについて考えたことがない方のために言うと、一般的な平均は1分あたり1万ドルくらいです。
もう一つ非常に興味深い数字があります。定期的にダウンタイムを経験している場合、そのコストは、ダウンタイムが少ない企業と比べて約16倍高くなる可能性があるのです。想像以上に高額ですが、ダウンしている間には多くの影響があり、それについて少しお話しします。
企業がダウンタイムを心配する理由は非常に分かりやすいですね。ダウンタイムには多くの影響があります。もちろん、顧客は喜びませんが、収益の損失もあります。コンプライアンスにも影響を与える可能性があり、これは非常に深刻な問題になり得ます。株価にも影響を与える可能性があり、採用プロセスにも影響します。ビジネスチャンスも逃してしまいます。しかし、ここにはもう少し厄介なことがあります。ダウンタイムはブランドにも影響を与えるのです。Will Rogersの有名な言葉に「良い評判を築くには一生かかるが、失うのは一瞬だ」というものがあります。
これは非常によくある問題です。特に最近では、さまざまなアプリケーションや競合するビジネスが多数存在します。顧客の注目を集めるためには、ダウンタイムが長いと、通常、顧客は他の場所で何か別のものを探そうとします。そうなると、彼らをあなたのプラットフォームに呼び戻すのは非常に難しくなります。そのため、ダウンタイムは非常に重要であり、避けるのは困難です。実際のところ、ダウンタイムを完全に避けることはほぼ不可能だと言えるでしょう。なぜなら、私たちは複雑なシステムを扱っているからです。
複雑なシステムと失敗への対処
複雑なシステムというと、人々は非常に広範で大規模な分散システムに関連していると考えがちですが、実際はそれだけではありません。むしろ、非常にシンプルなクライアント・サーバーアプリケーションでさえ、実際には複雑なシステムだと私は主張します。考えてみてください。失敗の可能性がある組み合わせは多数存在します。例えば、クライアントがメッセージを作成し、ネットワーク経由で送信する必要があります。ネットワークはそのメッセージをサーバーに届ける必要があります。サーバーは通常、メッセージを検証し、データストアの状態を更新し、応答を作成してネットワークに送信する必要があります。ネットワークはそれをクライアントに届けます。クライアントは検証を行い、場合によってはローカルの状態も更新します。
ここで問題が発生する可能性のある箇所は数多くあります。ネットワークが遅くなったり、レイテンシーが発生したり、パケットロスが起きたりする可能性があります。検証メカニズムが失敗したりエラーを投げたりする可能性もあります。データストアが混雑していたり、オープンな接続が多すぎて書き込めずに失敗する可能性もあります。このような小規模な計算システムでさえ、失敗の組み合わせは実に驚くべき数に上ります。クラウドやハイブリッド環境、あるいはその他の環境で広範な分散システムを構築する場合、それは本当に複雑で、失敗の可能性は非常に多くなります。
では、失敗を避けるにはどうすればよいのでしょうか？実は、避けることはできません。このプレゼンテーションを要約するなら、失敗は避けられないということです。失敗は必ず起こり、時間が経てばすべてのものは失敗する、とCTOのDr. Werner Vogelsがよく言っているように。そこで疑問が生じます：失敗にどう対処するか、あるいは失敗の影響をどのように軽減するか？「Resilience Engineering in Practice」という非常に興味深い本があり、著者たちはレジリエンスを4つの柱に分類しています：予測、モニタリング、対応、学習です。
予測とは、あらゆる失敗のシナリオを考え出し、レジリエントなシステムを設計することです。モニタリングは、失敗のシナリオ中に何が起こっているかを理解することです。多くの方が、適切なアラームやモニタリングがない状態で障害を経験したことがあるでしょう。対応とは、失敗から回復するために何をすべきかを理解しようとすることです。これは簡単ではありません。時には、非常に複雑なシステムで、Tier 0アプリケーションを復旧させ、その後Tier 1、2、3を順番に復旧させるといった一連のイベントが必要になることがあります。時には、あるシステムが別のダウンしているシステムに依存していることに気づき、循環依存に陥ることもあります。これらもレジリエントなシステムの側面です。
学びとは、障害の後に座って何が起こったのかを理解し、それを意味づけ、ベストプラクティスを導き出すことです。できれば、組織全体でそれを共有し、皆が学べるようにします。これはレジリエントなシステムを考える上で良い方法です。なぜなら、私たちはレジリエントなシステムを技術そのものとしてのみ考えがちですが、実際には文化、メカニズム、ツールの全スペクトルが関わっているからです。
AWS resilience lifecycle frameworkと障害分離境界
私たちはレジリエンスの4つの基本要素を取り上げ、AmazonとAWSでどのようにレジリエンスを実現してきたか、そして顧客がどのように実現しているかを考えました。そして、AWS resilience lifecycle frameworkと呼ばれるものを考案しました。このフレームワークは、これらのステップを通じてシステムのレジリエンスを向上させる方法を理解しようとする、継続的なレジリエンスプロセスです。まず目標設定から始まります。当たり前のように聞こえますが、実際には私たちはレジリエントなシステムが必要な理由や、ビジネス目標が何であるかを本当に理解していないことがよくあります。99.99%の可用性のためでしょうか？ライブイベントのためでしょうか？新機能のためでしょうか？
次に、設計と実装、評価とテスト、観察、対応、学習へと進みます。これはライフサイクルです。興味深いのは、企業内では、チームによってこのライフサイクルの異なるレベルにいる可能性があることです。深く進んでいるチームもあれば、始めたばかりのチームもあります。どこかから始めることもあります。必ずしも目標設定から始めるとは限りません。問題が発生して再発防止のために考え始める必要があるため、テストから始めることもあります。議論と修正の試みは通常、目標設定の会話につながります。このライフサイクルはいつでも参加できます。ちなみに、このライフサイクルにアクセスできます。私たちはこれをドキュメントで公開しています。
今日のプレゼンテーションでは、AWS resilience lifecycle frameworkの設計、実装、評価、テストのフェーズにより焦点を当てます。 レジリエントなシステムを設計する上で、おそらく最も重要な部分は 障害分離境界について考えることです。先ほど言ったように、障害は必ず発生します。障害から回復するための戦略は2つあります。1つ目は非常に速く回復できることです。つまり、回復を練習することです。2つ目はワークロードへの影響を最小限に抑えることです。顧客への影響を制限しようとします。ここで障害分離境界が効果を発揮します。
障害分離境界は、船の隔壁に似ています。船の一部に穴が開いても、船全体ではなく、その一部だけが水で満たされます。ここでのアイデアも同様です。システムを影響範囲のドメインという観点で考えようとしています。これは非常に興味深い特性を持っています。ワークロードの分離、障害の封じ込め、そしてより重要なのは、境界のサイズが非常に限定されているため、その特定の境界を理解し、テストし、その限界を理解し、可能であれば水平方向に複製できることです。ここでのテスト可能性は非常に興味深いです。
RegionとAvailability Zoneの概要とマルチAZアプリケーション
私たちが最もよく使用する分離境界は、RegionとAvailability Zoneです。世界中に32のRegionと102のAvailability Zoneがあります。通常、1つのRegionには3つ以上のAvailability Zoneがあります。Availability Zoneは、電力、通信、ネットワークが独立した複数のデータセンターの集まりです。一般的に、1つのRegion内のAZは約100キロメートル離れていますが、AZ間で一桁ミリ秒台のレイテンシーを実現できる程度の距離に抑えられています。これは、一部のリージョナルサービスで同期レプリケーションを行うためです。
AZは互いに非常に独立しています。それぞれが異なる電力システム、ネットワーク、冷却システムを持ち、竜巻、地震、停電などの問題に耐えることができます。これらは、私たちが持つ最も一般的に使用される障害分離境界です。これらの境界を利用したい場合、おそらく最も簡単な方法はマルチAZアプリケーションを構築することです。これは、レジリエントなアプリケーションを構築する旅を始める際に、誰もが最初に取り組むべきことです。
通常、複数のAZにまたがってインスタンスやコンピュートを分散させ、データベースも別のAZにレプリカやフェイルオーバーを持つことから始めます。もしAZに何か問題が発生した場合、例えばAZに影響を与えるデプロイメントがあったり、一部のサービスに問題が発生したり、大きな障害が起きたりして、このAZからトラフィックを分離したい場合、通常は1つのAZから別のAZにトラフィックを移動させます。これをAZ分離と呼びます。このシナリオでは、プライマリインスタンスがセカンダリRegionにフェイルオーバーし、そのスタンバイがプライマリになります。
AmazonやAWSで私たちがよく使用するもう1つの非常に興味深い障害分離境界は、セルと呼ばれるものです。セルは、障害の影響範囲を抑えるもう1つの方法です。セルで非常に興味深いのは、例えば、マルチAZアプリケーションを取り上げると、これは先ほど示したのと同じスライドです。そしてこれが私たちのセルです。これは実際にはサービスのインスタンス化であり、データレイヤーを含めてそれをセルに配置します。そして通常、セルを取り、薄いルーティング層の背後にそれらのセルを水平方向に複製します。一般的に、これはドメイン名を持つRoute 53になります。
私たちは異なるセルにトラフィックを振り分け、達成したいレジリエンスのレベルに応じて、顧客を1つまたは複数のセルに割り当てます。もし1つのセルで何か問題が発生した場合、例えばCell 1 example.comでデプロイメントの失敗があった場合、その問題が他のセルに影響を与えないようにしたいのです。Cell 1でデプロイメントを行い、セルの動作を観察します。何か悪いことが起これば、そのセルをルーティング層から外し、顧客を他のセルに移動させることができます。トラフィックのルーティング方法によっては、通常、顧客は複数のセルに割り当てられます。
セルアーキテクチャと静的安定性の概念
このデザインはカオスエンジニアリングにとって特に興味深いものです。なぜなら、合成ユーザーとトラフィックだけのセルを作ることができるからです。このセルは、本番トラフィックと実際のユーザーを扱う他のセルと全く同じサイズです。一つのセルで障害注入を行い、障害モードを理解し、その回復力を向上させ、それを他のセルに複製することができます。このアプローチにより、本番環境で障害注入を実施することが可能になります。Prime Videoもこれと非常によく似たことを行っています。
もう一つの重要な障害分離境界は、コントロールプレーンとデータプレーンの分離と呼ばれるものです。コントロールプレーンは通常、アカウント内のリソースをセットアップする操作を含み、一方でデータプレーンはそれらのリソースを使用することに関わります。例えば、EC2インスタンスの場合、インスタンスの起動はコントロールプレーンの操作であり、インスタンスの使用はデータプレーンの操作です。これらを分離する理由は、コントロールプレーンの操作が通常より複雑で、ワークフロー、データベース、より多くのビジネスロジックを含むからです。障害時には、コントロールプレーンの使用を避けたいのです。データプレーンをできるだけシンプルにすることで、障害時にコントロールプレーンが統計的により多くの問題を抱える可能性があるため、複雑さを抑えてデプロイされたリソースを使用できるようにします。
これは静的安定性の概念につながります。 静的安定性の概念を使用したり聞いたことがある人はどれくらいいますか？私たちはここでよくこの概念を使用しており、静的に安定したシステムを、障害時にコントロールプレーンの操作を必要としないシステムと定義しています。この概念を説明するために、簡単な例を挙げましょう。4つのエンジンを持つ飛行機のようなシステムがあり、2つのエンジンを失っても影響なく飛行を続けられる場合、そのシステムは静的に安定しているといえます。
システムを設計する際、この概念は興味深い特性をもたらします。例えば、3つのAZを持つマルチAZアプリケーションを設計する場合、1つのAZに問題が発生したり問題のあるデプロイメントがあっても、他のAZが新しいインスタンスを起動することなく、障害が発生したAZからのトラフィックの急増を処理できれば、そのシステムは静的に安定しているといえます。私たちはシステムを設計する際にこのことをよく考慮します。なぜなら、先ほど述べたように、障害時にはコントロールプレーンの操作が利用できないことが一般的だからです。その意味で、システムは静的に安定しています。これは、回復力について話す際に非常に重要な概念です。
障害時に最後にやりたいのは、新しいインスタンスを起動しようとしたり、クラスターをデプロイしようとすることです。通常、何もする必要がなく、システムが自身で障害に対処する必要があります。
私たちは、AWS Lambdaが複数のAvailability Zoneアプリケーションを使用して実際にどのように耐障害性を構築しているかについて、非常に優れた論文を書きました。彼らはAvailability Zoneを使用して静的な安定性を構築しています。この記事を読むことを強くお勧めします。それは私がMarciaと一緒に書いたからではなく、複数のAZという非常に重要な概念を説明しているからです。
レジリエンステストとAWS Fault Injection Serviceの概要
これは、評価とテストという2番目の部分につながります。障害分離境界は素晴らしいですが、それをどのように評価し、テストするのでしょうか？従来、障害分離境界について多くの議論がありましたが、お客様がそれをテストするのは非常に困難でした。自分で試すしかなく、それは簡単ではありませんでした。
そこで数年前、レジリエンステストを行うための製品をリリースしました。これについては後ほど少し触れます。レジリエンステストとは、システムにストレスを与え、その反応を観察し、改善を行うことです。これはシステムの信頼性、パフォーマンス、そしてレジリエンスを向上させるために行います。ここには非常に興味深い特性があります。システムに障害を注入し始めると、欠落しているアラーム、ログ、観測性など、隠れた問題が明らかになります。これらを本番環境ではなく、テスト環境で観察できるのは大きな利点です。
レジリエンステストの興味深い点は、運用スキルを練習できることです。頻繁に障害が発生するかどうかわかりませんが、システムはますます耐障害性が高くなっています。迅速な復旧を実現するには、運用プラクティスの筋肉記憶を十分に持つ必要があります。コマンドライン、runbook、これらは最新の状態を保ち、すべてが迅速に動作する必要があります。障害発生時に運用手順が古くなっていて機能しないことに気づくのは最悪のシナリオです。
通常、システムに障害を注入する際は、学校で教わった科学的方法に似たものを使用します。「データベースを削除したらどうなるか」や「システムの認証レイヤーを削除したらどうなるか」といった仮説から始めます。そして、仮説を検証するための実験を行います。データベースレイヤーを削除すると、システムが読み取り専用モードに移行し、キャッシュを使用して動作し続けるという仮説があれば、それをテストします。テストするまでは、それは単なる仮定です。そして、仮定は真実に変わるまで間違っていると断言できます。月曜日の仮定が、10回のデプロイメントによる構成のドリフトで金曜日には間違っているということもあり得るのです。
このようなシナリオを定期的に実践することが重要です。この種の動作をテストするため、2年前に AWS Fault Injection Simulator をローンチしました。これは後に AWS Fault Injection Service と名称変更されました。このサービスを使用すると、システムに制御された実験を注入できます。このサービスについてより詳しく説明するために、Iris さんをステージにお招きし、特に本日発表した新しいアナウンスメントについて掘り下げたいと思います。ありがとうございました。
AWS Fault Injection Serviceの主要概念と新機能
Adrian さん、ありがとうございます。この次のセクションでは、AWS Fault Injection Service とは何か、アプリケーションのレジリエンスをテストするためにどのように使用するか、そして最後に、おそらく私のお気に入りの部分ですが、本日発表したばかりの新機能について説明します。しかし、詳しく説明する前に、FIS の主要な概念をいくつか確認しておくべきだと思います。まず、FIS を使用するには、セットアップした実験テンプレートから始めます。
実行すると、これが実験を作成します。実験テンプレートは必要な回数だけ実行できます。実験テンプレートをセットアップするには、いくつかの重要な要素を定義する必要があります。まず、アクションとターゲットです。アクションは実際に注入する障害であり、ターゲットは障害を注入するリソースです。例えば、コンピューティングの損失をシミュレートするためにインスタンスを終了したい場合、アクションはインスタンスの終了であり、ターゲットは障害を注入する EC2 インスタンスです。ターゲットは ARN で指定することもできますし、リソースタグでターゲットを指定することもできます。スケールでターゲットを指定する場合は、リソースタグを使用することをお勧めします。
次はセーフガードと IAM コントロールです。FIS の使用は、システムにカオスを注入することではありません。制御された環境で実験を実行することが目的です。FIS を使用すると、いつでも手動で実験を停止することで、安全で制御された実験を実行できます。または、ストップコンディションを使用することもできます。これは、トリガーされると FIS が実験を停止し、自動的にロールバックする警告を設定するものです。ここでのアイデアは、アプリケーションが動作すると予想される境界を定義することです。これらの境界外になった場合、実験を停止するよう指示します。また、FIS がリソースに対してアクションを実行することを許可する権限を持つ IAM ロールを作成する必要があります。実験を実行できる人と、実行できる実験の種類を明示的に定義するために、きめ細かな権限を使用することをお勧めします。
これらが FIS の主要なコンポーネントですが、私たちは常に顧客が FIS をより簡単に使用できるようにする方法を探しています。いくつかの新機能について触れたいと思います。まず、数週間前にシナリオをローンチしました。シナリオをローンチしたのは、顧客からアプリケーションのレジリエンスをテストしたいが、どこから始めればいいかわからないという声をよく聞くからです。「どのようなアプリケーションの障害に対してレジリエントであるべきか？」といった質問をよく受けます。ここでシナリオが役立ちます。シナリオは、AWS が作成し所有する実験テンプレート上の事前定義されたアクションとターゲットです。例えば、CPU 負荷を 90% から 100% に増加させたり、Amazon EKS ポッドのレイテンシーを増加させたりするなど、CPU 負荷に対するアプリケーションの応答をチェックできるシナリオがあります。シナリオは FIS Management Console のシナリオライブラリから見つけることができます。
また、マルチアカウント実験のサポートも開始したばかりです。複数のアカウントにまたがるリソースを持つアプリケーションがある場合、単一の FIS 実験からこれらのアプリケーションでシナリオを実行できるようになりました。これらの機能をリリースできて嬉しく思います。ぜひ試していただき、ご意見をお聞かせください。これらのコンポーネントがどのように連携するかの概要です。 AWS Management Console または AWS CLI から、アクションとターゲットを定義する実験テンプレートで始めることができます。アクションは任意の順序で設定でき、アクションの期間を指定します。また、FIS がこれらの特定のアクションを実行できるようにする権限を持つ IAM ロールも作成する必要があります。
実験を開始すると、Amazon CloudWatch ダッシュボードや好みのモニタリングツールから実験の効果を確認できます。実験は、すべてのアクションが完了したとき、または停止条件などによって実験が停止されたときに終了します。実験が終了すると、実験の結果を確認し、パフォーマンス、観測可能性、および回復力の問題を観察できます。アプリケーションの実験への反応と、実行すべき実験の種類に自信がついたら、例えば AWS FIS の Amazon EventBridge Scheduler 統合を使用したり、これらの実験を CI/CD パイプラインにデプロイしたりして、実験を自動的に実行するように設定できます。これが FIS を使用するエンドツーエンドのプロセスで、数分でセットアップできます。
AZ Availability: Power Interruptionシナリオのデモ
さて、これは素晴らしいですが、FIS で何をテストできるのでしょうか？コンピューティング、ストレージ、ネットワーキング、データベース、管理など、幅広い AWS サービスをサポートしています。これらには、Amazon Elastic Compute Cloud (Amazon EC2)、Amazon EC2 Auto Scaling、Amazon Simple Storage Service (Amazon S3)、Amazon Virtual Private Cloud (Amazon VPC)、Amazon Relational Database Service (Amazon RDS)、Amazon CloudWatch、Amazon Elastic Kubernetes Service (Amazon EKS)、Amazon Elastic Block Store (Amazon EBS)、AWS Transit Gateway、Amazon DynamoDB、AWS Systems Manager が含まれます。応答しない EBS ボリューム I/O をシミュレートする独自の AWS フォールトがあることも言及する価値があります。
FIS は当初 EC2 インスタンスのサポートで立ち上がり、今年は EKS ポッドと ECS タスクのコンテナフォールトのサポートを導入しました。これらの両方のタイプのフォールトを拡張し続けています。 例えば、今日だけでも 6 つの新しいリソースタイプにわたって 7 つの新しいアクションをリリースしました。そして、 サポートするサービスと各サービスのフォールトの数の両方を拡大し続けています。
また、AWS Systems Manager、SSM ドキュメント、および自動化実行を使用して、アプリケーションにカスタムフォールトを注入できることも言及したいと思います。AWS は開始するための SSM ドキュメントを提供していますが、これは独自のフォールトをセルフサービスで作成する素晴らしい方法です。さらに、Adrian が言及したように、今日発表したばかりの 2 つの新しいシナリオ の一部であるため、新しいアクションについても触れたいと思います。これらは、アプリケーションのコンポーネントだけでなく、マルチ AZ およびマルチリージョンにまたがる完全なアプリケーションをテストできる、最初の複雑なマルチリソースタイプシナリオです。
Adrianはすでにマルチ AZ 構築の重要性について素晴らしい説明をしてくれました。そして、多くの方々がすでに複数の AZ にまたがってレプリカホストをロードバランサーの背後に配置するような形でアプリケーションを構築されているかもしれません。しかし、ある AZ で停電イベントが発生したとしましょう。適切なアラームとモニタリングを設置して対応できているか、そしてアプリケーションが残りの Availability Zone で期待通りに動作できるかをどのように確認すればよいでしょうか？ここで役立つのが、AZ Availability: Power Interruption シナリオです。
このシナリオは、お客様がマルチ AZ アーキテクチャの実装をテストできるようにするものです。1つの AZ での停電の症状を再現するために、複数の FIS アクションを組み合わせています。基本的な考え方は、1つの AZ が停電イベントを経験し、アプリケーションが残りの Availability Zone で期待通りに動作し、パフォーマンスを発揮できるかどうかを確認することです。 このシナリオには、停電イベントで予想される障害が含まれています。それがどれほど起こりにくいものであっても。
例えば、EC2 インスタンスやコンテナのポッド、タスクは失敗すると予想されますが、ロードバランサーや Auto Scaling グループは期待通りに動作するはずです。Lambda のようなリージョンベースのサービスも同様に期待通りに動作するはずです。これが、ローンチ時にサポートする障害の現在のリストです。まず、EC2 インスタンスを停止し、これらのインスタンス上のポッドやタスクも停止します。また、Auto Scaling グループと IAM ロールに容量不足エラーを注入する新しいアクションも用意しており、対象の Availability Zone へのインスタンス起動リクエストを防ぎます。このシナリオでは、ElastiCache と RDS データベースのフェイルオーバーも発生させます。最後に、AZ が復旧した後、永続的な EBS ボリュームが応答しなくなる可能性があります。
Availability Zone A の端から端までの停電シナリオは次のようになります。 Availability Zone A のリソースをターゲットにして実験を開始します。これによりコンピュートが失敗し、ElastiCache のプライマリノードや RDS のライターインスタンスがある場合はフェイルオーバーします。適切なアラームとモニタリングが設置されていれば（このシナリオはそれをテストするのに適しています）、アラームとヘルスチェックがトリガーされるはずです。この時点で、標準的な運用手順か、または Route 53 application recovery controller のゾーナルシフトを使って AZ A からトラフィックをシフトする必要があります。ゾーナルシフトは ALB と NLB の標準機能で、このようなシナリオへの対応として特に優れています。トラフィックをシフトしたら、主要なメトリクスを観察できます。
可用性やレイテンシーなどの主要なメトリクスを観察して、アプリケーションが他の Availability Zone でどのようにパフォーマンスを発揮しているかを確認できます。実験が終了したら、フェイルバックしてアプリケーションがどのように回復するかを確認し、 トラフィックを元に戻せることを確認できます。ここで、事前に録画したデモをお見せします。このデモでは、先ほどのものと似たアプリケーションで、3つの Availability Zone にまたがる NLB の背後にレプリカホストがある構成を us-east-1a でターゲットにしています。また、各ゾーンのエンドポイントに対する合成モニタリングと、このようなシナリオ中の顧客体験をチェックできるリージョナルカナリアをすでに作成しています。
まず、AWS Fault Injection Service Management Consoleから始めましょう。これはResilience Hubの下にあり、左側にScenario Libraryがあります。そこに移動してください。次に、Scenario Libraryにはさまざまなシナリオがあることがわかります。それぞれを選択できます。私はAZ Availability: Power Interruptionシナリオを選択します。ここでは、シナリオに関する情報を見ることができます。各シナリオの具体的なアクションとターゲットも確認できます。また、実験テンプレートの実際のJSONを見て、コピーして自分のニーズに合わせて修正することもできます。最後に、シナリオの詳細や追加のドキュメントを確認することもできます。
このシナリオからテンプレートを作成してみましょう。先ほど言及したように、複数のアカウントにリソースがある場合は、ここでそのオプションを選択できます。私はすでにスタックを1つのアカウントに設定しているので、そのまま進めます。ご覧のように、この実験のアクションとターゲットはすでにここで定義されています。この実験テンプレートを設定するには、いくつかの重要なパラメータを入力するだけです。そこで、Edit shared parametersをクリックします。ここで影響を受けるAZを指定します。今回の場合、us-east-1aのリソースをターゲットにしたいので、このパラメータを選択します。
次に、このシナリオのほとんどのリソースタイプはリソースタグでターゲットにされています。FISはIAMロールをタグでターゲットにすることをサポートしていないので、インスタンス起動リクエストを防ぐために不十分な容量エラーを注入するIAMロールを選択する必要があります。ここで作成したデモロールを選択します。先ほど言及したように、タグによるターゲティングをサポートしています。ここで各リソースタイプのタグキーと値を指定します。私はすでにリソースにそれに応じてタグを付けていますが、例えば、アプリケーションに一貫したタグがある場合は、それを指定することもできます。
最後に、実験の期間を指定する必要があります。デフォルトは30分の停止と30分の回復期間です。1時間もないので、ここで少し短縮しました。これで、アクションとターゲットの設定に関しては他に何もする必要はありません。必要であれば、特定のターゲットとアクションをクリックして、パラメータがどのように入力されているかを確認することができます。ここでそれを行って、お見せしています。予想通り、us-east-1aをターゲットにしています。
次に、必要であれば、アクションをスキップできるこの実験オプションがあります。例えば、スタックに特定のリソースタイプ（ElastiCacheクラスターなど）がない場合、実験は単にそのアクションをスキップします。この実験テンプレートが、指定されたすべてのリソースがあることを検証するようにしたい場合は、Failを選択できます。ただし、このオプションのデフォルトはアクションをスキップすることです。最後に、ここでFISがアクションを実行できるようにするIAMロールを指定します。私はすでに適切な権限を持つロールを作成して設定しているので、ここで選択するだけです。もし事前に作成していなければ、ここで作成することになります。
このデモでは、実験を最後まで実行したいので、stop conditionは指定しません。ただし、もし必要であれば、ここで定義することができます。最後に、ログを有効にするのがベストプラクティスだと思います。そこで、実験ログを送信するためのS3バケットの送信先を指定します。これで、テンプレートを作成できます。
このデモでは、すでに実験を開始しています。 「開始」をクリックすると、実験が初期化されます。初期化中に、セットアップした残りのスタックをお見せしましょう。先ほど述べたように、各ゾーンのエンドポイントにCanaryを設置し、FISを使用した地域別のカスタマーCanaryも設置しています。ロードバランサーの背後には6つの正常なホストがあり、各Availability Zoneに2つずつのホストがあります。ご覧のように、プライマリノードはus-east-1aにあります。Amazon RDSデータベースについては、ライターインスタンスもus-east-1aにあります。
実験に戻ると、アクションが実行中または保留中の状態になっていることがわかります。RDSのフェイルオーバーアクションはすでに完了しています。これは一度だけ発生するからです。この実験がリソースに与える影響を確認してみましょう。Auto Scaling groupを見ると、us-east-1aでインスタンスが終了していることがわかります。アクティビティを確認すると、Auto Scaling groupがus-east-1aにインスタンスを起動しようとしましたが、FISによって注入された容量不足エラーを受け取ったことがわかります。これにより、ターゲットAZへのインスタンスのプロビジョニングが妨げられます。残りのAvailability Zoneに追加のインスタンスがデプロイされていることもわかります。
ロードバランサーを見ても、同様の状況が確認できます。現在、正常なホストは4つだけです。2つのホストが初期化中で、ヘルスチェックは初期化状態です。RDSデータベースを確認すると、現在変更中であることがわかります。ElastiCacheクラスターも確認してみると、こちらも変更中の状態です。プライマリノードはすでにus-east-1cにフェイルオーバーしています。次に、Canaryの状態を確認できます。現在、us-east-1aのCanaryは失敗していますが、顧客体験を表す地域別のCanaryも影響を受けており、応答時間が増加していることがわかります。
この実験から、アプリケーションを改善し、ゾーンシフトを開始し、AZからトラフィックを移動させる必要があることがわかります。これにより、このようなシナリオに対するアプリケーションの回復力と復旧時間を改善できるでしょう。FIS実験に戻ると、アクションが完了していることがわかります。すべてのリソースタイプがあったわけではないので、それらのアクションは単にスキップされました。これで、このタイプのシナリオがどのように機能するかがおわかりいただけたと思います。
Cross-Region: Connectivityシナリオと結論
次に、Cross-Region: Connectivityというシナリオの詳細に入ります。このシナリオでは、複数のリージョンにまたがるアプリケーションを持つお客様が、プライマリリージョンにアクセスできない状況での運用をテストすることができます。ほとんどのお客様にとっては、マルチAZアーキテクチャで十分ですが、極めて高い可用性を必要とする重要なアプリケーションを持つお客様や、セカンダリリージョンへのフェイルオーバーが可能であることを示し、セカンダリリージョンで期待通りに運用できることを証明する必要があるコンプライアンス要件を持つお客様もいます。このシナリオにより、お客様はセカンダリリージョンからプライマリリージョンへの隠れた依存関係（ハードコードされたリージョナルエンドポイント、内部依存関係、証明書など）がないかをテストすることができます。
このシナリオの一部として、本日新たに4つのアクションをリリースしました。クロスリージョンのネットワーク接続を遮断する2つの新しいアクションがあります。これには、VPCピアリング、API Gateway、クロスリージョンのAWSエンドポイント、ロードバランサーを介して公開されるエンドポイントを含むVPCからのクロスリージョン接続のブロックが含まれます。また、グローバルテーブルのクロスリージョンレプリケーションを一時停止する新しいアクションも含まれています。同様に、S3アクションはS3バケットからのクロスリージョンレプリケーションを一時停止します。このS3アクションは、このシナリオ以外でも、同じリージョン内のバケット間のレプリケーションを一時停止するのにも使用できます。
Cross-Region: Connectivityシナリオの一連のゲームデイは次のようになります。セカンダリリージョンで実験を開始し、ネットワーク接続を遮断してレプリケーションを一時停止します。この時点で、標準的な運用手順に従ってプライマリリージョンからトラフィックをシフトできます。ここで、実験がアプリケーションに与える影響を監視できます。この実験のデフォルトの期間は3時間で、このシナリオの影響を観察するのに十分な時間です。アラームの欠落や異常な動作がないか注意深く観察する必要があります。アプリケーションの動作に自信が持てたら、トラフィックを元に戻し、アプリケーションが期待通りに回復するかどうかを確認できます。
さて、今日の時間も終わりに近づいてきました。マルチAZとAWSの障害境界の構築の重要性、レジリエンスのベストプラクティス、そしてAWS Fault Injection Simulator（FIS）などのAWSで利用可能なツールについて話してきました。この発表から何か一つ持ち帰るとすれば、組織全体でレジリエンスを構築するには本当に時間がかかるということです。残念ながら、特効薬はありません。レジリエンスの構築は習慣であり、すべての組織のすべての人が達成できるものですが、ただ練習、練習、そして練習が必要なのです。
さて、ここで皆さまのレジリエンスの旅を続けるためのリソースをいくつかご紹介します。写真を撮りたい方のために、少し間を置きます。最後に、本日は貴重なお時間をいただき、誠にありがとうございました。AWS re:Inventにお越しいただき、心より感謝申し上げます。たくさんのセッションがある中、もし可能でしたら、モバイルアプリでセッションのアンケートにお答えいただければ幸いです。また、Adrianとわたしはこちらの廊下側で質問をお受けしますので、ご質問のある方はお気軽にお声がけください。本当にありがとうございました。
※ こちらの記事は Amazon Bedrock を様々なタスクで利用することで全て自動で作成しています。
※ どこかの機会で記事作成の試行錯誤についても記事化する予定ですが、直近技術的な部分でご興味がある場合はTwitterの方にDMください。
Discussion