翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # マルチ 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)