# コンポーネントの障害に耐えられるようにワークロードを設計する
高い可用性と低い平均復旧時間 (MTTR) の要件を持つワークロードは、回復力を考慮した設計をする必要があります。
**Topics**
+ [REL11-BP01 ワークロードのすべてのコンポーネントをモニタリングして障害を検知する](rel_withstand_component_failures_monitoring_health.md)
+ [REL11-BP02 正常なリソースにフェイルオーバーする](rel_withstand_component_failures_failover2good.md)
+ [REL11-BP03 すべてのレイヤーの修復を自動化する](rel_withstand_component_failures_auto_healing_system.md)
+ [REL11-BP04 復旧中はコントロールプレーンではなくデータプレーンを利用する](rel_withstand_component_failures_avoid_control_plane.md)
+ [REL11-BP05 静的安定性を使用してバイモーダル動作を防止する](rel_withstand_component_failures_static_stability.md)
+ [REL11-BP06 イベントが可用性に影響する場合に通知を送信する](rel_withstand_component_failures_notifications_sent_system.md)
+ [REL11-BP07 可用性の目標と稼働時間のサービスレベルアグリーメント (SLA) を満たす製品を設計する](rel_withstand_component_failures_service_level_agreements.md)
# REL11-BP01 ワークロードのすべてのコンポーネントをモニタリングして障害を検知する
ワークロードの状態を継続的にモニタリングすることで、お客様と自動化システムが障害やパフォーマンスの低下の発生をすみやかに把握できるようにします。ビジネス価値に基づいて主要業績評価指標 (KPI) をモニタリングします。
復旧および修復メカニズムはすべて、問題を迅速に検出する機能から開始する必要があります。技術的な障害を最初に検出して、解決できるようにするのです。ただし、可用性はワークロードがビジネス価値を提供する能力に基づいているため、これを測定する主要業績評価指標 (KPI) が検出および修正戦略の一部である必要があります。
**期待される成果:** ワークロードの重要なコンポーネントは個別にモニタリングされ、障害が発生したタイミングと場所で障害を検出してアラートを出します。
**一般的なアンチパターン:**
+ アラームが設定されていないため、停止は通知なしで発生する。
+ アラームは存在しますが、そのしきい値では対応するために十分な時間がない。
+ メトリクスは、目標復旧時間 (RTO) を満たすのに十分な頻度で収集されない。
+ ワークロードの顧客向けインターフェイスのみがアクティブにモニタリングされる。
+ 技術的なメトリクスのみ収集し、ビジネス関数のメトリクスは収集しない。
+ ワークロードのユーザーエクスペリエンスを測定するメトリクスがない。
+ 作成されたモニタが多すぎる。
**このベストプラクティスを活用するメリット:** すべてのレイヤーで適切なモニタリングを行うことで、検出までの時間を短縮して、復旧時間を短縮できます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
モニタリングの対象となるすべてのワークロードを特定します。モニタリングする必要があるワークロードのすべてのコンポーネントを特定したら、次はモニタリングの間隔を決定します。モニタリングの間隔は、障害の検出にかかる時間に基づいた復旧を開始する速さに直接影響します。平均検出時間 (MTTD) は、障害が発生してから修理作業が開始されるまでの時間です。サービスのリストは広範囲かつ完全でなければなりません。
モニタリングは、アプリケーション、プラットフォーム、インフラストラクチャ、ネットワークを含むアプリケーションスタックのすべてのレイヤーを対象とする必要があります。
モニタリング戦略では、Gray failure の影響を考慮する必要があります。Gray failure の詳細については、ホワイトペーパー「Advanced Multi-AZ Resilience Patterns」の「[Gray failures](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/gray-failures.html)」を参照してください。
### 実装手順
+ モニタリング間隔は、どの程度迅速に復旧する必要があるかによって異なります。復旧時間は復旧にかかる時間によって決まるため、この時間と目標復旧時間 (RTO) を考慮して、収集の頻度を決定する必要があります。
+ コンポーネントとマネージドサービスの詳細なモニタリングを設定します。
+ [EC2 インスタンス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-cloudwatch-new.html)と [Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-monitoring.html) の詳細モニタリングが必要かどうかを判断します。詳細モニタリングは 1 分間隔メトリクスを提供し、デフォルトのモニタリングは 5 分間隔メトリクスを提供します。
+ RDS の[拡張モニタリング](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Monitoring.html)が必要かどうかを判断します。拡張モニタリングでは、RDS インスタンスのエージェントを使用して、さまざまなプロセスまたはスレッドに関する有益な情報を取得します。
+ [Lambda](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-metrics.html)、[API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/monitoring_automated_manual.html)、[Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/eks-observe.html)、[Amazon ECS](https://catalog.workshops.aws/observability/en-US/aws-managed-oss/amp/ecs)、すべての[ロードバランサー](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-monitoring.html)のタイプに不可欠なサーバーレスコンポーネントの、モニタリング要件を決定します。
+ [Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/monitoring-overview.html)、[Amazon FSx](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/monitoring_overview.html)、[Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/monitoring_overview.html)、[Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-volume-status.html) のストレージコンポーネントのモニタリング要件を決定します。
+ ビジネスの重要業績評価指標 (KPI) を測定する[カスタムメトリクス](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)を作成します。ワークロードには主要なビジネス機能が実装されており、いつ間接的な問題が発生したのかを特定するのに役立つ KPI として使用される必要があります。
+ ユーザー Canary を使用して、障害に対するユーザーエクスペリエンスをモニタリングします。顧客の行動を実行およびシミュレートできる[合成トランザクションテスト](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) (「canary テスト」ともいう。「カナリアデプロイ」と混同しないこと) は、最も重要なテストプロセスの 1 つです。さまざまなリモートロケーションからワークロードエンドポイントに対してこれらのテストを常に実行します。
+ ユーザーのエクスペリエンスを追跡する[カスタムメトリクス](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)を作成します。顧客のエクスペリエンスを測定できる場合は、コンシューマーエクスペリエンスが低下するタイミングを判断できます。
+ ワークロードのいずれかの要素が正常に動作していない場合にこれを検出し、リソースを自動的にスケールする時期を示す、[アラームを設定](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)します。アラームは、ダッシュボードに視覚的に表示したり、Amazon SNS または E メールを介して送信したり、Auto Scaling と連携させてワークロードリソースをスケールアップ/スケールダウンするのに使用したりすることができます。
+ [ダッシュボード](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)を作成してメトリクスを視覚化します。ダッシュボードは、傾向や異常値などの潜在的な問題の指標を視覚的に確認したり、調査対象となり得る問題の存在を示したりするために使用できます。
+ サービスに[分散トレースモニタリング](https://aws.amazon.com/xray/faqs/)を作成します。分散型モニタリングにより、アプリケーションと基盤となるサービスがどのように動作しているかを理解して、パフォーマンスの問題やエラーの根本原因を特定し、トラブルシューティングすることができます。
+ モニタリングシステム ([CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_xaxr_dashboard.html) または [X-Ray](https://aws.amazon.com/xray/faqs/) を使用) のダッシュボードとデータ収集を別のリージョンとアカウントに作成します。
+ [AWS Health](https://aws.amazon.com/premiumsupport/technology/aws-health/) でサービスの低下について最新情報を入手してください。[AWS User Notifications](https://docs.aws.amazon.com/notifications/latest/userguide/what-is-service.html) を通じて E メールやチャットチャネルに、[目的に合った AWS Health イベント通知を作成](https://docs.aws.amazon.com/health/latest/ug/user-notifications.html)し、[Amazon EventBridge を通じてモニタリングツールやアラートツール](https://docs.aws.amazon.com/health/latest/ug/cloudwatch-events-health.html)をプログラムで統合します。
## リソース
**関連するベストプラクティス:**
+ [可用性](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+ [REL11-BP06 イベントが可用性に影響する場合に通知を送信する](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_notifications_sent_system.html)
**関連ドキュメント:**
+ [canary の使用 (Amazon CloudWatch Synthetics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [インスタンスの詳細モニタリングを有効または無効にする](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-cloudwatch-new.html)
+ [拡張モニタリング](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html)
+ [Auto Scaling グループとインスタンスを Amazon CloudWatch でモニタリングする](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-monitoring.html)
+ [カスタムメトリクスをパブリッシュする](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ [Amazon CloudWatch でのアラームの使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Amazon CloudWatch ダッシュボードの使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
+ [クロスアカウントクロスリージョンダッシュボード](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_xaxr_dashboard.html)
+ [AWS X-Ray のよくある質問](https://aws.amazon.com/xray/faqs/)
+ [可用性について](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/understanding-availability.html)
**関連動画:**
+ [グレー障害の緩和](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/gray-failures.html)
**関連する例:**
+ [つのオブザーバビリティワークショップ: X-Ray の探究](https://catalog.workshops.aws/observability/en-US/aws-native/xray/explore-xray)
**関連ツール:**
+ [CloudWatch](https://aws.amazon.com/cloudwatch/)
+ [CloudWatch X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/security-logging-monitoring.html)
# REL11-BP02 正常なリソースにフェイルオーバーする
リソース障害の発生時に、正常なリソースが引き続きリクエストに対応します。ロケーション障害 (アベイラビリティーゾーンや AWS リージョンなど) に対しては、障害のないロケーションの正常なリソースにフェイルオーバーするシステムを用意します。
サービスを設計するときは、リソース、アベイラビリティーゾーン、またはリージョンに負荷を分散します。そのため、個々のリソースの障害は、残りの正常なリソースにトラフィックをシフトすることによって緩和できます。障害発生時にサービスがどのように検出され、ルーティングされるかを検討してください。
障害復旧を念頭に置いてサービスを設計します。AWS では、障害からの復旧時間とデータへの影響を最小限に抑えるサービスを設計しています。当社のサービスは主にデータストアを使用しており、リクエストが認識されるのは、リージョン内の複数のレプリカにわたりデータが永続的に保存された後です。これらのサービスは、セル単位の分離とアベイラビリティーゾーンにより提供される障害切り分けを活用するように構成されています。当社は、運用上の手順の多くで自動化を幅広く使用しています。また、中断から迅速に復旧するために、置換と再起動の機能を最適化しています。
フェイルオーバーを可能にするパターンとデザインは、AWS プラットフォームサービスごとに異なります。AWS ネイティブのマネージドサービスの多くは、複数のアベイラビリティーゾーン (Lambda や API Gateway など) にネイティブに対応しています。他の AWS サービス (EC2 や EKS など) では、AZ 間でのリソースまたはデータストレージのフェイルオーバーをサポートするための特定のベストプラクティス設計が必要です。
モニタリングは、フェイルオーバーリソースが正常であることを確認し、リソースのフェイルオーバーの進行状況を追跡して、ビジネスプロセスの復旧をモニタリングするために設定する必要があります。
**期待される成果:** システムは、新しいリソースを自動または手動で使用してパフォーマンスの低下から復旧できます。
**一般的なアンチパターン:**
+ 障害を想定した計画が、計画と設計の段階に含まれていない。
+ RTO と RPO が確立されていない。
+ モニタリングが不十分で、障害が発生しているリソースを検出できない。
+ 障害ドメインの適切な隔離。
+ マルチリージョンのフェイルオーバーが考慮されていない。
+ フェイルオーバーを決定する際の障害検出の感度が高すぎる、または過剰である。
+ フェイルオーバー設計のテストや検証を行っていない。
+ オートヒーリングのオートメーションを実行したが、ヒーリングが必要とされたことは通知しない。
+ すぐにフェイルバックするのを防ぐための減衰期間を十分に設けていない。
**このベストプラクティスを活用するメリット:** 適切に機能低下し、迅速に回復することで、障害発生時でも信頼性を維持する耐障害性の高いシステムを構築できます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
[Elastic Load Balancing](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-subnets.html) や [Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-groups.html) などの AWS サービスは、複数のリソースおよびアベイラビリティーゾーンへの負荷分散に役立ちます。そのため、個々のリソース (EC2 インスタンスなど) の障害や、アベイラビリティーゾーンの障害を、残りの正常なリソースにトラフィックをシフトすることによって緩和できます。
マルチリージョンのワークロードの場合、設計はさらに複雑です。例えば、クロスリージョンリードレプリカを使用すると、データを複数の AWS リージョンにデプロイできます。ただし、リードレプリカをプライマリに昇格させ、トラフィックを新しいエンドポイントに向けるには、やはりフェイルオーバーが必要です。Amazon Route 53、[Amazon Application Recovery Controller (ARC)](https://aws.amazon.com/application-recovery-controller/)、Amazon CloudFront、AWS Global Accelerator は、AWS リージョン間でトラフィックをルーティングするために役立ちます。
Amazon S3、Lambda、API Gateway、Amazon SQS、Amazon SNS、Amazon SES、Amazon Pinpoint、Amazon ECR、AWS Certificate Manager、EventBridge、Amazon DynamoDB などの AWS サービスは、AWS によって複数のアベイラビリティーゾーンに自動的にデプロイされます。障害が発生した場合、これらの AWS サービスはトラフィックを正常なロケーションに自動的にルーティングします。データは複数のアベイラビリティーゾーンに冗長的に保存され、使用可能な状態を維持します。
Amazon RDS、Amazon Aurora、Amazon Redshift、Amazon EKS、Amazon ECS の場合、マルチ AZ は設定オプションです。フェイルオーバーが開始すると、AWS はトラフィックを正常なインスタンスに転送させることができます。このフェイルオーバーアクションは、AWS が行うことも、必要に応じてお客様が実行することもできます。
Amazon EC2 インスタンス、Amazon Redshift、Amazon ECS タスク、Amazon EKS ポッドの場合は、デプロイ先のアベイラビリティーゾーンを選択します。設計によっては、Elastic Load Balancing に、異常なゾーンにあるインスタンスを検出してトラフィックを正常なゾーンにルーティングするソリューションが用意されています。Elastic Load Balancing は、オンプレミスのデータセンター内のコンポーネントにトラフィックをルーティングすることもできます。
マルチリージョンのトラフィックフェイルオーバーの場合、再ルーティングでは、インターネットドメインを定義し、ヘルスチェックなどのルーティングポリシーを割り当ててトラフィックを正常なリージョンにルーティングする手段として、Amazon Route 53、Amazon Application Recovery Controller、AWS Global Accelerator、Route 53 Private DNS for VPC、または CloudFront を活用できます。AWS Global Accelerator はアプリケーションへの固定エントリポイントとして機能する静的 IP アドレスを提供し、インターネットの代わりに AWS グローバルネットワークを使用して任意の AWS リージョンのエンドポイントにルーティングすることで、パフォーマンスと信頼性を高めます。
### 実装手順
+ すべての適切なアプリケーションとサービスのフェイルオーバー設計を作成します。各アーキテクチャコンポーネントを分離し、各コンポーネントの RTO と RPO を満たすフェイルオーバー設計を作成します。
+ フェイルオーバープランに必要なすべてのサービスを使用して、下位環境 (開発環境やテスト環境など) を構成します。Infrastructure as Code (IaC) を使用してソリューションをデプロイし、再現性を確保します。
+ フェイルオーバー設計を実装してテストするために、2 つ目のリージョンなどの復旧サイトを設定します。必要に応じて、テスト用のリソースを一時的に設定して、追加コストを抑えることができます。
+ どのフェイルオーバープランを AWS で自動化するか、どのフェイルオーバープランを DevOps プロセスで自動化できるか、どのフェイルオーバープランを手動で行うかを判断します。各サービスの RTO と RPO を文書化して測定します。
+ フェイルオーバープレイブックを作成し、各リソース、アプリケーション、サービスをフェイルオーバーするためのすべての手順を含めます。
+ フェイルバックプレイブックを作成し、各リソース、アプリケーション、サービスをフェイルバックするためのすべての手順を (タイミングとともに) 含めます。
+ プレイブックを開始してリハーサルするための計画を立てます。シミュレーションとカオステストを使用して、プレイブックの手順と自動化をテストします。
+ ロケーション障害 (アベイラビリティーゾーンや AWS リージョンなど) に対しては、障害のないロケーションの正常なリソースにフェイルオーバーするシステムを用意します。フェイルオーバーテストの前に、クォータ、自動スケーリングのレベル、実行中のリソースを確認してください。
## リソース
**関連する Well-Architected のベストプラクティス:**
+ [REL13 - 災害対策 (DR) を計画する](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-for-disaster-recovery-dr.html)
+ [REL10 - 障害部分を切り離してワークロードを保護する](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/use-fault-isolation-to-protect-your-workload.html)
**関連ドキュメント:**
+ [RTO と RPO のターゲットを設定する](https://aws.amazon.com/blogs/mt/establishing-rpo-and-rto-targets-for-cloud-applications/)
+ [Route 53 加重ルーティングを使用したフェイルオーバー](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-2-multi-region-stack)
+ [Amazon Application Recovery Controller を使用したディザスタリカバリ](https://catalog.us-east-1.prod.workshops.aws/workshops/4d9ab448-5083-4db7-bee8-85b58cd53158/en-US/)
+ [EC2 with autoscaling](https://github.com/adriaanbd/aws-asg-ecs-starter)
+ [EC2 Deployments - Multi-AZ](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
+ [ECS Deployments - Multi-AZ](https://github.com/aws-samples/ecs-refarch-cloudformation)
+ [Amazon Application Recovery Controller を使用したトラフィックの切り替え](https://docs.aws.amazon.com/r53recovery/latest/dg/routing-control.failover-different-accounts.html)
+ [Lambda を使用した Application Load Balancer とフェイルオーバー](https://docs.aws.amazon.com/lambda/latest/dg/services-alb.html)
+ [ACM Replication and Failover](https://github.com/aws-samples/amazon-ecr-cross-region-replication)
+ [Parameter Store Replication and Failover](https://medium.com/devops-techable/how-to-design-an-ssm-parameter-store-for-multi-region-replication-support-aws-infrastructure-db7388be454d)
+ [ECR クロスリージョンレプリケーションとフェイルオーバー](https://docs.aws.amazon.com/AmazonECR/latest/userguide/registry-settings-configure.html)
+ [Secrets Manager クロスリージョンレプリケーションの設定](https://disaster-recovery.workshop.aws/en/labs/basics/secrets-manager.html)
+ [新機能 – Amazon Elastic File System (EFS) のレプリケーション](https://aws.amazon.com/blogs/aws/new-replication-for-amazon-elastic-file-system-efs/)
+ [EFS クロスリージョンレプリケーションとフェイルオーバー](https://aws.amazon.com/blogs/storage/transferring-file-data-across-aws-regions-and-accounts-using-aws-datasync/)
+ [ネットワークフェイルオーバー](https://docs.aws.amazon.com/whitepapers/latest/hybrid-connectivity/aws-dx-dxgw-with-vgw-multi-regions-and-aws-public-peering.html)
+ [MRAP を使用した S3 エンドポイントフェイルオーバー](https://catalog.workshops.aws/s3multiregionaccesspoints/en-US/0-setup/1-review-mrap)
+ [S3 のクロスリージョンレプリケーションを作成する](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html)
+ [AWS でのクロスリージョンフェイルオーバーとグレースフルフェイルバックに関するガイダンス](https://d1.awsstatic.com/solutions/guidance/architecture-diagrams/cross-region-failover-and-graceful-failback-on-aws.pdf)
+ [マルチリージョンの Global Accelerator によるフェイルオーバー](https://aws.amazon.com/blogs/networking-and-content-delivery/deploying-multi-region-applications-in-aws-using-aws-global-accelerator/)
+ [DRS によるフェイルオーバー](https://docs.aws.amazon.com/drs/latest/userguide/failback-overview.html)
**関連する例:**
+ [ でのディザスタリカバリAWS](https://disaster-recovery.workshop.aws/en/)
+ [ の Elastic Disaster RecoveryAWS](https://catalog.us-east-1.prod.workshops.aws/workshops/080af3a5-623d-4147-934d-c8d17daba346/en-US)
# REL11-BP03 すべてのレイヤーの修復を自動化する
障害を検出したら、自動化機能を使用して修復するアクションを実行します。パフォーマンスの低下は、内部のサービスメカニズムによって自動的に修復される場合もあれば、修復アクションによってリソースを再起動または削除する必要がある場合もあります。
セルフマネージドアプリケーションやクロスリージョン修復では、復旧設計と自動修復プロセスを[既存のベストプラクティス](https://aws.amazon.com/blogs/architecture/understand-resiliency-patterns-and-trade-offs-to-architect-efficiently-in-the-cloud/)から引き出すことができます。
リソースを再起動または削除する機能は、障害を修復するための重要なツールです。ベストプラクティスは、可能な限りサービスをステートレスにすることです。これにより、リソースの再起動時のデータまたは可用性が失われるのを防ぎます。クラウドでは、再起動の一環として、リソース全体 (コンピューティングインスタンス、サーバーレス関数など) を置き換えることができます (通常はそうする必要があります)。再起動自体は、障害から復旧するための簡単で信頼できる方法です。ワークロードでは、さまざまなタイプの障害が発生します。障害は、ハードウェア、ソフトウェア、通信、オペレーションなどさまざまな部分で発生する可能性があります。
再起動または再試行は、ネットワークリクエストにも適用されます。依存関係にあるシステムからエラーが返された場合、ネットワークのタイムアウトの場合と依存関係にあるシステムの障害の両方に同じ復旧アプローチを適用します。どちらのイベントもシステムに類似の影響を与えるため、どちらかのイベントを特例とするのではなく、エクスポネンシャルバックオフとジッターで限定的に再試行するという類似の戦略を適用します。再起動の機能は、復旧指向コンピューティングと高可用性クラスターアーキテクチャを特徴とする復旧メカニズムです。
**期待される成果:** 障害の検出を修正するために、自動アクションが実行されます。
**一般的なアンチパターン:**
+ 自動スケーリングなしでリソースをプロビジョニングする。
+ インスタンスまたはコンテナにアプリケーションを個別にデプロイする。
+ 自動復旧を使用せずに、複数のロケーションにデプロイできないアプリケーションをデプロイします。
+ 自動スケーリングと自動復旧が修復に失敗するアプリケーションを手動で修復する。
+ フェイルオーバーデータベースの自動化はない。
+ トラフィックを新しいエンドポイントに再ルーティングする自動化された方法が足りない。
+ ストレージのレプリケーションはない。
**このベストプラクティスを活用するメリット:** 自動修復により、平均回復時間を短縮し、可用性を向上させることができます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
Amazon EKS やその他の Kubernetes サービスの設計には、レプリカセットまたはステートフルセットの最小値と最大値の両方、およびクラスターとノードグループの最小サイズが含まれている必要があります。これらのメカニズムは、Kubernetes コントロールプレーンを使用して障害を自動的に修正しながら、継続的に利用可能な処理リソースを最小限に抑えます。
コンピューティングクラスターを使用してロードバランサーを介してアクセスされる設計パターンでは、Auto Scaling グループを活用する必要があります。Elastic Load Balancing (ELB) は、受信アプリケーショントラフィックを 1 つ以上のアベイラビリティーゾーン (AZ) にある複数のターゲットと仮想アプライアンスに自動的に分散します。
ロードバランシングを使用しないクラスター化されたコンピューティングベースの設計では、少なくとも 1 台のノードが失われることを想定したサイズにする必要があります。これにより、新しいノードを復旧している間も、容量が減少する可能性がある状態でサービスが稼働し続けることができます。サービスの例としては、Mongo、DynamoDB Accelerator、Amazon Redshift、Amazon EMR、Cassandra、Kafka、MSK-EC2、Couchbase、ELK、Amazon OpenSearch Service などがあります。これらのサービスの多くは、追加の自動修復機能を使用して設計できます。一部のクラスターテクノロジーでは、ノードが失われたときにアラートを生成し、新しいノードを再作成するための自動または手動のワークフローをトリガーする必要があります。このワークフローは、AWS Systems Manager を使用して自動化でき、問題を迅速に修正できます。
Amazon EventBridge を使用すれば、CloudWatch アラームなどのイベントや、その他の AWS サービスの状態の変化などを、モニタリングおよびフィルタリングすることができます。イベント情報に基づいて、AWS Lambda、Systems Manager Automation、または他のターゲットを呼び出して、ワークロードに対してカスタム修正ロジックを実行できます。Amazon EC2 Auto Scaling は、EC2 インスタンスの状態をチェックするように設定できます。インスタンスが実行中以外の状態にある場合、またはシステムステータスが損なわれている場合、Amazon EC2 Auto Scaling はインスタンスが異常であるとみなして代替インスタンスを起動します。大規模な置き換え (アベイラビリティーゾーン全体の喪失など) の場合、静的安定性が高可用性のために優先されます。
### 実装手順
+ Auto Scaling グループを使用して、ワークロードに階層をデプロイします。[Auto Scaling](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html) は、ステートレスなアプリケーションで自己修復を実行し、キャパシティを追加および削除できます。
+ 前述のコンピューティングインスタンスの場合は、[ロードバランシング](https://docs.aws.amazon.com/autoscaling/ec2/userguide/autoscaling-load-balancer.html)を使用して適切なロードバランサーのタイプを選択します。
+ Amazon RDS の修復を検討します。スタンバイインスタンスでは、スタンバイインスタンスへの[自動フェイルオーバー](https://repost.aws/questions/QU4DYhqh2yQGGmjE_x0ylBYg/what-happens-after-failover-in-rds)を設定します。Amazon RDS リードレプリカの場合、リードレプリカをプライマリにするには自動化されたワークフローが必要です。
+ 複数のロケーションにデプロイできないアプリケーションがデプロイされている [EC2 インスタンスに自動復旧を](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html)実装し、障害時の再起動を許容できます。自動復旧は、アプリケーションが複数のロケーションにデプロイできない場合に、障害が発生したハードウェアを交換してインスタンスを再起動するために使用できます。インスタンスメタデータおよび関連する IP アドレスは保持されます。また、[EBS ボリューム](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html)と [Amazon Elastic File System](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEFS.html) または [File Systems for Lustre](https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html) および [Windows](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html) へのマウントポイントも保持されます。[AWS OpsWorks](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html) を使用することで、レイヤーレベルで EC2 インスタンスの自動修復を設定できます。
+ 自動スケーリングまたは自動復旧を使用できない場合、または自動復旧が失敗した場合は、[AWS Step Functions](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html) と [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) を使用して自動復旧を実装します。自動スケーリングを使用できず、さらに、自動復旧が使用できないか、自動復旧が失敗した場合は、AWS Step Functions と AWS Lambda を使用して修復を自動化できます。
+ [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html) を使用すれば、[CloudWatch アラーム](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)などのイベントや、その他の AWS サービスの状態の変化などを、モニタリングおよびフィルタリングすることができます。イベント情報に基づいて、AWS Lambda (または他のターゲット) を呼び出し、ワークロードに対してカスタム修正ロジックを実行できます。
## リソース
**関連するベストプラクティス:**
+ [可用性](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+ [REL11-BP01 ワークロードのすべてのコンポーネントをモニタリングして障害を検知する](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_notifications_sent_system.html)
**関連ドキュメント:**
+ [AWS Auto Scaling の仕組み](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ [Amazon EC2 自動復旧](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html)
+ [Amazon Elastic Block Store (Amazon EBS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html)
+ [Amazon Elastic File System (Amazon EFS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEFS.html)
+ [Amazon FSx for Lustre とは](https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html)
+ [Amazon FSx for Windows File Server とは](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html)
+ [AWS OpsWorks: 障害の発生したインスタンスを自動修復機能によって交換する](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html)
+ [What is AWS Step Functions?](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)
+ [ とはAWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)
+ [What Is Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Amazon CloudWatch でのアラームの使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Amazon RDS フェイルオーバー](https://d1.awsstatic.com/rdsImages/IG1_RDS1_AvailabilityDurability_Final.pdf)
+ [SSM - Systems Manager Automation](https://docs.aws.amazon.com/resilience-hub/latest/userguide/integrate-ssm.html)
+ [回復力のあるアーキテクチャのベストプラクティス](https://aws.amazon.com/blogs/architecture/understand-resiliency-patterns-and-trade-offs-to-architect-efficiently-in-the-cloud/)
**関連動画:**
+ [Automatically Provision and Scale OpenSearch Service](https://www.youtube.com/watch?v=GPQKetORzmE)
+ [Amazon RDS Failover Automatically](https://www.youtube.com/watch?v=Mu7fgHOzOn0)
**関連する例:**
+ [Amazon RDS フェイルオーバーワークショップ](https://catalog.workshops.aws/resilient-apps/en-US/rds-multi-availability-zone/failover-db-instance)
**関連ツール:**
+ [CloudWatch](https://aws.amazon.com/cloudwatch/)
+ [CloudWatch X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/security-logging-monitoring.html)
# REL11-BP04 復旧中はコントロールプレーンではなくデータプレーンを利用する
コントロールプレーンはリソースの作成、読み取り、記述、更新、削除、一覧表示 (CRUDL) に使用される管理 API を提供し、データプレーンは日々のサービストラフィックを処理します。回復力に影響を与える可能性のあるイベントへの回復または軽減対応を実装するときは、サービスの回復、再スケーリング、復元、修復、またはフェイルオーバーに最小限のコントロールプレーンのオペレーションを使用することに焦点を当ててください。これらのパフォーマンスの低下イベント中は、データプレーンのアクションがどのアクティビティよりも優先されるはずです。
例えば、新しいコンピューティングインスタンスの起動、ブロックストレージの起動、キューサービスの記述などは、すべてコントロールプレーンのアクションです。コンピューティングインスタンスを起動後、コントロールプレーンは、容量のある物理ホストの検索、ネットワークインターフェイスの割り当て、ローカルブロックストレージボリュームの準備、認証情報の生成、セキュリティルールの追加など、複数のタスクを実行する必要があります。コントロールプレーンは複雑なオーケストレーションになりがちです。
**期待される成果:** リソースに障害が発生すると、システムは、トラフィックを障害のあるリソースから正常なリソースに移行することで、自動または手動で回復できます。
**一般的なアンチパターン:**
+ トラフィックを再ルーティングするための DNS レコードの変更への依存。
+ リソースのプロビジョニングが不十分なため、障害が発生したコンポーネントの交換をコントロールプレーンのスケーリング操作に依存。
+ あらゆるカテゴリの障害を修復するために、広範囲にわたるマルチサービス、マルチ API コントロールプレーンアクションに依存。
**このベストプラクティスを活用するメリット:** 自動修復の成功率が高くなると、平均復旧時間が短縮され、ワークロードの可用性が向上します。
**このベストプラクティスを活用しない場合のリスクレベル: 中**。特定の種類のサービス低下の場合、コントロールプレーンが影響を受けます。コントロールプレーンを広範囲に使用して修復すると、復旧時間 (RTO) と平均復旧時間 (MTTR) が長くなる可能性があります。
## 実装のガイダンス
データプレーンのアクションを制限するには、サービスの復元に必要なアクションについて各サービスを評価します。
DNS トラフィックをシフトするときは Amazon Application Recovery Controller を活用します。これらの機能により、障害から回復するアプリケーションの機能を継続的にモニタリングし、複数の AWS リージョン、アベイラビリティーゾーン、およびオンプレミスにまたがってアプリケーションの回復を管理できます。
Route 53 ルーティングポリシーにコントロールプレーンが使用されているため、復旧の際にコントロールプレーンに依存しないようにします。Route 53 データプレーンは、DNS クエリに応答し、ヘルスチェックを実行し、評価します。これらはグローバルに配布され、[「100% 利用可能」のサービスレベルアグリーメント (SLA)](https://aws.amazon.com/route53/sla/) 向けに設計されています。
Route 53 のリソースを作成、更新、削除する Route 53 管理 API およびコンソールは、コントロールプレーンで実行します。コントロールプレーンは、DNS の管理に必要な強力な一貫性と耐久性を重視するように設計されています。これを達成するために、コントロールプレーンは単一のリージョン、米国東部 (バージニア北部) に配置されています。どちらのシステムも非常に高い信頼性で構築されていますが、コントロールプレーンは SLA には含まれません。まれに、データプレーンの回復力設計によって可用性を維持できるときでも、コントロールプレーンでは維持でない場合があります。ディザスタリカバリおよびフェイルオーバーメカニズムについては、データプレーンの機能を使用して、可能な限り最善の信頼性を提供してください。
コンピューティングインフラストラクチャは静的に安定するように設計して、インシデント中にコントロールプレーンを使用しないようにします。例えば、Amazon EC2 インスタンスを使用している場合は、新しいインスタンスを手動でプロビジョニングしたり、Auto Scaling グループにインスタンスの追加を指示したりすることは避けてください。回復性を最大限に高めるには、フェイルオーバーに使用するクラスターに十分な容量をプロビジョニングしてください。この容量のしきい値を制限する必要がある場合は、エンドツーエンドのシステム全体にスロットルを設定して、限られたリソースに到達するトラフィックの合計を安全に制限してください。
Amazon DynamoDB、Amazon API Gateway、ロードバランサー、AWS Lambda サーバーレスなどのサービスでは、これらのサービスを使用するとデータプレーンを活用できます。ただし、新しい関数、ロードバランサー、API ゲートウェイ、または DynamoDB テーブルの作成はコントロールプレーンのアクションであり、イベントの準備やフェイルオーバーアクションのリハーサルとして、パフォーマンス低下の前に完了しておく必要があります。Amazon RDS では、データプレーンのアクションによりデータへのアクセスが可能になります。
データプレーン、コントロールプレーン、および、AWS が高可用性の目標を満たすサービスをいかに構築しているのか、についての詳細は、「[アベイラビリティーゾーンを使用した静的安定性](https://aws.amazon.com/builders-library/static-stability-using-availability-zones/)」を参照してください。
データプレーンでの運用と、コントロールプレーンでの運用を理解します。
### 実装手順
パフォーマンス低下のイベント後に復元する必要のある各ワークロードについて、フェイルオーバーランブック、高可用性設計、自動修復設計、または HA リソース復元プランの評価を行います。コントロールプレーンのアクションとみなされる可能性のある各アクションを特定します。
コントロールアクションをデータプレーンアクションに変更することを検討します。
+ 自動スケーリング (コントロールプレーン) を事前スケールされた Amazon EC2 リソース (データプレーン) に変更します。
+ Amazon EC2 インスタンススケーリング (コントロールプレーン) を AWS Lambda スケーリング (データプレーン) に変更します。
+ Kubernetes を使用するあらゆる設計とコントロールプレーンのアクションの性質を評価します。ポッドの追加は Kubernetes のデータプレーンのアクションです。アクションはノードの追加ではなく、ポッドの追加に限定する必要があります [過剰にプロビジョニングされたノード](https://www.eksworkshop.com/docs/autoscaling/compute/cluster-autoscaler/overprovisioning/)を使用することは、コントロールプレーンのアクションを制限するための推奨される方法です。
データプレーンのアクションが同じ修復に影響を与えられる代替アプローチを検討してください。
+ Route 53 レコードの変更 (コントロールプレーン) または Amazon Application Recovery Controller (データプレーン)
+ [自動化がさらに進んだアップデート用の Route 53 ヘルスチェック](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/)
サービスがミッションクリティカルな場合は、影響を受けていないリージョンでより多くのコントロールプレーンとデータプレーンのアクションを実行できるように、セカンダリリージョンのサービスを検討してください。
+ プライマリリージョンの Amazon EC2 Auto Scaling または Amazon EKS と、セカンダリリージョンの Amazon EC2 Auto Scaling または Amazon EKS とを比較し、セカンダリリージョンにトラフィックをルーティングします (コントロールプレーンのアクション)。
+ セカンダリプライマリでリードレプリカを作成するか、プライマリリージョンで同じアクションを試みる (コントロールプレーンのアクション)
## リソース
**関連するベストプラクティス:**
+ [可用性](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+ [REL11-BP01 ワークロードのすべてのコンポーネントをモニタリングして障害を検知する](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_notifications_sent_system.html)
**関連ドキュメント:**
+ [APN Partner: partners that can help with automation of your fault tolerance](https://aws.amazon.com/partners/find/results/?keyword=automation)
+ [AWS Marketplace: products that can be used for fault tolerance](https://aws.amazon.com/marketplace/search/results?searchTerms=fault+tolerance)
+ [Amazon Builders' Library: 小さなサービスに制御を任せて分散型システムのオーバーヘッドを回避する](https://aws.amazon.com/builders-library/avoiding-overload-in-distributed-systems-by-putting-the-smaller-service-in-control/)
+ [Amazon DynamoDB API (コントロールプレーンとデータプレーン)](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.API.html)
+ [AWS Lambda の実行](https://docs.aws.amazon.com/whitepapers/latest/security-overview-aws-lambda/lambda-executions.html) (コントロールプレーンとデータプレーンに分割)
+ [AWS Elemental MediaStore Data Plane](https://docs.aws.amazon.com/mediastore/latest/apireference/API_Operations_AWS_Elemental_MediaStore_Data_Plane.html)
+ [Amazon Application Recovery Controller を使用して回復力の高いアプリケーションを構築する、パート 1: 単一リージョンスタック](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-1-single-region-stack/)
+ [Amazon Application Recovery Controller を使用して回復力の高いアプリケーションを構築する、パート 2: マルチリージョンスタック](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-2-multi-region-stack/)
+ [Amazon Route 53 を用いたディザスタリカバリ (DR) のメカニズム](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/)
+ [Amazon Application Recovery Controller とは](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
+ [Kubernetes Control Plane and data plane](https://aws.amazon.com/blogs/containers/managing-kubernetes-control-plane-events-in-amazon-eks/)
**関連動画:**
+ [Back to Basics - Using Static Stability](https://www.youtube.com/watch?v=gy1RITZ7N7s)
+ [Building resilient multi-site workloads using AWS global services](https://www.youtube.com/watch?v=62ZQHTruBnk)
**関連する例:**
+ [Amazon Application Recovery Controller の紹介](https://aws.amazon.com/blogs/aws/amazon-route-53-application-recovery-controller/)
+ [Amazon Builders' Library: 小さなサービスに制御を任せて分散型システムのオーバーヘッドを回避する](https://aws.amazon.com/builders-library/avoiding-overload-in-distributed-systems-by-putting-the-smaller-service-in-control/)
+ [Amazon Application Recovery Controller を使用して回復力の高いアプリケーションを構築する、パート 1: 単一リージョンスタック](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-1-single-region-stack/)
+ [Amazon Application Recovery Controller を使用して回復力の高いアプリケーションを構築する、パート 2: マルチリージョンスタック](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-2-multi-region-stack/)
+ [アベイラビリティーゾーンを使用した静的安定性](https://aws.amazon.com/builders-library/static-stability-using-availability-zones/)
**関連ツール:**
+ [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/)
+ [AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/security-logging-monitoring.html)
# REL11-BP05 静的安定性を使用してバイモーダル動作を防止する
ワークロードは静的に安定し、1 つの通常モードでのみ動作する必要があります。バイモーダル動作とは、通常モードと障害モードでワークロードが異なる動作を示す場合をいいます。
例えば、別のアベイラビリティーゾーン (AZ) で新しいインスタンスを起動して、AZ の障害からの復旧を試みることができます。これにより、障害モード中にバイモーダル応答が発生する可能性があります。バイモーダル動作を防止するために、静的に安定し、1 つのモードでのみ動作するワークロードを構築する必要があります。この例では、これらのインスタンスは障害発生前に 2 番目の AZ でプロビジョニングしておく必要があります。この静的に安定した設計により、確実にワークロードが単一のモードでのみ動作するようになります。
**期待される成果:** ワークロードは、通常モードと障害モードでバイモーダル動作を示しません。
**一般的なアンチパターン:**
+ 障害の範囲に関係なく、リソースが常にプロビジョニング可能であると仮定する。
+ 障害発生時にリソースを動的に取得しようとする。
+ 障害が発生するまで、ゾーンまたはリージョン間で適切なリソースをプロビジョニングしない。
+ コンピューティングリソースにのみ静的に安定した設計を検討する。
**このベストプラクティスを活用するメリット:** 静的に安定した設計で実行されるワークロードは、通常のイベント時でも障害発生時でも予測可能な結果を得ることができます。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
バイモーダル動作とは、例えばアベイラビリティーゾーン (AZ) に障害が発生した場合に新しいインスタンスの起動に依存するなど、通常モードと障害モードでワークロードが異なる動作を示す場合をいいます。バイモーダル動作の例は、安定した Amazon EC2 設計により、1 つの AZ が削除された場合にワークロードの負荷を処理するのに十分な数のインスタンスが各 AZ にプロビジョニングされる場合です。Elastic Load Balancing または Amazon Route 53 ヘルスチェックを使用して、障害のあるインスタンスから負荷を分散します。トラフィックがシフトした後、AWS Auto Scaling を使用して、障害が発生したゾーンのインスタンスを非同期で置き換え、正常なゾーンで起動します。EC2 インスタンスやコンテナなどのコンピューティングデプロイの静的安定性があると、信頼性が最も高くなります。
![\[複数のアベイラビリティーゾーンにわたる EC2 インスタンスの静的安定性を示す図\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/reliability-pillar/images/static-stability.png)
これは、このモデルのコストと、すべてのレジリエンスケースでワークロードを維持することのビジネス価値に照らして検討する必要があります。コンピューティングキャパシティを少なくプロビジョニングし、障害発生時に新しいインスタンスの起動に依存するほうがコストは低くなりますが、大規模な障害 (AZ やリージョンの障害など) の場合、このアプローチは、運用プレーンと、影響を受けていないゾーンまたはリージョンでリソースが十分に利用可能であることの両方に依存するため、あまり効果的ではありません。
また、ソリューションでは、信頼性とワークロードに必要なコストを比較検討する必要があります。静的に安定したアーキテクチャは、複数の AZ に分散されているコンピューティングインスタンス、データベースリードレプリカ設計、Kubernetes (Amazon EKS) クラスター設計、マルチリージョンフェイルオーバーアーキテクチャなど、さまざまなアーキテクチャに適用されます。
各ゾーンでより多くのリソースを使用することにより、より静的に安定した設計を実装することもできます。ゾーンを追加することで、静的安定性に必要な追加のコンピューティング量を減らすことができます。
バイモーダル動作の例に、ネットワークのタイムアウトにより、システム全体の設定状態の再読み込みが始まることがあります。これにより想定外の負荷が別のコンポーネントに加わり、そのコンポーネントで障害が発生し、想定外の結果につながる可能性があります。この負のフィードバックループは、ワークロードの可用性に影響を与えます。そこで、静的に安定し、1 つのモードでのみ動作するシステムを構築する必要があります。静的に安定した設計は、一定の作業を行い、常に一定の周期で設定状態を更新します。呼び出しに失敗すると、ワークロードは以前にキャッシュされた値を使用し、アラームを開始します。
バイモーダル動作のもう 1 つの例は、障害発生時にクライアントがワークロードキャッシュをバイパスできるようにすることです。これは、クライアントのニーズに対応するソリューションのように思われるかもしれませんが、ワークロードの需要を大幅に変更し、障害が発生する可能性が高くなります。
重要なワークロードを評価して、どのワークロードにこのタイプのレジリエンス設計が必要かを判断します。重要と思われるものについては、各アプリケーションコンポーネントを確認する必要があります。静的安定性評価を必要とするサービスの種類の例は次のとおりです。
+ **コンピューティング**: Amazon EC2、EKS-EC2、ECS-EC2、EMR-EC2
+ **データベース**: Amazon Aurora、Amazon RDS、Amazon Redshift。
+ **ストレージ**: Amazon S3 (単一ゾーン)、Amazon EFS (マウント)、Amazon FSx (マウント)
+ **ロードバランサー:** 特定の設計で
### 実装手順
+ 静的に安定し、1 つのモードでのみ動作するシステムを構築します。この場合、1 つのアベイラビリティーゾーンまたはリージョンが削除された場合にワークロード容量を処理するのに十分な数のインスタンスを、各アベイラビリティーゾーンまたはリージョンにプロビジョニングします。正常なリソースへのルーティングには、次のようなさまざまなサービスを使用できます。
+ [クロスリージョン DNS ルーティング](https://docs.aws.amazon.com/whitepapers/latest/real-time-communication-on-aws/cross-region-dns-based-load-balancing-and-failover.html)
+ [MRAP Amazon S3 マルチリージョンのルーティング](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiRegionAccessPointRequestRouting.html)
+ [AWS Global Accelerator](https://aws.amazon.com/global-accelerator/)
+ [Amazon Application Recovery Controller](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
+ 単一のプライマリインスタンスまたはリードレプリカが失われた場合に備えて、[データベースリードレプリカ](https://aws.amazon.com/rds/features/multi-az/)を設定します。トラフィックがリードレプリカによって処理されている場合、各アベイラビリティーゾーンと各リージョンでの量は、そのゾーンまたはリージョンに障害が発生した場合の全体的な必要量と同じにします。
+ アベイラビリティーゾーンに障害が発生した場合に保存されるデータに対して静的に安定するように設計された Amazon S3 ストレージに重要なデータを設定します。[Amazon S3 One Zone-IA](https://aws.amazon.com/about-aws/whats-new/2018/04/announcing-s3-one-zone-infrequent-access-a-new-amazon-s3-storage-class/) ストレージクラスを使用する場合、そのゾーンが失われると、保存されたデータへのアクセスが最小限に抑えられるため、静的に安定しているとみなすべきではありません。
+ [ロードバランサー](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/disable-cross-zone.html)は、誤って、または設計により、特定のアベイラビリティーゾーン (AZ) を処理するように設定されている場合があります。この場合、静的に安定した設計では、ワークロードをより複雑な設計の複数の AZ に分散することが考えられます。セキュリティ、レイテンシー、またはコスト上の理由から、元の設計を使用してゾーン間のトラフィックを削減できる場合があります。
## リソース
**関連する Well-Architected のベストプラクティス:**
+ [可用性](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+ [REL11-BP01 ワークロードのすべてのコンポーネントをモニタリングして障害を検知する](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_notifications_sent_system.html)
+ [REL11-BP04 復旧中はコントロールプレーンではなくデータプレーンを利用する](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_avoid_control_plane.html)
**関連ドキュメント:**
+ [ディザスタリカバリディザスタリカバリプランの依存関係を最小化する](https://aws.amazon.com/blogs/architecture/minimizing-dependencies-in-a-disaster-recovery-plan/)
+ [The Amazon Builders' Library: アベイラビリティーゾーンを使用した静的安定性](https://aws.amazon.com/builders-library/static-stability-using-availability-zones)
+ [障害分離境界](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/appendix-a---partitional-service-guidance.html)
+ [アベイラビリティーゾーンを使用した静的安定性](https://aws.amazon.com/builders-library/static-stability-using-availability-zones)
+ [マルチゾーン RDS](https://aws.amazon.com/rds/features/multi-az/)
+ [ディザスタリカバリディザスタリカバリプランの依存関係を最小化する](https://aws.amazon.com/blogs/architecture/minimizing-dependencies-in-a-disaster-recovery-plan/)
+ [クロスリージョン DNS ルーティング](https://docs.aws.amazon.com/whitepapers/latest/real-time-communication-on-aws/cross-region-dns-based-load-balancing-and-failover.html)
+ [MRAP Amazon S3 マルチリージョンのルーティング](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiRegionAccessPointRequestRouting.html)
+ [AWS Global Accelerator](https://aws.amazon.com/global-accelerator/)
+ [Amazon Application Recovery Controller](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
+ [1 ゾーン Amazon S3](https://aws.amazon.com/about-aws/whats-new/2018/04/announcing-s3-one-zone-infrequent-access-a-new-amazon-s3-storage-class/)
+ [クロスゾーンロードバランシング](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/disable-cross-zone.html)
**関連動画:**
+ [Static stability in AWS: AWS re:Invent 2019: Introducing The Amazon Builders' Library (DOP328)](https://youtu.be/sKRdemSirDM?t=704)
# REL11-BP06 イベントが可用性に影響する場合に通知を送信する
しきい値の違反が検出されると、イベントによって引き起こされた問題が自動的に解決された場合でも、通知が送信されます。
自動ヒーリング機能により、ワークロードの信頼性を高めることができます。ただし、対処する必要のある根本的な問題もあいまいになる可能性があります。根本原因の問題を解決できるように、自動ヒーリングによって対処されたものを含む問題のパターンを検出できるように、適切なモニタリングとイベントを実装します。
回復力を備えたシステムは、低下イベントがすぐに適切なチームに通知されるよう設計されています。これらの通知は、1 つまたは複数の通信チャネルを通じて送信する必要があります。
**期待される成果:** エラー率、レイテンシー、その他の主要業績評価指標 (KPI) メトリクスなどのしきい値を超えると、直ちにオペレーションチームにアラートが送信されます。これにより、これらの問題をできるだけ早く解決し、ユーザーへの影響を回避するか最小限に抑えることができます。
**一般的なアンチパターン:**
+ 送信するアラームが多すぎる。
+ 実行できないアラームを送信する。
+ アラームのしきい値の設定が高すぎる (感度が高すぎる) か、低すぎる (感度が低すぎる)。
+ 外部依存関係に対するアラームを送信しない。
+ モニタリングとアラームを設計する際に[グレー障害](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/gray-failures.html)を考慮していない。
+ ヒーリングのオートメーションを実行しているが、ヒーリングが必要となったことを適切なチームに通知しない。
**このベストプラクティスを活用するメリット:** 復旧の通知により、運用チームやビジネスチームはサービスの低下を認識し、直ちに対応して平均検出時間 (MTTD) と平均修復時間 (MTTR) の両方を最小限に抑えることができます。復旧イベントの通知により、発生頻度の低い問題を無視することもなくなります。
**このベストプラクティスを活用しない場合のリスクレベル:** 中 適切なモニタリングとイベント通知のメカニズムを実装しないと、自動ヒーリングで対処されるものも含め、問題のパターンを検出できなくなる可能性があります。チームは、ユーザーがカスタマーサービスに連絡した場合、または偶然に見つけた場合にしか、システムの低下を認識できなくなります。
## 実装のガイダンス
モニタリング戦略の定義において、アラームのトリガーは一般的なイベントです。このイベントには、アラームの識別子、アラームの状態 (`IN ALARM` や `OK`) およびアラームをトリガーした原因の詳細が含まれる可能性があります。多くの場合、1 件のアラームイベントが検出されると、1 件の E メール通知が送信されます。これは、1 件のアラームにつき 1 つのアクションの例です。アラーム通知は、問題があることを適切な担当者に通知するため、オブザーバビリティにおいて非常に重要です。ただし、オブザーバビリティソリューションでイベントに対するアクションが洗練されると、人間の介入を必要とせずに問題を自動的に修正できます。
KPI モニタリングアラームを設定すると、しきい値を超えたときに適切なチームにアラートが送信されます。これらのアラートを使用して、低下の修復を試みる自動プロセスをトリガーすることもできます。
より複雑なしきい値のモニタリングには、複合アラームを検討する必要があります。複合アラームでは、多くの KPI モニタリングアラームを使用して、運用上のビジネスロジックに基づいてアラートを作成します。CloudWatch アラームは、Amazon SNS 統合または Amazon EventBridge を使用して、E メールを送信するか、サードパーティーのインシデント追跡システムにインシデントをログ記録するように設定できます。
### 実装手順
モニタリング対象のワークロードに応じて、次のようなさまざまなタイプのアラームを作成します。
+ アプリケーションアラームは、ワークロードの一部が正常に動作していないことを検出するために使用します。
+ [インフラストラクチャアラーム](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)は、リソースをスケールするタイミングを示します。アラームは、ダッシュボードに視覚的に表示したり、Amazon SNS または E メールを介して送信したり、Auto Scaling と連携させてワークロードリソースをスケールイン/スケールアウトするのに使用したりすることができます。
+ シンプルな[静的アラーム](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html)を作成して、メトリクスが指定された評価期間の静的しきい値を超える状況をモニタリングできます。
+ [複合アラーム](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Composite_Alarm.html)は、複数のソースからの複雑なアラームに対応できます。
+ アラームを作成したら、適切な通知イベントを作成します。[Amazon SNS API](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) を直接呼び出して、通知を送信し、修正やコミュニケーションのための自動化をリンクすることができます。
+ [AWS Health](https://aws.amazon.com/premiumsupport/technology/aws-health/) でサービスの低下について最新情報を入手してください。[AWS User Notifications](https://docs.aws.amazon.com/notifications/latest/userguide/what-is-service.html) を通じて E メールやチャットチャネルに、[目的に合った AWS Health イベント通知を作成](https://docs.aws.amazon.com/health/latest/ug/user-notifications.html)し、[Amazon EventBridge を通じてモニタリングツールやアラートツール](https://docs.aws.amazon.com/health/latest/ug/cloudwatch-events-health.html)をプログラムで統合します。
## リソース
**関連する Well-Architected のベストプラクティス:**
+ [可用性](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
**関連ドキュメント:**
+ [静的しきい値に基づいて CloudWatch アラームを作成する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html)
+ [Amazon EventBridge とは](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Amazon Simple Notification Service とは](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)
+ [カスタムメトリクスを発行する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ [Amazon CloudWatch でのアラームの使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [CloudWatch 複合アラームの設定](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Composite_Alarm.html)
+ [re:Invent 2022 で公開された AWS オブザーバビリティに関する最新情報](https://aws.amazon.com/blogs/mt/whats-new-in-aws-observability-at-reinvent-2022/)
**関連ツール:**
+ [CloudWatch](https://aws.amazon.com/cloudwatch/)
+ [CloudWatch X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/security-logging-monitoring.html)
# REL11-BP07 可用性の目標と稼働時間のサービスレベルアグリーメント (SLA) を満たす製品を設計する
可用性の目標と稼働時間のサービスレベルアグリーメント (SLA) を満たすように製品を設計します。可用性目標またはアップタイム SLA を公開するか、非公開で同意する場合は、アーキテクチャと運用プロセスが SLA をサポートするように設計されていることを確認します。
**期待される成果:** 各アプリケーションには、可用性の目標とパフォーマンスメトリクスの SLA が定義されています。これらのメトリクスは、ビジネス上の成果を満たすためにモニタリングおよび管理できます。
**一般的なアンチパターン:**
+ SLA を設定せずにワークロードを設計およびデプロイする。
+ 合理的な理由やビジネス要件なしに SLA メトリクスが高すぎに設定されている。
+ 依存関係とその基盤となる SLA を考慮せずに SLA を設定する。
+ 回復力の共有責任モデルを考慮せずにアプリケーションが設計される。
**このベストプラクティスを活用するメリット:** 主要な復元力の目標に基づいてアプリケーションを設計すると、ビジネス目標と顧客の期待を満たすことができます。このような目標は、さまざまなテクノロジーを評価し、さまざまなトレードオフを考慮に入れたアプリケーション設計プロセスの促進につながります。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
アプリケーションの設計では、ビジネス、オペレーション、財務上の目的に基づくさまざまな要件を考慮する必要があります。運用上の要件の範囲内で、ワークロードを適切にモニタリングおよびサポートできるように、ワークロードには特定の回復性メトリクス目標が必要です。ワークロードのデプロイ後は、回復性メトリクスの設定や派生の作成を行うべきではありません。これは設計段階で定義し、さまざまな決定とトレードオフのガイドとしての役割を果たす必要があります。
+ 各ワークロードには、独自の回復性メトリクスセットが必要です。このようなメトリクスは、その他のビジネスアプリケーションとは異なる場合があります。
+ 依存関係を減らすと、可用性にプラスの影響を与えることができます。各ワークロードは、独自の依存関係と SLA を考慮に入れる必要があります。通常、ワークロードの目標以上の可用性目標を持つ依存関係を選択します。
+ 可能であれば、依存関係が損なわれてもワークロードが正常に動作できるように、疎結合の設計を検討します。
+ コントロールプレーンの依存関係を減らします。特に、復旧時または機能低下時の依存関係を低減します。ミッションクリティカルなワークロードに対して静的安定性がある設計を評価します。リソースを節約して、ワークロード内のこのような依存関係の可用性を向上します。
+ オブザーバビリティと計測は、平均検出時間 (MTTD) と平均修復時間 (MTTR) の短縮と SLA の達成のために重要です。
+ 分散システムの可用性を向上させる要素は、障害の頻度が少ない (MTBF が長い)、障害検出時間が短い (MTTD が短い)、修理時間が短い (MTTR が短い) という 3 つです。
+ ワークロードの回復性メトリクスを確立し、それを満たすことは、効果的な設計の基本となります。このような設計では、設計の複雑性、サービスの依存関係、パフォーマンス、スケーリング、コストのトレードオフを考慮する必要があります。
**実装手順**
+ 以下の質問を検討し、ワークロードの設計を確認して、文書化します。
+ コントロールプレーンはワークロードのどの個所で使用されますか。
+ ワークロードはどのように耐障害性を実装しますか。
+ どのようなスケーリング、自動スケーリング、冗長性、高可用性コンポーネントの設計パターンがありますか。
+ どのようなデータ整合性と可用性の要件がありますか。
+ リソース節約またはリソースの静的安定性に関する考慮事項はありますか。
+ どのようなサービスの依存関係がありますか。
+ ステークホルダーと協力して、ワークロードアーキテクチャに基づいて SLA メトリクスを定義します。ワークロードで使用されるすべての依存関係の SLA を検討します。
+ SLA 目標の設定後、SLA を満たすようにアーキテクチャを最適化します。
+ SLA を満たす設計が定まったら、運用上の変更、プロセスの自動化、MTTD および MTTR の短縮についても重視するランブックを導入します。
+ デプロイ後、SLA についてモニタリングしてレポートを作成します。
## リソース
**関連するベストプラクティス:**
+ [REL03-BP01 ワークロードをセグメント化する方法を選択する](rel_service_architecture_monolith_soa_microservice.md)
+ [REL10-BP01 複数の場所にワークロードをデプロイする](rel_fault_isolation_multiaz_region_system.md)
+ [REL11-BP01 ワークロードのすべてのコンポーネントをモニタリングして障害を検知する](rel_withstand_component_failures_monitoring_health.md)
+ [REL11-BP03 すべてのレイヤーの修復を自動化する](rel_withstand_component_failures_auto_healing_system.md)
+ [REL12-BP04 カオスエンジニアリングを使用して回復力をテストする](rel_testing_resiliency_failure_injection_resiliency.md)
+ [REL13-BP01 ダウンタイムやデータ消失に関する復旧目標を定義する](rel_planning_for_recovery_objective_defined_recovery.md)
+ [ワークロードの状態の理解](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/understanding-workload-health.html)
**関連ドキュメント:**
+ [冗長性を実装した可用性](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/availability-with-redundancy.html)
+ [信頼性の柱 - 可用性](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+ [可用性の測定](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/measuring-availability.html)
+ [AWS 障害分離境界](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/abstract-and-introduction.html)
+ [回復性に関する責任共有モデル](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/shared-responsibility-model-for-resiliency.html)
+ [アベイラビリティーゾーンを使用した静的安定性](https://aws.amazon.com/builders-library/static-stability-using-availability-zones/)
+ [AWS サービスレベルアグリーメント (SLA)](https://aws.amazon.com/legal/service-level-agreements/)
+ [Guidance for Cell-based Architecture on AWS](https://aws.amazon.com/solutions/guidance/cell-based-architecture-on-aws/)
+ [AWS インフラストラクチャ](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/aws-infrastructure.html)
+ [マルチ AZ の高度なレジリエンスパターン (ホワイトペーパー)](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/advanced-multi-az-resilience-patterns.html)
**関連サービス:**
+ [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/)
+ [AWS Config](https://aws.amazon.com/config/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)