翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# マルチ AZ の高度なレジリエンスパターン
出版日:**2023 年 7 月 11 日** ([ドキュメントの改訂](document-revisions.md))
多くのカスタマーは、高可用性のマルチアベイラビリティーゾーン (AZ) 設定でワークロードを実行しています。このアーキテクチャは、バイナリ障害が発生しても良好に動作しますが、*グレー*障害が発生して問題を起こす場合があります。この種の障害の兆候は微妙で、迅速かつ確実に検出できない場合があります。このホワイトペーパーでは、1 つのアベイラビリティーゾーンに分離されたグレー障害の影響を検出し、そのアベイラビリティーゾーンでの影響を軽減するアクションを実行するように、ワークロードをインストルメント化する方法について説明します。
## 序章
本書の目的は、回復力のあるマルチ AZ アーキテクチャをより効果的に実装できるようにすることです。[Amazon 仮想プライベートクラウド](https://aws.amazon.com/vpc/) (VPC) ネットワークで回復力のあるシステムを構築するためのベストプラクティスの 1 つは、[複数のアベイラビリティーゾーンに各ワークロードをデプロイする](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-best-practices.html)ことです。
[アベイラビリティーゾーン](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/)は、冗長電源、ネットワーク、および接続を備えた 1 つ以上の個別のデータセンターです。複数のアベイラビリティーゾーンを使用すると、単一のデータセンターを使用した場合よりも、可用性、耐障害性、スケーラビリティが高いワークロードを運用できます。
[Amazon Elastic Compute Cloud (EC2) Auto Scaling](https://aws.amazon.com/ec2/autoscaling/) や [Amazon Relational Database](https://aws.amazon.com/rds/) (Amazon RDS) など、多くの AWS のサービスでは、マルチ AZ 設定を利用できます。これらのサービスでは、追加のオブザーバビリティツールやフェイルオーバーツールを構築する必要はありません。これらのサービスでは、単一のアベイラビリティーゾーンに影響する [AWS リージョン](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/) 内で簡単に検出できるバイナリ障害モードに対して、ワークロードの回復性を実現します。バイナリ障害は、大部分のリソースに影響を与える完全に物理的なハードウェア障害、停電、または潜在的なソフトウェアバグである場合があります。
しかし、*グレー障害*と呼ばれる別のカテゴリの障害があります。この障害の兆候は微妙で、迅速かつ確実な検出が困難です。その結果、障害による影響を軽減するまでの時間が長くなります。このホワイトペーパーでは、グレー障害がマルチ AZ アーキテクチャに与える影響、その検出方法、そして最後に軽減方法に焦点を当てて説明しています。
****
このホワイトペーパーに記載されているガイダンスは、主に次のような特定のクラスのワークロードに適用されます。
主にゾーン AWS サービスを使用している
単一リージョンの回復力を改善する必要がある
必要なオブザーバビリティと回復力のパターンを構築するために多額を投資する意思がある
このようなワークロードでは、[グレー障害への対応](gray-failures.md#responding-to-gray-failures) に示されているトレードオフの一部または全部を行いたくない場合があります。または、複数のリージョンを使用するオプションがないかもしれません。これらのタイプのワークロードは、ポートフォリオ全体のごく一部である可能性が高いため、このガイダンスはプラットフォームレベルではなくワークロードレベルで検討する必要があります。