re:Invent 2023: AWSが解説するグレー障害の検出と緩和戦略
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2023 - Detecting and mitigating gray failures (ARC310)
この動画では、AWSのSenior Principal Solutions ArchitectであるMichael Hakenが、グレー障害の検出と緩和について詳しく解説します。差分的観測性の概念から、Contributor InsightsやCloudWatch composite alarmsを活用した具体的な検出方法、そしてAmazon Route 53 Application Recovery Controllerのzonal shift機能を用いた効果的な緩和策まで、実践的な知識が満載です。AZ独立性やコントロールプレーンとデータプレーンの違いなど、高度なレジリエンス戦略も学べる内容となっています。 ※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
本編
グレー障害：定義と重要性
グレー障害の検出と緩和について。私はMichael Hakenと申します。AWSのSenior Principal Solutions Architectで、多くのお客様と様々なレジリエンスに関するトピックについて取り組んでいます。その中でも、グレー障害について話すのが私のお気に入りです。今日は、グレー障害とは何か、それをどのように見つけて検出するか、そしてどう対処するかについて議論していきます。
まず、ここに私たちのサービスの一つから得た可用性ダッシュボードの表現があります。 ご覧のように、サービスの可用性が98%をわずかに下回っています。この事象を引き起こしたサーバーの数が何台だったか、誰か推測できますか？答えをお教えしましょう。1台です。たった1台のホストがサービス可用性を2%低下させたのです。私たちはこのような経験を様々な形で目にします。 不良メモリを持つ1台のホスト。不良CPUを持つ1台のホスト。 さらに、ソフトウェアでもこのような問題を経験します。例えば、Javaのクラスパスの競合が起きている1台のホストなどです。Javaはクラスを非決定論的にロードするため、1台のホストでランダムに障害が発生する可能性があります。これらはすべてグレー障害の例です。
グレー障害と言う時に私が意味することをもう少し詳しく理解しましょう。グレー障害は、差分的観測性という考え方で定義されます。 差分的観測性とは、異なる視点から健全性が異なって観察されることを意味します。使用している基盤システムは影響をまったく認識しないかもしれませんし、閾値を超えないかもしれません。しかし、そのシステムのユーザーである私たちは、不釣り合いに大きな影響を受ける可能性があります。 これは、障害を検出し緩和するために、その基盤システムに頼ることができないことを意味します。私たち自身が行動を起こす必要があるのです。
グレー障害の抽象的モデルと影響
これをもう少し明確にするために、抽象的なモデルを見てみましょう。画面上には、顧客のために何かを行うコアビジネスロジックを持つシステムがあります。また、障害検出器となるobserverもあります。これはシステムからメトリクスを報告されたり、メトリクスを取得したりします。そして、observerが問題を検出したときに修正するreactorがあります。システムは自身の健全性について観察を行います。しかし、app1、app2、app3というユーザーもいて、彼らもシステムの健全性について独自の観察を行います。
この例では、平均レイテンシーを見ています。app1は50ミリ秒、app2は53ミリ秒、app3は56ミリ秒の平均レイテンシーを観測しています。そのため、システム全体では53ミリ秒の平均レイテンシーを観測しています。 ここで、システムに閾値があるとしましょう：システム全体の平均レイテンシーが60ミリ秒を超えると、reactorが起動して問題を修正します。 ここで、app1が70ミリ秒の平均レイテンシーを観測しているとします。これによりシステムの平均レイテンシーは59.66ミリ秒に上昇します。しかし、閾値を超えていないため、reactorは起動しません。システムは何も対応しないのです。
しかし、アプリ1のレイテンシーが40%増加しています。これは非常に重大な問題になる可能性があります。タイムアウトを超えたり、他の依存関係のある呼び出しに連鎖的な影響を与えたりする可能性があります。40%の増加は大きな問題となり得るのです。これがグレー障害です。 私たちが本当に話しているのは、この右上の象限についてです。システムの観点からは健全で、何も問題がありません。しかし、アプリケーションの観点、つまり顧客の観点からは、不健全な状態なのです。
障害はこの象限を移動することがあります。グレー障害として始まり、検出された障害になり、そして全て正常になることもあります。あるいは、検出された障害として始まり、グレー障害に移行することもあります。ここでのポイントは、システムが最終的に何かが間違っていることに気づくかもしれませんが、十分に速く反応できない可能性があるということです。このような種類の障害に対して耐性を持ちたい場合、依存しているシステムよりも早く検出し、より速く反応できるようにする必要があります。
AWSにおける障害分離境界とグレー障害の例
グレー障害は通常、何らかの障害分離境界に沿って発生します。AWSには多くのこのような境界があります。 リージョンがあります。リージョンは障害を封じ込め、異なるリージョンに障害が連鎖しないようにします。 Availability Zoneもあります。Availability Zoneは障害を封じ込めます。インスタンスもあります。単一のEC2インスタンスの障害が他のインスタンスに影響を与えることは想定していません。
同様に、コンテナやソフトウェアモジュール、システムコンポーネントも他の境界です。 満杯のEBSボリュームが他のインスタンスに影響を与えたり、 商品リスト機能のバグがチェックアウト機能に影響を与えたりすることは想定していません。これらはすべて障害を封じ込めるものです。今日は、 グレー障害が最も頻繁に発生する障害コンテナとして、Availability Zoneとインスタンスに焦点を当てます。
単一ホストのグレー障害について話しましょう。ここにロードバランサーの背後にあるEC2インスタンスのフリートがあります。 このインスタンス内で障害が発生し、顧客のリクエストに応答できなくなり、顧客に500エラーを返し始めたとします。しかし、ヘルスチェックには依然として応答します。そのため、ロードバランサーはヘルスチェックに応答できるので、インスタンスが健全だと考えます。しかし、顧客のリクエストを受け取ると、エラーを生成してしまうのです。
こちらはもう一つの例です。EC2インスタンスのフリートがあり、それらはAmazon DynamoDBを分散ロックテーブルとして使用しています。インスタンスはテーブルにアクセスして、特定のデータにロックを確立しようとします。ハートビート、ロックを取得したい時間、そしてロックしようとしているデータの情報と共に、自身の注釈をテーブルに書き込みます。ここで、このインスタンスが故障し、実行しようとしていた作業を処理できなくなったとしましょう。ロックしたデータに対して進捗を出せなくなります。しかし、少なくともテーブルへのハートビートを続けられるほどには健全な状態です。そのため、テーブル内のタイムスタンプを更新し続けることができ、結果として他のインスタンスがロックされたデータにアクセスできない状況が続きます。ただし、このインスタンスは実際には実行しようとしていた作業を完了できないのです。
これらは単一ホストのグレー障害の2つの例です。このような状況が発生した場合、ロードバランサーからの浅いヘルスチェックやテーブルへのハートビートでは、このタイプのエラーを見つけるのに役立たないことに気づきます。では、どうすればいいのでしょうか？より深いヘルスチェックが必要です。より深くテストすれば、これらの問題を見つけられるかもしれません。
ヘルスチェックの種類と課題
浅いヘルスチェックと深いヘルスチェックの違いについて話しましょう。浅いヘルスチェックはサーバーとアプリケーションをチェックします。依存関係をモックすることもあり、サーバー自体が問題の原因である場合、より正確なチェックとなります。オンボックスと呼ばれるもののみをチェックするので、このインスタンスの外部には何もアクセスしません。一方、深いヘルスチェックは浅いヘルスチェックで行うすべてをチェックした上で、さらに依存関係、つまりオフボックスの依存関係もチェックします。データベースへのクエリを実行したり、S3でget objectを行ったりするかもしれません。あなたの依存関係が何であれ、完全なネットワークパス、つまりユーザーストーリー全体がテストされていることを確認します。
浅いヘルスチェックから深いヘルスチェックに移行する方法の例をいくつか見てみましょう。この例では、依存関係と通信するインスタンスを持つAuto Scaling グループを使用し、すべてをロードバランサーの背後に配置します。Auto Scalingでは、そのAuto Scalingグループ内のインスタンスの健全性を判断するために2つのオプションがあります。1つ目のオプションは、EC2ステータスチェックを使用することです。これはpingリクエストやARPへの応答など、EC2インスタンスの生存確認に近いものです。もう1つのオプションは、ELBヘルスチェックをAuto Scalingグループに追加することで、ロードバランサーが実行するヘルスチェックもインスタンスの健全性判断に使用されます。
この例では、浅いヘルスチェックを実行します。これらのサーバーの/healthというWebパスにアクセスします。これらのインスタンスの1つで障害が発生した場合、例えば重要なプロセスが動作していない場合、その問題を回避してルーティングします。ロードバランサーがそのインスタンスを不健全と判断し、それ以上のトラフィックを送信しなくなるからです。そしてAuto Scalingがそのインスタンスを置き換えます。これは良いことですね。
しかし、ここで接続性のグレーな障害が発生したとしましょう。例えば、このインスタンスがデータベースに接続できない、あるいはクエリの10%がタイムアウトしたり、ドロップしたりしているような状況です。 浅いヘルスチェックでは、この問題を回避できず、顧客はエラーに遭遇することになります。ロードバランサーは、問題を抱えているにもかかわらず、そのインスタンスにトラフィックを送り続けます。これは、先ほどの例で見たのと似たような状況です。
そこで、より深いヘルスチェックが必要になります。 グレーな障害を回避するために、深いヘルスチェックを使ってみましょう。
グレーな障害を回避するために、Auto Scaling グループと一緒に EC2 のステータスチェックを使用します。これがなぜ重要なのか見てみましょう。接続性のグレーな障害が発生した場合、それを回避することができます。 深いヘルスチェックは、この依存関係への接続パスをチェックします。このインスタンスが接続できないため、ヘルスチェックは失敗し、ロードバランサーはトラフィックを送信しません。しかし、このインスタンス内で障害が発生した場合はどうなるでしょうか？ ロードバランサーは不健全と見なすため、トラフィックは回避されますが、置き換えられることはありません。これは、Auto Scaling グループが ELB のヘルスチェックではなく、EC2 のステータスチェックのみを使用しているためです。これは望ましくない問題です。
ELB のヘルスチェックを追加してみましょう。これで、インスタンス内で障害が発生した場合、それを回避し、Auto Scaling がこのインスタンスを置き換えることができます。しかし、ここに問題があります。 この依存関係に一時的なエラーが発生したとします。ネットワークパスでもインスタンスでもなく、依存関係に問題があるとします。そして、それがこれらのインスタンスすべてに影響を与えます。すると、これらのインスタンスはすべて不健全に見えてしまいます。ELB のヘルスチェックにすべて失敗し、 フリート全体が不健全に見えてしまいます。Auto Scaling は、これらの不健全なインスタンスを最大10%のバッチで置き換え始めます。キャパシティの10%の低下は、顧客への影響という点で非常に大きな問題になる可能性があります。ブートストラップを伴う EC2 インスタンスの起動は、インストールする内容やインスタンスのタイプによって、おそらく5〜15分のプロセスです。そのため、これらのインスタンスが置き換えられている間、大量のダウンタイムが発生することになります。
残念ながら、状況はさらに悪化する可能性があります。 一時的なデータベースエラーが発生しているものの、実際にはすべてのインスタンスが影響を受けているわけではない場合があります。例えば、1つの残りのインスタンスが完全に正常である場合を考えてみましょう。ELB はフェイルオープンしません。少なくとも1つの健全なインスタンスがある場合、その1つの健全なインスタンスにのみトラフィックを送信します。 ここで起こるのは、他のすべてのインスタンスが置き換えられている間、その1つのホストにすべてのトラフィックが集中し、オーバーワhelm状態になることです。これはおそらくそのインスタンスをダウンさせてしまうでしょう。そうなると、再び健全なインスタンスがゼロになってしまいます。 さらに悪いことに、オーバーワhelm状態でも、そのインスタンスはヘルスチェックに合格し続ける可能性があります。顧客のトラフィックを処理できなくても、ヘルスチェックリクエストには応答できるかもしれません。そうなると、不健全なインスタンスにすべてのトラフィックを送り続けることになります。これはおそらく最悪のシナリオでしょう。
どうやら、私たちのヘルスチェックが少し深すぎたようです。では、どうすればいいでしょうか？より浅いヘルスチェックを行うことです。 私たちは、浅いヘルスチェックか深いヘルスチェックかを選択するという状況に置かれています。正解は何でしょうか？先ほど見たように、提案したすべての方法に問題がありました。 トレードオフを見てみましょう。深いヘルスチェックを使用したい場合は、Auto Scaling グループと統合しないでください。これにより、不要なインスタンスの終了を防ぐことができます。深いヘルスチェックを使えば、インスタンスを終了せずにグレーな障害を回避できます。しかし、 ローカルインスタンスの健全性を全体的に把握するための追加のメカニズムが必要になります。これを実現するために使用したパターンの1つが、次に説明するハートビートテーブルパターンです。Auto Scaling のために、ローカルのインスタンスが不健全で交換すべきかどうかを判断できるようにしたいのです。深いヘルスチェックだけでは、必ずしもそれを教えてくれません。
浅いヘルスチェックを使用する場合は、常に Auto Scaling グループと統合すべきです。そうすることにデメリットはありません。 浅いヘルスチェックは、不健全なインスタンスがルーティングから外され、Auto Scaling によって置き換えられることを保証するのに役立ちます。ボックス外を見ないので、 一時的な依存関係の問題によるインスタンスの終了を防ぐことができます。ただし、グレーな障害に対処するための追加のメカニズムを構築する必要があります。深いヘルスチェックも浅いヘルスチェックも、正解も不正解もありません。どちらを選ぶべきかは私からは言いません。しかし、トレードオフを理解する必要があります。それぞれに正しい実装方法と間違った実装方法があります。どちらを選んでも、選択したアプローチを補完する別のメカニズムが必要になる可能性が高いでしょう。
グレー障害の検出手法：ハートビートテーブルと外れ値検出
深いヘルスチェックを使用したい場合は、このようなものを使用してローカルインスタンスの健全性を判断できます。 この Auto Scaling グループ内のインスタンスがロードバランサーからヘルスチェックを受けるたびに、DynamoDB テーブルに書き込みます。インスタンス ID、そのハートビートが行われた時間、自身が健全だと考えているかどうか、そして AZ ID などの情報を書き込みます。
下にあるインスタンス i-543210 が最後に報告したのは 11:55 で、現在時刻は 12:01 であることがわかります。この Lambda 関数は1分ごとに実行され、テーブルをクエリして古いエントリを探します。5分以上経過したエントリを見つけると、Auto Scaling API を呼び出してインスタンスの健全性を設定し、そのインスタンスを終了します。これは、深いヘルスチェックを使用しながら、依存関係なしでインスタンスがローカルでどのように動作しているかの良好な全体像を得る方法です。
しかし、私たちが直面する課題は、ヘルスチェックが必ずしも全体像を示すわけではないということです。 ここでは、ロードバランサーの背後にいくつかのインスタンスがあり、2つの依存関係があるとしましょう。これらの依存関係は、サードパーティのシステム、S3、または DynamoDB かもしれません。私のシステムには3つのパスがあるとします：ホーム、製品、チェックアウトです。ホームは依存関係1に、製品は依存関係1に、チェックアウトは依存関係1と2の両方に依存しているとします。ELB のヘルスチェックには、このスラッシュヘルスパスにアクセスします。
ヘルスチェックが実行されると、依存関係の一部だけをテストする場合があります。通常の機能で50のAPIやS3を使用している場合、ヘルスチェックでそのすべてをテストするのは現実的ではありません。依存関係チェーンのすべてのAPIを実際にテストすることはできないかもしれません。そのため、依存関係2に障害があっても、ヘルスチェックで見逃される可能性があります。例えば、主にS3のget objectを依存関係として呼び出し、まれにput objectを使用する場合、ディープヘルスチェックでそれをテストしていないと、障害を見逃す可能性があります。
もう一つの課題があります。特定のインスタンスが依存関係1との通信に問題を抱えており、4%のエラー率を生み出しているとしましょう。これは98%のサービス可用性につながります。ロードバランサーからのヘルスチェックが失敗したと判断するには、例えば3回連続でヘルスチェックが失敗する必要があるとします。リクエストの4%だけが失敗している場合、各ヘルスチェックが失敗する確率は4%です。3回連続で失敗する確率は0.0064%になります。つまり、このような問題をヘルスチェックで捉える可能性は非常に低いのです。
そのため、ELBヘルスチェックでこの種の問題を捉えるのは非常に難しいでしょう。これにより、シャローヘルスチェックを使用し、グレーフェイルの検出と緩和ツールを構築したくなるかもしれません。なぜなら、ELBやEC2インスタンスステータスチェックからのヘルスチェックでは、このタイプの問題を捉える可能性が非常に低いからです。
グレー障害の検出に必要な計測と可観測性
では、単一インスタンスのグレーフェイルをどのように検出できるでしょうか？まず必要なのは計測です。システムの可観測性が必要です。可観測性と計測には明示的なコードの記述が必要です。ビジネスロジックの周りにコードを書く必要があります。標準で提供されるもの以上のものが必要です。AWSはEC2やその他のサービスに対して、多くの優れたメトリクスをネイティブに提供しています。CPU、メモリ、ネットワークの入出力などが得られます。しかし、ホスト内部で何が起こっているかを本当に知る必要があります。
ホストが何をしているか、誰と通信しているか、どれくらい時間がかかったか、どれだけのデータを処理したかを知りたいのです。クライアント側とサーバー側の両方の視点を得たいです。メトリクスに何が起こっているかのコンテキストを付加したいです。また、AWSにはリージョン、Availability Zone、ホストなど、異なる障害分離境界があると言及しましたが、これらの障害分離境界に合わせてメトリクスにディメンションを付けたいのです。
すべてのメトリクスにおいて、Availability Zone IDを使用してレイテンシーを確認する必要があります。システムの可用性をAvailability Zone IDで検証したいのです。これにより、ある特定のAvailability Zoneで問題が発生しているかどうかを区別することができます。メトリクスにAvailability Zone IDやホストIDを付加しなければ、問題の実際の原因を特定することはできません。
CloudWatchで提供している機能の1つに、embedded metric formatがあります。個人的にこの機能が気に入っているのは、メトリクスとログを一つの画面で確認できるからです。開発者やエンジニアの皆さんは、ログファイルに書き込むコードと、CloudWatch APIにカスタムメトリクスを書き込むコードの2セットを作成する必要がありません。すべてのメトリクスを直接ログファイルに記述すれば、自動的に抽出してCloudWatchメトリクスとして公開します。
これがembedded metric formatのログの例です。単なる構造化されたJSONです。ここでは、2XX、3XX、などのレスポンスや、成功時のレイテンシーといったメトリクスを見ることができます。呼び出されているサービスの名前、リージョン、Availability Zone ID、インスタンスIDなどのディメンションがあることがわかります。ここにはいくつかのディメンションセットが含まれています。そして実際のデータがあり、このインスタンスはAZ 1にあり、2XXで応答し、成功時のレイテンシーが20ミリ秒だったことがわかります。非常に強力なツールなので、このログファイルを見て、すべてのメトリクスデータを理解し、クエリを実行したり、ダッシュボードで確認したりすることができます。
Contributor Insightsを用いたグレー障害の検出
グレー障害を発見するには、EC2インスタンス間でデータを比較できる必要があります。おそらく、ある時点で全てのインスタンスにある程度のエラー率が発生するでしょう。通常、全体的にゼロということはありません。しかし、私たちが本当に知りたいのは、あるホストが他のホストよりも明らかに悪い状態にあるかどうかです。これを行い、インスタンス間で比較するために、Contributor Insightsというサービスを使用できます。
Contributor InsightsはCloudWatchの機能で、ログファイルに対してルールを記述することができます。この例では、HTTPステータスコードが499から600の間、つまり500系のレスポンスを探しています。インスタンスIDをキーにしています。これがContributor Insightsのルール全体で、このようなグラフを含むダッシュボードが表示されます。ここには多くのインスタンスがあり、おそらくほぼ同じエラー率を示しています。この場合、このContributor Insightsダッシュボードを見ていれば、「おそらく問題はない」と判断できるでしょう。
しかし、もしこのような状況を目にしたら、おそらくこう考えるでしょう。「あれ、このホストには何か問題があるな。他のホストよりもエラーが多すぎる。グレーフェイルアーが起きている可能性がある。」ただ、人間の対応は遅いものです。グレーフェイルアーを見つけるために、人間がこのダッシュボードを一日中監視するのは望ましくありません。 そこで、Contributor Insightsのルールに基づいてアラームを作成することができます。
CloudWatchでは、insight rule metricを使用して、Contributor Insightsのデータからアラームを作成することがネイティブにサポートされています。ここでは、最大のコントリビューター値を全体の合計で割った値が0.75を超えるかどうかを見ています。つまり、システム内のエラーの75%以上を占める1つのホストを探しているのです。1つのホストがエラーの75%を占めているのであれば、それに対して対策を講じることができます。このアラームに基づいて自動化を作成したり、Lambda関数を起動したり、SNSにメッセージを送信したりすることができます。
Availability Zone (AZ)のグレー障害：検出と対応
あるいは、Contributor Insightsのデータを定期的に確認するLambda関数を用意することもできます。例えば、スケジュールされたイベントで1分ごとにContributor Insightsのデータを確認し、「誰かがエラーの75%を占めていないか？」をチェックします。 ここで実際に行っているのは外れ値検出です。エラー率に基づいてシステム内の外れ値を見つけようとしているのです。これは、レイテンシーや、システムにとって重要な他の統計値やKPIに基づいて、何かが間違っているかどうかを特定することもできます。
先ほど述べたように、定期的または特定のトリガーに応じてLambdaを使用し、CloudWatchのメトリクスデータやContributor Insightsのデータを直接消費することができます。私たちが知りたいのは、偏りが発生する可能性が低いかどうかです。外れ値検出には、カイ二乗検定、K-means clustering、標準偏差を見るZ-scoreなど、さまざまなアルゴリズムを使用できます。または、単に静的な数値を使用することもできます。
何かがバランスを崩しているかどうかを判断するには、多くの異なる選択肢があります。グレーフェイルアーを検出するために外れ値検出を検討する際には、2つの重要な考慮事項があります。
まず、これによってシステム内の実際の障害が隠れてしまう可能性があります。不調なホストが頻繁に終了される場合、それはコードにバグがある兆候かもしれません。これはグレー障害ではなく、実際の障害である可能性があります。しかし、自動化されたアクションでそれを検出し対応しているため、潜在的にそのバグを隠してしまっている可能性があります。自動化の使用には注意が必要で、定期的に自動化が行うアクションを確認する必要があります。これが常に起こっているのを見かけたら、毎時間や毎日グレー障害が発生しているとは考えにくいでしょう。このような問題が定期的に発生しているのを見かけたら、システムの根本的な部分をチェックする必要があるかもしれません。
もう一つのリスクは、誤検出です。これらの外れ値検出アルゴリズムは完璧ではなく、実際にはグレー障害ではないものを検出してしまう可能性があります。単一のホストを考慮する場合、おそらくこれはそれほど大きな問題ではありません。誤検出でホストを終了しても、大きな問題にはなりません。ただし、注意すべき点ではあります。
では、単一インスタンスのグレー障害をどのように軽減すればよいでしょうか？この問題に対する最も短く、最もシンプルな答えをお教えしましょう。半分のスライドで説明できます。グレー障害が発生したら、インスタンスを置き換えます。以上です。この問題を軽減する最も簡単な方法は、新しいインスタンスを起動することです。新しいインスタンスが、終了されたインスタンスが抱えていた問題（メモリ障害、CPU障害、ネットワーク問題、競合状態、メモリリークなど）を持っている可能性は低いでしょう。インスタンスを置き換えることで、ほとんどの場合問題が解決されるはずです。
ここで考慮すべき点は、自動化でこれを構築する場合、一種の速度制御を適用することです。AWSの社内では、これを「bullet counter（弾丸カウンター）」と呼んでいます。短時間に多くのインスタンスを終了しすぎないようにしたいのです。10分間で10回目の終了を試みようとしている場合は、停止して人間に確認してもらいます。暴走した自動化が誤ってすべてを終了し始めるようなことは避けたいですからね。
複合アラームを用いたAZグレー障害の検出
これまで、単一のEC2ホストでのグレー障害の検出と軽減について話してきました。この同じロジックを、単一のAZのグレー障害の発見にも適用できます。Availability Zone全体に影響を与えるグレー障害がある場合、その障害は主に3つの異なる形で現れる可能性があります。
最初のケースは、複数のAZが影響を受けているものの、1つのAZが他よりもはるかに大きな影響を受けている場合です。これは、私たちが利用しているすべてのAvailability Zoneでエラーが発生しているが、1つのAZが他よりもはるかに多くのエラーを抱えている状況を指します。このような状況を見つけるために、先ほど説明した外れ値検出が役立ちます。
2つ目の可能性は、1つのAZが明らかに影響を受けており、他のAZは影響を受けていない場合です。これも外れ値検出を使って見つけることができます。また、CloudWatch composite alarmsを使って見つけることもできます。このような状況を見つけるためのcomposite alarmsの構築例を後ほど説明します。
最後に、シングルAZのグレー障害が現れる3つ目の方法は、すべての障害コンテナ（この場合はAvailability Zone）が、グレー障害を起こしている単一の共有リソースの影響を受けている場合です。例えば、データベースのようなものです。データベースがグレー障害を起こしているAvailability Zoneにある場合、すべてのAZのインスタンスがその影響を受ける可能性があります。このような問題も、composite alarmsを使って見つけることができます。
では、システムの可用性アラームの作成について話しましょう。ここにある私のサービスには、homeファンクションとlist productsファンクションの2つの機能があります。これらはアラーム定義です。AZ 1用のアラームがあり、3 out of 3と3 out of 5の設定があります。可用性が99.9%未満になることを監視しています。ここには4つの別々のアラームがありますが、オペレーターが4つの別々のアラームを扱って見る必要はありません。そこで、composite alarmsを作成できます。
ここでは、AZ 1のhome可用性composite alarmがあり、連続する3 out of 3または3 out of 5、つまりM out of Nを監視しています。これは、指定された総試行回数のうち、成功したチェックの数に基づいて可用性を判断する方法です。
私のリスト製品用のアラームも1つあります。これは、私が利用しているすべてのアベイラビリティーゾーン（AZ）に対して行います。つまり、3つのAZを使用している場合、各サービスに対して各AZのアラームを設定します。 そして、これらを最終的な複合アラームにまとめて、AZ1の可用性について知らせるようにします。ホームの可用性またはリスト製品の可用性のいずれかがアラーム状態になれば、AZ1で可用性の問題が発生していることがわかります。これをAZ1、AZ2、AZ3に対して設定します。同様に、レイテンシーや、システムの健全性を判断する上で重要だと思われる他の指標についても行うことができます。
では、これを使って特定のAZへの影響を見つけるにはどうすればよいでしょうか？ AZ1の可用性アラームとレイテンシーアラームがあります。これが恐らく最も複雑な部分です。この複合アラームが示しているのは、AZ1で可用性またはレイテンシーのアラームが発生しているが、AZ2やAZ3では発生していない場合です。この複合アラームは、AZ1がレイテンシーまたは可用性の影響を受けているが、AZ2とAZ3は影響を受けていないことを示しています。ただし、知る必要があるもう一つのことは、複数のインスタンスが問題を経験していることです。単一のAZにある1つの不良ホストが、そのAZ全体を悪く見せてしまう可能性も十分にあります。
AZの退避：目標と考慮事項
そこで、Contributor Insightsを使用している場合、5XXエラーを見るルールを定義していれば、そのContributor Insightsルールに戻ることができます。ユニークな貢献者が2以上であることを確認したいのです。これは、フリートの規模によっては、少なくとも2つ、あるいはそれ以上のインスタンスが実際に問題を経験していることを示します。これにより、そのAZで単一のホストがエラーを生成しているのではないことを排除できます。そして、これが最終的なアラーム となり、SNSトピックにアタッチして、オペレーターに通知したり自動化を開始したりすることができます。つまり、AZ1だけで影響が見られ、それが単一のインスタンスによって引き起こされているのではないことを示したいのです。
これを見て「すごく複雑だな。セットアップに時間がかかりそうだ」と思っているかもしれませんね。ここに示されているこれらのアラームは、一度設定すれば静的なものになります。つまり、これらを作成するには最初に投資が必要ですが、製品を追加したり機能を追加したりするたびに、最上位のアラームだけを編集して、最初の複合アラームに追加するだけで済みます。ですので、一度これを構築すれば、この複合アラームのセットは静的なままです。
次に、エラーが現れる2つ目の方法、つまりデータベース、Aurora、RDSなどの単一の共有リソースがある場合について話しましょう。ここでは、使用すべき指標についてはあまり具体的に言及しません。例として、失敗したトランザクションが1%を超えた場合を測定するとしましょう。また、P99トランザクションレイテンシーも測定します。 例えば、75ミリ秒を超えた場合にアラームが発生するとします。各AZ、つまりAZ1、AZ2、AZ3にアラームがあることがわかります。 これらを使って複合アラームを作成することもできます。
これが示しているのは、2つ以上のAZで主要データベースに問題がある場合です。これは、AZのすべての可能性の組み合わせです。AZ1とAZ2、AZ1とAZ3、またはAZ2とAZ3。つまり、すべてのAZの組み合わせで、少なくとも2つのAZでデータベースとのやり取りに影響が出ていることを示しています。同じことをレイテンシーについても行えます。 そして、最終的な複合アラームを作成し、これもSNSトピックにアタッチしてオペレーターに通知できます。
さて、単一のAZでグレー障害を検出する方法をいくつか見てきました。 外れ値検出を使用するか、複合アラームを構築することができます。何かがおかしいと分かったら（これがグレー障害の最も難しい部分です）、それを緩和するための行動を取ることができます。単一のAZ障害が発生した場合、実際には3つの選択肢があります。 1つ目の選択肢は、待つことです。他の誰かが気づくのを待つか、障害が自然に解消されるのを待ちます。正直に言って、多くのお客様が1つ目の選択肢を選びます。それでも構いませんが、グレー障害が発生している間は、顧客体験に何らかの影響が出ることを認識しておく必要があります。
2つ目の選択肢は、障害が単一のアベイラビリティーゾーンにのみ影響する場合、そのAZを退避することです。 そのAZから離れ、そこでの作業を停止して、障害を解消します。
3つ目の選択肢は、マルチリージョンの災害復旧計画がある場合、別のリージョンにフェイルオーバーすることです。3つ目の選択肢を選ぶお客様も多くいます。3つ目の選択肢の課題は、復旧時間が長くなることと、データ損失やデータの不整合が発生する可能性があることです。S3クロスリージョンレプリケーション、DynamoDB グローバルテーブル、Aurora グローバルデータベースなど、AWSのネイティブなレプリケーションサービスを使用している場合、それらはすべて非同期レプリケーションを使用します。つまり、セカンダリリージョンのデータがプライマリリージョンのデータより遅れている可能性があります。そのセカンダリリージョンにフェイルオーバーすると、不整合なデータで操作を行う可能性があり、ゼロ以外のRPO（Recovery Point Objective）になる可能性があります。
もう1つの課題は、別のリージョンへのフェイルオーバーに時間がかかることです。問題を検出し、「フェイルオーバーすべきだ」と誰かに連絡し、実際に別のリージョンへのフェイルオーバーを実行するまでに、かなりの時間がかかる可能性があります。パイロットライト戦略を使用している場合でも、セカンダリリージョンでリソースを立ち上げる必要があります。これには時間がかかります。アクティブ-アクティブやアクティブ-パッシブ（ホットスタンバイなど）を使用している場合でも、DNSレコードにはTTLがあります。そのため、TTLが期限切れになってDNSレコードが更新されるまでの間、顧客は引き続きプライマリリージョンにアクセスすることになります。マルチリージョンには考慮すべき点が多くありますが、ゼロ以外のRPOと、同じリージョン内でAZを退避する場合と比べて、潜在的に長いRTO（Recovery Time Objective）が発生する可能性があります。
リージョン内では、強力な一貫性を実現できます。S3での強力な一貫性、DynamoDBでの強力な一貫性のある読み取り、マルチAZ RDSでの強力な一貫性、EBSボリュームのクラッシュ整合性のあるスナップショットなどがあります。つまり、単一のリージョン内でRPOゼロを達成できるのです。そして、おそらくすでに複数のアベイラビリティーゾーンにデプロイされているため、新しいリソースを起動するのに時間はかかりません。ここで、static stabilityと呼ばれるパターンについて少し触れてみましょう。static stabilityとは、障害から回復するために変更や更新を行う必要がないことを意味します。EC2フリートの場合、アベイラビリティーゾーンの障害に対してstatically stableであるということは、1つのアベイラビリティーゾーンの損失に対応できるよう、他の2つのAZで事前にプロビジョニングされているということです。
このように構成されていれば、つまりアーキテクチャがこのように設定されていれば、ほぼゼロに近いRTOで回復できます。障害の検出にはまだ時間がかかるため、完全にゼロのRTOを達成することはできませんが、環境に変更を加える必要がなく、単に1つのAZからトラフィックを除去するだけで済むため、はるかに速く回復できます。そこで、これから説明するのは、データ損失なしで、より迅速に回復するために、単一のアベイラビリティーゾーンをどのように退避させるかということです。
コントロールプレーンとデータプレーン：AZ退避の観点から
AZの退避には2つの目標があります。1つ目の目標は、そのアベイラビリティーゾーンでの作業処理を停止することです。HTTPやgRPCリクエスト、あるいはシステムが行うどのような種類の作業であれ、そのAZに向かわないようにしたいのです。バッチ処理タイプのワークロードであれば、そのAZでのバッチ処理を停止したいと考えます。どのような種類の作業であれ、障害が発生している場所では行いたくありません。2つ目の目標は、長期間のイベントの場合、そのAZに新しいキャパシティをデプロイすることを停止することです。例えば、Auto Scalingを使用している場合、作業処理を停止したAZに新しいインスタンスをデプロイしないようにしたいかもしれません。必要だったためにAuto Scalingが起動したそのキャパシティは、実際には負荷を分担しないからです。これはECS、EKS、ポッド、コンテナでも同じです。退避したばかりのAZにそれらを引き続きデプロイしたくないかもしれません。
AZの退避について議論すべき2つの主要な考慮事項があります。1つ目は、アベイラビリティーゾーン独立性と呼ばれるアーキテクチャ上の概念です。AZから完全にトラフィックをシフトするためには、アーキテクチャがAZ独立である必要があります。つまり、そのアベイラビリティーゾーンに配信されるトラフィックを、そのアベイラビリティーゾーン内に留めておく必要があるのです。
Elastic Load Balancing (ELB)のロードバランサーについて考えると、Network Load BalancerとApplication Load Balancerの両方で、クロスゾーンロードバランシングを有効または無効にするオプションがあります。AZ独立のアーキテクチャを持つためには、クロスゾーンロードバランシングを無効にする必要があります。そうすることで、あるAZでトラフィックを受け取るロードバランサーノードは、同じアベイラビリティーゾーン内のインスタンスやリソースにのみトラフィックを送信します。これは、アーキテクチャ全体の他のすべての相互作用にも当てはまります。
例えば、VPC endpointsでは、サービス名に一致するトップレベルのDNS名を提供しますが、同時に可用性ゾーン固有のDNS名も提供しています。これは、1つのAZでの障害が他の可用性ゾーンに波及することを防ぐためです。AZ1に問題があり、そこのVPC endpointがトラフィックをドロップしているとしても、AZ3のインスタンスがAZ1のVPC endpointを使用することは望ましくありません。私たちは、インスタンスが自身の可用性ゾーン内のendpointを使用することを望んでいます。このようにすることで、障害のあるコンテナ、つまり可用性ゾーンを完全に切り離し、他の可用性ゾーンへの影響を防ぐことができます。
可用性ゾーン独立型のアーキテクチャを構築する際に最も注意すべき点は、データベースのリードレプリカです。Amazon RDSのプライマリインスタンスでは、別のリードレプリカに手動でフェイルオーバーする機能があります。AZ1に問題があり、RDSインスタンスがAZ1にある場合、AZ2やAZ3の別のレプリカにフェイルオーバーできます。しかし、リードレプリカの場合、制御できません。AZ1からAZ2へのリードレプリカのフェイルオーバーはありません。同じAZ内でトラフィックを維持したい場合、リードレプリカを使用するなら、AZごとにリードレプリカを設定する必要があります。
リードレプリカを使用する場合、各可用性ゾーンにリードレプリカを配置し、インスタンスが自身のAZ内のリードレプリカに接続するためのエンドポイントを知るためのサービスディスカバリメカニズムが必要です。これをSSM Parameter Storeに保存したり、DNSを使用したり、AWS Cloud Mapをサービスディスカバリに使用したり、その他のデータの保存とアクセス方法を探ることができます。重要なのは、効果的に避難できるよう、すべてをAZ内で分離しておくことです。
次に考慮すべき点は、コントロールプレーンとデータプレーンです。AWSサービスのコントロールプレーンは、リソースの作成、更新、削除、変更を担当するソフトウェアの部分です。ほとんどのCRUD（Create, Read, Update, Delete）アクションがこのカテゴリに該当します。一方、データプレーンはリソースの日常的なビジネスを提供します。例えば、Amazon S3では、バケットの作成はコントロールプレーンのアクションですが、オブジェクトの取得や配置はデータプレーンのアクションです。
Amazon EC2インスタンスを起動する際、EC2 run instancesはコントロールプレーンのアクションであり、バックグラウンドで多くのことが起こります。容量のある物理ホストを見つけ、Amazon EBSボリュームをセットアップし、IAM認証情報を設定し、セキュリティグループを更新して割り当てる必要があります。コントロールプレーンは、より複雑なシステムでより多くの依存関係を持つ傾向があります。そのため、データプレーンと比較して、統計的に障害が発生する可能性が高くなります。私たちは、データプレーンへの依存の方が、コントロールプレーンへの依存よりも信頼性が高いと考えています。
より高いレベルで考えると、変更する必要のないものは、障害に対応して変更しなければならないものよりも信頼性が高いと考えられます。最終的に、私たちの復旧パスでは、できる限りデータプレーンに依存しようとしています。常に可能というわけではありませんが、復旧パスでデータプレーンのアクションを使用できれば、コントロールプレーンよりも信頼性が高いと考えています。 それでは、データプレーンを使用してアベイラビリティーゾーンを退避させる方法を見てみましょう。
Amazon Route 53 Application Recovery Controllerを用いたAZ退避
昨年、Amazon Route 53 Application Recovery Controllerの機能として、zonal shiftをリリースしました。zonal shiftを使用すると、クロスゾーンロードバランシングが無効になっているApplication Load BalancerやNetwork Load Balancerに対して、アベイラビリティーゾーンIDとリソースIDを指定し、そのアベイラビリティーゾーンへのトラフィック送信を停止できます。内部的には、DNSを操作しているだけです。指定したAZにあるそのロードバランサーノードのIPアドレスを返さないようにします。zonal shiftを実行すると、各AZにエンドポイントを持つ単一のNetwork Load Balancerのノードに対して、www.example.comへのDNS要求に応答する際にそのIPアドレスを削除します。
ここではAZ独立のアーキテクチャを採用しているため、AZ3へのトラフィックはなくなり、AZ1とAZ2でのみ顧客のワークロードを処理します。これが、アベイラビリティーゾーンを退避させる最もシンプルで低コストなオプションです。
しかし、AZの健全性を一元的に把握したいと思うかもしれません。多くの顧客と話をしましたが、彼らはプラットフォームチームが独立したアプリケーションチームすべてに「AZ1の調子が悪いようなので、おそらくそのアベイラビリティーゾーンから退避すべきだ」と伝えられるようにしたいと考えています。ビジネスにおける数十、数百、あるいは数千のアカウントに対してzonal shiftを実行しようとするのではなく、集中管理されたAPIを作成することができます。これは、Amazon API GatewayやAmazon DynamoDBのようなものを使用して非常にシンプルに実現できます。
この場合、API GatewayとDynamoDBの間に統合を設けています。APIを呼び出すと、DynamoDBテーブルからアイテムを取得します。DynamoDBテーブルには、AZ IDとそれが健全とみなされるかどうかのキーバリューだけが格納されています。そして、Amazon Route 53ヘルスチェックをAPI Gatewayエンドポイントに向けます。Route 53ヘルスチェックはRoute 53のデータプレーンの一部であり、コントロールプレーンに依存しません。
これらの各ロードバランサーノードについて、ゾーンDNS名を使用します。つまり、各Network Load BalancerとApplication Load Balancerには、US-East-1A.my-load-balancer.elbなどのようなDNS名があります。これらの各ゾーンレコードに対してDNSレコードを指定し、API Gatewayエンドポイントにヘルスチェックを向けることができます。グレーフェイルが発生していると思われるアベイラビリティーゾーンを退避させたい場合、DynamoDBテーブルのhealthy値をfalseに設定します。これによりRoute 53のヘルスチェックが失敗し、そのDNSレコードを返さなくなります。
実質的に、これはzonal shiftが行っていることと同じ効果を得られます。しかし、この方法では多くのチームがこれに依存してアクセスできるようになります。Route 53のヘルスチェックだけでなく、他のタイプのシステムでこの値をチェックして対応することもできます。必ずしもヘルスチェックである必要はありません。
これらは、データプレーンのアクションのみを使用する2つの異なるパターンです。API Gatewayエンドポイントを呼び出し、DynamoDBからアイテムを取得するなど、すべてデータプレーンの一部です。どちらもAZの退避を実行する非常に信頼性の高い方法です。ただし、場合によってはコントロールプレーンを使用する必要があるかもしれません。
コントロールプレーンを使用したAZ退避の実装例
どのような場合にこれが必要になるでしょうか？例えば、このようなアーキテクチャがあるとします。ロードバランサーを全く使用せず、キューに基づいてスケーリングするAuto Scaling groupがあります。これらはAmazon Simple Queue Service (SQS)キューからメッセージを取得し、そのメッセージに基づいて処理を行います。
このようなアーキテクチャでAZを退避させるにはどうすればよいでしょうか？これは非常に規範的なパターンではありません。むしろ、自分で書いて呼び出すことができる高レベルなものになります。この場合、オペレーターがローカルスクリプトを実行します。 ローカルスクリプトを実行する理由は、リカバリーパスの依存関係をできるだけ減らすためです。リカバリーに依存するものが少ないほど、そのリカバリーが機能する確率が高くなります。他のサービスやサードパーティのシステムに依存していて、そのシステムが調子悪い日だった場合、リカバリーの実行が妨げられる可能性があります。
さて、このスクリプトを実行するオペレーターがいます。このスクリプトが基本的に行うのは、指定したタイプのリソース、この場合はAuto Scaling groupをすべてリストアップすることです。スクリプトで提供されたAZ IDとサブネットのAvailability Zone IDを比較して、ネットワーク構成から削除する必要があるサブネットを特定します。Availability Zone IDとリソース名またはARN、そして削除したサブネットをDynamoDBテーブルに記録します。DynamoDBテーブルでも、他のものでも構いません。ローカルファイル、CSVなどでも良いでしょう。これを行う理由は、後でこの操作を元に戻せるようにするためです。削除するサブネットを知るのは簡単ですが、一度削除してしまうと、それらを再び追加する方法の記録がなくなってしまいます。そのため、元に戻す方法を知るために記録を取ります。最後に、リソースのネットワーク構成を更新します。
実際にAPIを呼び出して、ネットワーク構成からそれらのサブネットを削除します。Auto Scalingの場合、ネットワーク構成からサブネットを削除すると、残りのAvailability Zones (AZs)で新しいインスタンスを起動します。離脱したAZにあるインスタンスは終了させます。これはAuto Scaling groupの構成を更新するコントロールプレーンのアクションです。しかし、これによって影響を受けたAvailability Zoneでの処理を停止し、そのキャパシティを削除することができます。
AZの障害が解消されたときなど、この操作を元に戻して復旧したい場合は、同じスクリプトを呼び出しますが、今回は「evacuate」ではなく「recover」を指定します。削除したすべてのサブネットを取得します。先ほど行ったすべての作業を確認します。テーブルに記録した各リソースを詳細に調べます。現在のネットワーク構成と削除されたサブネットを組み合わせます。そのネットワーク構成を更新し、実際にリソースの構成を変更します。最後に、更新後にレコードを削除します。
これはべき等な操作です。つまり、何回実行しても、常に同じ結果になります。したがって、スクリプトが途中で失敗して、テーブルからレコードの削除を忘れたとしても、再度実行すれば、以前に構成されていた最大のサブネットのみが追加されます。サブネットがすでにネットワーク構成に存在する場合は、変更する必要はありません。
グレー障害対策のまとめと参考リソース
では、まとめましょう。グレー障害とは何かについて話し始めました。グレー障害は、差分的観測性という考え方で定義されます。これは、健全性が異なる視点から異なって観察されることを意味します。お客様として、影響を受けているまたは不健全な何かを見ることがあるかもしれませんが、基盤となるシステムはそれを認識していません。私たちが行いたいのは、グレー障害を検出された障害に変えることです。これは、お客様のシステムやカスタマーエクスペリエンス、そして使用している依存関係にも当てはまるかもしれません。グレーのままにしておきたくありません。検出されるようにしたいのです。
そのためには、自ら行動を起こす必要があります。基盤となるサービスに頼るだけでは不十分です。グレーフェイルに対して耐性を持つためには、それらを検出し修正するための観測性とミティゲーションツールを構築する必要があります。そのためには特に、 メトリクスが障害分離境界に沿った次元で充実していることが重要です。AZ1に固有のメトリクス、AZ2に固有のメトリクス、AZ3に固有のメトリクスがなければ、AZ1に影響が出ていることを知るのは非常に困難です。リージョンレベルで集計されたデータしかない場合、可用性の低下や遅延の増加の原因を特定することは不可能でしょう。
つまり、ロードバランサーやAmazon EC2のヘルスチェックだけでは不十分ということです。これを実現するには、より高度なシステムを構築する必要があります。検出には、 外れ値検出と複合アラームの組み合わせを使用したいと思います。そして最後に、実際に退避を行うには、 可能な限りコントロールプレーンよりもデータプレーンを優先したいと考えています。
いくつかの参考リソースをご紹介します。 外れ値検出についてのブログ、適切なタイプのヘルスチェックの使用に関する記事（ヘルスチェックについてより詳しく説明しています）、ヘルスチェックに関するWell-Architectedラボ、今話したことすべてについてより詳しく説明している「Advanced Multi-AZ Resilience Patterns」というホワイトペーパーがあります。また、ワークショップもあります。グレーフェイルの作成、体験、検出、緩和について実践的に学びたい方向けです。まだ空きがあれば、今日の午後5時から実際にワークショップが開催されますので、そこで実践的に学ぶことができます。
AWSのレジリエンス関連サービスと結び
最後に、resilience lifecycle frameworkを立ち上げたことをお伝えしたいと思います。これは、お客様がレジリエンスを理解するための標準的な方法です。このフレームワークの中でグレーフェイルの検出と緩和について考えると、5つの異なる領域があります。設計、実装、運用フェーズでは、単一ホストおよび単一Availability Zoneのグレーフェイルに対する検出と緩和技術の作成について考えます。
また、これに役立つレジリエンス向けの多くの専用オファリングもあります。AWS Resilience Hubを使用すると、アプリケーションのコンポーネントを分析して、潜在的なレジリエンスの弱点を発見できます。AWS Fault Injection Simulatorを使用して、単一ホストまたは単一AZの障害をシミュレートできます。データ保護にはAWS Elastic Disaster RecoveryとAWS Backupがあります。そして、Availability Zoneの緩和と退避に使用する主な機能またはサービスの1つが、ゾーンシフト機能を持つAmazon Route 53 Application Recovery Controllerです。このように、この旅をサポートするさまざまな機能があります。
以上で終わりです。皆様、本日はご来場いただき誠にありがとうございました。
※ こちらの記事は Amazon Bedrock を様々なタスクで利用することで全て自動で作成しています。
※ どこかの機会で記事作成の試行錯誤についても記事化する予定ですが、直近技術的な部分でご興味がある場合はTwitterの方にDMください。
Discussion