翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # グレー障害 グレー障害は、[https://doi.org/10.1145/3102980.3103005](https://doi.org/10.1145/3102980.3103005)という特性によって定義されます。これは、異なるエンティティは異なる視点で障害を観測することを意味します。これが何を意味するのかを定義しましょう。 ## 視点別のオブザーバビリティ 通常、操作するワークロードには依存関係があります。例えば、これらは、ワークロードの構築に使用する AWS クラウドサービス、またはフェデレーションに使用するサードパーティの ID プロバイダー (IdP) の場合があります。これらの依存関係は、ほとんどの場合、独自のオブザーバビリティを実装し、エラー、可用性、レイテンシーなどに関するメトリクスを記録して、カスタマーの使用状況によって生成されます。これらのメトリクスのいずれかでしきい値を超えると、通常、依存関係は何らかのアクションを実行してそれを修正します。 これらの依存関係には通常、サービスのコンシューマーが複数存在します。また、コンシューマーは独自のオブザーバビリティを実装し、依存関係とのやり取りに関するメトリクスとログを記録し、ディスク読み取りのレイテンシー、失敗した API リクエストの数、データベースクエリに要した時間などを記録します。 これらのやり取りと測定については、次の図の抽象モデルに示されています。 ![\[グレー障害を理解するための抽象モデルを示す図\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/advanced-multi-az-resilience-patterns/images/gray-failures-model.png) まず、このシナリオでは、コンシューマーアプリ 1、アプリ 2、アプリ 3 の依存関係である*システム*が存在します。このシステムには、コアビジネスプロセスから作成されたメトリクスについて検証する障害ディテクターがあります。また、障害ディテクターで検出された問題を軽減または修正する障害対応メカニズムも備えています。システム全体の平均レイテンシーは 53 ミリ秒で、平均レーテンシーが 60 ミリ秒を超えると障害応答メカニズムを呼び出すためのしきい値が設定されています。アプリ 1、アプリ 2、アプリ 3 もシステムとのやり取りについて独自のオブザベーションを行い、それぞれ 50 ミリ秒、53 ミリ秒、56 ミリ秒の平均レイテンシーを記録しています。 視点別のオブザーバビリティとは、システムコンシューマーの 1 つがシステムの異常を検出しても、システム自体の監視では問題が検出されないか、影響がアラームのしきい値を超えない状況です。アプリ 1 の平均レイテンシーが 50 ミリ秒ではなく 70 ミリ秒になったとしましょう。アプリ 2 とアプリ 3 の平均レイテンシーに変化は見られません。これにより、基礎となるシステムの平均レイテンシーは 59.66 ミリ秒に増加しますが、障害対応メカニズムを有効化するレイテンシーのしきい値を超えることはありません。ただし、アプリ 1 のレイテンシーは 40% 増加しています。これにより、アプリ 1 に設定されたクライアントタイムアウトを超えることで可用性に影響が出たり、より長い一連のやり取りで影響が連鎖的に発生する可能性があります。アプリ 1 から見ると、依存している基盤となるシステムに異常があるものの、アプリ 2 とアプリ 3 と同様にシステム自体から見た場合、システムは正常です。次の図は、これらの異なる視点をまとめたものです。 ![\[異なる視点に基づいてシステムがどのような状態になるかを示した図\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/advanced-multi-az-resilience-patterns/images/states-based-on-perspectives.png) 障害はこの象限を超えることもあります。イベントは、グレー障害として始まり、次に検出された障害になり、その後マスクされた障害に移行してから、グレー障害に戻ることもあります。サイクルが決まっているわけではなく、根本原因が解決されるまで、ほとんどの場合、障害が再発する可能性があります。 このことから導き出された結論は、ワークロードは、障害を検出し、軽減する基盤となるシステムに常に依存できるとは限らないということです。基盤となるシステムがどれほど洗練され、回復力に優れていても、障害が検出されなかったり、反応しきい値を下回る可能性が常にあります。アプリ 1 など、このシステムのコンシューマーには、グレー障害が引き起こす影響を迅速に検出し、軽減する機能が必要です。これには、こうした状況に対応するオブザーバビリティおよび復旧のメカニズムを構築する必要があります。 ## グレー障害の例 グレーの障害は、AWS のマルチ AZ システムに影響する可能性があります。例えば、3 つのアベイラビリティーゾーンにデプロイされた Auto Scaling グループの [Amazon EC2](https://aws.amazon.com/ec2/) インスタンスのフリートがあるとします。これらはすべて 1 つのアベイラビリティーゾーンの Amazon Aurora データベースに接続しています。そこで、アベイラビリティーゾーン 1 とアベイラビリティーゾーン 2 の間のネットワークに影響するグレー障害が発生したとします。この障害の結果、アベイラビリティーゾーン 1 のインスタンスからの新規および既存のデータベース接続の一部が失敗します。このアーキテクチャを次の図に示します。 ![\[グレー障害がデータベース接続に与える潜在的な影響を示す図。\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/advanced-multi-az-resilience-patterns/images/potential-gray-failure-impact.png) この例では、Amazon EC2 は、[システムとインスタンスのステータスのチェック](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-system-instance-status-check.html)を引き続きパスしているため、アベイラビリティーゾーン 1 のインスタンスは正常と見なします。また、Amazon EC2 Auto Scaling はどのアベイラビリティーゾーンへの直接的な影響も検出せず、[設定されたアベイラビリティーゾーンでキャパシティを起動](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html)し続けます。また、Network Load Balancer (NLB) は、NLB エンドポイントに対して実行される Route 53 ヘルスチェックと同様に、その背後にあるインスタンスも正常であると見なします。同様に、Amazon Relational Database Service (Amazon RDS) は、データベースクラスターが正常であると見なし、[自動フェイルオーバーをトリガー](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html)しません。多くの異なるサービスが存在し、それらすべてがサービスとリソースを正常と見なしていても、ワークロードはその可用性に影響する障害を検出します。これがグレー障害です。 ## グレー障害への対応 AWS 環境にグレー障害が発生したとき、一般的に次の 3 つのオプションを使用できます。 + 何もしないで、障害が終了するのを待ちます。 + 障害が 1 つのアベイラビリティーゾーンに分離されている場合は、そのアベイラビリティーゾーンから退避します。 + 別の AWS リージョン にフェイルオーバーし、AWS リージョンの分離を活用して影響を軽減します。 多くの AWS カスタマーは、ほとんどのワークロードでオプション 1 を使用しても問題ありません。カスタマーは、追加のオブザーバビリティや回復力のソリューションを構築する必要はなくなる代わりに、[目標復旧時間 (RTO)](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/disaster-recovery-dr-objectives.html) が長くなる可能性を受け入れます。中には、3 番目のオプションである [マルチリージョンのディザスタリカバリ](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-i-strategies-for-recovery-in-the-cloud/) (DR) を、さまざまな障害モードに対する緩和策として実装することを選択するカスタマーもいます。マルチリージョンアーキテクチャは、このようなシナリオでうまく機能します。ただし、この方法を使用する場合にはいくつかのトレードオフがあります (マルチリージョンの考慮事項についての詳しい説明は「[AWS マルチリージョンの基礎](https://docs.aws.amazon.com/whitepapers/latest/aws-multi-region-fundamentals/aws-multi-region-fundamentals.html)」を参照)。 まず、マルチリージョンアーキテクチャの構築と運用は困難かつ複雑で、コストがかかる可能性があります。マルチリージョンアーキテクチャでは、どの [DR 戦略](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html)を選ぶかについて慎重に検討する必要があります。ゾーンの障害に対処するためだけにマルチリージョンのアクティブ/アクティブ DR ソリューションを実装するのは、経済的に実現可能ではないかもしれません。一方、バックアップと復元の戦略は、回復力の要件を満たさない可能性があります。さらに、必要なときに確実に機能するように、マルチリージョンのフェイルオーバーを本番環境で継続的に実施する必要があります。これらすべてにおいて、構築、運用、テストに多くの時間とリソースが必要です。 次に、現在 AWS のサービスを使用した AWS リージョン 間のデータレプリケーションは、非同期で行われます。非同期レプリケーションに伴ってデータが失われる可能性があります。つまり、リージョン間のフェイルオーバー中に、ある程度のデータ損失や不整合が発生する可能性があります。データ損失量に対する許容範囲は、[目標復旧時点](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/disaster-recovery-dr-objectives.html) (RPO) として定義します。確かなデータ整合性が必須であるカスタマーは、プライマリリージョンが再び利用可能になったときに、これらの一貫性の問題を解決するための調整システムを構築する必要があります。または、独自の同期レプリケーションシステムや二重書き込みシステムを構築する必要があり、これらは応答遅延、コスト、複雑さに大きな影響を与える可能性があります。また、セカンダリリージョンがすべてのトランザクションに対してハード依存関係になるため、システム全体の可用性が低下する可能性があります。 最後に、アクティブ/スタンバイアプローチを使用する多くのワークロードでは、別のリージョンへのフェイルオーバーの実行に要する時間はゼロではありません。場合によっては、ワークロードのポートフォリオをプライマリリージョンで特定の順序で切断したり、接続をドレインしたり、または特定のプロセスを停止する必要があります。その後、特定の順序でサービスを再開しなければならない場合があります。また、新しいリソースをプロビジョニングする必要がある場合や、サービス開始前に必要なヘルスチェックをパスするまでに時間がかかる場合もあります。このフェイルオーバー処理は、完全に利用できない期間として行われる可能性があります。これが RTO が懸念されることです。 リージョン内では、AWS の多くのサービスが強力な整合性のあるデータの永続性を提供します。Amazon RDS マルチ AZ 配置では[同期レプリケーション](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html)を使用します。[Amazon Simple Storage Service](https://aws.amazon.com/s3/) (Amazon S3) は、[強力な書き込み後の読み取り整合性](https://aws.amazon.com/blogs/aws/amazon-s3-update-strong-read-after-write-consistency/)を提供します。[Amazon Elastic Block Storage](https://aws.amazon.com/ebs/) (Amazon EBS) は、[マルチボリュームの Crash-consistent スナップショット](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-creating-snapshot.html#ebs-create-snapshot-multi-volume)を提供します。[Amazon DynamoDB](https://aws.amazon.com/dynamodb/) では、[強力な整合性のある読み込み](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.ReadConsistency.html)を実行できます。これらの機能により、マルチリージョンアーキテクチャで達成できるよりも低い RPO (ほとんどの場合 RPO はゼロ) を単一のリージョンで達成できます。 インフラストラクチャとリソースはすでにアベイラビリティーゾーン全体でプロビジョニングされているため、アベイラビリティーゾーンを退避する方がマルチリージョン戦略よりも RTO が低くなる可能性があります。マルチ AZ アーキテクチャは、アベイラビリティーゾーンに障害が発生しても、サービスの停止とバックアップの順序付けを慎重に行ったり、接続をドレインする必要はなく、静的に動作し続けることができます。リージョン間のフェイルオーバーでは完全に利用不能になる期間が発生する場合がありますが、アベイラビリティーゾーン間の退避中は、作業が残りのアベイラビリティーゾーンにシフトされるため、多くのシステムではわずかな機能低下で済む場合があります。システムがアベイラビリティーゾーンの障害に対して[静的に安定する](https://aws.amazon.com/builders-library/static-stability-using-availability-zones)ように設計されている場合 (この場合、これは負荷を吸収するために他のアベイラビリティーゾーンにキャパシティがあらかじめプロビジョニングされていることを意味します)、ワークロードのカスタマーにはまったく影響がない可能性があります。 **** 1 つのアベイラビリティーゾーンの障害がワークロードに加えて 1 つまたは複数の AWS [リージョンサービス](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/regional-services.html)に影響を与える可能性があります。リージョンへの影響が観測された場合は、その影響の原因が単一のアベイラビリティーゾーンにあったとしても、そのイベントをリージョンサービスの障害として扱う必要があります。アベイラビリティーゾーンを退避させても、この種の問題は軽減されません。これが発生した場合は、リージョンのサービス障害に対して準備している対応計画を使用してください。 このドキュメントの残りの部分では、シングル AZ のグレー障害に対して RTO と RPO を低く抑える方法として、2 つ目のオプションであるアベイラビリティーゾーンからの退避に焦点を当てます。これらのパターンは、マルチ AZ アーキテクチャの価値と効率を高めるのに役立ち、ほとんどのクラスのワークロードで、これらの種類のイベントに対処するためにマルチリージョンアーキテクチャを構築する必要性を軽減できます。