翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# マルチ AZ の可観測性
1 つのアベイラビリティーゾーンに分離されたイベント中にアベイラビリティーゾーンから退避するには、まず、障害が 1 つのアベイラビリティーゾーンに実際に分離されていることを検出できる必要があります。そのためには、各アベイラビリティーゾーンでシステムの動作を忠実に可視化する必要があります。AWS の多くのサービスには、リソースに関する運用上のインサイトを提供する、すぐに使えるメトリクスが用意されています。例えば、Amazon EC2 には、CPU 使用率、ディスクの読み取りと書き込み、ネットワークトラフィックの送受信など、多数のメトリクスがあります。
ただし、これらのサービスを使用するワークロードを構築する場合は、これらの標準メトリクスだけでなく、追加の可視性が必要となります。ワークロードが提供するカスタマーエクスペリエンスへの可視性が必要です。さらに、メトリクスをそれらが生成されるアベイラビリティーゾーンに合わせる必要があります。これこそが、視点別の観測可能なグレー障害を検出するために必要なインサイトです。このレベルの可視性には、インストルメント化が必要です。
インストルメント化では、明示的なコードを記述する必要があります。このコードは、タスクにかかった時間の記録、成功または失敗した項目の数のカウント、リクエストに関するメタデータの収集などを行う必要があります。また、事前にしきい値を定義して、何を正常と見なし、何を正常と見なさないかを定義する必要があります。ワークロードのレイテンシー、可用性、エラー数の目標とさまざまな重要度のしきい値を定義する必要があります。Amazon Builders' Library の記事「[運用の可視性を高めるために分散システムを装備する](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)」には、さまざまなベストプラクティスが記載されています。
メトリクスは、サーバー側とクライアント側の両方から生成する必要があります。クライアント側のメトリクスを生成してカスタマーエクスペリエンスを理解するには、ワークロードを定期的に調査してメトリクスを記録するソフトウェアである [canary](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) を使用するのがベストプラクティスです。
これらのメトリクスを作成することに加えて、そのコンテキストも理解する必要があります。その 1 つの方法は、[ディメンション](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Dimension)を使用することです。ディメンションは、メトリクスに独自のアイデンティティを与え、メトリクスが何を伝えているかを説明するのに役立ちます。ワークロードの障害を特定するためのメトリクス (レイテンシー、可用性、エラー数など) には、[障害分離境界](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/use-fault-isolation-to-protect-your-workload.html)に合わせたディメンションを使用する必要があります。
例えば、[モデルビューコントローラー](https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller) (MVC) の Web フレームワークを使用して、1 つのリージョンで複数のアベイラビリティーゾーンにまたがる Web サービスを実行している場合、ディメンションセットのディメンションとして `Region`、[https://docs.aws.amazon.com/ram/latest/userguide/working-with-az-ids.html](https://docs.aws.amazon.com/ram/latest/userguide/working-with-az-ids.html)、`Controller`、`Action`、および `InstanceId` を使用する必要があります (マイクロサービスを使用している場合は、コントローラ名とアクション名の代わりにサービス名と HTTP メソッドを使用します)。これは、さまざまなタイプの障害が、これらの境界で分離されることが望ましいためです。ウェブサービスのコードのバグが商品の出品に影響を与えている場合、このバグがホームページにも影響を与えることは望ましくありません。同様に、1 つの EC2 インスタンスの EBS ボリューム全体が、他の EC2 インスタンスによるウェブコンテンツの提供に影響を与えることは望ましくありません。アベイラビリティーゾーンの ID ディメンションを使用すると、AWS アカウント全体でアベイラビリティーゾーンに関連する影響を一貫して特定できます。ワークロード内のアベイラビリティーゾーン ID は、いくつかの方法で確認できます。一部の例については、「[付録 A — アベイラビリティーゾーン ID の取得](appendix-a-getting-the-availability-zone-id.md)」を参照してください。
このドキュメントでは、例の中で主に Amazon EC2 をコンピューティングリソースとして使用していますが、`InstanceId` は、ディメンションのコンポーネントとして [Amazon Elastic Container Service](https://aws.amazon.com/ecs/) (Amazon ECS) コンピューティングリソースおよび [Amazon Elastic Kubernetes Services](https://aws.amazon.com/eks/) (Amazon EKS) コンピューティングリソースのコンテナ ID に置き換えることができます。
ワークロードにゾーンエンドポイントがある場合、canary では、`Controller`、`Action`、`AZ-ID`、`Region` をメトリクスのディメンションとして使用することもできます。この場合、テスト中のアベイラビリティーゾーンで実行するように canary を調整します。これにより、分離されたアベイラビリティーゾーンのイベントが canary を実行しているアベイラビリティーゾーンに影響を与えている場合でも、テスト中の別のアベイラビリティーゾーンに異常があるように見せるメトリクスは記録されなくなります。例えば、canary では、Network Load Balancer (NLB) または Application Load Balancer (ALB) の背後にあるサービスの各ゾーンのエンドポイントを、その [ゾーンの DNS 名](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/network-load-balancers.html#dns-name)を使用してテストできます。
![\[CloudWatch Synthetics で実行している canary、または NLB の各ゾーンのエンドポイントをテストする AWS Lambda 機能を示す図\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/advanced-multi-az-resilience-patterns/images/canary-testing-for-zonal-impact.png)
これらのディメンションを使用してメトリクスを生成することで、これらの境界内で可用性やレイテンシーに変化が生じたときに通知する [Amazon CloudWatch アラーム](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)を設定できます。また、[ダッシュボード](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)を使用してそのデータをすばやく分析することもできます。メトリクスとログの両方を効率的に使用するために、Amazon CloudWatch にはカスタムメトリクスをログデータに埋め込むことができる[埋め込みメトリクスフォーマット](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Embedded_Metric_Format.html) (EMF) が用意されています。CloudWatch はカスタムメトリクスを自動的に抽出するため、これらを視覚化してアラームを発行できます。AWS には、EMF を簡単に開始できるように、さまざまなプログラミング言語用の[クライアントライブラリ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Embedded_Metric_Format_Libraries.html)がいくつか用意されています。これらのライブラリは、Amazon EC2、Amazon ECS、Amazon EKS、[AWS Lambda](https://aws.amazon.com/lambda/)、およびオンプレミス環境で使用できます。ログにメトリクスが埋め込まれていると、[Amazon CloudWatch Contributor Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContributorInsights.html) を使用してコントリビューターデータを表示する時系列グラフを作成することもできます。このシナリオでは、`AZ-ID`、`InstanceId`、または `Controller` などのディメンション、および `SuccessLatency` または `HttpResponseCode` などのログ内の他のフィールド別にグループ化されたデータを表示できます。
```
{
"_aws": {
"Timestamp": 1634319245221,
"CloudWatchMetrics": [
{
"Namespace": "workloadname/frontend",
"Metrics": [
{ "Name": "2xx", "Unit": "Count" },
{ "Name": "3xx", "Unit": "Count" },
{ "Name": "4xx", "Unit": "Count" },
{ "Name": "5xx", "Unit": "Count" },
{ "Name": "SuccessLatency", "Unit": "Milliseconds" }
],
"Dimensions": [
[ "Controller", "Action", "Region", "AZ-ID", "InstanceId"],
[ "Controller", "Action", "Region", "AZ-ID"],
[ "Controller", "Action", "Region"]
]
}
],
"LogGroupName": "/loggroupname"
},
"CacheRefresh": false,
"Host": "use1-az2-name.example.com",
"SourceIp": "34.230.82.196",
"TraceId": "|e3628548-42e164ee4d1379bf.",
"Path": "/home",
"OneBox": false,
"Controller": "Home",
"Action": "Index",
"Region": "us-east-1",
"AZ-ID": "use1-az2",
"InstanceId": "i-01ab0b7241214d494",
"LogGroupName": "/loggroupname",
"HttpResponseCode": 200,
"2xx": 1,
"3xx": 0,
"4xx": 0,
"5xx": 0,
"SuccessLatency": 20
}
```
このログには 3 つのディメンションのセットがあります。これらは、インスタンス、アベイラビリティーゾーン、リージョンの粒度の順に進んでいきます (この例では、`Controller` と `Action` が常に含まれます)。これらは、1 つのインスタンス、1 つのアベイラビリティーゾーン、または AWS リージョン全体で、特定のコントローラーのアクションに影響が生じた場合に知らせるアラームを、ワークロード全体にわたって作成することをサポートします。これらのディメンションは、2xx、3xx、4xx、5xx の HTTP 応答数のメトリクスと、成功したリクエストのレイテンシーのメトリクスに使用します (リクエストが失敗した場合、失敗したリクエストのレイテンシーのメトリクスも記録されます)。またログには、HTTP パス、リクエスト元のソース IP、このリクエストでローカルキャッシュを更新する必要があるかどうかなど、その他の情報も記録されます。これらのデータポイントを使用して、ワークロードが提供する各 API の可用性とレイテンシーを計算できます。
**可用性のメトリクスで HTTP 応答コードを使用することに関する注意。**
通常、2xx と 3xx の応答は成功、5xx は失敗と見なすことができます。4xx 応答コードは中間のいずれかの問題を示します。通常、これらはクライアントエラーが原因で生成されます。パラメータが範囲外であるために [400 応答](https://en.wikipedia.org/wiki/List_of_HTTP_status_codes)になったり、存在しないものをリクエストしたために 404 応答になったりします。これらの応答は、ワークロードの可用性に対してカウントされません。ただし、これはソフトウェアのバグが原因である可能性もあります。
例えば、より厳格な入力検証を導入したために、以前なら成功していたはずのリクエストが拒否された場合、400 応答は可用性の低下としてカウントされる可能性があります。または、顧客のスロットリングにより、429 応答が返される場合があります。顧客のスロットリングでサービスの可用性を維持することはできますが、顧客の観点からは、サービスが顧客のリクエストを処理できないことになります。4xx 応答コードを可用性の計算に含めるかどうかを決める必要があります。
このセクションでは、CloudWatch を使用してメトリクスを収集して分析する方法について説明しましたが、使用できるソリューションはこれだけではありません。Amazon Managed Service for Prometheus および Amazon Managed Grafana、Amazon DynamoDB テーブルにメトリクスを送信したり、サードパーティのモニタリングソリューションを使用したりすることもできます。重要なのは、ワークロードが生成するメトリクスには、ワークロードの障害分離境界に関するコンテキストが含まれている必要があるということです。
ワークロードで生成するメトリクスのディメンションを障害分離境界に合わせることで、アベイラビリティーゾーンの分離された障害を検出するオブザーバビリティを構築できます。以下のセクションでは、1 つのアベイラビリティーゾーンの障害から生じるエラーを検出するための 3 つの補完的な方法について説明します。
**Topics**
+ [CloudWatch 複合アラームによる障害検出](failure-detection-with-cloudwatch-composite-alarms.md)
+ [外れ値検出による障害検出](failure-detection-using-outlier-detection.md)
+ [単一インスタンスのゾーンリソースの障害検出](failure-detection-of-single-instance-zonal-resources.md)
+ [[概要]](summary.md)
# CloudWatch 複合アラームによる障害検出
CloudWatch メトリクスの場合、各ディメンションセットは一意のメトリクスであり、それぞれに CloudWatch アラームを作成できます。次に、[Amazon CloudWatch 複合アラーム](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Composite_Alarm.html)を作成し、これらのメトリクスを集約できます。
影響を正確に検出するために、このホワイトペーパーの例では、アラームの対象となるディメンションセットごとに 2 つの異なる CloudWatch アラーム構造を使用します。各アラームは 1 分間の**ピリオド**を使用します。つまり、メトリクスは 1 分に 1 回評価されます。1 つ目の方法では、**評価期間**および**アラームへのデータポイント**を 3 に設定して (合計 3 分間の影響)、3 つの連続する違反データポイントを使用します。2 つ目の方法では、**評価期間**を 5、**アラームへのデータポイント**を 3 に設定して、5 分間の時間枠内で 3 つのデータポイントが違反している場合に、「M out of N」という値を使用します。これにより、一定の信号だけでなく、短時間で変動する信号も検出できます。ここに記載されている期間とデータポイントの数はあくまでも目安です。ワークロードに適した値を使用してください。
## 1 つのアベイラビリティーゾーンで影響を検知する
このコンストラクトを使用して、`Controller`、`Action`、`InstanceId`、`AZ-ID`、および `Region` を使用するワークロードについて考えてみましょう。ワークロードには、Products と Home の 2 つのコントローラーがあり、コントローラーごとに 1 つのアクション、List と Index があります。このワークロードは、`us-east-1` リージョンの 3 つのアベイラビリティーゾーンで動作します。各アベイラビリティーゾーンの `Controller` と `Action` の各組み合わせの可用性について 2 つのアラームと、それぞれのレイテンシーについて 2 つのアラームを作成します。次に、オプションで、それぞれの `Controller` および`Action` の組み合わせの可用性について複合アラームを作成することもできます。最後に、アベイラビリティーゾーンのすべてのアベイラビリティアラームを集約する複合アラームを作成します。これについては、1 つのアベイラビリティーゾーン `use1-az1` に関する次の図で示しています。ここでは、それぞれの `Controller` と `Action` の組み合わせに対してオプションの複合アラームを使用しています (同様のアラームが `use1-az2` と `use1-az3` アベイラビリティーゾーンでも存在する場合がありますが、わかりやすくするために表示されていません)。
![\[use1-az1 の可用性に対する複合アラーム構造を示す図\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/advanced-multi-az-resilience-patterns/images/composite-alarm-structure-availability.png)
また、次の図に示すように、レイテンシーについても同様のアラーム構造を構築することになります。
![\[use1-az1 のレイテンシーの複合アラーム構造を示す図\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/advanced-multi-az-resilience-patterns/images/composite-alarm-structure-latency.png)
このセクションの残りの図では、`az1-availability` と `az1-latency` の複合アラームのみがトップレベルに表示されます。これらの複合アラーム `az1-availability` および `az1-latency` は、ワークロードのあらゆる部分において、可用性が特定のアベイラビリティーゾーンで定義済みのしきい値を下回るか、またはレイテンシーがそれを上回った場合に通知します。また、スループットを測定して、1 つのアベイラビリティーゾーンのワークロードが作業を受け付けるのを防止する影響を検出することも検討してください。canary によって発行されたメトリクスから生成されたアラームを、これらの複合アラームに統合することもできます。これにより、サーバー側またはクライアント側のどちらかで可用性やレイテンシーへの影響が確認された場合に、アラームによってアラートが作成されます。
## 影響がリージョンのものではないことを確認する
別の複合アラームのセットを使用して、分離されたアベイラビリティーゾーンのイベントのみにより、アラームをアクティブにすることができます。これを行うには、1 つのアベイラビリティーゾーンの複合アラームを `ALARM` 状態にし、その他のアベイラビリティーゾーンの複合アラームを `OK` 状態にします。これにより、使用するアベイラビリティーゾーンごとに 1 つの複合アラームが生成されます。次の図に例を示しています (`use1-az2`、`use1-az3`、`az2-latency`、`az2-availability`、`az3-latency`、および `az3-availability` のレイテンシーと可用性に関するアラームがあることに注意してください、ここでは簡略化のため画像は掲載していません)。
![\[1 つの AZ に隔離された影響を検出する複合アラーム構造を示す図\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/advanced-multi-az-resilience-patterns/images/composite-alarm-structure-impact.png)
## 影響が 1 つのインスタンスによるものではないことを確認する
1 つのインスタンス (またはフリート全体のごく一部) が可用性とレイテンシーのメトリクスに不均衡な影響を与える可能性があり、これによって、実際はそうではないのに、アベイラビリティーゾーン全体が影響を受けているように見えることがあります。アベイラビリティーゾーンを評価するよりも、問題のあるインスタンスを 1 つ削除するほう早く、効果的です。
通常、インスタンスとコンテナは一時的なリソースとして扱われ、[AWS Auto Scaling](https://aws.amazon.com/autoscaling/) などのサービスによく置き換えられます。新しいインスタンスが作成されるたびに新しい CloudWatch アラームを作成することは困難です (ただし、[Amazon EventBridge](https://docs.aws.amazon.com/autoscaling/ec2/userguide/cloud-watch-events.html) または [Amazon EC2 Auto Scaling ライフサイクルフック](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html)を使用すると、確実に可能です)。代わりに、[CloudWatch Contributor Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContributorInsights.html) を使用して、可用性とレイテンシーのメトリクスへの寄与要因の数を特定できます。
例えば、HTTP Web アプリケーションの場合、各アベイラビリティーゾーンで 5xx HTTP 応答に関する上位の寄与要因を特定するルールを作成できます。これにより、どのインスタンスが可用性の低下の原因となっているかが特定されます (上記で定義した可用性メトリクスは、5xx エラーの存在によって決まります)。EMF ログの例を使用して、`InstanceId` のキーでルールを作成します。次に、`HttpResponseCode` フィールドでログをフィルタリングします。次の例は `use1-az1` アベイラビリティーゾーンのルールです。
```
{
"AggregateOn": "Count",
"Contribution": {
"Filters": [
{
"Match": "$.InstanceId",
"IsPresent": true
},
{
"Match": "$.HttpStatusCode",
"IsPresent": true
},
{
"Match": "$.HttpStatusCode",
"GreaterThan": 499
},
{
"Match": "$.HttpStatusCode",
"LessThan": 600
},
{
"Match": "$.AZ-ID",
"In": ["use1-az1"]
},
],
"Keys": [
"$.InstanceId"
]
},
"LogFormat": "JSON",
"LogGroupNames": [
"/loggroupname"
],
"Schema": {
"Name": "CloudWatchLogRule",
"Version": 1
}
}
```
CloudWatch アラームは、これらのルールに基づいて作成することもできます。[Metric Math](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html) と `INSIGHT_RULE_METRIC` 関数を `UniqueContributors` メトリクスで使用して、Contributor Insights のルールに基づくアラームを作成できます。また、可用性のメトリクスに加えて、レイテンシーやエラー数などのメトリクスに対する CloudWatch アラームを使用して、追加の Contributor Insights ルールを作成することもできます。これらのアラームを、分離されたアベイラビリティーゾーンに対する影響の複合アラームと組み合わせて使用すると、1 つのインスタンスがアラームをアクティブにしていないことを確認できます。`use1-az1` のインサイトルールの メトリクスは、次のような場合があります。
```
INSIGHT_RULE_METRIC("5xx-errors-use1-az1", "UniqueContributors")
```
このメトリクスがしきい値 (この例では 2) を超えた場合のアラームを定義できます。5xx 応答に対する一意の寄与要因がこのしきい値を超えると、アラームがアクティブになり、2 つを超えるインスタンスから影響が生じていることを示します。このアラームで「より小さい」比較ではなく「より大きい」比較を使用する理由は、一意の寄与要因の値が 0 である場合にアラームを始動しないようにするためです。これにより、影響が単一のインスタンスからのものではないことがわかります。このしきい値は、ワークロードごとに調整します。一般的な目安は、この数をアベイラビリティーゾーンの総リソースの 5% 以上にすることです。サンプルのサイズが十分であれば、全体の 5% を超えるリソースが影響を受けた場合、統計的有意性を示します。
## まとめ
次の図は、1 つのアベイラビリティーゾーンの複合アラーム構造全体を示しています。
![\[1 つの AZ の影響を判断するための複合アラーム構造全体を示す図\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/advanced-multi-az-resilience-patterns/images/composite-alarm-structure-complete.png)
最後の複合アラーム「`use1-az1-isolated-impact`」は、レイテンシーまたは可用性からの分離されたアベイラビリティーゾーンの影響を示す `use1-az1-aggregate-alarm` が `ALARM` の状態であり、同じアベイラビリティーゾーンの Contributor Insights ルールに基づくアラーム `not-single-instance-use1-az1` も `ALARM` の状態である場合 (つまり、複数のインスタンスから影響が生じている場合) にアクティブになります。このアラームスタックは、ワークロードが使用するアベイラビリティーゾーンごとに作成します。
この最終アラームに、[Amazon Simple Notification Service](https://aws.amazon.com/sns/) (Amazon SNS) アラートをアタッチできます。以上のすべてのアラームは、アクションなしで設定しています。アラートは、手動調査を開始するよう E メールでオペレーターに通知できます。また、アベイラビリティーゾーンから退避するためのオートメーションを開始することもできます。ただし、これらのアラートに対応するためのオートメーションの構築には注意が必要です。アベイラビリティーゾーンからの退避が起きると、エラー率の増加が緩和され、アラームが `OK` 状態に戻ります。別のアベイラビリティーゾーンで影響が発生すると、オートメーションは 2 番目や 3 番目のアベイラビリティーゾーンからの退避も起こす場合があり、ワークロードの使用可能なすべての容量が削除される可能性があります。オートメーションでは、アクションを実行する前に、退避が既に実行されていないかどうかを確認する必要があります。退避を成功させるには、他のアベイラビリティーゾーンのリソースをスケールすることが必要になる場合もあります。
MVC Web アプリ、新しいマイクロサービス、または一般として個別に監視したい追加機能に新しいコントローラーやアクションを追加する場合、この設定ではいくつかのアラームを変更するだけで済みます。その新しい機能に新しい可用性アラームとレイテンシーアラームを作成し、それらを適切なアベイラビリティーゾーンに合わせた可用性とレイテンシーの複合アラームに追加します。ここで使用している例では、これらは `az1-latency` と `az1-availability` です。残りの複合アラームは、設定後も変化しません。これにより、この方法による新機能のオンボーディングプロセスがより簡単になります。
# 外れ値検出による障害検出
複数のアベイラビリティーゾーンで*相関性のない*理由で発生するエラー率が高くなっている場合、前述の方法とのギャップが 1 つ生じることがあります。3 つのアベイラビリティーゾーンに EC2 インスタンスをデプロイしていて、可用性アラームのしきい値が 99% であるシナリオを想像してみてください。その後、1 つのアベイラビリティーゾーンで障害が発生し、多くのインスタンスが分離され、そのゾーンの可用性が 55% まで低下します。同時に、別のアベイラビリティーゾーンでは、1 つの EC2 インスタンスが EBS ボリュームのストレージをすべて使い果たし、ログファイルを書き込めなくなります。これによりエラーが返され始めますが、ロードバランサーのヘルスチェックはログファイルの書き込みをトリガーしないため、それでもパスします。その結果、そのアベイラビリティーゾーンの可用性が 98% に低下します。この場合、複数のアベイラビリティーゾーンで可用性の影響が見られるため、1 つのアベイラビリティーゾーンの影響アラームは有効になりません。ただし、障害のあるアベイラビリティーゾーンを退避させることで、影響のほぼすべてを軽減することはできます。
ワークロードの種類によっては、前の可用性メトリクスが役に立たない可能性があるすべてのアベイラビリティーゾーンで、エラーが一貫して発生することがあります。例えば AWS Lambda の場合について検討してみましょう。AWS は、カスタマーが独自のコードを作成して Lambda 関数で実行できるようにします。このサービスを使用するには、依存関係を含むコードを ZIP ファイルにアップロードし、関数へのエントリポイントを定義する必要があります。しかし、カスタマーはこの部分を間違えることがあります。例えば、ZIP ファイルの重要な依存関係を忘れたり、Lambda 関数定義のメソッド名を間違えたりすることがあります。これにより、関数が呼び出されず、エラーが発生します。AWS Lambda では、この種のエラーは常に発生しますが、必ずしも異常であることを示すものではありません。ただし、アベイラビリティーゾーンの障害などが原因でこれらのエラーが表示されることもあります。
この種のノイズに含まれるシグナルを見つけるには、外れ値検出を使用して、アベイラビリティーゾーン間でエラー数に統計的に有意な偏りがあるかどうかを判断できます。複数のアベイラビリティーゾーンでエラーが見られるものの、そのうちの 1 つで本当に障害が発生した場合、そのアベイラビリティーゾーンでは他のアベイラビリティーゾーンに比べてエラー率が大幅に高くなるか、はるかに低くなる可能性があります。しかし、どれくらい高い、または低いのでしょうか。
この分析を行う方法の 1 つは、[カイ二乗](https://en.wikipedia.org/wiki/Chi-squared_test) (*χ*2) 検定を使用してアベイラビリティーゾーン間のエラー率の統計的に有意な差を検出することです ([外れ値検出を実行するためのさまざまなアルゴリズム](https://dataprocessing.aixcape.org/DataPreprocessing/DataCleaning/OutlierDetection/index.html)があります)。それでは、カイ二乗検定の仕組みを見てみましょう。
カイ二乗検定では、何らかの結果の分布が生じる確率を評価します。ここでは、一連の定義済みの AZ 全体にわたるエラーの分布を調べます。この例では、計算を簡単にするために、4 つのアベイラビリティーゾーンを考えてみます。
まず、帰無仮説を立てます。これにより、何をデフォルトの結果と信じるかを定義します。この検定では、帰無仮説として、エラーは各アベイラビリティーゾーンに均等に分布していると予想します。次に、エラーは均等に分布しておらず、アベイラビリティーゾーンの障害が示唆されているという*対立仮説*を立てます。これで、メトリクスのデータを使用して、これらの仮説を検定できるようになります。この目的のために、5 分間のウィンドウからメトリクスをサンプリングします。このウィンドウに 1,000 個の公開されたデータポイントがあり、合計で 100 個のエラーが確認されたとします。均等な分布では、4 つのアベイラビリティーゾーンのそれぞれで 25% の確率でエラーが発生すると予想されます。次の表は、予想した結果と実際の結果の比較を示しているものとします。
*表 1: 予想したエラーと実際に確認されたエラー*
| AZ | 予想 | 実際 |
| --- | --- | --- |
| use1-az1 | 25 | 20 |
| use1-az2 | 25 | 20 |
| use1-az3 | 25 | 25 |
| use1-az4 | 25 | 35 |
したがって、実際には分布が均等ではないことがわかります。ただし、サンプリングしたデータポイントにある程度のランダム性があったために、このような結果になったとも考えられます。この種の分布がサンプルセットで発生する可能性がある程度あると、帰無仮説がまだ成り立つ余地があります。これは次の質問につながります。少なくともこれくらいの極端な結果が得られる確率はどれくらいであるか。その確率が定義したしきい値を下回っている場合は、帰無仮説を棄却します。[https://en.wikipedia.org/wiki/Statistical_significance](https://en.wikipedia.org/wiki/Statistical_significance)ためには、この確率は 5% 以下でなければなりません。1
1 Craparo, Robert M. (2007). 「有意水準」。Salkind, Neil J、Encyclopedia of Measurement and Statistics3. Thousand Oaks、CA: SAGE Publications。889〜891ページ。ISBN 1-412-91611-9.
この結果の確率は、どのように計算すればよいでしょうか。よく研究された分布を提供する *χ2* 統計を使用します。これは、この公式を使ってこれくらい極端な、あるいはもっと極端な結果が得られる確率を決定できます。
![\[E i、O i、および X2 の公式\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/advanced-multi-az-resilience-patterns/images/formulas1.png)
この例では、次のような結果になります。
![\[この例を使用すると、E i、O i、および X2 の公式の答えは 6 になります。\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/advanced-multi-az-resilience-patterns/images/formulas2.png)
それでは、確率の観点から `6` は何を意味するでしょうか。カイ二乗分布は、適切な自由度で調べる必要があります。次の図は、さまざまな自由度でいくつかの異なるカイ二乗分布を示しています。
![\[さまざまな自由度でのカイ二乗分布を示すグラフ\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/advanced-multi-az-resilience-patterns/images/chi-squared-distributions.png)
自由度は、テストの選択肢の数より 1 つ少ない数として計算します。この場合、アベイラビリティーゾーンは 4 つあるため、自由度は 3 になります。次に、k = 3 プロットで x ≥ 6 の曲線の下の面積 (積分) を知りたいとします。一般的に使用される値を含む、事前に計算された表を使用して、その値を概算することもできます。
*表 2: カイ二乗の臨界値*
| 自由度 | 臨界値を下回る確率 | | **0.75** | **0.90** | **0.95** | **0.99** | **0.999** |
| --- | --- | --- | --- | --- | --- | --- | --- |
| 1 | 1.323 | 2.706 | 3.841 | 6.635 | 10.828 |
| 2 | 2.773 | 4.605 | 5.991 | 9.210 | 13.816 |
| 3 | 4.108 | 6.251 | 7.815 | 11.345 | 16.266 |
| 4 | 5.385 | 7.779 | 9.488 | 13.277 | 18.467 |
自由度が 3 の場合、カイ二乗値 6 は、確率列 0.75 および 0.9 の間になります。つまり、この分布が発生する可能性は 10% を超え、しきい値の 5% を下回らないということです。したがって、帰無仮説を受け入れ、アベイラビリティーゾーン間のエラー率には統計的に有意な差はないと判断します。
カイ二乗統計テストの実行は CloudWatch メトリクスの計算ではネイティブにサポートされていないため、CloudWatch から該当するエラーメトリクスを収集し、Lambda などのコンピューティング環境でテストを実行する必要があります。このテストは、MVC コントローラー/アクション、個々のマイクロサービスレベル、またはアベイラビリティーゾーンレベルなどで実行するかを決めることができます。アベイラビリティーゾーンの障害が各コントローラー/アクションまたはマイクロサービスに等しく影響するのか、それとも DNS 障害のようなものが高いスループットのサービスではなく低いスループットのサービスに影響を与えてるのか、つまり集約したときにその影響を隠すことができるのかをについて検討する必要があります。いずれの場合も、適切なディメンションを選択してクエリを作成します。詳細度のレベルは、作成する結果の CloudWatch アラームにも影響します。
指定された時間枠内の各 AZ とコントローラー/アクションのエラー数メトリクスを収集します。まず、カイ二乗検定の結果を true (統計的に有意な偏りがあった) または false (なかった、つまり帰無仮説が成立する) のいずれかで計算します。結果が false の場合は、各アベイラビリティーゾーンの結果をカイ二乗するため、メトリクスストリームに 0 データポイントをパブリッシュします。結果が true の場合は、エラーが予想値から最も遠いアベイラビリティーゾーンの 1 データポイント、その他には 0 データポイントをパブリッシュします (Lambda 関数で使用できるサンプルコードについては [付録 B — カイ二乗計算の例](appendix-b-example-chi-squared-calculation.md) を参照)。Lambda 関数によって生成されるデータポイントに基づいて、3 つ連続の CloudWatch メトリクスアラームと 5 つのうち 3 つの CloudWatch メトリクスアラームを作成することで、以前の可用性アラームと同じアプローチをとることができます。前の例と同様に、この方法を変更して、短い枠または長い枠で使用するデータポイントを増減することができます。
次に、以下の図に示すように、コントローラーとアクションの組み合わせの既存のアベイラビリティーゾーンにこれらのアラームを追加します。
![\[カイ二乗統計検定と複合アラームの統合を示す図\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/advanced-multi-az-resilience-patterns/images/statistics-test-with-composite-alarms.png)
前述のように、ワークロードに新しい機能をオンボードするとき、その新機能に固有の適切な CloudWatch メトリクスアラームを作成し、複合アラーム階層の次の層を更新してそれらのアラームを含めるのみになります。残りのアラーム構造は変化しません。
# 単一インスタンスのゾーンリソースの障害検出
場合によっては、ゾーンリソースのアクティブなインスタンスが 1 つしかないことがあります。最も一般的には、リレーショナルデータベース (Amazon RDS など) や分散キャッシュ ([Amazon ElastiCache (Redis OSS)](https://aws.amazon.com/elasticache/redis/) など) などの単一のライターコンポーネントを必要とするシステムが該当します。1 つのアベイラビリティーゾーンの障害がプライマリリソースのあるアベイラビリティーゾーンに影響する場合、そのリソースにアクセスするすべてのアベイラビリティーゾーンに影響が及ぶ可能性があります。これにより、すべてのアベイラビリティーゾーンで可用性のしきい値を超える可能性があります。つまり、最初の方法では、影響のソースである 1 つのアベイラビリティーゾーンを正しく特定できません。さらに、各アベイラビリティーゾーンで同様のエラー率が見られる可能性が高いため、外れ値分析でも問題は検出されません。つまり、このシナリオを具体的に検出するには、追加のオブザーバビリティを実装する必要があります。
懸念するリソースがその状態に関する独自のメトリクスを生成する可能性が高いですが、アベイラビリティーゾーンに障害が発生している間は、そのリソースはそれらのメトリクスを提供できない場合があります。このシナリオでは、アラームを作成または更新して、いつ*盲目飛行*しているのかを知る必要があります。すでに監視してアラームを設定している重要なメトリクスが存在する場合は、[欠如しているデータ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-missing-data)を違反として処理するようにアラームを設定できます。これにより、そのリソースがデータの報告を停止したかどうかを知ることができ、そのリソースを以前に使用した同じ *in a row* および *m out of n* アラームに含めることができます。
また、リソースの状態を示す一部のメトリクスでは、アクティビティがないときにゼロ値のデータポイントがパブリッシュされることもあります。障害によってリソースとのやり取りが妨げられているのであれば、この種のメトリクスには欠損データのアプローチを使用することはできません。また、値がゼロになってもおそらく警告する必要はありません。なぜなら、それが通常のしきい値の範囲内である場合があるからです。この種の問題を検出する最善の方法は、この依存関係を使用するリソースによって生成されるメトリックを使用することです。この場合、複合アラームを使用して*複数の*アベイラビリティーゾーンでの影響を検出する必要があります。これらのアラームでは、リソースに関連する重要なメトリクスカテゴリをいくつか使用する必要があります。以下にいくつかの例を示します。
+ **スループット** — 受け取る作業単位の割合。これには、トランザクション、読み取り、書き込みなどが含まれます。
+ **可用性** — 成功した作業単位と失敗した作業単位の数を測定します。
+ **レイテンシー**— 重要なオペレーション全体にわたって正常に実行された作業のレイテンシーのパーセンタイルを複数測定します。
ここでも、測定する各メトリクスカテゴリのメトリクスに対して *in a row* および *m out of n* メトリクスアラームを作成できます。前と同様に、これらを複合アラームにまとめて、この共有リソースがアベイラビリティーゾーン全体に影響を与えるソースであるかどうかを判断できます。複合アラームを使用して複数のアベイラビリティーゾーンへの影響を特定できるようにしたいと思うものの、必ずしもその影響が*すべての*アベイラビリティーゾーンである必要はありません。次の図は、この種のアプローチにおける高レベルの複合アラーム構造を示しています。
![\[1 つのリソースによる複数のアベイラビリティーゾーンへの影響を検出するアラームの作成例を示す図\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/advanced-multi-az-resilience-patterns/images/creating-alarms-to-detect-impact.png)
この図は、使用するメトリクスアラームのタイプと複合アラームの階層について、より規範的ではないことに気付くでしょう。これは、この種の問題を発見するのは難しい場合があり、共有リソースに適したシグナルに細心の注意を払う必要があるためです。これらの信号は、特定の方法で評価しなければならない場合もあります。
さらに、`primary-database-impact` アラームは特定のアベイラビリティーゾーンに関連付けられていない点にも注意してください。これは、プライマリデータベースインスタンスは、使用するように設定されているどのアベイラビリティーゾーンにも配置でき、その場所を指定する CloudWatch メトリクスがないためです。このアラームが有効になったら、リソースに問題がある可能性を示すシグナルとして使用し、自動的に実行されていない場合は、別のアベイラビリティーゾーンへのフェイルオーバーを開始する必要があります。リソースを別のアベイラビリティーゾーンに移動したら、隔離されたアベイラビリティーゾーンのアラームが有効になるかどうかを確認するか、またはアベイラビリティーゾーンの退避計画を先制的に呼び出すかを選択できます。
# [概要]
このセクションでは、1 つのアベイラビリティーゾーンの障害を特定するのに役立つ 3 つの方法について説明しました。ワークロードの状態を全体的に把握するには、それぞれの方法を組み合わせて使用する必要があります。
CloudWatch 複合アラームの方法では、例えば、単一の共有リソースが原因ではない 98% (アベイラビリティーゾーンの障害)、100%、99.99% の可用性など、可用性の偏りが統計的に有意でない場合に問題を検出することができます。
異常値検出は、複数のアベイラビリティーゾーンで相関関係のないエラーが発生し、そのすべてがアラームのしきい値を超えている場合に、1 つのアベイラビリティーゾーンの障害を検出するのに役立ちます。
最後に、単一インスタンスのゾーンリソースの劣化を特定すると、アベイラビリティーゾーンの障害がアベイラビリティーゾーン間で共有されているリソースにいつ影響を与えるかを発見するのに役立ちます。
これらのパターンのそれぞれから生成されたアラームを CloudWatch 複合アラーム階層にまとめることで、1 つのアベイラビリティーゾーンの障害が発生し、ワークロードの可用性やレイテンシーに影響が及ぶときを検出できます。