# 障害管理
**Topics**
+ [REL 9 データはどのようにバックアップするのですか?](w2aac19b9c11b5.md)
+ [REL 10 ワークロードを保護するために、障害分離をどのように使用すればよいですか?](w2aac19b9c11b7.md)
+ [REL 11 コンポーネントの障害に耐えるようにワークロードを設計するにはどうすればよいですか?](w2aac19b9c11b9.md)
+ [REL 12 信頼性はどのようにテストすればよいですか?](w2aac19b9c11c11.md)
+ [REL 13 災害対策 (DR) はどのように計画するのですか?](w2aac19b9c11c13.md)
# REL 9 データはどのようにバックアップするのですか?
目標復旧時間 (RTO) と目標復旧時点 (RPO) の要件を満たすように、データ、アプリケーション、設定をバックアップします。
**Topics**
+ [REL09-BP01 バックアップが必要なすべてのデータを特定し、バックアップする、またはソースからデータを再現する](rel_backing_up_data_identified_backups_data.md)
+ [REL09-BP02 バックアップを保護し、暗号化する](rel_backing_up_data_secured_backups_data.md)
+ [REL09-BP03 データバックアップを自動的に実行する](rel_backing_up_data_automated_backups_data.md)
+ [REL09-BP04 データの定期的な復旧を行ってバックアップの完全性とプロセスを確認する](rel_backing_up_data_periodic_recovery_testing_data.md)
# REL09-BP01 バックアップが必要なすべてのデータを特定し、バックアップする、またはソースからデータを再現する
すべての AWS データストアは、バックアップ機能を備えています。Amazon RDS や Amazon DynamoDB などのサービスは、ポイントインタイムリカバリ (PITR) を有効にする自動バックアップを追加でサポートします。これにより、現在時刻の 5 分前までの任意の時刻にバックアップを復元することができます。多くの AWS サービスは、バックアップを別の AWS リージョン にコピーする機能を備えています。AWS Backup は、複数の AWS のサービスにまたがってデータ保護を一元化し、自動化できるツールです。
Amazon S3 をセルフマネージドおよび AWS マネージドデータソースのバックアップ先として使用できます。Amazon EBS、Amazon RDS、Amazon DynamoDB などの AWS サービスには、バックアップを作成する機能が組み込まれています。サードパーティー製のバックアップソフトウェアも使用できます。
オンプレミスのデータを AWS クラウド にバックアップするには、 [AWS Storage Gateway](https://docs.aws.amazon.com/storagegateway/latest/vgw/WhatIsStorageGateway.html) または [AWS DataSync](https://docs.aws.amazon.com/datasync/latest/userguide/what-is-datasync.html)を使用します。Amazon S3 バケットは、このデータを AWS に保存するために使用できます。Amazon S3 は、 [Amazon Glacier または S3 Glacier Deep Archive](https://docs.aws.amazon.com/prescriptive-guidance/latest/backup-recovery/amazon-s3-glacier.html) など複数のストレージ階層を提供して、データストレージのコストを削減します。
他のソースからデータを再生成することによって、データリカバリのニーズを満たすこともできます。例えば、 [Amazon ElastiCache レプリカノード](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Replication.Redis.Groups.html) または [RDS リードレプリカ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html) を使用して、プライマリが失われた場合にデータを再生成できます。このようなソースを使用して、 [目標復旧時点 (RPO) と目標復旧時間 (RTO)](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/disaster-recovery-dr-objectives.html)を満たすことができる場合、バックアップは不要です。別の例として、Amazon EMR を操作している場合、 [S3 から EMR にデータを再生成できる限り、HDFS データストアをバックアップする必要はありません](https://aws.amazon.com/premiumsupport/knowledge-center/copy-s3-hdfs-emr/).
バックアップ戦略を選択するときには、データの復旧にかかる時間を考慮してください。データの復旧に必要な時間は、バックアップのタイプ (バックアップ戦略の場合) やデータ再生成メカニズムの複雑性に依存します。この時間は、ワークロードの RTO 以内でなければなりません。
**期待される成果:**
データソースが識別され、重要性に基づいて分類されている。次に、RPO に基づいてデータ復旧戦略を確立します。この戦略には、これらのデータソースをバックアップするか、他のソースからデータを再生成する能力を持つことが含まれます。データ損失の場合、実装された戦略によって、定義された RPO および RTO 内でのデータの復旧または再生成が可能になります。
**クラウド成熟度フェーズ:** Fondational
**一般的なアンチパターン:**
+ ワークロードのすべてのデータソースとそれらの重要性を認識していない。
+ 重要なデータソースのバックアップを取っていない。
+ 重要性を評価基準として使用せずに、一部のデータソースのみのバックアップを取る。
+ RPO が定義されていないか、バックアップの頻度が RPO を満たしていない。
+ バックアップが必要かどうか、またはデータを他のソースから再生成できるかどうかを評価していない。
**このベストプラクティスを確立するメリット:** バックアップが必要な場所を特定し、バックアップを作成するメカニズムを実装するか、外部ソースからデータを再生成できるようにすることで、停止時にデータを復元し、復旧する能力が高まります。
**このベストプラクティスが確立されていない場合のリスクレベル:** 高
## 実装のガイダンス
ワークロードが使用する AWS のサービスとリソースのバックアップ機能を理解し、使用します。ほとんどの AWS のサービスは、ワークロードデータをバックアップする機能を提供します。
**実装手順:**
1. **ワークロードのすべてのデータソースを特定します**.データは、データベース、 [からの脱却](https://aws.amazon.com/products/databases/)io1 [ボリューム](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html)io1 [ファイルシステム](https://docs.aws.amazon.com/efs/latest/ug/whatisefs.html)io1 [ロギングシステム](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)、および [オブジェクトストレージなど、多くのリソースに保存できます](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html).ウェブアプリケーションのバックエンドに関する推奨事項については、 **リソース** セクションで、 **関連するドキュメント** から、データが保存されるさまざまな AWS のサービスと、これらのサービスが提供するバックアップ機能に関するものを参照してください。
1. **重要性に基づいてデータソースを分類します**.データセットごとにワークロードにとっての重要度が異なるため、回復力の要件も異なります。例えば、一部のデータは重要であり、ゼロに近い RPO を必要とするかもしれませんが、その他のデータは重要度が低く、より高い RPO や部分的なデータ損失に耐えられるかもしれません。同様に、データセットごとに RTO 要件も異なります。
1. **AWS またはサードパーティのサービスを使用して、データのバックアップを作成します**. [AWS Backup](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html) は、AWS にさまざまなデータソースのバックアップを作成できるマネージドサービスです。また、これらのサービスのほとんどは、バックアップを作成する機能をネイティブで備えています。AWS Marketplace には、これらの機能を提供する多数のソリューションも用意されています。ウェブアプリケーションのバックエンドに関する推奨事項については、 **リソース** 以下に記載されているリソースの中で、さまざまな AWS のサービスからデータのバックアップを作成する方法に関する情報を参照してください。
1. **バックアップしないデータについては、データ再生成メカニズムを確立します**.さまざまな理由から、他のソースから再生成できるデータはバックアップしないという選択をすることもあるでしょう。バックアップの保管にコストがかかるため、バックアップを作成するよりも、必要なときにソースからデータを再現したほうが安いという状況もあるかもしれません。別の例としては、バックアップからの復元にかかる時間が、ソースからデータを再生成するよりも長く、結果として RTO に反する場合です。このような状況では、トレードオフを考慮して、データ復旧が必要なときに、これらのソースからデータを再生成する方法について、十分に定義されたプロセスを確立してください。例えば、データの分析を行うために、Amazon S3 からデータウェアハウス (Amazon Redshift など) 、または MapReduce クラスター (Amazon EMR など) にデータをロードしてある場合、これは他のソースから再生成できるデータの例になるかもしれません。これらの分析の結果がどこかに保存されているか再現可能である限り、データウェアハウスまたは MapReduce クラスターで発生した障害でデータが失われることはありません。ソースから再現できる例には他にも、キャッシュ (Amazon ElastiCache など) や RDS リードレプリカなどがあります。
1. **データをバックアップするサイクルを確立します**.データソースのバックアップの作成は定期的なプロセスであり、頻度は RPO に依存します。
**実装計画の工数レベル:** 中
## リソース
**関連するベストプラクティス:**
[REL13-BP01 ダウンタイムやデータ消失に関する復旧目標を定義する](rel_planning_for_recovery_objective_defined_recovery.md)
[REL13-BP02 復旧目標を満たすため、定義された復旧戦略を使用する](rel_planning_for_recovery_disaster_recovery.md)
**関連するドキュメント:**
+ [「AWS Backup とは。」](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html)
+ [AWS DataSync とは?](https://docs.aws.amazon.com/datasync/latest/userguide/what-is-datasync.html)
+ [ボリュームゲートウェイとは?](https://docs.aws.amazon.com/storagegateway/latest/vgw/WhatIsStorageGateway.html)
+ [APN パートナー: バックアップを支援できるパートナー](https://aws.amazon.com/partners/find/results/?keyword=Backup)
+ [AWS Marketplace: バックアップに活用できる製品](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup)
+ [Amazon EBS スナップショット](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSSnapshots.html)
+ [Amazon EFS のバックアップ](https://docs.aws.amazon.com/efs/latest/ug/efs-backup-solutions.html)
+ [Amazon FSx for Windows File Server のバックアップ](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/using-backups.html)
+ [ElastiCache for Redis のバックアップと復元](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/backups.html)
+ [Creating a DB Cluster Snapshot in Neptune (Neptune での DB クラスタースナップショットの作成)](https://docs.aws.amazon.com/neptune/latest/userguide/backup-restore-create-snapshot.html)
+ [DB スナップショットの作成](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CreateSnapshot.html)
+ [スケジュールに従って実行する EventBridge ルールの作成](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-scheduled-rule.html)
+ [クロスリージョンレプリケーション](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr.html) と Amazon S3
+ [EFS-to-EFS AWS Backup](https://aws.amazon.com/solutions/efs-to-efs-backup-solution/)
+ [Amazon S3 へのログデータのエクスポート](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/S3Export.html)
+ [オブジェクトのライフサイクル管理](https://docs.aws.amazon.com/AmazonS3/latest/dev/object-lifecycle-mgmt.html)
+ [On-Demand Backup and Restore for DynamoDB (DynamoDB のオンデマンドバックアップと復元)](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/backuprestore_HowItWorks.html)
+ [DynamoDB のポイントインタイムリカバリ](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/PointInTimeRecovery.html)
+ [Working with Amazon OpenSearch Service Index Snapshots (Amazon OpenSearch Service インデックススナップショットの操作)](https://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/es-managedomains-snapshots.html)
**関連動画:**
+ [AWS re:Invent 2021 - Backup, disaster recovery, and ransomware protection with AWS (AWS によるバックアップ、ディザスタリカバリ、ランサムウェア保護)](https://www.youtube.com/watch?v=Ru4jxh9qazc)
+ [AWS Backup Demo: Cross-Account and Cross-Region Backup (デモ: クロスアカウントおよびクロスリージョンバックアップ)](https://www.youtube.com/watch?v=dCy7ixko3tE)
+ [AWS re:Invent 2019: Deep dive on AWS Backup (AWS Backup の深掘り), ft.Rackspace (STG341)](https://youtu.be/av8DpL0uFjc)
**関連する例:**
+ [Well-Architected ラボ: Amazon S3 の双方向クロスリージョンレプリケーション (CRR) の実装](https://wellarchitectedlabs.com/reliability/200_labs/200_bidirectional_replication_for_s3/)
+ [Well-Architected ラボ: データのバックアップと復元のテスト](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/)
+ [Well-Architected ラボ: 分析ワークロードのフェイルバックによるバックアップと復元](https://wellarchitectedlabs.com/reliability/200_labs/200_backup_restore_failback_analytics/)
+ [Well-Architected ラボ: ディザスタリカバリ - バックアップと復元](https://wellarchitectedlabs.com/reliability/disaster-recovery/workshop_1/)
# REL09-BP02 バックアップを保護し、暗号化する
AWS IAM などの認証と承認を使用して、バックアップへのアクセスを制御し、検出します。暗号化によりバックアップのデータ保全性が損なわれることを防止、検出します。
Amazon S3 は、保管時のデータを暗号化するための方法をいくつかサポートしています。Amazon S3 はサーバー側の暗号化を使用して、オブジェクトを暗号化されていないデータとして受け入れてから、保存時に暗号化します。クライアント側の暗号化を使用すると、ワークロードアプリケーションはデータを Amazon S3 に送信する前に暗号化することに対して責任を負います。どちらの方法でも、AWS Key Management Service (AWS KMS) を使ってデータキーを作成して保存することもできますし、自分でキーを用意し、そのキーに責任を持つこともできます。AWS KMS を使用すると、IAM を使用してポリシーを設定し、データキーと復号化されたデータにアクセスできるユーザーとアクセスできないユーザーにわけることができます。
Amazon RDS では、データベースの暗号化を選択すると、バックアップも暗号化されます。DynamoDB のバックアップは常に暗号化されます。
**一般的なアンチパターン:**
+ データに対するのと同一の、バックアップおよび復元オートメーションへのアクセスを設定する。
+ バックアップを暗号化しない。
**このベストプラクティスを確立するメリット:** バックアップを保護することで、データの改ざんを防止し、データの暗号化により、誤って公開されたデータへのアクセスが防止されます。
**このベストプラクティスが確立されていない場合のリスクレベル:** 高
## 実装のガイダンス
+ 各データストアで暗号化を使用します。ソースデータが暗号化されている場合、バックアップも暗号化されます。
+ RDS での暗号化を有効にします。RDS インスタンスの作成時に、AWS Key Management Service を使用して、保管時の暗号化を設定できます。
+ [Amazon RDS リソースの暗号化](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html)
+ EBS ボリュームの暗号化を有効にします。デフォルトの暗号化を設定するか、ボリュームの作成時に一意のキーを指定できます。
+ [Amazon EBS 暗号化](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html)
+ 必要な Amazon DynamoDB 暗号化を使用します。DynamoDB は保管中のすべてのデータを暗号化します。AWS 所有の AWS KMS キーを使用するか、AWS マネージド KMS キーを使用して、アカウントに保存されるキーを指定できます。
+ [保管時の DynamoDB 暗号化](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/EncryptionAtRest.html)
+ [暗号化されたテーブルの管理](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/encryption.tutorial.html)
+ Amazon EFS に保存されているデータを暗号化します。ファイルシステムを作成するときに暗号化を設定します。
+ [EFS でのデータとメタデータの暗号化](https://docs.aws.amazon.com/efs/latest/ug/encryption.html)
+ 送信元と送信先のリージョンで暗号化を設定します。KMS に保存されているキーを使用して Amazon S3 で保管時の暗号化を設定できますが、キーはリージョン固有です。レプリケーションを設定するときに、送信先キーを指定できます。
+ [CRR 追加設定: AWS KMS に保存された暗号化キーを使用したサーバー側の暗号化 (SSE) で作成されたオブジェクトをレプリケートする](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr-replication-config-for-kms-objects.html)
+ バックアップにアクセスするための最小特権のアクセス許可を実装します。セキュリティのベストプラクティスに従って、バックアップ、スナップショット、およびレプリカへのアクセスを制限します。
+ [セキュリティの柱: AWS Well-Architected](./wat.pillar.security.en.html)
## リソース
**関連するドキュメント:**
+ [AWS Marketplace: バックアップに活用できる製品](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup)
+ [Amazon EBS 暗号化](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html)
+ [Amazon S3: 暗号化を使用しデータを保護する](https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingEncryption.html)
+ [CRR 追加設定: AWS KMS に保存された暗号化キーを使用したサーバー側の暗号化 (SSE) で作成されたオブジェクトをレプリケートする](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr-replication-config-for-kms-objects.html)
+ [保管時の DynamoDB 暗号化](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/EncryptionAtRest.html)
+ [Amazon RDS リソースの暗号化](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html)
+ [EFS でのデータとメタデータの暗号化](https://docs.aws.amazon.com/efs/latest/ug/encryption.html)
+ [AWS でのバックアップの暗号化](https://docs.aws.amazon.com/aws-backup/latest/devguide/encryption.html)
+ [暗号化されたテーブルの管理](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/encryption.tutorial.html)
+ [セキュリティの柱: AWS Well-Architected](./wat.pillar.security.en.html)
**関連する例:**
+ [Well-Architected ラボ: Amazon S3 の双方向クロスリージョンレプリケーション (CRR) の実装](https://wellarchitectedlabs.com/reliability/200_labs/200_bidirectional_replication_for_s3/)
# REL09-BP03 データバックアップを自動的に実行する
目標復旧時点 (RPO) によって、またはデータセット内の変更によって通知される定期的なスケジュールに基づいて、バックアップが自動的に行われるように設定します。データ損失の少ない重要なデータセットは頻繁に自動バックアップする必要がありますが、多少の損失は許容できる重要度の低いデータは、バックアップの頻度を少なくすることができます。
AWS Backup を使用して、さまざまな AWS データソースの自動化されたデータバックアップを作成できます。Amazon RDS インスタンスは 5 分ごとにほぼ連続的にバックアップでき、Amazon S3 オブジェクトは 15 分ごとにほぼ連続的にバックアップできます。これにより、バックアップ履歴内の特定の時点へのポイントインタイムリカバリ (PITR) が可能になります。Amazon EBS ボリューム、Amazon DynamoDB テーブル、Amazon FSx ファイルシステムなど、その他の AWS データソースについては、AWS Backup は 1 時間ごとの頻度で自動バックアップを実行できます。これらのサービスでは、バックアップ機能もネイティブに提供されています。ポイントインタイムリカバリを備えた自動バックアップを提供する AWS サービスとしては、 [Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/PointInTimeRecovery_Howitworks.html)io1 [Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PIT.html)、および [Amazon Keyspaces (Apache Cassandra 向け)](https://docs.aws.amazon.com/keyspaces/latest/devguide/PointInTimeRecovery.html) があります。これらはバックアップ履歴内の特定の時点への復元が可能です。その他の AWS データストレージサービスのほとんどが、1 時間ごとの定期バックアップをスケジュールする機能を提供しています。
Amazon RDS と Amazon DynamoDB は、ポイントインタイムリカバリを使用した継続的なバックアップを提供しています。Amazon S3 バージョニングは、一度有効にすると、自動で実行されます。[Amazon Data Lifecycle Manager](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/snapshot-lifecycle.html) を使用して、Amazon EBS スナップショットの作成、コピー、および削除を自動化できます。また、Amazon EBS-backed Amazon マシンイメージ (AMI) とその基盤となる Amazon EBS スナップショットの作成、コピー、廃止、および登録解除も自動化できます。
バックアップの自動化と履歴を一元的に確認できるようにするために、AWS Backup は完全マネージド型の、ポリシーベースのバックアップソリューションを提供します。AWS Storage Gateway を使用して、クラウド内およびオンプレミスの複数の AWS のサービスにわたってデータのバックアップを一元化および自動化します。
バージョン管理に加えて、Amazon S3 はレプリケーション機能も備えています。S3 バケット全体を同じまたは異なる AWS リージョン にある別のバケットに自動的にレプリケートできます。
**期待される成果:**
一定の周期でデータソースのバックアップを作成する自動化されたプロセス。
**一般的なアンチパターン:**
+ バックアップを手動で実行する。
+ バックアップ機能があるが、自動化にバックアップが含まれていないリソースを使用する。
**このベストプラクティスを確立するメリット:** バックアップを自動化することで、バックアップが RPO に基づいて定期的に作成され、作成されない場合はアラートが送信されます。
**このベストプラクティスが確立されていない場合のリスクレベル:** ミディアム
## 実装のガイダンス
1. **現在、手動でバックアップされている** データソースを特定します。AWS に ANF サーバーを構築するための詳細については、 [REL09-BP01 バックアップが必要なすべてのデータを特定し、バックアップする、またはソースからデータを再現する](rel_backing_up_data_identified_backups_data.md) これに関するガイダンスを参照してください。
1. **ワークロードの RPO を** 決定します。AWS に ANF サーバーを構築するための詳細については、 [REL13-BP01 ダウンタイムやデータ消失に関する復旧目標を定義する](rel_planning_for_recovery_objective_defined_recovery.md) これに関するガイダンスを参照してください。
1. **自動バックアップソリューションまたはマネージドサービスを使用します**。AWS Backup はフルマネージドサービスであり、 [AWS のサービス、クラウド、およびオンプレミスでのデータ保護の一元化と自動化を容易にします](https://docs.aws.amazon.com/aws-backup/latest/devguide/creating-a-backup.html#creating-automatic-backups).バックアッププランは AWS Backup の機能であり、バックアップするリソースと、これらのバックアップを作成する頻度を定義するルールの作成を可能にします。この頻度は、ステップ 2 で確立した RPO によって通知される必要があります。 [この WA ラボは、](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/) AWS Backup を使用して自動バックアップを作成する方法に関するハンズオンガイダンスを提供します。データを保存するほとんどの AWS サービスでは、バックアップ機能がネイティブで提供されています。例えば、RDS は、ポイントインタイムリカバリ (PITR) 付きの自動バックアップに利用できます。
1. **オンプレミスデータソースやメッセージキューなど、自動バックアップソリューションまたはマネージドサービスによってサポートされないデータソースについては、** 信頼できるサードパーティソリューションを使用して自動バックアップを作成することを検討してください。または、AWS CLI または SDK を使用してこれを行うオートメーションを作成することができます。AWS Lambda 関数または AWS Step Functions を使用して、データバックアップの作成にかかわるロジックを定義し、Amazon EventBridge を使用して RPO (ステップ 2 で確立) に基づく頻度で実行することができます。
**実装計画の工数レベル:** 低
## リソース
**関連するドキュメント:**
+ [APN パートナー: バックアップを支援できるパートナー](https://aws.amazon.com/partners/find/results/?keyword=Backup)
+ [AWS Marketplace: バックアップに活用できる製品](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup)
+ [スケジュールに従って実行する EventBridge ルールの作成](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-scheduled-rule.html)
+ [「AWS Backup とは。」](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html)
+ [「AWS Step Functions とは何ですか?」](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)
**関連動画:**
+ [AWS re:Invent 2019: Deep dive on AWS Backup (AWS Backup の深掘り), ft.Rackspace (STG341)](https://youtu.be/av8DpL0uFjc)
**関連する例:**
+ [Well-Architected ラボ: データのバックアップと復元のテスト](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/)
# REL09-BP04 データの定期的な復旧を行ってバックアップの完全性とプロセスを確認する
復旧テストを実行して、バックアッププロセスの実装が目標復旧時間 (RTO) と目標復旧時点 (RPO) を満たしていることを検証します。
AWS を使用して、テスト環境を立ち上げ、そこにバックアップを復元して RTO および RPO が機能するかを評価し、データコンテンツと完全性のテストを実行できます。
さらに、Amazon RDS および Amazon DynamoDB はポイントインタイムリカバリ (PITR) を許可します。継続的バックアップを使用すると、データセットを指定された日時の状態に復元できます。
**期待される成果:** バックアップからのデータを、十分に定義されたメカニズムを使用して定期的に復旧することで、ワークロードについて確立された目標復旧時間 (RTO) 内での復旧が可能であることを確認できます。バックアップからの復元により、オリジナルデータを含むリソースになり、破損したりアクセス不能になっていたりするデータがなく、目標復旧時点 (RPO) 内のデータ損失であることを確認します。
**一般的なアンチパターン:**
+ バックアップを復元しますが、復元が使用可能であることを確認するためのデータのクエリや取得は行いません。
+ バックアップが存在することを前提とする。
+ システムのバックアップが完全に動作可能であり、そこからデータを復旧できることを前提とする。
+ バックアップからデータを復元または復旧する時間がワークロードの RTO の範囲内であることを前提とする。
+ バックアップに含まれるデータがワークロードの RPO の範囲内であることを前提とする。
+ ランブックを使用せずに、または確立された自動手順の外部で、アドホックに復元する。
**このベストプラクティスを活用するメリット:** バックアップの復旧をテストすることで、データの紛失や破損を心配せずに、必要なときにデータを復元できること、ワークロードの RTO 内で復元と復旧が可能であること、ならびにデータ損失がワークロードの RPO の範囲内であることを確認できます。
**このベストプラクティスを活用しない場合のリスクレベル:** ミディアム
## 実装のガイダンス
バックアップおよび復元機能をテストすることで、停止時にこれらのアクションを実行できるという安心感が得られます。定期的にバックアップを新しい場所に復元して、テストを実行し、データの完全性を確認します。実行すべき一般的なテストは、
すべてのデータが使用可能であり、破損しておらず、アクセス可能であり、データ損失がワークロードの RPO の範囲内であることを確認します。そのようなテストは、復旧メカニズムが十分に高速であり、ワークロードの RTO に対応できることを確認するのにも役立ちます。
1. **現在、手動でバックアップされている** データソースと、これらのバックアップの保存場所を特定します。AWS に ANF サーバーを構築するための詳細については、 [REL09-BP01 バックアップが必要なすべてのデータを特定し、バックアップする、またはソースからデータを再現する](rel_backing_up_data_identified_backups_data.md) この実装方法に関するガイダンスを参照してください。
1. **各データソースの** データ検証基準を確立します。データのタイプが異なると、プロパティも異なり、異なる検証メカニズムが必要になることがあります。本番環境での使用を決定する前に、このデータを検証する方法を考慮してください。データを検証するための一般的な方法としては、データタイプ、フォーマット、チェックサム、サイズ、またはこれらの組み合わせなど、データとバックアッププロパティをカスタム検証ロジックで使用することです。例えば、復元されたリソースと、バックアップが作成された時点でのデータソースの間でチェックサム値を比較します。
1. **データの重要度に基づいて、データ復元の** RTO と RPO を確立します。AWS に ANF サーバーを構築するための詳細については、 [REL13-BP01 ダウンタイムやデータ消失に関する復旧目標を定義する](rel_planning_for_recovery_objective_defined_recovery.md) この実装方法に関するガイダンスを参照してください。
1. **データ復旧機能を評価します**.バックアップおよび復元戦略をレビューして、RTO および RPO を満たせるかどうかを理解し、必要に応じて戦略を調整します。分析のために、 [AWS レジリエンスハブ](https://docs.aws.amazon.com/resilience-hub/latest/userguide/create-policy.html)を使用して、ワークロードのアセスメントを実行できます。アセスメントは、回復力ポリシーに対してアプリケーション設定を評価し、RTO および RPO 目標を満たすことができるかどうかを報告します。
1. **本番環境で現在使われている確立されたデータ復元プロセスを使用して、** テスト復元を行います。これらのプロセスは、オリジナルデータソースのバックアップ方法、バックアップそのもののフォーマットとストレージ場所、またはデータが他のソースから再生成されるかどうかによって異なります。例えば、 [AWS Backup などのマネージドサービスを使用している場合、バックアップを新しいリソースに容易に復元できます](https://docs.aws.amazon.com/aws-backup/latest/devguide/restoring-a-backup.html).AWS Elastic Disaster Recovery を使用した場合、 [リカバリドリルを開始できます](https://docs.aws.amazon.com/drs/latest/userguide/failback-preparing.html).
1. **(前のステップから) 復元されたリソースからのデータリカバリを** ステップ 2 でデータ検証のために確立した基準に基づいて検証します。復元され、復旧されたデータには、バックアップ時点で最新のレコード/アイテムが含まれていますか? このデータはワークロードの RPO の範囲内ですか?
1. **復元と復旧に必要な時間を測定して、** ステップ 3 で確立された RTO と比較します。このプロセスは、ワークロードの RTO の範囲内ですか? 例えば、復元プロセスが開始されたときのタイムスタンプと復旧検証が完了したときのタイムスタンプを比較して、このプロセスの所要時間を計算します。すべての AWS API 呼び出しにはタイムスタンプが付けられるため、この情報を使用できます [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html).この情報から復元プロセスが開始したときの詳細がわかりますが、検証が完了したときの終了タイムスタンプが検証ロジックによって記録される必要があります。自動化プロセスを使用している場合、 [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) などのサービスを使用して、この情報を保存できます。さらに、多くの AWS のサービスは、特定のアクションが発生したときのタイムスタンプ付きの情報を提供するイベント履歴を備えています。AWS Backup 内では、バックアップおよび復元アクションは *ジョブ*と呼ばれ、これらのジョブにはメタデータの一部としてタイムスタンプ情報が含まれ、復元と復旧の所要時間の測定に使用できます。
1. **データ検証に失敗した場合や、** 復元と復旧に必要な時間がワークロードについて確立された RTO を超えている場合は、関係者に通知します。これを行うオートメーションを実装するときには、 [このラボのように、](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/)Amazon Simple Notification Service (Amazon SNS) などのサービスを使用して、メールや SMS などで関係者にプッシュ通知を送信できます。 [これらのメッセージは、Amazon Chime、Slack、Microsoft Teams などのメッセージングアプリケーションに発行したり、](https://aws.amazon.com/premiumsupport/knowledge-center/sns-lambda-webhooks-chime-slack-teams/) または [AWS Systems Manager OpsCenter を使用して OpsItems としてタスクを作成するために使用したりすることもできます](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-creating-OpsItems.html).
1. **このプロセスを定期的に実行するように自動化します**.例えば、AWS Lambda や AWS Step Functions の状態マシンなどのサービスを使用して、復元および復旧プロセスを自動化でき、Amazon EventBridge を使用して、下のアーキテクチャ図に示されているように、このオートメーションワークフローを定期的にトリガーすることができます。データ復旧検証を [AWS Backup で自動化する方法について確認してください](https://aws.amazon.com/blogs/storage/automate-data-recovery-validation-with-aws-backup/).さらに、 [この Well-Architected ラボは、](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/) いくつかのステップを自動化するための 1 つの方法について、ハンズオンエクスペリエンスを提供します。
![\[自動化されたバックアップおよび復元プロセスを示す図\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2022-03-31/framework/images/automated-backup-restore-process.png)
**実装計画の工数レベル:** 検証基準の複雑性に応じて、中～高。
## リソース
**関連するドキュメント:**
+ [AWS Backup でデータ復旧検証を自動化する](https://aws.amazon.com/blogs/storage/automate-data-recovery-validation-with-aws-backup/)
+ [APN パートナー: バックアップを支援できるパートナー](https://aws.amazon.com/partners/find/results/?keyword=Backup)
+ [AWS Marketplace: バックアップに活用できる製品](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup)
+ [スケジュールに従ってトリガーする EventBridge ルールの作成](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-scheduled-rule.html)
+ [DynamoDB のオンデマンドバックアップと復元](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/BackupRestore.html)
+ [「AWS Backup とは。」](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html)
+ [「AWS Step Functions とは何ですか?」](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)
+ [AWS Elastic Disaster Recovery とは](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html)
+ [AWS Elastic Disaster Recovery](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html)
**関連する例:**
+ [Well-Architected ラボ: データのバックアップと復元のテスト](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/)
# REL 10 ワークロードを保護するために、障害分離をどのように使用すればよいですか?
障害部分を分離した境界は、ワークロード内の障害の影響を限られた数のコンポーネントに限定します。境界外のコンポーネントは、障害の影響を受けません。障害部分を切り離した境界を複数使用すると、ワークロードへの影響を制限できます。
**Topics**
+ [REL10-BP01 複数の場所にワークロードをデプロイする](rel_fault_isolation_multiaz_region_system.md)
+ [REL10-BP02 マルチロケーションデプロイ用の適切な場所の選択](rel_fault_isolation_select_location.md)
+ [REL10-BP03 単一のロケーションに制約されるコンポーネントのリカバリを自動化する](rel_fault_isolation_single_az_system.md)
+ [REL10-BP04 バルクヘッドアーキテクチャを使用して影響範囲を制限する](rel_fault_isolation_use_bulkhead.md)
# REL10-BP01 複数の場所にワークロードをデプロイする
ワークロードのデータとリソースを複数のアベイラビリティゾーンに分散するか、必要に応じて複数の AWS リージョン にまたがって分散します。これらのロケーションは、必要に応じて多様化できます。
AWS のサービス設計の基本原則の 1 つは、基盤となる物理インフラストラクチャの単一障害点を回避することです。これによって、複数のアベイラビリティーゾーンを使用して単一ゾーンで起こる障害に耐えられるソフトウェアおよびシステムを構築することができます。これと同様に、システムは単一のコンピューティングノード、単一のストレージボリューム、単一のデータベースインスタンスの障害に対する弾力性を持つように設計されています。冗長コンポーネントに依存するシステムを構築するときには、それぞれのコンポーネントが独立して動作すること、また、AWS リージョン の場合は、それぞれのリージョンが自律して動作することが重要です。冗長化されたコンポーネントを使用した理論的な可用性の計算から得られるメリットは、これが当てはまる場合にのみ有効です。
**アベイラビリティゾーン (AZ)**
AWS リージョン は、互いに独立するように設計された 2 つ以上のアベイラビリティゾーンで構成されます。各アベイラビリティゾーンは、火災、洪水、竜巻などの自然災害による障害の影響を回避するため、ほかのゾーンから物理的に大きな距離を隔てています。各アベイラビリティゾーンは、商用電源への専用接続、スタンドアロンのバックアップ電源、独立したメカニカルサービス、アベイラビリティゾーン内外の独立したネットワーク接続など、独立した物理インフラストラクチャも備えています。この設計により、これらのシステムのいずれかに障害が発生した場合、影響を受ける AZ は 1 だけで済みます。地理的には分離されていても、アベイラビリティゾーンは、同じリージョンのエリアに配置されているため、高スループットで低レイテンシーなネットワーク接続が可能です。AWS リージョン 全体 (すべてのアベイラビリティゾーンにまたがり、複数の物理的に独立したデータセンターで構成される) をワークロードの単一の論理的なデプロイ先として扱うことができ、同期したデータレプリケーション (例えば、データベース間で) が可能です。このようにして、アクティブ/アクティブまたはアクティブ/スタンバイの設定でアベイラビリティゾーンを使用することができます。
アベイラビリティゾーンは独立しているため、ワークロードが複数のゾーンを使用するように設定された場合、ワークロードの可用性が向上します。一部の AWS サービス (Amazon EC2 インスタンスデータプレーンを含む) は、厳密なゾーンサービスとしてデプロイされるため、属するアベイラビリティゾーンに左右されます。ただし、他の AZ 内の Amazon EC2 インスタンスは影響を受けず、機能し続けます。同様に、アベイラビリティゾーンの障害によって Amazon Aurora データベースに障害が発生した場合、影響を受けない AZ のリードレプリカ Aurora インスタンスは自動的にプライマリに昇格できます。一方、Amazon DynamoDB などのリージョンにおける AWS のサービスは、サービスの可用性の設計目標を達成するために、内部ではアクティブ/アクティブ設定で複数のアベイラビリティゾーンを使用するため、AZ 配置を設定する必要はありません。
![\[3 つのアベイラビリティゾーンにまたがってデプロイされる多階層アーキテクチャを示す図。Amazon S3 と Amazon DynamoDB は常に自動的にマルチ AZ であることに注意してください。ELB も 3 つのゾーンすべてにデプロイされます。\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2022-03-31/framework/images/multi-tier-architecture.png)
AWS コントロールプレーンは、通常、リージョン全体 (複数のアベイラビリティゾーン) 内のリソースを管理する機能を提供しますが、特定のコントロールプレーン (Amazon EC2 および Amazon EBS を含む) は、結果を単一のアベイラビリティゾーンにフィルタリングする機能を備えています。これを実行すると、指定されたアベイラビリティーゾーン内でのみリクエストが処理されるため、その他のアベイラビリティーゾーンで起こる障害からの影響を軽減できます。この AWS CLI の例は、us-east-2c アベイラビリティゾーンからのみ Amazon EC2 インスタンス情報を取得する例を示しています。
```
AWS ec2 describe-instances --filters Name=availability-zone,Values=us-east-2c
```
*AWS ローカルゾーン*
AWS ローカルゾーンは、サブネットや EC2 インスタンスなど、ゾーン内の AWS リソースの配置場所として選択できるという点で、それぞれの AWS リージョン リージョン内でアベイラビリティゾーンと同じように機能します。それらが特別なのは、関連する AWS リージョン リージョンにあるのではなく、現在 AWS リージョン が存在しない大規模な人口、産業、IT センターの近くにあることです。それでも、ローカルゾーンのローカルワークロードと AWS リージョン で実行されているワークロードの間で、高帯域幅で安全な接続を維持します。ワークロードをユーザーに近い場所にデプロイし、低レイテンシー要件を満たすには、AWS ローカルゾーンを使用する必要があります。
**Amazon Global Edge Network**
Amazon Global Edge Network は、世界中の都市のエッジロケーションで構成されます。Amazon CloudFront は、このネットワークを使用して、コンテンツをエンドユーザーに低レイテンシーで配信します。AWS Global Accelerator を使用すると、これらのエッジロケーションにワークロードエンドポイントを作成して、ユーザーに近い AWS グローバルネットワークへのオンボーディングを提供できます。Amazon API Gateway は、CloudFront ディストリビューションを使用してエッジ最適化された API エンドポイントを有効にし、最も近いエッジロケーションを経由してクライアントアクセスを容易にします。
*AWS リージョン*
AWS リージョン は自律するように設計されているため、マルチリージョンアプローチを使用するには、各リージョンにサービスの専用コピーをデプロイします。
マルチリージョンアプローチは、1 回限りの大規模なイベントが発生したときに復旧目標を満たすための *ディザスタリカバリ* 戦略に一般的です。把握 [https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-for-disaster-recovery-dr.html](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-for-disaster-recovery-dr.html) これらの戦略の詳細について確認してください。ただし、ここでは、 *可用性*に焦点を当てて、平均アップタイム目標の実現を目指します。高可用性目標については、マルチリージョンアーキテクチャは、一般に、アクティブ/アクティブとして設計され、(それぞれのリージョンの) 各サービスコピーはアクティブです (リクエストを処理します)。
**推奨**
ほとんどのワークロードの可用性目標は、単一の AWS リージョン 内でマルチ AZ 戦略を使用して満たすことができます。マルチリージョンアーキテクチャは、ワークロードの可用性要件が極端に高いか、その他のビジネス目標のために、マルチリージョンアーキテクチャが必要とされる場合のみ検討してください。
AWS は、お客様がリージョンをまたいでサービスを運用できるようにしています。例えば、AWS は、Amazon Simple Storage Service (Amazon S3) レプリケーション、Amazon RDS リードレプリカ (Aurora リードレプリカを含む)、Amazon DynamoDB グローバルテーブルを使用して、連続的な非同期データレプリケーションを提供します。連続レプリケーションでは、アクティブリージョンのそれぞれでデータのバージョンをほとんどすぐに使用できます。
AWS CloudFormation を使用して、インフラストラクチャを定義し、複数の AWS アカウント と複数の AWS リージョン にまたがって一貫してデプロイできます。また、AWS CloudFormation StackSets は、この機能を拡張し、複数のアカウントとリージョンにまたがって単一のオペレーションで AWS CloudFormation スタックの作成、更新、または削除が可能です。Amazon EC2 インスタンスのデプロイの場合、AMI (Amazon マシンイメージ) は、ハードウェア設定やインストールされたソフトウェアなどの情報を提供するために使用されます。Amazon EC2 Image Builder パイプラインを実装して、必要な AMI を作成し、これらをアクティブリージョンにコピーできます。これにより、これらの *ゴールデン AMI* は、新しい各リージョンにワークロードをデプロイし、スケールアウトするために必要なすべてを備えることになります。
トラフィックをルーティングするために、Amazon Route 53 と AWS Global Accelerator の両方により、どのユーザーをどのアクティブリージョンエンドポイントに向かわせるかを決定するポリシーを定義できます。Global Accelerator では、トラフィックダイヤルを設定して、各アプリケーションエンドポイントに向かうトラフィックのパーセンテージを制御します。Route 53 は、このパーセンテージアプローチをサポートするほか、地理的近接性やレイテンシーに基づくものなど、他の複数の可用性ポリシーもサポートします。Global Accelerator は、AWS エッジサーバーの拡張ネットワークを自動的に利用して、AWS ネットワークバックボーンへのトラフィックを可能な限りすぐにオンボードするため、リクエストのレイテンシーが低下します。
これらの機能はすべて、各リージョンの自律性を保つように動作します。このアプローチには、ごくわずかな例外があり、AWS Identity and Access Management (IAM) サービスのコントロールプレーンと共に、グローバルエッジデリバリーを提供するサービス (Amazon CloudFront や Amazon Route 53 など) が含まれます。大部分のサービスが、完全に単一リージョン内で運用されています。
**オンプレミスのデータセンター**
オンプレミスのデータセンターで実行されるワークロードに関しては、可能な場合はハイブリッドエクスペリエンスを設計します。AWS Direct Connect は、オンプレミスから AWS への専用ネットワーク接続を提供し、両方での実行が可能になります。
もう 1 つのオプションは、AWS Outposts を使用して、AWS インフラストラクチャとサービスをオンプレミスで実行することです。AWS Outposts は、AWS インフラストラクチャ、AWS のサービス、API、ツールをデータセンターに拡張する完全マネージド型サービスです。AWS クラウド で使用されているのと同じハードウェアインフラストラクチャがデータセンターにインストールされます。その後、AWS Outposts は最も近い AWS リージョン に接続されます。その結果、AWS Outposts を使用して、低レイテンシーまたはローカルデータ処理を要求されるワークロードをサポートできます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
+ 複数のアベイラビリティゾーンと AWS リージョン を使用します。ワークロードのデータとリソースを複数のアベイラビリティゾーンに分散するか、必要に応じて複数の AWS リージョン にまたがって分散します。これらのロケーションは、必要に応じて多様化できます。
+ リージョンサービスは初めからアベイラビリティーゾーンにデプロイされます。
+ これには、Amazon S3、Amazon DynamoDB、AWS Lambda (VPC に接続されていない場合) が含まれます。
+ コンテナ、インスタンス、機能ベースのワークロードを複数のアベイラビリティーゾーンにデプロイします。キャッシュを含め、マルチゾーンデータストアを使用します。EC2 Auto Scaling、ECS タスク配置、AWS Lambda 関数の設定 (VPC で実行するとき)、および ElastiCache クラスターの機能を使用します。
+ Auto Scaling グループをデプロイするときには、アベイラビリティーゾーンの異なるサブネットを使用します。
+ [例: 複数のアベイラビリティーゾーンにインスタンスを分散する](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#arch-AutoScalingMultiAZ)
+ [Amazon ECS タスク配置戦略](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement-strategies.html)
+ [Amazon VPC 内のリソースにアクセスできるように AWS Lambda 関数を設定する](https://docs.aws.amazon.com/lambda/latest/dg/vpc.html)
+ [リージョンとアベイラビリティーゾーンを選択する](https://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/RegionsAndAZs.html)
+ Auto Scaling グループをデプロイするときには、アベイラビリティーゾーンの異なるサブネットを使用します。
+ [例: 複数のアベイラビリティーゾーンにインスタンスを分散する](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#arch-AutoScalingMultiAZ)
+ タスク配置パラメータを使用して、DB サブネットグループを指定します。
+ [Amazon ECS タスク配置戦略](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement-strategies.html)
+ VPC で実行する関数を設定するには、複数のアベイラビリティーゾーンでサブネットを使用します。
+ [Amazon VPC 内のリソースにアクセスできるように AWS Lambda 関数を設定する](https://docs.aws.amazon.com/lambda/latest/dg/vpc.html)
+ ElastiCache クラスターには複数のアベイラビリティーゾーンを使用します。
+ [リージョンとアベイラビリティーゾーンを選択する](https://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/RegionsAndAZs.html)
+ ワークロードを複数のリージョンにデプロイする必要がある場合は、マルチリージョン戦略を選択します。信頼性に関するほとんどのニーズは、マルチアベイラビリティゾーン戦略を使用して単一の AWS リージョン 内で満たすことができます。必要に応じて、ビジネスニーズを満たすためにマルチリージョン戦略を使用します。
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ 別の AWS リージョン にバックアップすると、必要なときにデータが利用可能になるという保証のレイヤーを追加できます。
+ ワークロードによっては、マルチリージョン戦略の使用を必要とする規制要件があります。
+ ワークロードの AWS Outposts を評価します。ワークロードでオンプレミスのデータセンターへの低レイテンシーが必要な場合、またはローカルのデータ処理要件がある場合があります。その場合、AWS Outposts を使用して、オンプレミスで AWS インフラストラクチャとサービスを実行します。
+ [「What is AWS Outposts?」](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html)
+ AWS Local Zones がユーザーにサービスを提供するのに役立つかどうかを判断します。低レイテンシー要件がある場合は、AWS Local Zones がユーザーの近くにあるかどうかを確認してください。近くにある場合は、それらのユーザーの近くにワークロードをデプロイするのに使用します。
+ [AWS Local Zones のよくある質問](https://aws.amazon.com/about-aws/global-infrastructure/localzones/faqs/)
## リソース
**関連するドキュメント:**
+ [AWS グローバルインフラストラクチャ](https://aws.amazon.com/about-aws/global-infrastructure)
+ [AWS Local Zones のよくある質問](https://aws.amazon.com/about-aws/global-infrastructure/localzones/faqs/)
+ [Amazon ECS タスク配置戦略](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement-strategies.html)
+ [リージョンとアベイラビリティーゾーンを選択する](https://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/RegionsAndAZs.html)
+ [例: 複数のアベイラビリティーゾーンにインスタンスを分散する](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#arch-AutoScalingMultiAZ)
+ [グローバルテーブル: DynamoDB を使用したマルチリージョンレプリケーション](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GlobalTables.html)
+ [Amazon Aurora グローバルデータベースの使用](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database.html)
+ [AWS のサービスによるマルチリージョンアプリケーションの作成 (ブログシリーズ)](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/)
+ [「What is AWS Outposts?」](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html)
**関連動画:**
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [AWS re:Invent 2019: Innovation and operation of the AWS global network infrastructure (NET339)](https://youtu.be/UObQZ3R9_4c)
# REL10-BP02 マルチロケーションデプロイ用の適切な場所の選択
## 期待される成果
高可用性のためには、(可能なときには) 常に、図 10 に示されているように、ワークロードコンポーネントを複数のアベイラビリティゾーン (AZ) にデプロイします。回復力要件が極端に高いワークロードについては、マルチリージョンアーキテクチャのオプションを慎重に評価してください。
![\[別の AWS リージョンへのバックアップを備えた回復力の高いマルチ AZ データベースデプロイを示す図\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2022-03-31/framework/images/multi-az-architecture.png)
## 一般的なアンチパターン:
+ マルチ AZ アーキテクチャで要件を満たせるときに、マルチリージョンアーキテクチャの設計を選択する。
+ 回復力要件とマルチロケーション要件がアプリケーションコンポーネント間で異なる場合に、コンポーネント間の依存関係を考慮しない。
## このベストプラクティスを活用するメリット:
回復力のためには、複数の防御層を構築するアプローチを使用する必要があります。1 つの層では、複数の AZ を使用して高可用性アーキテクチャを構築することによって、小規模で一般的な混乱に対して保護します。もう 1 つの防御層では、広範囲の自然災害やリージョンレベルの混乱など、まれな出来事に対して保護します。この 2 番目の層には、複数の AWS リージョン にまたがるアプリケーションの設計が必要です。
+ 99.5% の可用性と 99.9% の可用性の違いは、1 か月あたり 3.5 時間に相当します。複数の AZ で期待されるワークロードの可用性を達成するには、99.99% が必要です。
+ 複数の AZ でワークロードを実行することにより、電力、冷却、ネットワークの障害、および火災や洪水などの自然災害のほとんどを分離できます。
+ ワークロードのためのマルチリージョン戦略の実装は、国の広い範囲に影響を与える自然災害や、リージョン全体に及ぶ技術的障害に対する保護に役立ちます。マルチリージョンアーキテクチャの実装はかなり複雑になることがあり、通常、ほとんどのワークロードには不要である点に注意してください。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
1 つのアベイラビリティゾーンの混乱または部分的損失に基づく災害イベントについては、単一の AWS リージョン 内の複数のアベイラビリティゾーンで高可用性ワークロードを実装すると、自然災害または技術的な災害の軽減に役立ちます。各 AWS リージョン は複数のアベイラビリティゾーンで構成され、各ゾーンは他のゾーンの障害から隔離され、かなりの距離によって分離されます。ただし、相互にかなりの距離を隔てた複数のアベラビリティゾーンコンポーネントの損失リスクがある災害については、リージョン規模の障害を緩和するディザスタリカバリオプションを実装する必要があります。極端に高い回復力を必要とするワークロードについては (重要なインフラストラクチャ、医療関連のアプリケーション、財務システムインフラストラクチャなど)、マルチリージョン戦略が必要なことがあります。
## 実装手順
1. ワークロードを評価して、回復力ニーズをマルチ AZ アプローチ (単一の AWS リージョン) で満たせるか、それともマルチリージョンアプローチが必要かを判断します。これらの要件を満たすためにマルチリージョンアーキテクチャを実装すると、複雑性が増すため、ユースケースと要件を慎重に考慮してください。回復力の要件は、ほぼ常に、単一の AWS リージョン を使用して満たすことができます。複数のリージョンを使用する必要があるかどうかを判断するときには、次のような要件を考慮してください。
1. **ディザスタリカバリ (DR)**: 1 つのアベイラビリティゾーンの混乱または部分的損失に基づく災害イベントについては、単一の AWS リージョン 内の複数のアベイラビリティゾーンで高可用性ワークロードを実装すると、自然災害または技術的な災害の軽減に役立ちます。相互にかなりの距離を隔てた複数のアベイラビリティゾーンコンポーネントの損失リスクがある災害については、リージョン規模の自然災害や技術的障害を緩和するために、複数のリージョンにまたがるディザスタリカバリを実装する必要があります。
1. **高可用性 (HA)**: マルチリージョンアーキテクチャ (各リージョンで複数の AZ を使用) を使用して、99.99% 以上の可用性を達成できます。
1. **スタックローカリゼーション**: 世界中のオーディエンスにワークロードをデプロイするときには、異なる AWS リージョン にローカライズしたスタックをデプロイして、それらのリージョンのオーディエンスに対応できます。ローカリゼーションには、言語、通貨、および保存されるデータのタイプが含まれます。
1. **ユーザーへの近接性:** 世界中のオーディエンスにワークロードをデプロイするときには、エンドユーザーに近い AWS リージョン にスタックをデプロイすることによって、レイテンシーを軽減できます。
1. **データレジデンシー**: 一部のワークロードはデータレジデンシー要件の対象であり、特定のユーザーからのデータは特定の国境内にとどめる必要があります。該当する規制に基づいて、それらの国境内の AWS リージョン にスタック全体をデプロイするか、データだけをデプロイするかを選ぶことができます。
1. AWS のサービスによって提供されるマルチ AZ 機能の例をいくつか示します。
1. EC2 または ECS を使用するワークロードを保護するには、コンピューティングリソースの前に Elastic Load Balancer をデプロイします。Elastic Load Balancing は、異常のあるゾーンのインスタンスを検出して、正常なゾーンにトラフィックをルーティングするソリューションを提供します。
1. [Application Load Balancers の開始方法](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/application-load-balancer-getting-started.html)
1. [Network Load Balancer の開始方法](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/network-load-balancer-getting-started.html)
1. ロードバランシングをサポートしない市販のソフトウェアを実行する EC2 インスタンスの場合、マルチ AZ ディザスタリカバリ方法論を実装することによって、一種の耐障害性を達成できます。
1. [REL13-BP02 復旧目標を満たすため、定義された復旧戦略を使用する](rel_planning_for_recovery_disaster_recovery.md)
1. Amazon ECS タスクの場合は、3 つの AZ に均等にサービスをデプロイして、可用性とコストのバランスを達成します。
1. [Amazon ECS の可用性のベストプラクティス \$1 コンテナ](https://aws.amazon.com/blogs/containers/amazon-ecs-availability-best-practices/)
1. 非 Aurora Amazon RDS の場合、マルチ AZ を設定オプションとして選ぶことができます。プライマリデータベースインスタンスに障害が発生した場合、Amazon RDS はスタンバイデータベースを自動的に昇格させて、別のアベイラビリティゾーンのトラフィックを受け取ります。マルチリージョンリードレプリカを作成して、回復力を高めることもできます。
1. [Amazon RDS マルチ AZ デプロイ](https://aws.amazon.com/rds/features/multi-az/)
1. [別の AWS リージョン でのリードレプリカの作成](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.XRgn.html)
1. AWS のサービスによって提供されるマルチリージョン機能の例をいくつか示します。
1. マルチ AZ の可用性がサービスによって自動的に提供される Amazon S3 ワークロードの場合、マルチリージョンデプロイが必要な場合は、マルチリージョンアクセスポイントを検討してください。
1. [Amazon S3 のマルチリージョンアクセスポイント](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiRegionAccessPoints.html)
1. マルチ AZ の可用性がサービスによって自動的に提供される DynamoDB テーブルの場合、既存のテーブルをグローバルテーブルに容易に変換して、複数リージョンの利点を活かすことができます。
1. [単一リージョン Amazon DynamoDB テーブルをグローバルテーブルに変換する](https://aws.amazon.com/blogs/aws/new-convert-your-single-region-amazon-dynamodb-tables-to-global-tables/)
1. ワークロードの前に Application Load Balancers または Network Load Balancer がある場合には、AWS Global Accelerator を使用し、正常なエンドポイントを含んでいる複数のリージョンにトラフィックを向けることで、アプリケーションの可用性を高めます。
1. [AWS Global Accelerator にける標準アクセラレーター用エンドポイント - AWS Global Accelerator (amazon.com)](https://docs.aws.amazon.com/global-accelerator/latest/dg/about-endpoints.html)
1. AWS EventBridge を利用するアプリケーションの場合、クロスリージョンバスによってイベントを、選択したほかのリージョンに転送することを検討してください。
1. [Amazon EventBridge イベントの AWS リージョン 間での送受信](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-cross-region.html)
1. Amazon Aurora データベースの場合、複数の AWS リージョンにまたがる Aurora グローバルデータベースを検討してください。既存のクラスターを変更して、新しいリージョンも追加できます。
1. [Amazon Aurora グローバルデータベースの開始方法](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-getting-started.html)
1. ワークロードに AWS Key Management Service (AWS KMS) 暗号化キーが含まれる場合は、マルチリージョンキーがアプリケーションに適切かどうかを考慮してください。
1. [AWS KMS のマルチリージョンキー](https://docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-overview.html)
1. その他の AWS サービスの機能については、このブログシリーズの [AWS のサービスによるマルチリージョンアプリケーションの作成シリーズを参照してください。](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/)
**実装計画の工数レベル: **中～高
## リソース
**関連するドキュメント:**
+ [AWS のサービスによるマルチリージョンアプリケーションの作成シリーズを参照してください。](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/)
+ [AWS のディザスタリカバリ (DR) アーキテクチャ、パート IV: マルチサイトアクティブ/アクティブ](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iv-multi-site-active-active/)
+ [AWS グローバルインフラストラクチャ](https://aws.amazon.com/about-aws/global-infrastructure)
+ [AWS Local Zones のよくある質問](https://aws.amazon.com/about-aws/global-infrastructure/localzones/faqs/)
+ [AWS のディザスタリカバリ (DR) アーキテクチャ、パート I: クラウドでのリカバリ戦略](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-i-strategies-for-recovery-in-the-cloud/)
+ [クラウド上の災害対策はさまざまある](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-is-different-in-the-cloud.html)
+ [グローバルテーブル: DynamoDB を使用したマルチリージョンレプリケーション](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GlobalTables.html)
**関連動画:**
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [Auth0: 自動フェイルオーバーにより、月あたり 15 億回以上のログインにスケールするマルチリージョンの高可用性アーキテクチャ](https://www.youtube.com/watch?v=vGywoYc_sA8)
**関連する例:**
+ [AWS のディザスタリカバリ (DR) アーキテクチャ、パート I: クラウドでのリカバリ戦略](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-i-strategies-for-recovery-in-the-cloud/)
+ [DTCC はオンプレミスで実行できることをはるかに超えた回復力を達成](https://aws.amazon.com/solutions/case-studies/DTCC/)
+ [Expedia Group は専有 DNS サービスでマルチリージョン、マルチアベイラビリティゾーンを使用して、アプリケーションに回復力を追加](https://aws.amazon.com/solutions/case-studies/expedia/)
+ [Uber: マルチリージョン Kafka の災害対策](https://eng.uber.com/kafka/)
+ [Netflix: マルチリージョンの回復力のためのアクティブ/アクティブ](https://netflixtechblog.com/active-active-for-multi-regional-resiliency-c47719f6685b)
+ [Atlassian Cloud のデータ回復力を構築する方法](https://www.atlassian.com/engineering/how-we-build-data-residency-for-atlassian-cloud)
+ [Intuit TurboTax は 2 つのリージョンで実行](https://www.youtube.com/watch?v=286XyWx5xdQ)
# REL10-BP03 単一のロケーションに制約されるコンポーネントのリカバリを自動化する
ワークロードのコンポーネントが 1 つのアベイラビリティゾーンまたはオンプレミスのデータセンターでのみ実行できる場合は、定義された復旧目標内でワークロードを全面的に再構築する機能を実装する必要があります。
技術的な制約のためにワークロードを複数のロケーションにデプロイするベストプラクティスが不可能な場合は、弾力性を確保するための代替パスを採り入れる必要があります。このような場合、必要なインフラストラクチャを再作成し、アプリケーションを再デプロイし、必要なデータを再作成する機能を自動化する必要があります。
例えば、Amazon EMR は同じアベイラビリティーゾーンで特定のクラスターのすべてのノードを起動します。これは、同じゾーンでクラスターを実行すると、データアクセス率が高くなり、ジョブフローのパフォーマンスが向上するためです。このコンポーネントがワークロードの回復力のために必要な場合は、クラスターとそのデータを再デプロイする方法が必要です。また、Amazon EMR では、マルチ AZ を使用する以外の方法で冗長性をプロビジョニングする必要があります。複数のマスターノードを [プロビジョニングできます](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-ha-launch.html).EMR ファイルシステム (EMRFS) [を使用すると](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-fs.html)、EMR のデータを Amazon S3 に保存でき、次にそのデータを複数のアベイラビリティゾーンまたは AWS リージョン にわたってレプリケートできます。
Amazon Redshift も同様に、デフォルトでは、選択した AWS リージョン 内のランダムに選択されたアベイラビリティゾーンにクラスターをプロビジョニングします。すべてのクラスターノードが同じゾーンにプロビジョニングされます。
**このベストプラクティスを活用しない場合のリスクレベル:** ミディアム
## 実装のガイダンス
+ 自己修復を実装します。可能であれば自動スケーリングを利用して、インスタンスとコンテナをデプロイします。自動スケーリングを利用できない場合は、EC2 インスタンスの自動復旧機能を利用するか、Amazon EC2 または ECS のコンテナのライフサイクルイベントに基づいた自己修復自動化を実装します。
+ 単一インスタンス IP アドレスや、プライベート IP アドレス、Elastic IP アドレス、インスタンスメタデータを必要としないインスタンスとコンテナのワークロードには、Auto Scaling グループを使用します。
+ [EC2 Auto Scaling とは?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
+ [サービスのオートスケーリング](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-auto-scaling.html)
+ 起動設定ユーザーデータを使用して、ほとんどのワークロードを自己修復できるオートメーションを実装できます。
+ 単一インスタンス IP アドレスや、プライベート IP アドレス、elastic IP アドレス、インスタンスメタデータを必要とするワークロードには、EC2 インスタンスの自動復旧機能を使用します。
+ [インスタンスの復旧](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html)
+ 自動復旧は、インスタンスの障害が検出されると、復旧ステータスアラートを SNS トピックに送信します。
+ オートスケーリングや EC2 の復旧機能を利用できない場合は、EC2 インスタンスのライフサイクルイベントや ECS イベントを利用して、自己修復を自動化します。
+ [EC2 Auto Scaling ライフサイクルフック](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html)
+ [Amazon ECS イベント](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_cwe_events.html)
+ 必要なプロセスロジックに従ってコンポーネントを修復するオートメーションを呼び出すには、イベントを利用します。
## リソース
**関連するドキュメント:**
+ [Amazon ECS イベント](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_cwe_events.html)
+ [EC2 Auto Scaling ライフサイクルフック](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html)
+ [インスタンスの復旧](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html)
+ [サービスのオートスケーリング](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-auto-scaling.html)
+ [EC2 Auto Scaling とは?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
# REL10-BP04 バルクヘッドアーキテクチャを使用して影響範囲を制限する
このパターンは、船の隔壁のように、障害がリクエストまたはユーザーの小さなサブセットに確実にとどまるようにすることで、障害のあるリクエストの数を制限し、ほとんどがエラーなしで続行できるようにします。多くの場合、データの隔壁はパーティションと呼ばれ、サービスの隔壁はセルと呼ばれます。
セルベースのアーキテクチャ *では*、各セルは独立した完全なサービスのインスタンスで、最大サイズは固定されています。負荷が増加すると、セルが追加されることでワークロードが増大します。着信トラフィックでパーティションキーを使用して、リクエストを処理するセルを決定します。障害は発生した単一のセルに限定され、他のセルがエラーなしで継続するため、障害のあるリクエストの数が制限されます。セル間の相互作用を最小限に抑え、各リクエストに複雑なマッピングサービスを含める必要がないように、適切なパーティションキーを特定することが重要です。複雑なマッピングを必要とするサービスは、問題をマッピングサービスにシフトするだけですが、セル間の相互作用を必要とするサービスは、セルの独立性が低下します (そのため、これにより想定される可用性の改善が低下)。
![\[セルベースアーキテクチャを示す図\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2022-03-31/framework/images/cell-based-architecture.png)
AWS ブログ投稿で、Colm MacCarthaigh 氏は Amazon Route 53 が [https://aws.amazon.com/blogs/architecture/shuffle-sharding-massive-and-magical-fault-isolation/](https://aws.amazon.com/blogs/architecture/shuffle-sharding-massive-and-magical-fault-isolation/) の概念を使用して、顧客リクエストをシャードに分離する方法を説明します。この場合、シャードは 2 つ以上のセルで構成されます。パーティションキーに基づいて、顧客 (またはリソース、または分離対象) からのトラフィックは、割り当てられたシャードにルーティングされます。シャードごとに 2 つのセルを持つ 8 つのセルがあり、顧客が 4 つのシャードに分割された場合、問題が発生した場合に影響を受ける顧客は全体の 25% です。
![\[従来のシャードに分割されたサービスを示す図\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2022-03-31/framework/images/service-divided-into-traditional-shards.png)
シャッフルシャーディングでは、それぞれ 2 つのセルを持つ仮想シャードを作成し、顧客をそれらの仮想シャードの 1 つに割り当てます。問題が発生した場合でも、サービス全体の 4 分の 1 が失われる可能性がありますが、顧客またはリソースが割り当てられる方法から、シャッフルシャーディングでは影響を受ける範囲が 25% を大幅に下回ることになります。8 つのセル中の 2 つのセルには 28 のユニークな組み合わせがあります。つまり、シャッフルシャード (仮想シャード) が 28 通りあります。数百または数千の顧客がいて、各顧客を 1 つのシャッフルシャードに割り当てた場合、問題が発生したことで影響を受ける範囲はわずか 1/28 です。これは通常のシャーディングより 7 倍優れています。
![\[シャッフルシャードに分割されたサービスを示す図\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2022-03-31/framework/images/service-divided-into-shuffle-shards.png)
シャードは、セルだけでなく、サーバー、キュー、またはその他のリソースにも使用できます。
**このベストプラクティスを活用しない場合のリスクレベル:** ミディアム
## 実装のガイダンス
+ バルクヘッドアーキテクチャを使用します。このパターンは、船の隔壁のように、障害がリクエストまたはユーザーの小さなサブセットに確実にとどまるようにすることで、障害のあるリクエストの数を制限し、ほとんどがエラーなしで続行できるようにします。多くの場合、データの隔壁はパーティションと呼ばれ、サービスの隔壁はセルと呼ばれます。
+ [Well-Architected ラボ: シャッフルシャーディングを使用した障害分離](https://wellarchitectedlabs.com/reliability/300_labs/300_fault_isolation_with_shuffle_sharding/)
+ [Shuffle-sharding: AWS re:Invent 2019: Introducing The Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1373)
+ [AWS re:Invent 2018: How AWS Minimizes the Blast Radius of Failures (ARC338)](https://youtu.be/swQbA4zub20)
+ ワークロードのセルベースのアーキテクチャを評価します。セルベースのアーキテクチャでは、各セルは独立した完全なサービスのインスタンスで、最大サイズは固定されています。負荷が増加すると、セルが追加されることでワークロードが増大します。着信トラフィックでパーティションキーを使用して、リクエストを処理するセルを決定します。障害は発生した単一のセルに限定され、他のセルがエラーなしで継続するため、障害のあるリクエストの数が制限されます。セル間の相互作用を最小限に抑え、各リクエストに複雑なマッピングサービスを含める必要がないように、適切なパーティションキーを特定することが重要です。複雑なマッピングを必要とするサービスは、問題をマッピングサービスにシフトするだけですが、セル間の相互作用を必要とするサービスは、セルの自律性が低下します (そのため、予想された可用性の向上も低下します)。
+ Colm MacCarthaigh は、 AWS ブログの記事で、Amazon Route 53 がシャッフルシャーディングの概念を用いて顧客のリクエストをシャードに分離する方法を説明しています。
+ [シャッフルシャーディング: 大量およびマジカルな障害切り離し](https://aws.amazon.com/blogs/architecture/shuffle-sharding-massive-and-magical-fault-isolation)
## リソース
**関連するドキュメント:**
+ [シャッフルシャーディング: 大量およびマジカルな障害切り離し](https://aws.amazon.com/blogs/architecture/shuffle-sharding-massive-and-magical-fault-isolation)
+ [The Amazon Builders' Library: シャッフルシャーディングを使ったワークロードの分離](https://aws.amazon.com/builders-library/workload-isolation-using-shuffle-sharding/)
**関連動画:**
+ [AWS re:Invent 2018: How AWS Minimizes the Blast Radius of Failures (ARC338)](https://youtu.be/swQbA4zub20)
+ [Shuffle-sharding: AWS re:Invent 2019: Introducing The Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1373)
**関連する例:**
+ [Well-Architected ラボ: シャッフルシャーディングを使用した障害分離](https://wellarchitectedlabs.com/reliability/300_labs/300_fault_isolation_with_shuffle_sharding/)
# REL 11 コンポーネントの障害に耐えるようにワークロードを設計するにはどうすればよいですか?
高い可用性と低い平均復旧時間 (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-BP01 ワークロードのすべてのコンポーネントをモニタリングして障害を検知する
ワークロードの状態を継続的にモニタリングすることで、お客様と自動化システムがパフォーマンスの低下や完全な障害の発生を速やかに把握できるようにします。ビジネス価値に基づいて重要業績評価指標 (KPI) をモニタリングします。
復旧および修復メカニズムはすべて、問題を迅速に検出する機能から開始する必要があります。技術的な障害を最初に検出して、解決できるようにするのです。ただし、可用性はワークロードがビジネス価値を提供する能力に基づいているため、これを測定する重要業績評価指標 (KPI) が検出および修正戦略の一部である必要があります。
**一般的なアンチパターン:**
+ アラームが設定されていないため、停止は通知なしで発生します。
+ アラームは存在しますが、そのしきい値では対応するために十分な時間がありません。
+ メトリクスは、目標復旧時間 (RTO) を満たすのに十分な頻度で収集されません。
+ ワークロードの顧客向け階層のみがアクティブにモニタリングされます。
+ 技術的なメトリクスのみ収集し、ビジネス関数のメトリクスは収集しません。
+ ワークロードのユーザーエクスペリエンスを測定するメトリクスはありません。
**このベストプラクティスを活用するメリット:** すべてのレイヤーで適切なモニタリングを行うことで、検出までの時間を短縮して、復旧時間を短縮できます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
+ 復旧の目標に基づいて、コンポーネントの収集間隔を決定します。
+ モニタリング間隔は、どの程度迅速に復旧する必要があるかによって異なります。復旧時間は復旧にかかる時間によって決まるため、この時間と目標復旧時間 (RTO) を考慮して、収集の頻度を決定する必要があります。
+ コンポーネントの詳細モニタリングを設定します。
+ EC2 インスタンスと Auto Scaling の詳細モニタリングが必要かどうかを判断します。詳細モニタリングは 1 分間隔メトリクスを提供し、デフォルトのモニタリングは 5 分間隔メトリクスを提供します。
+ [インスタンスの詳細モニタリングの有効化/無効化](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-cloudwatch-new.html)
+ [Amazon CloudWatch を使用した Auto Scaling グループおよびインスタンスのモニタリング](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-monitoring.html)
+ RDS の拡張モニタリングが必要かどうかを判断します。拡張モニタリングでは、RDS インスタンスのエージェントを使用して、RDS インスタンスのさまざまなプロセスまたはスレッドに関する有益な情報を取得します。
+ [拡張モニタリング](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html)
+ ビジネスの重要業績評価指標 (KPI) を測定するカスタムメトリクスを作成します。ワークロードは主要なビジネス機能を実装します。これらの関数は、いつ間接的な問題が発生したのかを特定するのに役立つ KPI として使用される必要があります。
+ [カスタムメトリクスの発行](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ 模擬モニタリングを使用して、障害に対するユーザーエクスペリエンスをモニタリングします。顧客の行動を実行およびシミュレートできる合成トランザクションテスト (「カナリアテスト」とも呼ばれますが、カナリアデプロイと混同しないでください) は、最も重要なテストプロセスの 1 つです。さまざまなリモートロケーションからワークロードエンドポイントに対してこれらのテストを常に実行します。
+ [Amazon CloudWatch Synthetics により模擬モニタリングを作成可能](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ ユーザーのエクスペリエンスを追跡するカスタムメトリクスを作成します。顧客のエクスペリエンスを測定できる場合は、コンシューマーエクスペリエンスが低下するタイミングを判断できます。
+ [カスタムメトリクスの発行](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ ワークロードの一部が正常に動作していないことを検出し、リソースを Auto Scaling するタイミングを示すアラームを設定します。アラームはダッシュボードに視覚的に表示したり、Amazon SNS または E メールでアラートを送信したり、Auto Scaling と連携してワークロードのリソースをスケールアップまたはスケールダウンしたりできます。
+ [Amazon CloudWatch アラームの使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ ダッシュボードを作成してメトリクスを視覚化します。ダッシュボードは、傾向や異常値などの潜在的な問題の指標を視覚的に確認したり、調査対象となり得る問題の存在の示唆を与えたりするために使用できます。
+ [CloudWatch ダッシュボードの使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
## リソース
**関連するドキュメント:**
+ [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)
+ [Amazon CloudWatch を使用した Auto Scaling グループおよびインスタンスのモニタリング](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)
+ [CloudWatch ダッシュボードの使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
**関連する例:**
+ [Well-Architected ラボ: レベル 300: ヘルスチェックを実装し依存関係を管理して、信頼性を向上する](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html)
# REL11-BP02 正常なリソースにフェイルオーバーする
リソース障害の発生時に、正常なリソースが引き続きリクエストに対応できるようにします。ロケーション障害 (アベイラビリティゾーンや AWS リージョン など) に対しては、障害のないロケーションの正常なリソースにフェイルオーバーするシステムを用意します。
Elastic Load Balancing や AWS Auto Scaling などの AWS のサービスは、複数のリソースおよびアベイラビリティゾーンへの負荷分散に役立ちます。そのため、個々のリソース (EC2 インスタンスなど) の障害や、アベイラビリティゾーンの障害を、残りの正常なリソースにトラフィックをシフトすることによって緩和できます。マルチリージョンのワークロードの場合、状況はさらに複雑です。例えば、クロスリージョンリードレプリカを使用すると、データを複数の AWS リージョン にデプロイできますが、障害が発生した場合は、リードレプリカをプライマリに昇格させ、そこにトラフィックを向かわせる必要があります。Amazon Route 53 と AWS Global Accelerator は、AWS リージョン 間のトラフィックのルーティングを容易にします。
ワークロードが Amazon S3 や Amazon DynamoDB などの AWS のサービスを使用している場合、自動的に複数のアベイラビリティゾーンにデプロイされます。障害が発生した場合、AWS コントロールプレーンはトラフィックを正常なロケーションに自動的にルーティングします。データは複数のアベイラビリティゾーンに冗長的に保存され、使用可能なままとなります。Amazon RDS の場合、設定オプションとしてマルチ AZ を選択する必要があります。その場合、障害が発生すると、AWS はトラフィックを正常なインスタンスに自動的にルーティングします。Amazon EC2 インスタンス、Amazon ECS タスク、または Amazon EKS ポッドの場合、デプロイ先のアベイラビリティゾーンを選択します。Elastic Load Balancing は、異常なゾーンのインスタンスを検出し、正常なゾーンにトラフィックをルーティングするソリューションを提供します。Elastic Load Balancing は、オンプレミスのデータセンターのコンポーネントにトラフィックをルーティングすることもできます。
マルチリージョンのアプローチ (オンプレミスのデータセンターも含まれる場合があります) の場合、Amazon Route 53 はインターネットドメインを定義し、ヘルスチェックを含むルーティングポリシーを割り当てて、トラフィックが正常なリージョンにルーティングされるようにします。または、AWS Global Accelerator は、アプリケーションへの固定エントリポイントとして機能する静的 IP アドレスを提供します。そして、インターネットの代わりに AWS グローバルネットワークを使用して、選択した AWS リージョン のエンドポイントにルーティングして、パフォーマンスと信頼性を向上させます。
AWS は、障害復旧を念頭に置いてサービスの設計に取り組んでいます。当社は、障害からの復旧時間とデータへの影響を最小限に抑えるサービスを設計しています。当社のサービスは主にデータストアを使用しており、リクエストが認識されるのは、リージョン内の複数のレプリカにわたりデータが永続的に保存された後です。これらのサービスとリソースには Amazon Aurora、Amazon Relational Database Service (Amazon RDS) マルチ AZ DB インスタンス、Amazon S3、Amazon DynamoDB、Amazon Simple Queue Service、Amazon SQS、および Amazon Elastic File System (Amazon EFS) が含まれます。これらのサービスは、セル単位の分離とアベイラビリティーゾーンにより提供される障害切り分けを活用するように構成されています。当社は、運用上の手順の多くで自動化を幅広く使用しています。また、中断から迅速に復旧するために、置換と再起動の機能を最適化しています。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
+ 正常なリソースにフェイルオーバーします。リソース障害の発生時に、正常なリソースが引き続きリクエストに対応できるようにします。ロケーション障害 (アベイラビリティゾーンや AWS リージョン など) に対しては、障害のないロケーションの正常なリソースにフェイルオーバーするシステムを用意します。
+ ワークロードが Amazon S3 や Amazon DynamoDB などの AWS のサービスを使用している場合、自動的に複数のアベイラビリティゾーンにデプロイされます。障害が発生した場合、AWS コントロールプレーンはトラフィックを正常なロケーションに自動的にルーティングします。
+ Amazon RDS の場合、設定オプションとしてマルチ AZ を選択する必要があります。その場合、障害が発生すると、AWS はトラフィックを正常なインスタンスに自動的にルーティングします。
+ [Amazon RDS の高可用性 (マルチ AZ)](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html)
+ Amazon EC2 インスタンスまたは Amazon ECS タスクの場合、デプロイ先のアベイラビリティーゾーンを選択します。Elastic Load Balancing は、異常なゾーンのインスタンスを検出 し、正常なゾーンにトラフィックをルーティングするソリューションを提供します。Elastic Load Balancing は、オンプレミスのデータセンターのコンポーネントにトラフィックをルーティングすることもできます。
+ マルチリージョンのアプローチ (オンプレミスのデータセンターが含まれる場合もあります) の場合は、正常なロケーションのデータとリソースが、引き続きリクエストに対応できることを確認します。
+ 例えば、クロスリージョンリードレプリカを使用すると、データを複数の AWS リージョン にデプロイできますが、プライマリロケーションに障害が発生した場合は、リードレプリカをマスターに昇格させ、そこにトラフィックを向かわせる必要があります。
+ [Amazon RDS リードレプリカの概要](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html)
+ Amazon Route 53 は、インターネットドメインを定義し、ヘルスチェックを含むルーティングポリシーを割り当てて、トラフィックが正常なリージョンに確実にルーティングされるようにする方法を提供します。または、AWS Global Accelerator は、アプリケーションへの固定エントリポイントとして機能する静的 IP アドレスを提供します。そして、インターネットの代わりに AWS グローバルネットワークを使用して、選択した AWS リージョン のエンドポイントにルーティングして、パフォーマンスと信頼性を向上させます。
+ [Amazon Route 53: ルーティングポリシーを選択する](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html)
+ [「AWS Global Accelerator とは何ですか?」](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html)
## リソース
**関連するドキュメント:**
+ [APN パートナー: 耐障害性のオートメーションを支援できるパートナー](https://aws.amazon.com/partners/find/results/?keyword=automation)
+ [AWS Marketplace: 耐障害性に関して活用できる商品](https://aws.amazon.com/marketplace/search/results?searchTerms=fault+tolerance)
+ [AWS OpsWorks: 自動ヒーリングを使用して障害のあるインスタンスを置き換える](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html)
+ [Amazon Route 53: ルーティングポリシーを選択する](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html)
+ [Amazon RDS の高可用性 (マルチ AZ)](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html)
+ [Amazon RDS リードレプリカの概要](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html)
+ [Amazon ECS タスク配置戦略](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement-strategies.html)
+ [複数のアベイラビリティゾーンの Kubernetes Auto Scaling グループの作成](https://aws.amazon.com/blogs/containers/amazon-eks-cluster-multi-zone-auto-scaling-groups/)
+ [「AWS Global Accelerator とは何ですか?」](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html)
**関連する例:**
+ [Well-Architected ラボ: レベル 300: ヘルスチェックを実装し依存関係を管理して、信頼性を向上する](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html)
# REL11-BP03 すべてのレイヤーの修復を自動化する
障害を検出したら、自動化機能を使用して修復するアクションを実行します。
*再起動する機能* は、障害を修復するための重要なツールです。分散システムについて前述したように、ベストプラクティスは、可能な場合はサービスをステートレスにすることです。これにより、再起動時のデータまたは可用性が失われるのを防ぎます。クラウドでは、再起動の一環として、リソース全体 (EC2 インスタンス、Lambda 関数など) を置き換えることができます (通常はそうする必要があります)。再起動自体は、障害から復旧するための簡単で信頼できる方法です。ワークロードでは、さまざまなタイプの障害が発生します。障害は、ハードウェア、ソフトウェア、通信、オペレーションなどさまざまな部分で発生する可能性があります。さまざまなタイプの障害をそれぞれ捕捉、特定、修正するための新しいメカニズムを構築するのではなく、さまざまなカテゴリの障害を同じ復旧戦略にマッピングします。ハードウェアの障害、オペレーティングシステムのバグ、メモリリーク、その他の原因で、インスタンスが機能しなくなることがあります。状況ごとにカスタム修復を構築するのではなく、そのいずれかをインスタンスの障害として扱います。インスタンスを終了し、AWS Auto Scaling がそのインスタンスを置き換えることを許可します。その後、障害が発生したリソースの分析を帯域外で実行します。
もう 1 つの例は、ネットワークリクエストを再起動する機能です。依存関係にあるシステムからエラーが返された場合、ネットワークのタイムアウトの場合と依存関係にあるシステムの障害の両方に同じ復旧アプローチを適用します。どちらのイベントもシステムに類似の影響を与えるため、どちらかのイベントを「特例」とするのではなく、エクスポネンシャルバックオフとジッターで限定的に再試行するという類似の戦略を適用します。
*再起動する機能* は、復旧指向コンピューティング (ROC) と高可用性クラスターアーキテクチャを特徴とする復旧メカニズムです。
Amazon EventBridge を使用して、CloudWatch アラームなどのイベントや他の AWS のサービスの状態の変化をモニタリングおよびフィルタリングできます。イベント情報に基づいて、AWS Lambda、AWS Systems Manager Automation、または他のターゲットをトリガーして、ワークロードに対してカスタム修正ロジックを実行できます。
Amazon EC2 Auto Scaling は、EC2 インスタンスの状態をチェックするように設定できます。インスタンスが実行中以外の状態にある場合、またはシステムステータスが損なわれている場合、Amazon EC2 Auto Scaling はインスタンスが異常であると見なし、代替インスタンスを起動します。AWS OpsWorks を使用している場合は、OpsWorks レイヤーレベルで EC2 インスタンスの自動ヒーリングを設定できます。
大規模な置き換え (アベイラビリティーゾーン全体の喪失など) の場合、複数の新しいリソースを一度に取得するのではなく、静的安定性が高可用性のために優先されます。
**一般的なアンチパターン:**
+ インスタンスまたはコンテナにアプリケーションを個別にデプロイします。
+ 自動復旧を使用せずに、複数のロケーションにデプロイできないアプリケーションをデプロイします。
+ 自動スケーリングと自動復旧が修復に失敗するアプリケーションを手動で修復します。
**このベストプラクティスを活用するメリット:** ワークロードが一度に 1 つのロケーションにしかデプロイできない場合でも、自動ヒーリングによって、復旧までの平均時間が短縮され、ワークロードの可用性を確保できます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
+ Auto Scaling グループを使用して、ワークロードに階層をデプロイします。オートスケーリングは、ステートレスなアプリケーションで自己修復を実行し、キャパシティーを追加および削除できます。
+ [AWS Auto Scaling の仕組み](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ 複数のロケーションにデプロイできないアプリケーションがデプロイされている EC2 インスタンスに自動復旧を実装し、障害時の再起動を許容できます。自動復旧は、アプリケーションが複数のロケーションにデプロイできない場合に、障害が発生したハードウェアを交換してインスタンスを再起動するために使用できます。インスタンスメタデータおよび関連する IP アドレスは保持されます。また、Amazon EBS ボリュームと Elastic File Systems または File Systems for Lustre and Windows へのマウントポイントも保持されます。
+ [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 を使用している場合は、レイヤーレベルで EC2 インスタンスの自動ヒーリングを設定できます。
+ [AWS OpsWorks: 自動ヒーリングを使用して、障害のあるインスタンスを置き換える](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html)
+ 自動スケーリングまたは自動復旧を使用できない場合、または自動復旧が失敗した場合は、AWS Step Functions と AWS Lambda を使用して自動復旧を実装します。自動スケーリングを使用できず、さらに、自動復旧が使用できないか、自動復旧が失敗した場合は、AWS Step Functions と AWS Lambda を使用して修復を自動化できます。
+ [「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)
+ Amazon EventBridge を使用して、CloudWatch アラームなどのイベントや他の AWS のサービスの状態の変化をモニタリングおよびフィルタリングできます。イベント情報に基づいて、AWS Lambda (または他のターゲット) をトリガーし、ワークロードに対してカスタム修正ロジックを実行できます。
+ [「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)
## リソース
**関連するドキュメント:**
+ [APN パートナー: 耐障害性のオートメーションを支援できるパートナー](https://aws.amazon.com/partners/find/results/?keyword=automation)
+ [AWS Marketplace: 耐障害性に関して活用できる商品](https://aws.amazon.com/marketplace/search/results?searchTerms=fault+tolerance)
+ [AWS OpsWorks: 自動ヒーリングを使用して、障害のあるインスタンスを置き換える](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.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)
+ [AWS Auto Scaling の仕組み](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ [Amazon CloudWatch アラームの使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [「Amazon EventBridge とは?」](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [「AWS Lambda とは何ですか?」](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)
+ [AWS Systems Manager Automation をトリガーして](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [「AWS Step Functions とは何ですか?」](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.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 の静的安定性: AWS re:Invent 2019: Introducing The Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=704)
**関連する例:**
+ [Well-Architected ラボ: レベル 300: ヘルスチェックを実装し依存関係を管理して、信頼性を向上する](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html)
# REL11-BP04 復旧中はコントロールプレーンではなくデータプレーンを利用する
コントロールプレーンはリソースの設定に使用し、データプレーンはサービスを提供します。通常、データプレーンの可用性設計目標はコントロールプレーンよりも高く、複雑さは低くなっています。回復力に影響する可能性があるイベントに対して復旧または軽減対策を実装するときは、コントロールプレーンを使用すると、アーキテクチャの全体的な回復力が下がる可能性があります。例えば、Amazon Route 53 データプレーンを利用して、ヘルスチェックに基づいて DNS クエリを確実にルーティングできますが、Route 53 ルーティングポリシーの更新にはコントロールプレーンを使用するため、これを復旧には利用しないでください。
Route 53 データプレーンは、DNS クエリに応答し、ヘルスチェックを実行し、評価します。グローバルに分散され、 [100% の可用性サービスレベルアグリーメント (SLA) として設計されています。](https://aws.amazon.com/route53/sla/) Route 53 のリソースを作成、更新、削除する Route 53 管理 API およびコンソールは、コントロールプレーンで実行します。コントロールプレーンは、DNS の管理に必要な強力な一貫性と耐久性を重視するように設計されています。これを達成するために、コントロールプレーンは単一のリージョン、US East (N. Virginia) に配置されています。どちらのシステムも非常に高い信頼性で構築されていますが、コントロールプレーンは SLA には含まれません。まれに、データプレーンの回復力設計によって可用性を維持できるときでも、コントロールプレーンでは維持でない場合があります。ディザスタリカバリおよびフェイルオーバーメカニズムについては、データプレーンの機能を使用して、可能な限り最善の信頼性を提供してください。
データプレーン、コントロールプレーン、および AWS が高可用性目標を満たすためにサービスを構築する方法の詳細については、 [アベイラビリティーゾーンを使用した静的安定性](https://aws.amazon.com/builders-library/static-stability-using-availability-zones) ペーパーと [Amazon Builders' Library を参照してください。](https://aws.amazon.com/builders-library/)
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
+ ディザスタリカバリに Amazon Route 53 を使用するときには、コントロールプレーンではなくデータプレーンを利用します。Route 53 Application Recovery Controller は、準備状況のチェックとルーティングコントロールを使用して、フェイルオーバーの管理と調整を支援します。これらの機能により、障害から回復するアプリケーションの能力を継続的にモニタリングし、複数の AWS リージョン、アベイラビリティゾーン、およびオンプレミスにまたがってアプリケーションの回復を管理できます。
+ [Route 53 Application Recovery Controller とは](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
+ [Amazon Route 53 を使用したディザスタリカバリメカニズムの作成](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/)
+ [Amazon Route 53 を使用した回復力の高いアプリケーションの構築、パート 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 Route 53 を使用した回復力の高いアプリケーションの構築、パート 1: シングルリージョンスタック](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/)
+ データプレーンでの運用と、コントロールプレーンでの運用を理解します。
+ [The 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 Lambda の実行](https://docs.aws.amazon.com/whitepapers/latest/security-overview-aws-lambda/lambda-executions.html) (コントロールプレーンとデータプレーンに分割されています)
## リソース
**関連するドキュメント:**
+ [APN パートナー: 耐障害性のオートメーションを支援できるパートナー](https://aws.amazon.com/partners/find/results/?keyword=automation)
+ [AWS Marketplace: 耐障害性に関して活用できる商品](https://aws.amazon.com/marketplace/search/results?searchTerms=fault+tolerance)
+ [The 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 のデータプレーン](https://docs.aws.amazon.com/mediastore/latest/apireference/API_Operations_AWS_Elemental_MediaStore_Data_Plane.html)
+ [Amazon Route 53 を使用した回復力の高いアプリケーションの構築、パート 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 Route 53 を使用した回復力の高いアプリケーションの構築、パート 1: シングルリージョンスタック](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 を使用したディザスタリカバリメカニズムの作成](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/)
+ [Route 53 Application Recovery Controller とは](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
**関連する例:**
+ [Amazon Route 53 Application Recovery Controller の概要](https://aws.amazon.com/blogs/aws/amazon-route-53-application-recovery-controller/)
# REL11-BP05 静的安定性を使用してバイモーダル動作を防止する
バイモーダル動作とは、たとえばアベイラビリティーゾーンに障害が発生した場合に新しいインスタンスの起動に依存するなど、通常モードと障害モードでワークロードが異なる動作を示す場合をいいます。バイモーダル動作を防止するために、静的に安定し、1 つのモードでのみ動作するワークロードを構築する必要があります。この場合、1 つの AZ が削除された場合にワークロードの負荷を処理するのに十分な数のインスタンスを各アベイラビリティーゾーンにプロビジョニングしてから、Elastic Load Balancing または Amazon Route 53 ヘルスチェックを使用して、障害のあるインスタンスから負荷を分散します。
EC2 インスタンスやコンテナなどのコンピューティングデプロイの静的安定性があると、信頼性が最も高くなります。これは、コストがかかる懸念と比較検討する必要があります。プロビジョニングするコンピューティングキャパシティーを減らし、障害が発生した場合は新しいインスタンスを起動する方が、コストは低くなります。ただし、大規模な障害 (アベイラビリティーゾーンの障害など) が発生した場合には、効果が低くなります。このアプローチは障害が発生する前に準備するのではなく、障害が発生したときに事後的に対処することになるためです。ソリューションを考える際は、信頼性とワークロードのコストのニーズを比較検討する必要があります。より多くのアベイラビリティーゾーンを使用することで、静的安定性に必要なコンピューティングキャパシティーが減少します。
![\[複数のアベイラビリティゾーンにわたる EC2 インスタンスの静的安定性を示す図\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2022-03-31/framework/images/static-stability.png)
トラフィックがシフトした後、AWS Auto Scaling を使用して、障害が発生したゾーンのインスタンスを非同期で置き換え、正常なゾーンで起動します。
バイモーダル動作のもう 1 つの例に、ネットワークのタイムアウトにより、システム全体の設定状態の再読み込みが始まることがあります。これにより想定外の負荷が別のコンポーネントに加わり、そのコンポーネントで障害が発生し、想定外の結果につながる可能性があります。この負のフィードバックループは、ワークロードの可用性に影響を与えます。そこで、静的に安定し、1 つのモードでのみ動作するシステムを構築する必要があります。静的に安定した設計は、一定の作業を行い、常に一定の周期で設定状態を更新することになるでしょう。呼び出しに失敗すると、ワークロードは以前にキャッシュされた値を使用し、アラームをトリガーします。
バイモーダル動作のもう 1 つの例は、障害発生時にクライアントがワークロードキャッシュをバイパスできるようにすることです。これは、クライアントのニーズに対応するソリューションのように思われるかもしれませんが、ワークロードのリクエストを大幅に変更し、障害が発生する可能性が高いため、許可すべきではありません。
**このベストプラクティスを活用しない場合のリスクレベル:** ミディアム
## 実装のガイダンス
+ 静的安定性を使用してバイモーダル動作を防止します。バイモーダル動作とは、たとえばアベイラビリティーゾーンに障害が発生した場合に新しいインスタンスの起動に依存するなど、通常モードと障害モードでワークロードが異なる動作を示す場合をいいます。
+ [災害対策プランでの依存関係の最小化](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)
+ [AWS の静的安定性: AWS re:Invent 2019: Introducing The Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=704)
+ バイモーダル動作を防止するために、静的に安定し、1 つのモードでのみ動作するシステムを構築する必要があります。この場合、1 つの AZ が削除された場合にワークロードの負荷を処理するのに十分な数のインスタンスを各ゾーンにプロビジョニングしてから、Elastic Load Balancing または Amazon Route 53 ヘルスチェックを使用して、障害のあるインスタンスから負荷をシフトします。
+ バイモーダル動作のもう 1 つの例は、障害発生時にクライアントがワークロードキャッシュをバイパスできるようにすることです。これは、クライアントのニーズに対応するソリューションのように思われるかもしれませんが、ワークロードのリクエストを大幅に変更し、障害が発生する可能性が高いため、許可すべきではありません。
## リソース
**関連するドキュメント:**
+ [災害対策プランでの依存関係の最小化](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)
**関連動画:**
+ [AWS の静的安定性: AWS re:Invent 2019: Introducing The Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=704)
# REL11-BP06 イベントが可用性に影響する場合に通知を送信する
重大なイベントが検出されると、イベントによって引き起こされた問題が自動的に解決された場合でも、通知が送信されます。
自動ヒーリング機能により、ワークロードの信頼性を高めることができます。ただし、対処する必要のある根本的な問題もあいまいになる可能性があります。根本原因の問題を解決できるように、自動ヒーリングによって対処されたものを含む問題のパターンを検出できるように、適切なモニタリングとイベントを実装します。Amazon CloudWatch アラームは、発生した障害に基づいてトリガーできます。また、実行された自動ヒーリングアクションに基づいてトリガーすることもできます。CloudWatch アラームは、Amazon SNS 統合を使用して、E メールを送信するか、サードパーティのインシデント追跡システムにインシデントを記録するように設定できます。
**一般的なアンチパターン:**
+ 誰もアクションを実行しないアラームを送信する。
+ オートヒーリングのオートメーションを実行したが、ヒーリングが必要とされたことは通知しない。
**このベストプラクティスを確立するメリット:** 復旧イベントの通知により、まれに発生する問題を無視することがなくなります。
**このベストプラクティスが確立されていない場合のリスクレベル:** ミディアム
## 実装のガイダンス
+ ビジネスの重要業績評価指標が低しきい値を超えたときに警告します。ビジネス KPI に低しきい値を設定すると、ワークロードが利用不可または機能していない場合にそれを認識できます。
+ [静的しきい値に基づいて CloudWatch アラームを作成する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html)
+ ヒーリングオートメーションを呼び出すイベントについて警告します。SNS API を直接呼び出して、作成したオートメーションで通知を送信できます。
+ [Amazon Simple Notification Service とは](https://docs.aws.amazon.com/sns/latest/dg/welcome.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)
# REL 12 信頼性はどのようにテストすればよいですか?
本番環境のストレスに耐えられるようにワークロードを設計した後、ワークロードが意図したとおりに動作し、期待する弾力性を実現することを確認する唯一の方法が、テストを行うことです。
**Topics**
+ [REL12-BP01 プレイブックを使用して障害を調査する](rel_testing_resiliency_playbook_resiliency.md)
+ [REL12-BP02 インシデント後の分析を実行する](rel_testing_resiliency_rca_resiliency.md)
+ [REL12-BP03 機能要件をテストする](rel_testing_resiliency_test_functional.md)
+ [REL12-BP04 スケーリングおよびパフォーマンス要件をテストする](rel_testing_resiliency_test_non_functional.md)
+ [REL12-BP05 カオスエンジニアリングを使用して回復力をテストする](rel_testing_resiliency_failure_injection_resiliency.md)
+ [REL12-BP06 定期的にゲームデーを実施する](rel_testing_resiliency_game_days_resiliency.md)
# REL12-BP01 プレイブックを使用して障害を調査する
調査プロセスをプレイブックに文書化することで、よく理解されていない障害シナリオに対する一貫性のある迅速な対応が可能になります。プレイブックは、障害シナリオの原因となる要因を特定するために実行される事前定義されたステップです。プロセスステップの結果は、問題が特定されるか、エスカレーションされるまで、次のステップを決定するために使用されます。
プレイブックは、対応措置を効果的に実行できるようにするために立てる必要があるプロアクティブな計画です。本番環境でプレイブックに含まれていない障害シナリオが発生した場合は、まず問題に対処します (火を消します)。その後、振り返って問題に対処するために実行した手順を見て、これらの手順を用いてプレイブックに新しいエントリを追加します。
プレイブックは特定のインシデントに対応するために用いられる一方、ランブックは特定の結果を達成するために使用されます。多くの場合、ランブックは日常的なアクティビティに用いられる一方、プレイブックは非日常的なイベントに応えるために使用します。
**一般的なアンチパターン:**
+ 問題の診断やインシデントへの対応を行うためのプロセスを知ることなくワークロードのデプロイを計画する。
+ イベントを調査するときに、ログとメトリクスを収集するシステムに関する計画外の決定。
+ データを取得するためにメトリクスとイベントを十分な期間保持していない。
**このベストプラクティスを活用するメリット:** プレイブックをキャプチャすることで、プロセスへの一貫した遵守が実現できます。プレイブックを成文化することによって、手動のアクティビティによるエラーの発生が抑制されます。プレイブックのオートメーションは、チームメンバーの介入の必要性をなくし、または介入の開始時に追加情報を提供することによって、イベントへの対応時間を短縮します。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
+ プレイブックを使用して問題を特定します。プレイブックは、問題を調査するための文書化されたプロセスです。プロセスをプレイブックに文書化することで、障害シナリオに対する一貫性のある迅速な対応が可能になります。プレイブックには、十分なスキルを持った人物が該当する情報の収集、障害の潜在的原因の特定、障害の切り分け、寄与する要因の特定 (インシデント後の分析の実行) を行うために必要な情報とガイダンスが含まれている必要があります。
+ プレイブックをコードとして実装します。プレイブックをスクリプト化することにより、運用をコードとして実行し、一貫性を保ち、手動プロセスによって発生するエラーを抑制または低減します。プレイブックは、問題に寄与する要因を特定するために必要となり得るさまざまなステップを表す複数のスクリプトで構成できます。ランブックのアクティビティは、プレイブックのアクティビティの一部としてトリガーまたは実行するか、特定されたイベントへの応答としてプレイブックの実行を引き起こす場合があります。
+ [AWSSystems Manager を使用して運用上のプレイブックを自動化する](https://aws.amazon.com/about-aws/whats-new/2019/11/automate-your-operational-playbooks-with-aws-systems-manager/)
+ [AWS Systems Manager Run コマンド](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html)
+ [AWS Systems Manager Automation をトリガーして](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [「AWS Lambda とは何ですか?」](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)
+ [「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)
## リソース
**関連するドキュメント:**
+ [AWS Systems Manager Automation をトリガーして](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [AWS Systems Manager Run コマンド](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html)
+ [AWSSystems Manager を使用して運用上のプレイブックを自動化する](https://aws.amazon.com/about-aws/whats-new/2019/11/automate-your-operational-playbooks-with-aws-systems-manager/)
+ [Amazon CloudWatch アラームの使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [カナリアの使用 (Amazon CloudWatch Synthetics)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [「Amazon EventBridge とは?」](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [「AWS Lambda とは何ですか?」](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)
**関連する例:**
+ [プレイブックとランブックによるオペレーションの自動化](https://wellarchitectedlabs.com/operational-excellence/200_labs/200_automating_operations_with_playbooks_and_runbooks/)
# REL12-BP02 インシデント後の分析を実行する
顧客に影響を与えるイベントを確認し、寄与する要因と予防措置を特定します。この情報を使用して、再発を制限または回避するための緩和策を開発します。迅速で効果的な対応のための手順を開発します。対象者に合わせて調整された、寄与する要因と是正措置を必要に応じて伝えます。必要に応じて根本原因を他の人に伝える方法を確立します。
既存のテストで問題が見つからなかった理由を評価します。テストがまだ存在しない場合は、このケースのテストを追加します。
**一般的なアンチパターン:**
+ 寄与因子を見つけるが、他の潜在的な問題やリスクの軽減策についてさらに詳しく調べない。
+ 人的エラーの原因を特定するだけで、人的ミスを防止し得るトレーニングやオートメーションを実施しない。
**このベストプラクティスを活用するメリット:** インシデント後の分析を実施し、結果を共有することで、他のワークロードが同じ寄与因子を実装した場合のリスクを軽減し、インシデントが発生する前に軽減策または自動復旧を実装できます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
+ インシデント後の分析の標準を確立します。優れたインシデント後の分析は、システムの別の場所で使用されているアーキテクチャパターンの問題に対して、共通のソリューションを提案する機会になります。
+ 寄与する要因の記述が正直であり、非難の対象にならないようにします。
+ 問題を文書化しないと、問題を修正できません。
+ 提案された是正措置を冷静に検討し、アプリケーションチームにおける誠実な自己評価とコラボレーションを促進できるようにするため、インシデント後の分析が非難の場にならないようにします。
+ プロセスを使用して、寄与した要因を判断します。イベントに寄与した要因を特定してドキュメント化するプロセスを用意しておき、再発を抑制または防止する緩和策と、迅速で効果的な対応手順を展開できるようにしておきます。対象者に合わせて調整された、寄与因子を必要に応じて伝えます。
+ [ログ分析とは?](https://aws.amazon.com/log-analytics/)
## リソース
**関連するドキュメント:**
+ [ログ分析とは?](https://aws.amazon.com/log-analytics/)
+ [エラーの修正 (COE) を開発すべき理由](https://aws.amazon.com/blogs/mt/why-you-should-develop-a-correction-of-error-coe/)
# REL12-BP03 機能要件をテストする
必要な機能を検証する単体テストや統合テストなどの技法を使用します。
これらのテストがビルドおよびデプロイアクションの一部として自動的に実行されると、最良の結果が得られます。例えば、デベロッパーは AWS CodePipeline を使用して、CodePipeline が変更を自動的に検出するソースリポジトリに変更をコミットします。このような変更が構築されたら、テストが実行されます。テストが完了すると、ビルドされたコードがテストのためステージングサーバーにデプロイされます。CodePipeline はステージングサーバーから統合テストや負荷テストなど、より多くのテストを実行します。これらのテストが正常に完了すると、CodePipeline はテストおよび承認されたコードを本番稼働インスタンスにデプロイします。
また、経験上、合成トランザクションテスト ( *カナリアテスト*とも呼ばれますが、カナリアデプロイと混同しないでください) は、顧客の行動を実行およびシミュレートでき、最も重要なテストプロセスの 1 つです。さまざまなリモートロケーションからワークロードエンドポイントに対してこれらのテストを常に実行します。Amazon CloudWatch Synthetics を使用すると、 [Canary を作成して](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) エンドポイントと API をモニタリングできます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
+ 機能要件をテストします。これには、必要な機能を検証する単体テストと統合テストが含まれます。
+ [AWS CodeBuild で CodePipeline を使用してコードをテストし、ビルドを実行する](https://docs.aws.amazon.com/codebuild/latest/userguide/how-to-create-pipeline.html)
+ [AWS CodePipeline が、AWS CodeBuild を使用した単体テストとカスタム統合テストのサポートを追加](https://aws.amazon.com/about-aws/whats-new/2017/03/aws-codepipeline-adds-support-for-unit-testing/)
+ [継続的デリバリーと継続的インテグレーション](https://docs.aws.amazon.com/codepipeline/latest/userguide/concepts-continuous-delivery-integration.html)
+ [カナリアの使用 (Amazon CloudWatch Synthetics)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [ソフトウェアテストのオートメーション](https://aws.amazon.com/marketplace/solutions/devops/software-test-automation)
## リソース
**関連するドキュメント:**
+ [APN パートナー: 継続的インテグレーションパイプラインの実装を支援できるパートナー](https://aws.amazon.com/partners/find/results/?keyword=Continuous+Integration)
+ [AWS CodePipeline が、AWS CodeBuild を使用した単体テストとカスタム統合テストのサポートを追加](https://aws.amazon.com/about-aws/whats-new/2017/03/aws-codepipeline-adds-support-for-unit-testing/)
+ [AWS Marketplace: 継続的インテグレーションに利用できる製品](https://aws.amazon.com/marketplace/search/results?searchTerms=Continuous+integration)
+ [継続的デリバリーと継続的インテグレーション](https://docs.aws.amazon.com/codepipeline/latest/userguide/concepts-continuous-delivery-integration.html)
+ [ソフトウェアテストのオートメーション](https://aws.amazon.com/marketplace/solutions/devops/software-test-automation)
+ [AWS CodeBuild で CodePipeline を使用してコードをテストし、ビルドを実行する](https://docs.aws.amazon.com/codebuild/latest/userguide/how-to-create-pipeline.html)
+ [カナリアの使用 (Amazon CloudWatch Synthetics)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
# REL12-BP04 スケーリングおよびパフォーマンス要件をテストする
負荷テストなどの技法を使用して、ワークロードがスケーリングおよびパフォーマンス要件を満たしていることを検証します。
クラウドでは、ワークロードに合わせて、本番稼働働規模のテスト環境を作成できます。スケールダウンしたインフラストラクチャでこれらのテストを実行する場合、観測された結果を、本番環境で予想される事態にスケーリングする必要があります。実際のユーザーに影響を与えないように注意する場合は、本番環境でも負荷テストとパフォーマンステストを行います。その際、実際のユーザーデータと混合したり、使用統計や本番レポートを破損しないないようにテストデータにタグを付けます。
テストでは、ベースリソース、スケーリング設定、サービスクォータ、および弾力性設計が負荷がかかる時に想定どおりに動作することを確認します。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
+ スケーリングおよびパフォーマンス要件をテストします。ワークロードがスケーリングおよびパフォーマンスの要件を満たしていることを検証するための負荷テストを実行します。
+ [AWS での分散負荷テスト: 接続された数千のユーザーをシミュレートする](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/)
+ [Apache JMeter](https://github.com/apache/jmeter?ref=wellarchitected)
+ 本番環境と同じ環境にアプリケーションをデプロイして、負荷テストを実施します。
+ コードとしてのインフラストラクチャの概念を使用して、できるだけ本番環境と類似した環境を作成する
## リソース
**関連するドキュメント:**
+ [AWS での分散負荷テスト: 接続された数千のユーザーをシミュレートする](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/)
+ [Apache JMeter](https://github.com/apache/jmeter?ref=wellarchitected)
# REL12-BP05 カオスエンジニアリングを使用して回復力をテストする
不利な条件下でシステムがどのように反応するかを理解するために、本番環境またはできるだけそれに近い環境で定期的にカオス実験を行います。
** 期待される成果: **
イベント発生時のワークロードの既知の期待動作を検証する回復力テストに加え、フォールトインジェクション実験や想定外の負荷の注入という形でカオスエンジニアリングを適用し、ワークロードの回復力を定期的に検証します。カオスエンジニアリングと回復力テストの両方を組み合わせることで、ワークロードがコンポーネントの故障に耐え、予期せぬ中断から影響を最小限に抑えて回復できることへの信頼を得ることができます。
** 一般的なアンチパターン: **
+ 耐障害性を考慮した設計でありながら、障害発生時にワークロードが全体としてどのように機能するかを検証していない。
+ 実際の条件および予期された負荷の下で実験を一切行わない。
+ 実験をコードとして処理しないか、開発サイクルを通して維持しない。
+ CI/CD パイプラインの一部、またはデプロイの外部のどちらとしても、カオス実験を実行しない。
+ どの障害で実験するかを考慮する際に、過去のインシデント後の分析を軽視する。
** このベストプラクティスを活用するメリット:** ワークロードの回復力を検証するために障害を発生させることにより、耐障害性設計の回復手順が実際の障害発生時にも機能するという信頼性を得られます。
**このベストプラクティスを活用しない場合のリスクレベル:** ミディアム
## 実装のガイダンス
カオスエンジニアリングは、サービスプロバイダ、インフラストラクチャ、ワークロード、コンポーネントレベルにおいて、現実世界の障害 (シミュレーション) を継続的に発生させる機能を提供し、顧客には最小限の影響しか与えません。これにより、チームは障害から学び、ワークロードの回復力を観察、測定、改善することができます。また、イベント発生時にアラートが発せられ、チームに通知されることを確認することもできます。
カオスエンジニアリングを継続的に実施することで、ワークロードの欠陥が浮き彫りになり、そのままにしておくと可用性や オペレーションに悪影響が及ぶ可能性があります。
**注記**
カオスエンジニアリングとは、あるシステムで実験を行い、実稼働時の混乱状態に耐えることができるかどうかの確信を得るための手法です。 [カオスエンジニアリングの原則](https://principlesofchaos.org/)
もし、システムがこれらの混乱に耐えられるなら、カオス実験は自動化された回帰テストとして維持されるはずです。このように、カオス実験はシステム開発ライフサイクル (SDLC) の一部および CI/CD の一部として実行される必要があります。
ワークロードがコンポーネントの障害に耐えられることを確認するために、実際のイベントを実験の一部として挿入します。たとえば、Amazon EC2 インスタンスの喪失やプライマリ Amazon RDS データベースインスタンスのフェイルオーバーを実験し、ワークロードに影響がないこと (または最小限の影響にとどまること) を確認します。コンポーネントの障害の組み合わせを使用して、アベイラビリティーゾーンで中断によって発生する可能性のあるイベントをシミュレートします。
アプリケーションレベルの障害 (クラッシュなど) では、メモリや CPU の枯渇などのストレス要因から始めます。
断続的なネットワークの中断による外部依存のための [フォールバックまたはフェイルオーバーメカニズム](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems/) を検証するために、コンポーネントは、数秒から数時間の指定された期間、サードパーティプロバイダへのアクセスをブロックすることにより、そのようなイベントをシミュレートする必要があります。
その他の劣化モードでは、機能の低下や応答の遅れが発生し、サービスの中断につながることがよくあります。このパフォーマンス低下の一般的な原因は、主要サービスのレイテンシー増加と、信頼性の低いネットワーク通信 (パケットのドロップ) です。レイテンシー、メッセージのドロップ、DNS 障害などのネットワーク効果を含むこれらの障害の実験には、名前を解決できない、DNS サービスへリーチできない、または依存サービスへの接続を確立できないなどの可能性があります。
**カオスエンジニアリングのツール:**
AWS Fault Injection Service (AWS FIS) は、フォールトインジェクション実験を実行する完全マネージド型サービスであり、CD パイプラインの一部として、またはパイプラインの外で使用することができます。AWS FIS は、カオスエンジニアリングゲームデー中に使用するのに適しています。Amazon EC2、Amazon Elastic Container Service (Amazon ECS)、Amazon Elastic Kubernetes Service (Amazon EKS)、および Amazon RDS などを含む、異なるタイプのリソースに同時に障害を導入することをサポートします。これらの障害には、リソースの終了、強制フェイルオーバー、CPU にストレスをかける、スロットリング、またはメモリー、レイテンシー、およびパケットの損失が含まれます。Amazon CloudWatch アラームと連携しているため、ガードレールとして停止条件を設定し、予期せぬ影響を与えた場合に実験をロールバックすることができます。
![\[ワークロードのフォールトインジェクション実験を実行するため、AWS リソースと統合された AWS Fault Injection Service を示す図。\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2022-03-31/framework/images/fault-injection-simulator.png)
フォールトインジェクション実験のためのサードパーティオプションもいくつかあります。これには、次のようなオープンソースのツールが含まれます。 [Chaos Toolkit](https://chaostoolkit.org/)、[Chaos Mesh](https://chaos-mesh.org/)、および [Litmus Chaos](https://litmuschaos.io/)、Gremlin などの商用オプションです。AWS に挿入できる障害のスコープを拡張するために、AWS FIS [ は Chaos Mesh および Litmus Chaos と統合して](https://aws.amazon.com/about-aws/whats-new/2022/07/aws-fault-injection-simulator-supports-chaosmesh-litmus-experiments/)、複数のツール間でフォールトインジェクションワークフローの調整を可能にします。たとえば、AWS FIS 障害アクションを使用して、ランダムに選択した割合のクラスターノードを終了する間に、Chaos Mesh または Litmus 障害を使用してポッドの CPU のストレステストを実行することができます。
## 実装手順
+ どの障害を実験に使用するかを決定する。
回復力に関してワークロードの設計を評価します。そのような設計 ( [Well-Architected フレームワーク](https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html)のベストプラクティスを使用して作成) では、重要な依存関係、過去のイベント、既知の問題、およびコンプライアンス要件に基づくリスクが考慮されています。回復力を維持するために意図された設計の各要素と、それを軽減するために設計された障害をリストアップします。そのようなリストの作成に関する詳細については、 [運用準備状況の確認に関するホワイトペーパー](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html) を確認し、過去のインシデントの再発を防ぐためのプロセスを作成する方法を学びます。障害モードと影響の分析 (FMEA) プロセスにより、障害とそれがワークロードに与える影響をコンポーネントレベルで解析するためのフレームワークが提供されます。FMEA については Adrian Cockcroft 氏による「 [Failure Modes and Continuous Resilience](https://adrianco.medium.com/failure-modes-and-continuous-resilience-6553078caad5)」内に詳しく記載されています。
+ それぞれの障害に優先度を割り当てる。
「高」「中」「低」などの大まかな分類から始めます。優先度を評価するためには、障害の発生頻度と障害によるワークロード全体への影響度を考慮します。
ある障害の発生頻度を考慮する場合、利用可能であれば、そのワークロードの過去のデータを分析します。利用できない場合は、類似の環境において実行されている他のワークロードのデータを使用します。
ある障害の影響を考慮する場合、一般に、障害の範囲が大きければ大きいほど、影響も大きくなります。また、ワークロードの設計と目的も考慮します。たとえば、ソースデータストアにアクセスする機能は、データ変換や分析を行うワークロードにとって重要です。この場合、アクセス障害、スロットルアクセス、レイテンシー挿入の実験を優先させることになります。
障害発生後の分析は、障害モードの頻度と影響の両方を理解するための良いデータソースとなります。
割り当てた優先度を使用して、どの障害を最初に実験するか、および新しいフォールトインジェクション実験を開発する順序を決定します。
+ 実行するそれぞれの実験に対して、カオスエンジニアリングと継続的な回復力のフライホイールに従います。
![\[改善、定常状態、仮説、実験の実行、検証の各フェーズを表すカオスエンジニアリングと継続的な回復力フライホイールの図\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2022-03-31/framework/images/chaos-engineering-flywheel.png)
+ 定常状態とは、正常な動作を示すワークロードの測定可能な出力であると定義する。
ワークロードは、信頼性が高く、期待通りに動作していれば、定常状態を示しています。したがって、定常状態を定義する前に、ワークロードが正常であることを検証します。障害が発生した場合、一定の割合で許容範囲内である可能性があるため、定常状態は、必ずしもワークロードに影響を与えないことを意味するものではありません。定常状態は、実験中に観察する基準値であり、次のステップで定義した仮説が予想通りにならない場合に、異常が浮き彫りになります。
たとえば、決済システムの定常状態は、成功率 99％、往復時間 500ms で 300TPS を処理することと定義することができます。
+ ワークロードがどのように障害に対応するかについての仮説を立てる。
良い仮説とは、定常状態を維持するために、ワークロードがどのように障害を軽減すると予想されるかに基づいています。仮説は、特定のタイプの障害が発生した場合、システムまたはワークロードが定常状態を維持することを示しています。なぜなら、ワークロードは特定の緩和策を講じて設計されているからです。特定の種類の障害および緩和策は、仮説の中で特定さ れる必要があります。
次のテンプレートが仮説に使用できます (ただし、他の表現も許容されます)。
**注記**
もし *特定の障害* が発生した場合、 *ワークロード名* ワークロードは *緩和措置を説明* して *ビジネスまたは技術的なメトリクスの影響を維持します*。
例:
+ Amazon EKS ノードグループの 20% のノードが停止しても、[Transaction Create API] は 100 ミリ秒未満で 99% のリクエストに対応し続けます (定常状態)。Amazon EKS ノードは 5 分以内に回復し、ポッドは実験開始後 8 分以内にスケジューリングされてトラフィックを処理するようになります。3 分以内にアラートが発せられます。
+ Amazon EC2 インスタンスの単一障害が発生した場合、注文システムの Elastic Load Balancing ヘルスチェックにより、Amazon EC2 Auto Scaling が障害インスタンスを置き換える間、Elastic Load Balancing は残りの健全なインスタンスにのみリクエストを送信し、サーバーサイド (5xx) エラーの増加を 0.01% 未満に維持します (定常状態)。
+ プライマリ Amazon RDS データベースインスタンスに障害が発生した場合、サプライチェーンデータ収集ワークロードはフェイルオーバーし、スタンバイ Amazon RDS データベースインスタンスに接続して、データベースの読み取りまたは書き込みエラーを 1 分未満に維持します (定常状態)。
+ 障害を挿入して実験を実行する。
実験はデフォルトでフェイルセーフであり、ワークロードが耐えることができる必要があります。ワークロードが失敗することが分かっている場合は、実験を実行しないでください。カオスエンジニアリングは、既知の未知、または未知なる未知を見つけるために使用されるべきです。*既知の未知* とは、認識はしているが完全に理解していないことであり、 *未知なる未知* は、認識も完全な理解もしていないことです。壊れていると分かっているワークロードに対して実験を行っても、新しいインサイトを得ることはできません。実験は慎重に計画し、影響の範囲を明確にし、予期せぬ乱れが発生した場合に適用できるロールバックメカニズムを提供する必要があります。デューディリジェンスにより、ワークロードが実験に耐えられることが分かったら、実験を進めてください。障害を挿入するには、いくつかの方法があります。AWS 上のワークロードに対して、[AWS FIS](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html) は多くの事前定義された障害シミュレーションを挿入します。これは、 [アクション](https://docs.aws.amazon.com/fis/latest/userguide/actions.html)と呼ばれます。また、AWS FIS で実行するカスタムアクションも定義します。これには [AWS Systems Manager ドキュメント](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-ssm-docs.html)を使用します。
カオス実験にカスタムスクリプトを使用することは、スクリプトがワークロードの現在の状態を理解する機能を持ち、ログを出力でき、可能であればロールバックと停止条件のメカニズムを提供しない限り、推奨されません。
カオスエンジニアリングをサポートする効果的なフレームワークやツールセットは、実験の現在の状態を追跡し、ログを出力し、実験の制御された実行をサポートするためのロールバックメカニズムを提供する必要があります。AWS FIS のように、実験範囲を明確に定義し、実験によって予期せぬ乱れが生じた場合に実験をロールバックする安全なメカニズムを備えた実験を行うことができる、確立されたサービスから始めてみてください。AWS FIS を使用した、より幅広い実験に関する詳細については、「 [カオスエンジニアリングラボでの回復力と Well-Architected アプリ](https://catalog.us-east-1.prod.workshops.aws/workshops/44e29d0c-6c38-4ef3-8ff3-6d95a51ce5ac/en-US)」も参照してください。また、 [AWS Resilience Hub](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html) はワークロードを分析し、AWS FIS で実装、実行することを選択できるような実験を作成します。
**注記**
すべての実験について、その範囲と影響を明確に理解します。本番環境で実行する前に、まず非本番環境で障害をシミュレートすることをお勧めします。
実験は、可能な限り、対照系と実験系の両方をスピンアップする [canary デプロイ](https://medium.com/the-cloud-architect/chaos-engineering-q-a-how-to-safely-inject-failure-ced26e11b3db) を使用して、実世界の負荷で実稼働させる必要があります。オフピークの時間帯に実験を行うことは、本番で初めて実験を行う際に潜在的な影響を軽減するための良い習慣です。また、実際の顧客トラフィックを使用するとリスクが高すぎる場合は、本番インフラストラクチャの制御環境と実験環境に対して合成トラフィックを使用して実験を実行することができます。本番環境での実験が不可能な場合は、できるだけ本番環境に近いプレ本番環境で実験を行ってください。
実験が本番トラフィックや他のシステムに許容範囲を超えて影響を与えないように、ガードレールを確立してモニタリングする必要があります。停止条件を設定し、定義したガードレールのメトリクスでしきい値に達した場合に実験を停止するようにします。これには、ワークロードの定常状態のメトリクスと、障害を注入するコンポーネントに対するメトリク スを含める必要があります。ユーザー canary とも呼ばれる [合成モニタリング](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) は、通常、ユーザープロキシとして含む必要がある 1 つのメトリクスです。[AWS FIS への停止条件](https://docs.aws.amazon.com/fis/latest/userguide/stop-conditions.html) は、実験テンプレートの一部としてサポートされており、1 テンプレートあたり最大 5 つの停止条件を設定することが可能です。
カオスの原則の 1 つは、実験の範囲とその影響を最小化することです。
短期的な悪影響は許容されなければなりませんが、実験の影響を最小化し、抑制することはカオスエンジニアの責任であり義務です。
範囲や潜在的な影響を検証する方法としては、本番環境で直接実験を行うのではなく、まず非本番環境で実験を行い、実験中に停止条件のしきい値が想定通りに作動するか、例外をキャッチするための観測性があるかどうかを確認することが挙げられます。
フォールトインジェクション実験を実施する場合、すべての責任者に情報が十分に提供されるようにします。オペレーションチーム、サービス信頼性チーム、カスタマーサポートなどの適切なチームとコミュニケーションをとり、実験がいつ実行され、何を期待されるかを伝えます。これらのチームには、何か悪影響が見られた場合に、実験を行っているチームに知らせるためのコミュニケーションツールを与えます。
ワークロードとその基盤となるシステムを元の既知の良好な状態に復元する必要があります。多くの場合、ワークロードの回復力のある設計が自己回復を行います。しかし、一部の障害設計や実験の失敗により、ワークロードが予期せぬ障害状態に陥ることがあります。実験が終了するまでに、このことを認識し、ワークロードとシステムを復旧させなければなりません。AWS FIS では、アクションのパラメータ内にロールバック設定 (ポストアクションとも呼ばれる) を設定することができます。ポストアクションは、アクションが実行される前にある状態にターゲットを返します。自動化 (AWS FIS の使用など) であれ手動であれ、これらのポストアクションは、障害を検出し処理する方法を説明するプレイブックの一部であるべきです。
+ 仮説を検証する。
[カオスエンジニアリングの原則](https://principlesofchaos.org/) は、ワークロードの定常状態を検証する方法について、このようなガイダンスを示しています。
システムの内部属性ではなく、測定可能な出力に焦点を当てます。その出力を短期間で測定することによって、システムの安定状態のプロキシが構成されます。システム全体のスループット、エラーレート、レイテンシーのパーセンタイルはすべて、定常状態の動作を表す重要なメトリクスになり得ます。実験中にシステム的な動作パターンに注目することで、カオスエンジニアリングは、システムがどのように動作するかを検証するのではなく、システムが動作していることを検証します。
先の 2 つの例では、サーバーサイド (5xx) エラーの増加率が 0.01% 未満、データベースの読み取りと書き込みのエラーが 1 分未満という定常状態の測定基準が含まれています。
5xx エラーは、ワークロードのクライアントが直接経験する障害モードの結果であるため、良いメトリクスです。データベースエラーの測定は、障害の直接的な結果として適切ですが、顧客からのリクエストの失敗や、顧客に表面化したエラーなど、顧客への影響も測定して補足する必要があります。さらに、ワークロードのクライアントが直接アクセスする API や URI に、合成モニタリング (ユーザー canary としても知られる) を含めるようにしましょう。
+ 回復力を高めるためのワークロード設計を改善する。
定常状態が維持されなかった場合、障害を軽減するためにワークロード設計をどのように改善できるかを調査し、 [AWS Well-Architected 信頼性の柱](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html)のベストプラクティスを適用します。その他のガイダンスとリソースは [AWS Builder's Library](https://aws.amazon.com/builders-library/)にあり、ここでは、他の記事と共に [ヘルスチェックを見直す](https://aws.amazon.com/builders-library/implementing-health-checks/) 方法、または [アプリケーションコード内のバックオフを使用した再試行の採用](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)に関する記事が掲載されています。
これらの変更を実施した後、再度実験を行い (カオスエンジニアリングフライホイールの点線で表示)、その効果を判断します。検証の結果、仮説が正しいことがわかれば、ワークロードは定常状態になり、このサイクルが続きます。
+ 実験を定期的に実施する。
カオス実験はサイクルであり、実験はカオスエンジニアリングの一環として定期的に実施される必要があります。ワークロードが実験の仮説を満たした後、CI/CD パイプラインの回帰部分として継続的に実行されるように実験を自動化する必要があります。この方法については、このブログの「 [how to run AWS FIS experiments using AWS CodePipeline](https://aws.amazon.com/blogs/architecture/chaos-testing-with-aws-fault-injection-simulator-and-aws-codepipeline/)」を参照してください。このラボでは、 [CI/CD パイプラインで AWS FIS 実験](https://chaos-engineering.workshop.aws/en/030_basic_content/080_cicd.html) を繰り返し行うことで、実践的に作業することができます。
フォールトインジェクション実験は、ゲームデーの一部でもあります (参照: [REL12-BP06 定期的にゲームデーを実施する](rel_testing_resiliency_game_days_resiliency.md))。ゲームデーでは、障害やイベントをシミュレートし、システム、プロセス、チームの対応を検証します。その目的は、例外的な出来事が発生した場合にチームが実行することになっているアクションを実際に実行することです。
+ 実験結果をキャプチャし、保存する。
フォールトインジェクション実験の結果は、キャプチャおよび保持される必要があります。実験結果や傾向を後で分析できるように、必要なデータ (時間、ワークロード、条件など) をすべて含めておきましょう。結果の例には、ダッシュボードのスクリーンショット、メトリクスのデータベースからの CSV ダンプ、実験中のイベントや観察結果を手書きで記録したものなどがあります。[AWS FIS での実験記録](https://docs.aws.amazon.com/fis/latest/userguide/monitoring-logging.html) もデータキャプチャの一部となり得ます。
## リソース
**関連するベストプラクティス:**
+ [REL08-BP03 デプロイの一部として回復力テストを統合する](rel_tracking_change_management_resiliency_testing.md)
+ [REL13-BP03 ディザスタリカバリの実装をテストし、実装を検証する](rel_planning_for_recovery_dr_tested.md)
**関連するドキュメント:**
+ [AWS Fault Injection Service とは](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html)
+ [AWS Resilience Hub とは](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html)
+ [カオスエンジニアリングの原則](https://principlesofchaos.org/)
+ [カオスエンジニアリング: 最初の実験を計画する](https://medium.com/the-cloud-architect/chaos-engineering-part-2-b9c78a9f3dde)
+ [回復力エンジニアリング: 失敗から学ぶ](https://queue.acm.org/detail.cfm?id=2371297)
+ [カオスエンジニアリングのストーリー](https://github.com/ldomb/ChaosEngineeringPublicStories)
+ [分散システムでのフォールバックの回避](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems/)
+ [カオス実験の canary デプロイ](https://medium.com/the-cloud-architect/chaos-engineering-q-a-how-to-safely-inject-failure-ced26e11b3db)
**関連動画:**
+ [AWS re:Invent 2020: Testing resiliency using chaos engineering (ARC316)](https://www.youtube.com/watch?v=OlobVYPkxgg)
+ [AWS re:Invent 2019: Improving resiliency with chaos engineering (DOP309-R1)](https://youtu.be/ztiPjey2rfY)
+ [AWS re:Invent 2019: Performing chaos engineering in a serverless world (CMY301)](https://www.youtube.com/watch?v=vbyjpMeYitA)
**関連する例:**
+ [Well-Architected ラボ: レベル 300: Amazon EC2 Amazon RDS と Amazon S3 の回復力をテストする](https://wellarchitectedlabs.com/reliability/300_labs/300_testing_for_resiliency_of_ec2_rds_and_s3/)
+ [AWS ラボでのカオスエンジニアリング](https://chaos-engineering.workshop.aws/en/)
+ [カオスエンジニアリングラボでの回復力と Well-Architected アプリ](https://catalog.us-east-1.prod.workshops.aws/workshops/44e29d0c-6c38-4ef3-8ff3-6d95a51ce5ac/en-US)
+ [サーバーレスカオスラボ](https://catalog.us-east-1.prod.workshops.aws/workshops/3015a19d-0e07-4493-9781-6c02a7626c65/en-US/serverless)
+ [アプリケーションの回復力を AWS Resilience Hub ラボを使用して測定し、向上させる](https://catalog.us-east-1.prod.workshops.aws/workshops/2a54eaaf-51ee-4373-a3da-2bf4e8bb6dd3/en-US/200-labs/1wordpressapplab)
** 関連ツール: **
+ [AWS Fault Injection Service](https://aws.amazon.com/fis/)
+ AWS Marketplace: [Gremlin Chaos Engineering Platform](https://aws.amazon.com/marketplace/pp/prodview-tosyg6v5cyney)
+ [Chaos Toolkit](https://chaostoolkit.org/)
+ [Chaos Mesh](https://chaos-mesh.org/)
+ [Litmus](https://litmuschaos.io/)
# REL12-BP06 定期的にゲームデーを実施する
ゲームデーを使用して、実際の障害シナリオに関わる人々と、可能な限り本番環境に近い環境 (本番環境を含む) でのイベントと障害の対処手順を定期的に実行します。ゲームデーでは、本番環境のイベントがユーザーに影響を与えないようにするための対策を講じます。
ゲームデーでは、障害やイベントをシミュレーションして、システム、プロセス、チームの対応をテストします。その目的は、例外的な出来事が発生した場合にチームが実行することになっているアクションを実際に実行することです。これは、改善できる箇所を把握し、組織がイベントに対応することを経験するのに役⽴ちます。こうしたゲームデーを定期的に実施することで、チームは対応方法に関する *「基礎体力」* をつけることができます。
弾力性を考慮した設計が整い、本番環境以外の環境でテストした後、本番環境ですべてが計画どおりに機能することを確認するのがゲームデーです。ゲームデー、特に初日は、「全員が総力を挙げた」取り組みです。いつ起こるか、そして何が起こるかについてエンジニアと運用担当者に通知します。ランブックを用意します。障害イベントも含めて、シミュレートされたイベントが本番稼働システムで所定の方法で実行され、影響が評価されます。すべてのシステムが設計どおりに動作すると、検出と自己修復が行われ、影響はほとんどありません。ただし、負の影響が観察された場合、テストはロールバックされ、ワークロードの問題が必要に応じて (ランブックを参照して) 手動で修正されます。ゲームデーは本番環境で行われることが多いため、顧客の可用性に影響を与えないように、あらゆる予防策を講じる必要があります。
**一般的なアンチパターン:**
+ 手順は文書化するが、実行しない。
+ テスト演習にビジネス上の意思決定者を含めない。
**このベストプラクティスを活用するメリット:** ゲームデーを定期的に実施することで、実際のインシデントが発生したときにすべてのスタッフがポリシーと手順に従っていることを確認し、それらのポリシーと手順が適切であることを検証できます。
**このベストプラクティスを活用しない場合のリスクレベル:** ミディアム
## 実装のガイダンス
+ ゲームデーをスケジュールして定期的にランブックおよびプレイブックを使ってみるゲームデーには、事業主、開発スタッフ、運用スタッフ、インシデント対応チームといった、本番環境でのイベントに関与すると思われるすべての人員が参加する必要があります。
+ 負荷テストやパフォーマンステストを実施した後、障害注入を実施します。
+ ランブックのおかしな点やプレイブックを使う機会を探します。
+ ランブックから逸脱したら、対応マニュアルを改善するか行動を修正します。プレイブックを使用したら、使用すべきだったランブックを特定するか新しいランブックを作成します。
## リソース
**関連するドキュメント:**
+ [AWS GameDay とは?](https://aws.amazon.com/gameday/)
**関連動画:**
+ [AWS re:Invent 2019: Improving resiliency with chaos engineering (DOP309-R1)](https://youtu.be/ztiPjey2rfY)
**関連する例:**
+ [AWS Well-Architected ラボ - Testing Resiliency](https://wellarchitectedlabs.com/reliability/300_labs/300_testing_for_resiliency_of_ec2_rds_and_s3/)
# REL 13 災害対策 (DR) はどのように計画するのですか?
バックアップと冗長ワークロードコンポーネントを配置することは、DR 戦略の出発点です。[RTO と RPO は](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/disaster-recovery-dr-objectives.html) ワークロードの復旧目標です。これは、ビジネスニーズに基づいて設定します。ワークロードのリソースとデータのロケーションと機能を考慮して、目標を達成するための戦略を実装します。ワークロードの災害対策を提供することのビジネス価値を伝えるには、中断の可能性と復旧コストも重要な要素となります。
**Topics**
+ [REL13-BP01 ダウンタイムやデータ消失に関する復旧目標を定義する](rel_planning_for_recovery_objective_defined_recovery.md)
+ [REL13-BP02 復旧目標を満たすため、定義された復旧戦略を使用する](rel_planning_for_recovery_disaster_recovery.md)
+ [REL13-BP03 ディザスタリカバリの実装をテストし、実装を検証する](rel_planning_for_recovery_dr_tested.md)
+ [REL13-BP04 DR サイトまたはリージョンでの設定ドリフトを管理する](rel_planning_for_recovery_config_drift.md)
+ [REL13-BP05 復旧を自動化する](rel_planning_for_recovery_auto_recovery.md)
# REL13-BP01 ダウンタイムやデータ消失に関する復旧目標を定義する
ワークロードには、目標復旧時間 (RTO) と目標復旧時点 (RTO) が定義されます。
*目標復旧時間 (RTO)* RTO は、サービスの中断からサービスの復元までの最大許容遅延です。これにより、サービスが利用できないときに許容可能と見なされる時間枠が決まります。
*目標復旧時点 (RPO)* RPO は、最後のデータ復旧ポイントからの最大許容時間です。これにより、最後の復旧ポイントからサービスの中断までの間に許容可能と見なされるデータ損失が決まります。
RTO 値と RPO 値は、ワークロードに適したディザスタリカバリ (DR) 戦略を選択する際の重要な考慮事項です。これらの目標は企業によって決定され、技術チームによって DR 戦略の選択と実装のために使用されます。
**期待される成果:**
すべてのワークロードに、ビジネスへの影響に基づいて定義された RTO と RPO が割り当てられます。ワークロードが事前に定義された改装に割り当てられ、該当する RTO および RPO とともに、サービスの可用性と許容可能なデータ損失を定義します。そのような階層化ができない場合には、後で階層を作成する目的で、ワークロードごとに別注を割り当てることもできます。RTO と RPO は、ワークロードのディザスタリカバリ戦略実装を選択する際の主要な考慮事項の 1 つとして使用されます。DR 戦略を選択する際のその他の考慮事項としては、コストの制約、ワークロードの依存関係、運用要件があります。
RTO については、停止時間に基づく影響を理解してください。線形か、それとも非線形の意味合いがあるか (例えば、4 時間後に、次のシフトの開始まで製造ラインをシャットダウンしておく）。
次のようなディザスタリカバリマトリックスは、ワークロードが復旧目標にどの程度関係しているかを理解するのに役立ちます。(X 軸と Y 軸の実際の値は、組織のニーズに合わせてカスタマイズしてください)。
![\[ディザスタリカバリマトリックスを示すチャート\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2022-03-31/framework/images/disaster-recovery-matrix.png)
**一般的なアンチパターン:**
+ 復旧目標を定義していない。
+ 任意の復旧目標を選択する。
+ 過度に寛大で、ビジネス目標を満たさない復旧目標を選択する。
+ ダウンタイムとデータ損失の影響を理解していない。
+ 復旧時間ゼロやデータ損失ゼロなど、ワークロード設定では達成できない恐れのある非現実的な復旧目標を選択する。
+ 実際のビジネス目標よりも厳格な復旧目標を選択する。これにより、ワークロードが必要とするよりもコストが高く、複雑な DR 実装を強いられます。
+ 依存するワークロードの復旧目標とは互換性のない復旧目標を選択する。
+ 復旧目標で規制コンプライアンス要件が考慮されていない。
+ ワークロードの RTO と RPO は定義されたが、テストされていない。
**このベストプラクティスを活用するメリット:** 時間とデータ損失の復旧目標は、DR 実装の指針とするために必要です。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
特定のワークロードについて、ダウンタイムとデータ損失がビジネスに与える影響を理解する必要があります。一般に、ダウンタイムが長いほど、またはデータ損失が大きいほど、影響は増加しますが、この増加の形状はワークロードのタイプによって異なります。例えば、1 時間までのダウンタイムなら耐えられ、影響もほとんどないかもしれませんが、その後は影響が急増するかもしれません。ビジネスへの影響は、金銭的コスト (減益など)、顧客の信頼 (と評判への影響)、運用上の問題 (給与未払いや生産性の低下など)、規制リスクなど、多くの形態をとります。以下のステップを使用して、これらの影響を理解し、ワークロードの RTO と RPO を設定してください。
**実装手順**
1. このワークロードのビジネスステークホルダーを決め、これらのステップを実装するように促します。ワークロードの復旧目標は、ビジネス上の決定です。技術チームはビジネスステークホルダーと協力して、これらの目標に基づいて DR 戦略を選択します。
**注記**
ステップ 2 と 3 については、以下を使用してください。 [実装ワークシート](#implementation-worksheet).
1. 以下の質問に答えることによって、決定を下すために必要な情報を集めます。
1. ワークロードが組織に与える影響について、重要度のカテゴリまたは階層がありますか?
1. ある場合、このワークロードをカテゴリに割り当てます。
1. ない場合は、これらのカテゴリを確立します。5 つ以下のカテゴリを作成し、それぞれの目標復旧時間の範囲を絞り込みます。カテゴリの例としては、重要、高、中、低などがあります。ワークロードがどのようにカテゴリにマッピングされるかを理解するには、ワークロードがミッションクリティカルであるか、ビジネスにとって重要であるか、それともビジネスを駆動するものではないかを考慮します。
1. カテゴリに基づいて、ワークロードの RTO と RPO を設定します。このステップに入るときに計算した元の値より厳しいカテゴリ (低い RTO および RPO) を選ぶようにします。この結果、値の変化が不適切に大きくなる場合には、新しいカテゴリの作成を検討します。
1. これらの回答に基づいて、RTO 値と RPO 値をワークロードに割り当てます。これは直接行うか、ワークロードを事前定義のサービス階層に割り当てることで行うことができます。
1. このワークロードのディザスタリカバリプラン (DRP) を文書化し、組織の [ビジネス継続性計画 (BCP)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/business-continuity-plan-bcp.html)の一部とし、ワークロードチームとステークホルダーがアクセスできる場所に保管します。
1. RTO および RPO と、これらの値を決めるために使用した情報を記録します。ワークロードがビジネスに与える影響を評価するために使用した戦略も含めます。
1. RTO と RPO のほかに、ディザスタリカバリ目標のために追跡しているか、追跡する予定のその他のメトリクスも記録します。
1. DR 戦略とランブックを作成したときには、これらの詳細をこのプランに追加します。
1. 図 15 のようなマトリックスでワークロードの重要性を調べることで、組織で定義される事前定義のサービス階層の確立を開始できます。
1. に従って DR 戦略 (または DR 戦略の概念実証) を実装した後[REL13-BP02 復旧目標を満たすため、定義された復旧戦略を使用する](rel_planning_for_recovery_disaster_recovery.md)、この戦略をテストして、ワークロードの実際の RTC (復旧時間機能) と RPC (復旧時点機能) を判断します。これらがターゲットの復旧目標を満たさない場合は、ビジネスステークホルダーと協力して目標を調整するか、DR 戦略に変更を加えて、ターゲット目標を満たします。
**主な質問**
1. ワークロードがダウンしてからビジネスに重大な影響が出るまでの最大時間はどのくらいですか。
1. ワークロードが中断した場合にビジネスに及ぼす 1 分間あたりの金銭的コスト (直接的な経済的影響) を判断します。
1. 影響が常に線形とは限らないことを考慮します。影響は最初は限定的でも、臨界時点を超えると急増することがあります。
1. ビジネスに重大な影響が出るデータ損失の最大量はどのくらいですか。
1. 最も重要なデータストアについて、この値を考慮します。その他のデータストアのそれぞれの重要度を特定します。
1. ワークロードデータが失われた場合、再作成できますか? これがバックアップと復元よりも運用上容易な場合は、ワークロードデータの再作成に使用されるソースデータの重要度に基づいて RPO を選びます。
1. このワークロードに依存するワークロード (ダウンストリーム) またはこのワークロードが依存するワークロード (アップストリーム) の復旧目標と可用性期待は何ですか?
1. このワークロードがアップストリームの依存関係の要件を満たすことができる復旧目標を選びます。
1. ダウンストリームの依存関係の復旧機能を前提として達成可能な復旧目標を選びます。重要でないダウンストリームの依存関係 (「対処」できるもの) は除外できます。または、必要な場合は、ダウンストリームの重要な依存関係と協力して、復旧能力を高めます。
**その他の質問**
以下の質問と、これらがこのワークロードにどのように適用されるか考慮してください。
1. 停止のタイプ (リージョン対AZ など) に応じた異なる RTO および RPO がありますか?
1. RTO/RPO が変更される特定の時期 (季節性、販売イベント、製品の発売) がありますか? その場合、異なる測定と時間境界は何ですか?
1. ワークロードが中断した場合、何人の顧客が影響を受けますか?
1. ワークロードが中断した場合、評判への影響は何ですか?
1. ワークロードが中断した場合に発生する可能性のある、その他の運用上の影響は何ですか? 例えば、E メールシステムが使用できない場合や、給与システムがトランザクションを送信できない場合の従業員の生産性への影響などです。
1. ワークロードの RTO および RPO は基幹業務および組織の DR 戦略とどのように連携しますか?
1. サービスの提供に関する内部契約上の義務がありますか? 満たすことができなかった場合の罰則はありますか?
1. データに関する規制またはコンプライアンス制約は何ですか?
## 実装ワークシート
このワークシートは、実装ステップ 2 および 3 に使用できます。質問を追加するなど、特定のニーズに応じてこのワークシートを調整することができます。
![\[ワークシート\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2022-03-31/framework/images/worksheet.png)
**実装計画の工数レベル: **低
## リソース
**関連するベストプラクティス:**
+ [REL09-BP04 データの定期的な復旧を行ってバックアップの完全性とプロセスを確認する](rel_backing_up_data_periodic_recovery_testing_data.md)
+ [REL13-BP02 復旧目標を満たすため、定義された復旧戦略を使用する](rel_planning_for_recovery_disaster_recovery.md)
+ [REL13-BP03 ディザスタリカバリの実装をテストし、実装を検証する](rel_planning_for_recovery_dr_tested.md)
**関連するドキュメント:**
+ [AWS アーキテクチャブログ: Disaster Recovery Series](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [AWS でのワークロードのディザスタリカバリ: クラウドでの復旧 (AWS ホワイトペーパー)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [AWS レジリエンスハブによる回復力ポリシーの管理](https://docs.aws.amazon.com/resilience-hub/latest/userguide/resiliency-policies.html)
+ [APN パートナー: 災害対策を支援できるパートナー](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [AWS Marketplace: 災害対策に活用できる商品](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
**関連動画:**
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [Disaster Recovery of Workloads on AWS](https://www.youtube.com/watch?v=cJZw5mrxryA)
# REL13-BP02 復旧目標を満たすため、定義された復旧戦略を使用する
ワークロードの復旧目標を満たすディザスタリカバリ (DR) 戦略を定義します。バックアップと復元、スタンバイ (アクティブ/パッシブ)、アクティブ/アクティブなどの戦略を選択します。
DR 戦略は、プライマリロケーションでワークロードを実行できなくなった場合に復旧サイトでワークロードに耐えられる能力に依存します。最も一般的な復旧目標は、RTO と RPO です [REL13-BP01 ダウンタイムやデータ消失に関する復旧目標を定義する](rel_planning_for_recovery_objective_defined_recovery.md).
単一の AWS リージョン 内の複数のアベイラビリティゾーン (AZ) にまたがる DR 戦略は、火災、洪水、大規模な停電などの災害イベントに対して影響を緩和できます。ワークロードを特定の AWS リージョン で実行できなくなるような、可能性の低いイベントに対する保護を実装する必要がある場合には、複数のリージョンを使用する DR 戦略を使用できます。
複数のリージョンにまたがる DR 戦略を設計するときには、以下のいずれかの戦略を選んでください。戦略は、コストと複雑さの昇順、および RTO と RPO の降順でリストされています。 *復旧リージョン* とは、ワークロードで使用されるプライマリ以外の AWS リージョン を指します。
![\[DR 戦略を示す図\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2022-03-31/framework/images/disaster-recovery-strategies.png)
+ **バックアップと復元** (数時間での RPO、24 時間以下での RTO): データとアプリケーションを復旧リージョンにバックアップします。自動化されたバックアップまたは連続バックアップを使用すると、ポイントインタイムリカバリが可能であり、場合によっては RPO を 5 分間に短縮できます。災害の際には、インフラストラクチャをデプロイし (インフラストラクチャをコードとして使用して RTO を削減)、コードをデプロイし、バックアップされたデータを復元して、復旧リージョンで災害から復旧します。
+ **パイロットライト** （数分間の RPO、数十分間の RTO): コアワークロードインフラストラクチャのコピーを復旧リージョンにプロビジョニングします。データを復旧リージョンにレプリケートして、そこでバックアップを作成します。データベースやオブジェクトストレージなど、データのレプリケーションとバックアップのサポートに必要なリソースは、常にオンです。アプリケーションサーバーやサーバーレスコンピューティングなど、その他の要素はデプロイされませんが、必要なときには、必須の設定とアプリケーションコードで作成できます。
+ **ウォームスタンバイ** (数秒間の RPO、数分間の RTO): 完全に機能する縮小バージョンのワークロードを復旧リージョンで常に実行している状態に保ちます。ビジネスクリティカルなシステムは完全に複製され、常に稼働していますが、フリートは縮小されています。データは復旧リージョンでレプリケートされ、使用可能です。復旧時には、システムをすばやくスケールアップして本番環境の負荷を処理できるようにします。ウォームスタンバイの規模が大きいほど、RTO とコントロールプレーンへの依存は低くなります。これを完全にスケールアップしたものは **ホットスタンバイと呼ばれます**.
+ **マルチリージョン (マルチサイト) アクティブアクティブ** (ゼロに近い RPO、ほぼゼロの RTO): ワークロードは複数の AWS リージョン にデプロイされ、そこからトラフィックにアクティブに対応します。この戦略では、複数のリージョン間でデータを同期する必要があります。2 つの異なるリージョンレプリカ内の同じレコードへの書き込みによって生じる矛盾を回避または処理する必要があり、これは複雑になることがあります。データレプリケーションは、データの同期に便利であり、特定のタイプの災害から保護しますが、ソリューションがポイントインタイムリカバリのためのオプションを含んでいない限り、データの破損や破壊からは保護しません。
**注記**
パイロットライトとウォームスタンバイの違いは、理解しにくいかもしれません。どちらも、プライマリリージョンアセットのコピーがある復旧リージョン内の環境を含みます。違いは、パイロットライトが最初に追加アクションを取らなければリクエストを処理できないのに対して、ウォームスタンバイはトラフィックを直ちに (削減された能力レベルで) 処理できることです。パイロットライトでは、サーバーをオンにして、おそらく追加の (非コア) インフラストラクチャをデプロイし、スケールアップする必要があるのに対して、ウォームスタンバイでは、スケールアップするだけです (すべてがすでにデプロイされ、実行しています)。RTO と RPO のニーズに基づいて、両者の中から選択してください。
**期待される成果:**
各ワークロードについて、定義され、実装された DR 戦略があり、ワークロードは DR 目標を達成できます。ワークロード間の DR 戦略では、再利用可能なパターンを利用します (以前に記載された戦略など)。
**一般的なアンチパターン:**
+ 同じような DR 目標を持つワークロードについて、一貫性のない復旧手順を実装する。
+ DR 戦略は、災害が発生したときにアドホックに実装すればよいとする。
+ DR のプランがない。
+ 復旧時にコントロールプレーンのオペレーションに依存する。
**このベストプラクティスを活用するメリット:**
+ 定義された復旧戦略を使用すると、一般的なツールとテスト手順を使用できます。
+ 定義された復旧戦略を使用することで、チーム間での知識の共有が効率的になり、それぞれのチームが所有するワークロードの DR の実装が容易になります。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
+ 計画され、実装され、テストされた DR 戦略がなければ、災害発生時に復旧目標を達成できない可能性があります。
## 実装のガイダンス
これらのステップのそれぞれについて、以下の詳細を参照してください。
1. このワークロードの復旧要件を満たす DR 戦略を決定します。
1. 選択した DR 戦略の実装パターンをレビューします。
1. ワークロードのリソースと、それらの設定がフェイルオーバー前 (正常なオペレーション時) に復旧リージョンでどうなるかを評価します。
1. 必要なとき (災害発生時) に復旧リージョンをフェイルオーバーに備える方法を決定し、実装します。
1. 必要なとき (災害発生時) にフェイルオーバーするトラフィックを再ルーティングする方法を決定し、実装します。
1. ワークロードをフェイルバックする方法のプランを設計します。
**実装ステップ**
1. **このワークロードの復旧要件を満たす DR 戦略を決定します。**
DR 戦略を選ぶということは、ダウンタイムとデータ損失の削減 (RTO と RPO) と、戦略を実装するコストと複雑さのトレードオフです。必要以上に厳格な戦略の実装は、不要なコストにつながるため避けてください。
例えば、次の図では、許容可能な最大 RTO と、サービス復元戦略に費やすことができるコストの限界を決定しています。特定のビジネス目標の場合、パイロットライトまたはウォームスタンバイの DR 戦略は、RTO とコスト基準の両方を満たすことができます。
![\[RTO とコストに基づく DR 戦略の選択を示すグラフ\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2022-03-31/framework/images/choosing-a-dr-strategy.png)
詳細については、 [ビジネス継続性計画 (BCP) を参照してください](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/business-continuity-plan-bcp.html).
1. **選択した DR 戦略の実装パターンをレビューします。**
このステップでは、選択した戦略の実装方法を理解します。戦略は、プライマリサイトと復旧サイトとしての AWS リージョン を使用して説明されています。ただし、単一リージョン内のアベイラビリティゾーンを DR 戦略として使用することもでき、その場合は、これら複数の戦略の要素を利用します。
このステップの後のステップでは、戦略を特定のワークロードに適用します。
**バックアップと復元**
*バックアップと復元* は、実装の複雑さが最も少ない戦略ですが、ワークロードの復元に必要な時間と労力が多く、より高い RTO と RPO につながります。常にデータのバックアップを取り、これらを別のサイト (別の AWS リージョン など) にコピーすることをお勧めします。
![\[バックアップと復元アーキテクチャを示す図\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2022-03-31/framework/images/backup-restore-architecture.png)
この戦略の詳細については、下記を参照してください。 [AWS でのディザスタリカバリ (DR) アーキテクチャ、パート II: 迅速な復旧によるバックアップと復元](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-ii-backup-and-restore-with-rapid-recovery/).
**パイロットライト**
ように、 *パイロットライト* アプローチでは、プライマリリージョンから復旧リージョンにデータをレプリケートします。ワークロードインフラストラクチャに使用されるコアリソースは復旧リージョンにデプロイされますが、これを機能するスタックにするには、やはり追加のリソースと依存関係が必要です。例えば、図 20 では、コンピューティングインスタンスはデプロイされていません。
![\[パイロットライトアーキテクチャを示す図\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2022-03-31/framework/images/pilot-light-architecture.png)
この戦略の詳細については、下記を参照してください。 [AWS でのディザスタリカバリ (DR) アーキテクチャ、パート III: パイロットライトとウォームスタンバイ](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/).
**ウォームスタンバイ**
それらの *インフラストラクチャ* アプローチでは、本番稼働環境の完全に機能する縮小コピーを別のリージョンに用意する必要があります。このアプローチは、パイロットライトの概念を拡張して、ワークロードが別のリージョンに常駐するため、復旧時間が短縮されます。復旧リージョンが完全なキャパシティでデプロイされた場合は、 *ホットスタンバイと呼ばれます*.
![\[図 21: ウォームスタンバイアーキテクチャを示す図\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2022-03-31/framework/images/warm-standby-architecture.png)
ウォームスタンバイまたはパイロットライトを使用するには、復旧リージョンのリソースをスケールアップする必要があります。必要なときにキャパシティが使用可能であるためには、EC2 インスタンスの [キャパシティ予約](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-reservations.html) の使用を検討してください。AWS Lambda を使用する場合、 [プロビジョニングされた同時実行数](https://docs.aws.amazon.com/lambda/latest/dg/provisioned-concurrency.html) により、機能の呼び出しにすぐに応答できる実行環境を確保できます。
この戦略の詳細については、下記を参照してください。 [AWS でのディザスタリカバリ (DR) アーキテクチャ、パート III: パイロットライトとウォームスタンバイ](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/).
**マルチサイトアクティブ/アクティブ**
マルチサイトアクティブ/アクティブ戦略の一部として、 *複数のリージョンで同時に* ワークロードを実行できます。マルチサイトアクティブ/アクティブは、デプロイされたすべてのリージョンからのトラフィックを処理します。顧客は、DR 以外の理由でこの戦略を選択することもあります。可用性を高めるためや、グローバルオーディエンスにワークロードをデプロイするときに (エンドポイントをエンドユーザーに近づけるためや、そのリージョン内のオーディエンスに対してローカライズされたスタックをデプロイするため) 使用できます。DR 戦略としては、ワークロードがデプロイされている AWS リージョン の 1 つでワークロードをサポートできない場合、そのリージョンは隔離され、残りのリージョンを使用して可用性を維持します。マルチサイトアクティブ/アクティブは、運用が最も複雑な DR 戦略であり、ビジネス要件上、必須の場合のみ選択してください。
![\[マルチサイトアクティブ/アクティブアーキテクチャを示す図\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2022-03-31/framework/images/multi-site-active-active-architecture.png)
この戦略の詳細については、下記を参照してください。 [AWS のディザスタリカバリ (DR) アーキテクチャ、パート IV: マルチサイトアクティブ/アクティブ](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iv-multi-site-active-active/).
**データを保護するためのその他のプラクティス**
どの戦略でも、データ災害に対する緩和も必要です。連続的なデータレプリケーションは、特定のタイプの災害から保護しますが、戦略に、保存データのバージョニングまたはポイントインタイムリカバリのためのオプションが含まれていない限り、データの破損や破壊からは保護しません。復旧サイトにレプリケートしたデータもバックアップして、レプリカに加えて、ポイントインタイムバックアップを作成する必要があります。
**単一の AWS リージョン 内の複数のアベイラビリティゾーン (AZ) の使用**
単一のリージョン内の複数の AZ を使用する場合、DR 実装は上記の戦略の複数の要素を使用します。まず、図 23 に示されている複数の AZ を使用して、高可用性 (HA) アーキテクチャを作成する必要があります。このアーキテクチャは、マルチサイトアクティブ/アクティブアプローチを [Amazon EC2 インスタンスとして利用し、](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html#concepts-availability-zones) および [Elastic Load Balancing](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html#availability-zones) はリソースを複数の AZ にデプロイして、リクエストをアクティブに処理します。このアーキテクチャは、ホットスタンバイのデモンストレーションにもなります。ホットスタンバイでは、プライマリ [Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html) インスタンスに障害が発生した場合 (または AZ そのものに障害が発生した場合)、スタンバイインスタンスがプライマリに昇格します。
![\[図 23: マルチ AZ アーキテクチャを示す図\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2022-03-31/framework/images/multi-az-architecture2.png)
この HA アーキテクチャに加えて、ワークロードの実行に必要なすべてのデータのバックアップを追加する必要があります。これは、単一のゾーンに制約されるデータの場合に特に重要です。例えば、 [Amazon EBS ボリューム](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volumes.html) または [Amazon Redshift クラスターなどです](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html).AZ に障害が発生した場合、このデータを別の AZ に復元する必要があります。可能な場合には、追加の保護層として、データバックアップも別の AWS リージョン にコピーしてください。
単一リージョン、マルチ AZ DR に対する、あまり一般的でない代替アプローチが下記のブログ投稿で説明されています。 [Amazon Route 53 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/).ここでは、戦略は、AZ 間の分離をできるだけ高く維持して、リージョンのように動作させることです。この代替戦略を使用すると、アクティブ/アクティブまたはアクティブ/パッシブアプローチを選ぶことができます。
注: 一部のワークロードには、規制によるデータレジデンシー要件があります。現在 AWS リージョン が 1 つだけの地域のワークロードにこれが該当する場合、マルチリージョンではビジネスニーズに適しません。マルチ AZ 戦略は、ほとんどの災害に対して良好な保護を提供します。
1. **ワークロードのリソースと、それらの設定がフェイルオーバー前 (正常なオペレーション時) に復旧リージョンでどうなるかを評価します。**
インフラストラクチャと AWS リソースについては、 [AWS CloudFormation](https://aws.amazon.com/cloudformation) などのコードとしてのインフラストラクチャや、Hashicorp Terraform などのサードパーティ製ツールを使用してください。複数のアカウントとリージョンに単一の操作でデプロイするには、 [AWS CloudFormation StackSets を使用できます](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html).マルチサイトアクティブ/アクティブとホットスタンバイ戦略の場合、復旧リージョンにデプロイされるインフラストラクチャはプライマリリージョンと同じリソースを持ちます。パイロットライトとウォームスタンバイ戦略の場合、デプロイされたインフラストラクチャを本番稼働で使用するには追加のアクションが必要です。CloudFormation の [チューニング](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/parameters-section-structure.html) および [条件付きロジック](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-conditions.html)を使用すると、デプロイされるスタックがアクティブかスタンバイかを単一のテンプレートで制御できます。このような CloudFormation テンプレートの例が、 [このブログ投稿に含まれています](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/).
すべての DR 戦略では、データソースが AWS リージョン の範囲内にバックアップされ、その後、それらのバックアップが復旧リージョンにコピーされる必要があります。[AWS Backup](https://aws.amazon.com/backup/) は、これらのリソースのバックアップの設定、スケジュール、モニタリングができる一元的なビューを提供します。パイロットライト、ウォームスタンバイ、およびマルチサイトアクティブ/アクティブについては、プライマリリージョンのデータを復旧リージョンのデータリソース、例えば、 [Amazon Relational Database Service (Amazon RDS)](https://aws.amazon.com/rds) DB インスタンスや [Amazon DynamoDB](https://aws.amazon.com/dynamodb) テーブルなどにレプリケートする必要もあります。したがって、これらのデータリソースはライブであり、復旧リージョンのリクエストに対応できます。
複数のリージョンにまたがる AWS サービスの動作の詳細については、火気に関するこのブログシリーズを参照してください。 [AWS サービスによるマルチリージョンアプリケーションの作成](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/).
1. **必要なとき (災害発生時) に復旧リージョンをフェイルオーバーに備える方法を決定し、実装します。**
マルチサイトアクティブ/アクティブの場合、フェイルオーバーとは、リージョンを隔離して、残りのアクティブリージョンに頼ることを意味します。一般に、これらのリージョンはトラフィックを受け入れる準備ができています。パイロットライトとウォームスタンバイ戦略の場合、復旧アクションとして、図 20 の EC2 インスタンスなど、不足しているリソースやその他の不足リソースをデプロイする必要があります。
上記の戦略のすべてで、データベースの読み取り専用インスタンスを昇格して、プライマリの読み書きインスタンスにしなければならない場合があります。
バックアップと復元の場合、バックアップからのデータの復元によって、EBS ボリューム、RDS DB インスタンス、DynamoDB テーブルなど、そのデータのリソースを作成します。インフラストラクチャを復元し、コードをデプロイする必要もあります。AWS Backup を使用して、データを復旧リージョンに復元できます。把握 [REL09-BP01 バックアップが必要なすべてのデータを特定し、バックアップする、またはソースからデータを再現する](rel_backing_up_data_identified_backups_data.md) をご覧ください。インフラストラクチャの再構築には、 [Amazon Virtual Private Cloud (Amazon VPC) は、](https://aws.amazon.com/vpc)、サブネット、必要なセキュリティグループに加えて、EC2 インスタンスなどのリソースの作成も含まれます。復元プロセスの大部分を自動化できます。方法については、 [このブログ投稿を参照してください](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-ii-backup-and-restore-with-rapid-recovery/).
1. **必要なとき (災害発生時) にフェイルオーバーするトラフィックを再ルーティングする方法を決定し、実装します。**
このフェイルオーバー操作は、自動または手動で開始できます。ヘルスチェックまたはアラームに基づくフェイルオーバーの自動開始を使用するときには、不要なフェイルオーバー (誤ったアラーム) によって、使用できないデータやデータ損失などのコストが発生するため、注意が必要です。そのため、多くの場合、手動によるフェイルオーバーの開始が使用されます。この場合でも、フェイルオーバーのステップを自動化できるため、手動開始はボタンを押すようなものです。
AWS サービスを使用するときに検討すべき、いくつかのトラフィック管理オプションがあります。1 つのオプションは、火気を使用することです [Amazon Route 53](https://aws.amazon.com/route53).Amazon Route 53 を使用すると、1 つ以上の AWS リージョン の複数の IP エンドポイントを Route 53 ドメイン名に関連付けることができます。手動開始フェイルオーバーを実装するには、 [Amazon Route 53 Application Recovery Controller](https://aws.amazon.com/route53/application-recovery-controller/)を使用できます。これは、高可用性データプレーン API を提供して、トラフィックを復旧リージョンに再ルーティングします。フェイルオーバーを実装するときには、火気で説明されているように、データプレーン操作を使用し、コントロールプレーンを避けてください [REL11-BP04 復旧中はコントロールプレーンではなくデータプレーンを利用する](rel_withstand_component_failures_avoid_control_plane.md).
このオプションやその他のオプションの詳細については、 [ディザスタリカバリホワイトペーパーのこのセクションを参照してください](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html#pilot-light).
1. **ワークロードをフェイルバックする方法のプランを設計します。**
フェイルバックとは、災害イベントの終息後、ワークロード操作をプライマリリージョンに戻すことを言います。インフラストラクチャとコードをプライマリリージョンにプロビジョニングするときには、一般に、最初に使用したのと同じステップに従い、コードとしてのインフラストラクチャとコードデプロイパイプラインに依存します。フェイルバックでの課題は、データストアを復元し、動作中の復旧リージョンとの一貫性を確認することです。
フェイルオーバー状態では、復旧リージョンのデータベースはライブであり、最新データを保持しています。目的は、復旧リージョンからプライマリリージョンへ再同期して、最新であることを確認することです。
いくつかの AWS のサービスは、これを自動的に行います。例えば、 [Amazon DynamoDB グローバルテーブル](https://aws.amazon.com/dynamodb/global-tables/)を使用している場合、プライマリリージョンのテーブルが使用できなくなった場合でも、オンラインに復帰すると、DynamoDB が保留中の書き込みの伝播を再開します。例えば、 [Amazon Aurora グローバルデータベース](https://aws.amazon.com/rds/aurora/global-database/) を使用し、 [マネージドプランドフェイルオーバー](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-disaster-recovery.html#aurora-global-database-disaster-recovery.managed-failover)を使用している場合、Aurora グローバルデータベースの既存のレプリケーショントポロジが維持されます。そのため、プライマリリージョンの以前の読み書きインスタンスがレプリカになり、復旧リージョンから更新を受け取ります。
これが自動でない場合、プライマリリージョンで復旧リージョンのデータベースのレプリカとしてデータベースを再確立する必要があります。多くの場合、これには、古いプライマリデータベースを削除して、新しいレプリカを作成する必要があります。例えば、Amazon Aurora グローバルデータベースでこれを行う方法の説明については、 *計画外の* フェイルオーバーを前提として、次のラボを参照してください。 [グローバルデータベースのフェイルバック](https://awsauroralabsmy.com/global/failback/).
フェイルオーバー後、復旧リージョンでの実行を続行できる場合は、これを新しいプライマリリージョンにすることを検討してください。その場合でも、上記のすべてのステップを実行して、前のプライマリリージョンを復旧リージョンにします。一部の組織は、計画的ローテーションを実行して、プライマリリージョンと復旧リージョンを定期的に (3 か月ごとなど) 交換しています。
フェイルオーバーとフェイルバックに必要なすべてのステップをプレイブックに記載して、チームのメンバー全員が使用できるようにし、定期的にレビューする必要があります。
**実装計画に必要な工数レベル**: 高
## リソース
**関連するベストプラクティス:**
+ [REL09-BP01 バックアップが必要なすべてのデータを特定し、バックアップする、またはソースからデータを再現する](rel_backing_up_data_identified_backups_data.md)
+ [REL11-BP04 復旧中はコントロールプレーンではなくデータプレーンを利用する](rel_withstand_component_failures_avoid_control_plane.md)
+ [REL13-BP01 ダウンタイムやデータ消失に関する復旧目標を定義する](rel_planning_for_recovery_objective_defined_recovery.md)
**関連するドキュメント:**
+ [AWS アーキテクチャブログ: ディザスタリカバリシリーズ](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [AWS でのワークロードのディザスタリカバリ: クラウドでの復旧 (AWS ホワイトペーパー)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [クラウド内の災害対策オプション](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html)
+ [サーバーレス、マルチリージョン、アクティブ/アクティブのバックエンドソリューションを 1 時間で構築する](https://read.acloud.guru/building-a-serverless-multi-region-active-active-backend-36f28bed4ecf)
+ [マルチリージョンのサーバーレスバックエンド – 再ロード](https://medium.com/@adhorn/multi-region-serverless-backend-reloaded-1b887bc615c0)
+ [RDS: リージョン間でのリードレプリカのレプリケーション方法](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html#USER_ReadRepl.XRgn)
+ [Route 53: DNS フェイルオーバーの設定](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover-configuring.html)
+ [S3: クロスリージョンレプリケーション](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr.html)
+ [「AWS Backup とは。」](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html)
+ [Route 53 Application Recovery Controller とは?](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
+ [AWS Elastic Disaster Recovery](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html)
+ [HashiCorp Terraform: 開始方法 - AWS](https://learn.hashicorp.com/collections/terraform/aws-get-started)
+ [APN パートナー: 災害対策を支援できるパートナー](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [AWS Marketplace: 災害対策に活用できる商品](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
**関連動画:**
+ [AWS でのワークロードのディザスタリカバリ](https://www.youtube.com/watch?v=cJZw5mrxryA)
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [Get Started with AWS Elastic Disaster Recovery \$1 Amazon Web Services](https://www.youtube.com/watch?v=GAMUCIJR5as)
**関連する例:**
+ [AWS Well-Architected ラボ - ディザスタリカバリ](https://wellarchitectedlabs.com/reliability/disaster-recovery/) - DR 戦略を説明するワークショップシリーズ
# REL13-BP03 ディザスタリカバリの実装をテストし、実装を検証する
復旧サイトへの定期的なテストフェイルオーバーにより、適切な操作と、RTO および RPO が満たされることを確認します。
回避すべきパターンは、まれにしか実行されない復旧経路を作ることです。たとえば、読み取り専用のクエリに使用されるセカンダリデータストアがあるとします。データストアの書き込み時にプライマリデータストアで障害が発生した場合、セカンダリデータストアにフェイルオーバーします。もしこのフェイルオーバーを頻繁にテストしない場合、セカンダリデータストアの機能に関する前提が正しくない可能性があります。セカンダリデータストアの容量は、最後にテストしたときには十分だったかもしれませんが、このシナリオでは負荷に耐えられなくなる可能性があります。エラー復旧がうまくいくのは頻繁にテストする経路のみであることは、これまでの経験からも明らかです。少数の復旧経路を用意することがベストであるのはそのためです。復旧パターンを確立して定期的にテストできます。復旧経路が複雑な場合や重大な場合に復旧経路が正常に機能するという確信を持つには、本番環境でその障害を定期的に実行する必要があります。前述の例では、その必要性に関係なく、スタンバイへのフェイルオーバーを定期的に行う必要があります。
**一般的なアンチパターン:**
+ 本番環境ではフェイルオーバーを実行しない。
**このベストプラクティスを活用するメリット:** 災害対策プランを定期的にテストすることで、必要なときに機能することや、チームが戦略の実行方法を把握していることを確認できます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
+ ワークロードを復旧用にエンジニアリングします。復旧経路を定期的にテストする Recovery Oriented Computing (ROC) は、復旧を強化するシステムの特性を特定します。以下がその特性です。隔離と冗長性、システム全体の変更のロールバック機能、正常性を監視し判断する機能、診断する機能、自動的な復旧、モジュラー設計、そして再起動する機能。復旧経路を訓練して、指定された時間内に指定された状態に復旧できるようにします。この復旧中にランブックを使用して問題を文書化し、次のテストの前に解決策を見つけます。
+ [バークレー/スタンフォード大学の復旧指向コンピューティングプロジェクト](http://roc.cs.berkeley.edu/)
+ CloudEndure Disaster Recovery を使用して DR 戦略を実装し、テストします。
+ [CloudEndure を使用した災害対策ソリューションのテスト](https://docs.cloudendure.com/Content/Configuring_and_Running_Disaster_Recovery/Testing_the_Distaster_Recovery_Solution/Testing_the_Disaster_Recovery_Solution.htm)
+ [CloudEndure Disaster Recovery](https://aws.amazon.com/cloudendure-disaster-recovery/)
+ [AWS への CloudEndure Disaster Recovery](https://aws.amazon.com/marketplace/pp/B07XQNF22L)
## リソース
**関連するドキュメント:**
+ [APN パートナー: 災害対策を支援できるパートナー](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [AWS アーキテクチャブログ: Disaster Recovery Series](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [AWS Marketplace: 災害対策に活用できる商品](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
+ [CloudEndure Disaster Recovery](https://aws.amazon.com/cloudendure-disaster-recovery/)
+ [AWS でのワークロードのディザスタリカバリ: クラウドでの復旧 (AWS ホワイトペーパー)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [CloudEndure を使用した災害対策ソリューションのテスト](https://docs.cloudendure.com/Content/Configuring_and_Running_Disaster_Recovery/Testing_the_Distaster_Recovery_Solution/Testing_the_Disaster_Recovery_Solution.htm)
+ [バークレー/スタンフォード大学の復旧指向コンピューティングプロジェクト](http://roc.cs.berkeley.edu/)
+ [AWS Fault Injection Simulator とは?](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html)
**関連動画:**
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [AWS re:Invent 2019: Backup-and-restore and disaster-recovery solutions with AWS (STG208)](https://youtu.be/7gNXfo5HZN8)
**関連する例:**
+ [AWS Well-Architected Labs - Testing for Resiliency](https://wellarchitectedlabs.com/reliability/300_labs/300_testing_for_resiliency_of_ec2_rds_and_s3/)
# REL13-BP04 DR サイトまたはリージョンでの設定ドリフトを管理する
インフラストラクチャ、データ、設定が DR サイトまたはリージョンで必要とされるとおりであることを確認します。たとえば、AMI と Service Quotas が最新であることを確認します。
AWS Config は AWS リソース設定を継続的にモニタリングおよび記録します。これにより [AWS Systems Manager Automation のドリフトを検出、トリガーでき、](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) 修正してアラームを発生させます。AWS CloudFormation は、さらにデプロイしたスタックのドリフトを検出できます。
**一般的なアンチパターン:**
+ プライマリロケーションで設定またはインフラストラクチャに変更を加えたときに、復旧ロケーションの更新を行わない。
+ プライマリロケーションと復旧ロケーションの潜在的な制限 (サービスの違いなど) を考慮しない。
**このベストプラクティスを確立するメリット:** DR 環境が既存の環境と一致していることを確認することで、完全な復旧が保証されます。
**このベストプラクティスが確立されていない場合のリスクレベル:** ミディアム
## 実装のガイダンス
+ デリバリーパイプラインがプライマリサイトとバックアップサイトの両方に配信しているようにします。アプリケーションを本番環境にデプロイするための配信パイプラインは、開発環境やテスト環境など、指定されたすべての災害対策戦略のロケーションに分散する必要があります。
+ AWS Config を有効にして、潜在的なドリフトロケーションを追跡します。AWS Config ルールを使用して、ディザスタリカバリ戦略を実施するシステムを構築し、ドリフトを検出したときにアラートを生成します。
+ [AWS Config ルール による非準拠 AWS リソースの修復](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html)
+ [AWS Systems Manager Automation をトリガーして](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ AWS CloudFormation を使用して、インフラストラクチャをデプロイします。AWS CloudFormation は、CloudFormation テンプレートが指定するものと実際にデプロイされているものとの間のドリフトを検出できます。
+ [AWS CloudFormation: CloudFormation スタック全体のドリフトを検出する](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/detect-drift-stack.html)
## リソース
**関連するドキュメント:**
+ [APN パートナー: 災害対策を支援できるパートナー](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [AWS アーキテクチャブログ: ディザスタリカバリシリーズ](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [AWS CloudFormation: CloudFormation スタック全体のドリフトを検出する](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/detect-drift-stack.html)
+ [AWS Marketplace: 災害対策に活用できる商品](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
+ [AWS Systems Manager Automation をトリガーして](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [AWS でのワークロードの災害対策: クラウド内での復旧 (AWS ホワイトペーパー)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [How do I implement an Infrastructure Configuration Management solution on AWS? (AWS でインフラストラクチャ設定管理ソリューションを実装するにはどうすればよいですか?)](https://aws.amazon.com/answers/configuration-management/aws-infrastructure-configuration-management/?ref=wellarchitected)
+ [AWS Config ルール による非準拠 AWS リソースの修復](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html)
**関連動画:**
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (ARC209-R2) (マルチリージョンアクティブ/アクティブアプリケーションのアーキテクチャパターン)](https://youtu.be/2e29I3dA8o4)
# REL13-BP05 復旧を自動化する
AWS またはサードパーティ製のツールを使用して、システムの復旧を自動化し、トラフィックを DR サイトまたはリージョンにルーティングします。
設定されたヘルスチェックに基づいて、Elastic Load Balancing や AWS Auto Scaling などの AWS サービスは、正常なアベイラビリティゾーンに負荷を分散できますが、Amazon Route 53、や AWS Global Accelerator などのサービスは、正常な AWS リージョン に負荷をルーティングできます。Route 53 Application Recovery Controller は、準備状況のチェックとルーティングコントロール機能を使用して、フェイルオーバーの管理と調整を支援します。これらの機能は、障害から回復するアプリケーションの能力を継続的にモニタリングするため、複数の AWS リージョン、アベイラビリティゾーン、およびオンプレミスにまたがってアプリケーションの回復を管理できます。
既存の物理または仮想データセンターまたはプライベートクラウド上のワークロードについては、 [AWS Elastic Disaster Recovery](https://aws.amazon.com/cloudendure-disaster-recovery/)(AWS Marketplace から入手可能) により、組織は自動ディザスタリカバリ戦略を AWS にセットアップできます。CloudEndure は、AWS のクロスリージョン/クロス AZ ディザスタリカバリもサポートしています。
**一般的なアンチパターン:**
+ 同一の自動フェイルオーバーとフェイルバックを実装すると、障害が発生したときにフラッピングが発生する可能性があります。
**このベストプラクティスを活用するメリット:** 自動復旧により、手動エラーの可能性が排除され、復旧時間が短縮されます。
**このベストプラクティスを活用しない場合のリスクレベル:** ミディアム
## 実装のガイダンス
+ 復旧経路を自動化します。復旧時間が短い場合に人が判断して対処する方法は、高い可用性シナリオには利用できません。システムはあらゆる状況下で自動的に復旧する必要があります。
+ CloudEndure Disaster Recover を自動化したフェイルオーバーとフェイルバックに使用する CloudEndure Disaster Recovery は、マシン (オペレーティングシステム、システム状態設定、データベース、アプリケーション、ファイルなど) をターゲット AWS アカウント および希望するリージョンの低コストのステージングエリアに継続的にレプリケートします。災害が発生した場合、CloudEndure Disaster Recovery に指示して、数千台のマシンを数分で完全にプロビジョニングされた状態で自動的に起動できます。
+ [災害対策フェイルオーバーとフェイルバックの実行](https://docs.cloudendure.com/Content/Configuring_and_Running_Disaster_Recovery/Performing_a_Disaster_Recovery_Failover/Performing_a_Disaster_Recovery_Failover.htm)
+ [CloudEndure Disaster Recovery](https://aws.amazon.com/cloudendure-disaster-recovery/)
## リソース
**関連するドキュメント:**
+ [APN パートナー: 災害対策を支援できるパートナー](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [AWS アーキテクチャブログ: ディザスタリカバリシリーズ](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [AWS Marketplace: 災害対策に活用できる商品](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
+ [AWS Systems Manager Automation をトリガーして](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [AWS への CloudEndure Disaster Recovery](https://aws.amazon.com/marketplace/pp/B07XQNF22L)
+ [AWS でのワークロードのディザスタリカバリ: クラウドでの復旧 (AWS ホワイトペーパー)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
**関連動画:**
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (ARC209-R2)](https://youtu.be/2e29I3dA8o4)