翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# 単一インスタンスのゾーンリソースの障害検出
<a name="failure-detection-of-single-instance-zonal-resources"></a>

場合によっては、ゾーンリソースのアクティブなインスタンスが 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 メトリクスがないためです。このアラームが有効になったら、リソースに問題がある可能性を示すシグナルとして使用し、自動的に実行されていない場合は、別のアベイラビリティーゾーンへのフェイルオーバーを開始する必要があります。リソースを別のアベイラビリティーゾーンに移動したら、隔離されたアベイラビリティーゾーンのアラームが有効になるかどうかを確認するか、またはアベイラビリティーゾーンの退避計画を先制的に呼び出すかを選択できます。