# 信頼性
**Topics**
+ [基盤](a-foundations.md)
+ [ワークロードアーキテクチャ](a-workload-architecture.md)
+ [変更管理](a-change-management.md)
+ [障害管理](a-failure-management.md)
# 基盤
**Topics**
+ [REL 1 サービスクォータと制約はどのように管理しますか?](w2aac19b9b5b5.md)
+ [REL 2 ネットワークトポロジをどのように計画しますか?](w2aac19b9b5b7.md)
# REL 1 サービスクォータと制約はどのように管理しますか?
クラウドベースのワークロードアーキテクチャには、サービスクォータ (サービスの制限とも呼ばれます) というものがあります。このようなクォータは、誤って必要以上のリソースをプロビジョニングするのを防ぎ、サービスを不正使用から保護することを目的として API 操作のリクエスト頻度を制限するために存在します。リソースにも制約があります。たとえば、光ファイバーケーブルのビットレートや、物理ディスクの記憶容量などです。
**Topics**
+ [REL01-BP01 サービスクォータと制約を認識する](rel_manage_service_limits_aware_quotas_and_constraints.md)
+ [REL01-BP02 アカウントおよびリージョンをまたいでサービスクォータを管理する](rel_manage_service_limits_limits_considered.md)
+ [REL01-BP03 アーキテクチャを通じて、固定サービスクォータと制約に対応する](rel_manage_service_limits_aware_fixed_limits.md)
+ [REL01-BP04 クォータをモニタリングおよび管理する](rel_manage_service_limits_monitor_manage_limits.md)
+ [REL01-BP05 クォータ管理を自動化する](rel_manage_service_limits_automated_monitor_limits.md)
+ [REL01-BP06 フェイルオーバーに対応するために、現在のクォータと最大使用量の間に十分なギャップがあることを確認する](rel_manage_service_limits_suff_buffer_limits.md)
# REL01-BP01 サービスクォータと制約を認識する
あなたは、ワークロードアーキテクチャに対するデフォルトのクォータとクォータ引き上げリクエストを認識しています。さらに、ディスクやネットワークなど、どのリソースの制約が潜在的に大きな影響を与えるかを知っておきましょう。
Service Quotas は、100 を超える AWS のサービスのクォータを一元的に管理するのに役立つ AWS のサービスです。クォータ値の検索に加えて、Service Quotas コンソールから、または AWS SDK 経由でクォータ増加をリクエスト、追跡することもできます。AWS Trusted Advisor には、あるサービスの一部の要素に関する使用状況とクォータを表示するサービスクォータチェックが用意されています。サービスごとのデフォルトのサービスクォータは、それぞれのサービスごとの AWS ドキュメントにも記載されています。例えば、次を参照してください。 [Amazon VPC クォータ](https://docs.aws.amazon.com/vpc/latest/userguide/amazon-vpc-limits.html)。スロットルされた API のレート制限は、API Gateway 内で使用量プランを変更することで設定できます。それぞれのサービス上の構成として設定される他の制限には、プロビジョンド IOPS、割り当てられた RDS ストレージ、EBS ボリューム割り当てなどがあります。Amazon Elastic Compute Cloud (Amazon EC2) には、インスタンス、Amazon Elastic Block Store (Amazon EBS)、および Elastic IP アドレスの制限を管理するのに役立つ独自のサービスの制限ダッシュボードがあります。サービスクォータがアプリケーションのパフォーマンスに影響を及ぼし、ニーズに合わせて調整できないような事例が発生した場合は、AWS サポート に連絡し、緩和策の有無についてお問い合わせください。
**一般的なアンチパターン:**
+ 使用される AWS のサービスに対するサービスクォータを考慮に入れることなく、ワークロードをデプロイする。
+ AWS のサービスの設計上の制約を調査、対応することなく、ワークロードを設計する。
+ 必要なクォータを設定することなく、また AWS サポート に事前に連絡することなく、既知の既存のワークロードを置き換えるような、使用量の多いワークロードを導入すること。
+ ワークロードへのトラフィックを促進するイベントを計画したが、必要なクォータを設定せず、事前に AWS サポート に連絡しない。
**このベストプラクティスを確立するメリット:** サービスクォータ、API スロットリング制限、および設計制約を認識することで、ワークロードの設計、実装、およびオペレーションでこれらを考慮することができます。
**このベストプラクティスが確立されていない場合のリスクレベル:** 高
## 実装のガイダンス
+ 公開されているドキュメントと Service Quotas で AWS のサービスクォータを確認します
+ [AWS Service Quotas (旧称は「Liimits (制限)」)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
+ デプロイコードを見て、ワークロードに必要なすべてのサービスを決定します。
+ AWS Config を使用して、AWS アカウント で使用するすべての AWS リソースを検索します。
+ [AWS Config によってサポートされている AWS リソースタイプとリソース関係](https://docs.aws.amazon.com/config/latest/developerguide/resource-config-reference.html)
+ AWS CloudFormation を使用して、使用する AWS リソースを決めることもできます。AWS マネジメントコンソール で、または list-stack-resources CLI コマンドで作成されたリソースを確認します。テンプレート自体にデプロイされるように設定されたリソースも確認できます。
+ [AWS マネジメントコンソール での AWS CloudFormation スタックデータとリソースの表示](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-view-stack-data-resources.html)
+ [AWS CLI for CloudFormation: list-stack-resources](https://docs.aws.amazon.com/cli/latest/reference/cloudformation/list-stack-resources.html)
+ 適用されるサービスクォータを決定します。Trusted Advisor および Service Quotas を通じて、プログラムでアクセスできる情報を使用します。
## リソース
**関連するドキュメント:**
+ [AWS Marketplace: 制限の追跡に役立つ CMDB 製品](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB)
+ [AWS Service Quotas (旧称は「Liimits (制限)」)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
+ [AWS Trusted Advisor ベストプラクティスチェックリスト (「サービスの制限」セクションを参照)](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/)
+ [AWS Answers の AWS Limit Monitor](https://aws.amazon.com/answers/account-management/limit-monitor/)
+ [Amazon EC2 サービスの制限](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html)
+ [Service Quotas とは何ですか?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
**関連動画:**
+ [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo)
# REL01-BP02 アカウントおよびリージョンをまたいでサービスクォータを管理する
複数の AWS アカウント または AWS リージョン をご利用の場合は、必ず本番ワークロードを実行するすべての環境で適切なクォータをリクエストしてください。
サービスクォータの追跡はアカウントごとに行います。特に明記されていない限り、各クォータは AWS リージョン 固有です。テストと開発が妨げられないように、本番環境に加えて、該当するすべての非本番環境でもクォータを管理します。
**一般的なアンチパターン:**
+ 1 つの分離ゾーンでのリソース使用率の増加を許可し、他のゾーンにはキャパシティーを維持するメカニズムがない。
+ 分離ゾーン内のすべてのクォータを手動で設定する。
+ デプロイが失われた場合に別のリージョンからのトラフィック増加に対応できるように、リージョン別に分離されたデプロイが適切なサイズとなっていない。
**このベストプラクティスを活用するメリット:** 分離ゾーンが使用できない場合に現在の負荷を処理できることを確認することで、フェイルオーバー中に発生するエラーの数を減らすことができ、顧客にサービス拒否を発生させないようにします。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
+ サービスの要件、レイテンシー、およびディザスタリカバリ (DR) 要件に基づいて、関連するアカウントとリージョンを選択します。
+ 関連するすべてのアカウント、リージョン、アベイラビリティーゾーン全体のサービスクォータを特定します。制限の対象範囲はアカウントとリージョンです。
+ [Service Quotas とは何ですか?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
## リソース
**関連するドキュメント:**
+ [AWS Marketplace: CMDB products that help track limits](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB)
+ [AWS Service Quotas (旧称は「サービスの制限」)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
+ [AWS Trusted Advisor ベストプラクティスチェックリスト (「サービスの制限」セクションを参照)](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/)
+ [AWS Answers の AWS Limit Monitor](https://aws.amazon.com/answers/account-management/limit-monitor/)
+ [Amazon EC2 サービスの制限](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html)
+ [Service Quotas とは何ですか?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
**関連動画:**
+ [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo)
# REL01-BP03 アーキテクチャを通じて、固定サービスクォータと制約に対応する
サービスクォータと物理リソースには変更できないものもあることに注意し、これらが信頼性に影響を及ぼさないように設計します。
例としては、ネットワーク帯域幅、AWS Lambda ペイロードサイズ、API Gateway のスロットルバーストレート、Amazon Redshift クラスターへの同時ユーザー接続などがあります。
**一般的なアンチパターン:**
+ バースト制限を利用しながらベンチマークをごく短期間実行するが、継続する期間にわたってそのキャパシティーでサービスが実行されることが予想される。
+ ユーザーまたは顧客ごとに 1 つのサービスリソースを使用する設計を選択するが、この設計の制約 (スケーリング時にこの設計の失敗を引き起こすもの) があることを認識していない。
**このベストプラクティスを活用するメリット:** AWS のサービスの固定クォータと、接続の制約、IP アドレスの制約、サードパーティーのサービスの制約など、ワークロードの他の部分の制約を追跡することで、クォータに対する傾向を検出し、クォータを超える前にそのクォータに対応できます。
**このベストプラクティスを活用しない場合のリスクレベル:** ミディアム
## 実装のガイダンス
+ 固定されたサービスクォータと制約のほか、これらに関するアーキテクトを把握します。
+ [AWS Service Quotas](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
## リソース
**関連するドキュメント:**
+ [AWS Marketplace: 制限の追跡に役立つ CMDB 製品](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB)
+ [AWS Service Quotas (旧称は「サービスの制限」)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
+ [AWS Trusted Advisor ベストプラクティスのチェック (「サービスの制限」セクションを参照)](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/)
+ [AWS Answers の AWS Limit Monitor](https://aws.amazon.com/answers/account-management/limit-monitor/)
+ [Amazon EC2 サービスの制限](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html)
+ [「What Is Service Quotas?」](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
**関連動画:**
+ [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo)
# REL01-BP04 クォータをモニタリングおよび管理する
予想される使用量を評価し、クォータを必要に応じて引き上げて、使用量を予定通り増やせるようにします。
サポートされているサービスの場合、CloudWatch アラームを設定して使用量をモニタリングし、クォータのしきい値に近づいていることのアラームを受けることで、クォータを管理できます。このアラームは、Service Quotas または Trusted Advisor からトリガーできます。CloudWatch Logs のメトリクスフィルターを使用して、ログのパターンを検索および抽出し、使用量がクォータのしきい値に近づいているかどうかを判断することもできます。
**一般的なアンチパターン:**
+ Service Quotas に近づいている場合のアラートを設定するが、アラートへの対応方法に関するプロセスがない。
+ Service Quotas でサポートされているサービスのアラームのみを設定し、他のサービスのモニタリングを行わない。
**このベストプラクティスを活用するメリット:** AWS のサービスクォータの自動追跡と、それらのクォータに対する使用率のモニタリングにより、クォータの限界に近づいていることを確認できます。また、このモニタリングデータを使用して、コストを節約するためにクォータを下げるタイミングを評価することもできます。
**このベストプラクティスを活用しない場合のリスクレベル:** ミディアム
## 実装のガイダンス
+ AWS で予想される使用量を評価し、リージョンごとのサービスクォータを適切に増やして、計画的な使用量の増加を可能にします。
+ 現在のリソース消費 (バケットやインスタンスなど) を把握します。現在のリソース消費を収集するには、Amazon EC2 DescribeInstances API などのサービス API オペレーションを使用します。
+ 現在のクォータを把握する AWS Service Quotas、AWS Trusted Advisor、AWS のドキュメントを使用します。
+ AWS Service Quotas を使用します。これは、100 を超える AWS のサービスのクォータを一元的に管理するのに役立つ AWS のサービスです。
+ Trusted Advisor のサービスの制限を使用して、現在のサービスの制限を決定します。
+ サポートされている場合は、サービス API オペレーションを使用して、現在のサービスクォータを決定します。
+ リクエストしたクォータの増加とそれらのステータスを記録する クォータの増加が承認された後、クォータの変更を反映するように記録を更新します。
## リソース
**関連するドキュメント:**
+ [AWS Marketplace: CMDB products that help track limits](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB)
+ [AWS Service Quotas (旧称は「サービスの制限」)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
+ [サービスの制限に関する AWS Trusted Advisor ベストプラクティスのチェック](https://docs.aws.amazon.com/awssupport/latest/user/service-limits.html)
+ [AWS Answers の AWS Limit Monitor](https://aws.amazon.com/answers/account-management/limit-monitor/)
+ [Amazon EC2 サービスの制限](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html)
+ [「What Is Service Quotas?」](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
+ [Amazon CloudWatch を使用して Service Quotas をモニタリングする](https://docs.aws.amazon.com/servicequotas/latest/userguide/configure-cloudwatch.html)
**関連動画:**
+ [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo)
# REL01-BP05 クォータ管理を自動化する
しきい値に近づいたときに警告するツールを実装します。AWS Service Quotas API を使用すると、クォータの引き上げリクエストを自動化できます。
お使いの Configuration Management Database (CMDB) またはチケット発行システムを Service Quotas と統合すると、クォータの引き上げリクエストと現在のクォータに関する情報のトラッキングを自動化できます。AWS SDK のほかに、Service Quotas も AWS Command Line Interface (AWS CLI) を使用した自動化を提供しています。
**一般的なアンチパターン:**
+ スプレッドシートでクォータと使用状況を追跡する。
+ 毎日、毎週、または毎月の使用状況に関するレポートを実行し、使用量とクォータを比較する。
**このベストプラクティスを活用するメリット:** AWS のサービスクォータの自動追跡と、そのクォータに対する使用量のモニタリングにより、クォータに近づいていることを確認できます。必要に応じてクォータの引き上げをリクエストできるように、オートメーションを設定できます。使用量の傾向が反対の方向にある場合は、(認証情報が漏えいした場合の) リスクの低下とコスト削減のメリットを実現するために、クォータの削減を検討することをお勧めします。
**このベストプラクティスを活用しない場合のリスクレベル:** ミディアム
## 実装のガイダンス
+ 自動モニタリングをセットアップする しきい値に近づいたときにアラートを発行するため、SDK を使用するツールを実装します。
+ Service Quotas を使用し、AWS Limit Monitor や AWS Marketplace からのサービスなど、自動クォータモニタリングソリューションでサービスを補強します。
+ [Service Quotas とは何ですか?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
+ [AWS でのクォータモニタリング - AWS ソリューション](https://aws.amazon.com/answers/account-management/limit-monitor/)
+ Amazon SNS および AWS Service Quotas API を使用して、クォータしきい値に基づいてトリガーされるレスポンスをセットアップします。
+ 自動化をテストします。
+ 制限のしきい値を設定します。
+ AWS Config、デプロイパイプライン、Amazon EventBridge、またはサードパーティーからの変更イベントと統合します。
+ 応答をテストするために、人為的に低いクォータしきい値を設定します。
+ 通知に対して適切なアクションを取り、必要に応じて AWS サポート に問い合わせるトリガーをセットアップします。
+ 変更イベントを手動でトリガーします。
+ ゲームデーを実行して、クォータ引き上げの変更プロセスをテストします。
## リソース
**関連するドキュメント:**
+ [APN パートナー: 設定管理を支援できるパートナー](https://aws.amazon.com/partners/find/results/?keyword=Configuration+Management)
+ [AWS Marketplace: 制限の追跡に役立つ CMDB 製品](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB)
+ [AWS Service Quotas (旧称は「サービスの制限」)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
+ [AWS Trusted Advisor ベストプラクティスのチェック (「サービスの制限」セクションを参照)](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/)
+ [AWS でのクォータモニタリング - AWS ソリューション](https://aws.amazon.com/answers/account-management/limit-monitor/)
+ [Amazon EC2 サービスの制限](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html)
+ [Service Quotas とは何ですか?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
**関連動画:**
+ [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo)
# REL01-BP06 フェイルオーバーに対応するために、現在のクォータと最大使用量の間に十分なギャップがあることを確認する
リソースに障害が発生したときには、リソースが正常に終了されるまで、クォータにカウントされることがあります。エラーが生じたリソースが停止されるまで、エラーが生じたすべてのリソースと代替リソースの合計リソース数がクォータ内に収まるようにします。この開きを計算するときは、アベイラビリティーゾーンの不具合を考慮する必要があります。
**一般的なアンチパターン:**
+ フェイルオーバーシナリオを考慮せずに、現在のニーズに基づいてサービスクォータを設定する。
**このベストプラクティスを活用するメリット:** イベントが可用性に影響する恐れがあるとき、クラウドでは、これらのイベントを緩和またはイベントから復旧するための戦略を実装できます。そのような戦略には、多くの場合、障害が発生したリソースに置き換わる追加リソースの作成が含まれます。クォータ戦略は、これらの追加リソースに対応する必要があります。
**このベストプラクティスを活用しない場合のリスクレベル:** ミディアム
## 実装のガイダンス
+ フェイルオーバーに対応するため、サービスクォータと最大使用量の間に十分なギャップがあることを確認します。
+ デプロイのパターン、可用性の要件、消費の増加を考慮して、サービスクォータを決定します。
+ 必要に応じてクォータの引き上げをリクエストします。クォータの引き上げリクエストの実行に必要な時間を計画します。
+ 信頼性の要件 (「9 の数」としても知られる) を決定します。
+ 障害シナリオ (コンポーネント、アベイラビリティーゾーン、リージョンの損失など) を確立します。
+ デプロイ手法 (例えば、Canary、ブルー/グリーン、レッド/ブラック、ローリングなど) を確立します。
+ 現在の制限に適切なバッファ (例えば、15%) を含めます。
+ 消費の増加を計画します (例えば、消費の傾向をモニタリングする)。
## リソース
**関連するドキュメント:**
+ [AWS Marketplace: CMDB products that help track limits](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB)
+ [AWS Service Quotas (旧称は「サービスの制限」)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
+ [AWS Trusted Advisor ベストプラクティスチェックリスト (「サービスの制限」セクションを参照)](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/)
+ [Amazon EC2 サービスの制限](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html)
+ [「What Is Service Quotas?」](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
**関連動画:**
+ [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo)
# REL 2 ネットワークトポロジをどのように計画しますか?
多くの場合、ワークロードは複数の環境に存在します。このような環境には、複数のクラウド環境 (パブリックにアクセス可能なクラウド環境とプライベートの両方) と既存のデータセンターインフラストラクチャなどがあります。計画する際は、システム内およびシステム間の接続、パブリック IP アドレスの管理、プライベート IP アドレスの管理、ドメイン名解決といったネットワークに関する諸点も考慮する必要があります。
**Topics**
+ [REL02-BP01 ワークロードのパブリックエンドポイントに高可用性ネットワーク接続を使用する](rel_planning_network_topology_ha_conn_users.md)
+ [REL02-BP02 クラウド環境とオンプレミス環境のプライベートネットワーク間の冗長接続をプロビジョニングする](rel_planning_network_topology_ha_conn_private_networks.md)
+ [REL02-BP03 拡張性と可用性を考慮した IP サブネットの割り当てを確実に行う](rel_planning_network_topology_ip_subnet_allocation.md)
+ [REL02-BP04 多対多メッシュよりもハブアンドスポークトポロジを優先する](rel_planning_network_topology_prefer_hub_and_spoke.md)
+ [REL02-BP05 接続されているすべてのプライベートアドレス空間において、重複しないプライベート IP アドレス範囲を指定する](rel_planning_network_topology_non_overlap_ip.md)
# REL02-BP01 ワークロードのパブリックエンドポイントに高可用性ネットワーク接続を使用する
これらのエンドポイントとそれらへのルーティングは、可用性が高い必要があります。これを実現するには、可用性の高い DNS、コンテンツ配信ネットワーク (CDN)、API Gateway、ロードバランシング、またはリバースプロキシを使用します。
Amazon Route 53、AWS Global Accelerator、Amazon CloudFront、Amazon API Gateway、Elastic Load Balancing (ELB) はすべて、高可用性パブリックエンドポイントを提供します。また、ロードバランシングとプロキシ処理を行うために、AWS Marketplace のソフトウェアアプライアンスを評価することもできます。
ワークロードで提供されるサービスの消費者は、エンドユーザーであろうと他のサービスのユーザーであろうと、これらのサービスエンドポイントでリクエストを行います。高可用性のエンドポイントを提供できるように、いくつかの AWS リソースが利用できます。
Elastic Load Balancing は、アベイラビリティーゾーン間のロードバランシングを提供し、レイヤー 4 (TCP) またはレイヤー 7 (http/https) のルーティングを実施し、AWS WAF と統合します。また、AWS Auto Scaling との統合により、自己回復型のインフラストラクチャを構築し、トラフィックの増加を吸収しながら、トラフィックが減少したときにリソースを解放することができます。
Amazon Route 53 は、スケーラブルで可用性の高いドメインネームシステム (DNS) サービスであり、Amazon EC2 インスタンス、Elastic Load Balancing ロードバランサー、Amazon S3 バケットなど、AWS で実行するインフラストラクチャとユーザーリクエストを接続します。これはユーザーを AWS の外部のインフラストラクチャにルーティングするためにも使用できます。
AWS Global Accelerator は、AWS グローバルネットワーク上で最適なエンドポイントにトラフィックを誘導するために使用できるネットワークレイヤーサービスです。
分散型サービス拒否 (DDoS) 攻撃は、正当なトラフィックをシャットアウトして、ユーザーの可用性の低下を招きかねません。AWS Shield は、ワークロードにおける AWS サービスエンドポイントに対して、追加コストなしでこれらの攻撃に対する自動保護を提供します。これらの機能は、APN Partners や AWS Marketplace の仮想アプライアンスを使って、ニーズに合わせて拡張することができます。
**一般的なアンチパターン:**
+ インスタンスまたはコンテナでパブリックインターネットアドレスを使用し、DNS 経由でそれらのアドレスへの接続を管理する。
+ サービスの検索のために、ドメイン名ではなく、インターネットプロトコルアドレスを使用する。
+ 大規模な地理的領域にコンテンツ (ウェブページ、静的アセット、メディアファイル) を提供し、コンテンツ配信ネットワークを使用しない。
**このベストプラクティスを確立するメリット:** ワークロードに可用性の高いサービスを実装することで、ユーザーがワークロードを利用できるようになることがわかります。
**このベストプラクティスが確立されていない場合のリスクレベル:** 高
## 実装のガイダンス
ワークロードのユーザーのために高可用性接続を確保する Amazon Route 53、AWS Global Accelerator、Amazon CloudFront、Amazon API Gateway、Elastic Load Balancing (ELB) はすべて、高可用性パブリックエンドポイントを提供します。また、ロードバランシングとプロキシ処理を行うために、AWS Marketplace のソフトウェアアプライアンスを評価することもできます。
+ ユーザーへの高可用性接続を確保します。
+ 高可用性 DNS を使用して、アプリケーションエンドポイントのドメイン名を管理していることを確認します。
+ ユーザーがインターネット経由でアプリケーションにアクセスする場合は、サービス API オペレーションを使用して、インターネットゲートウェイの正しい使用状況を確認します。また、アプリケーションエンドポイントをホストするサブネットのルートテーブルのエントリが正しいことを確認します。
+ [DescribeInternetGateways](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeInternetGateways.html)
+ [DescribeRouteTables](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeRouteTables.html)
+ アプリケーションの前に高可用性リバースプロキシまたはロードバランサーを使用していることを確認します。
+ ユーザーがオンプレミス環境を通じてアプリケーションにアクセスする場合は、AWS とオンプレミス環境の間の接続が高可用性であることを確認します。
+ Route 53 を使用してドメイン名を管理します。
+ [Amazon Route 53 とは?](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html)
+ 要件を満たすサードパーティーの DNS プロバイダーを使用します。
+ Elastic Load Balancing を使用します。
+ [Elastic Load Balancing とは?](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html)
+ 要件を満たす AWS Marketplace アプライアンスを使用します。
## リソース
**関連するドキュメント:**
+ [APN パートナー: ネットワークの計画を支援できるパートナー](https://aws.amazon.com/partners/find/results/?keyword=network)
+ [AWS Direct Connect の回復性に関する推奨事項](https://aws.amazon.com/directconnect/resiliency-recommendation/)
+ [ネットワークインフラストラクチャ向け AWS Marketplace](https://aws.amazon.com/marketplace/b/2649366011)
+ [Amazon Virtual Private Cloud の接続オプションホワイトペーパー](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html)
+ [Multiple data center HA network connectivity](https://aws.amazon.com/answers/networking/aws-multiple-data-center-ha-network-connectivity/)
+ [Direct Connect Resiliency Toolkit を使用して開始する](https://docs.aws.amazon.com/directconnect/latest/UserGuide/resilency_toolkit.html)
+ [VPC Endpoints and VPC Endpoint Services (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-services-overview.html)
+ [AWS Global Accelerator とは?](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html)
+ [「Amazon VPC とは?」](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)
+ [Transit Gateway とは?](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)
+ [「Amazon CloudFront とは」](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html)
+ [Amazon Route 53 とは?](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html)
+ [Elastic Load Balancing とは?](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html)
+ [Direct Connect ゲートウェイの操作](https://docs.aws.amazon.com/directconnect/latest/UserGuide/direct-connect-gateways.html)
**関連動画:**
+ [AWS re:Invent 2018: Advanced VPC Design and New Capabilities for Amazon VPC (NET303) (高度な VPC 設計と Amazon VPC の新機能)](https://youtu.be/fnxXNZdf6ew)
+ [AWS re:Invent 2019: AWS Transit Gateway reference architectures for many VPCs (NET406-R1) (多くの VPC に対応した AWS Transit Gateway のリファレンスアーキテクチャ)](https://youtu.be/9Nikqn_02Oc)
# REL02-BP02 クラウド環境とオンプレミス環境のプライベートネットワーク間の冗長接続をプロビジョニングする
個別にデプロイされたプライベートネットワーク間で複数の AWS Direct Connect 接続または VPN トンネルを使用します。高可用性のために複数の Direct Connect ロケーションを使用します。複数の AWS リージョン を使用している場合は、少なくとも 2 つのリージョンで冗長性を確保してください。VPN を終端する AWS Marketplace アプライアンスを評価したい場合があります。AWS Marketplace アプライアンスを使用する場合は、さまざまなアベイラビリティーゾーンで高可用性を実現するために冗長インスタンスをデプロイします。
AWS Direct Connect は、オンプレミス環境から AWS への専用ネットワーク接続を簡単に確立できるようにするクラウドサービスです。Direct Connect ゲートウェイを使用すると、オンプレミスのデータセンターを複数の AWS リージョン にまたがる複数の AWS VPC に接続できます。
この冗長性は、接続の回復力に影響を与える可能性のある障害に対処します。
+ トポロジにおける障害に対する弾力性を高めるにはどうすればよいでしょうか?
+ 間違った設定を行い、接続が停止したらどうなりますか?
+ トラフィックとサービス利用量が予想外に増加した場合に対応できますか?
+ 分散型サービス拒否 (DDoS) 攻撃の影響を緩和できますか?
VPC をVPN 経由でオンプレミスのデータセンターに接続するときは、ベンダーとそのアプライアンスを実行する際に必要となるインスタンスサイズを選択する際に、弾力性と必要とする帯域幅の要件を考慮する必要があります。使用するVPN アプライアンスがその実装において十分な弾力性がない場合、2 つ目のアプライアンスを通じて冗長接続を設定する必要があります。すべてのシナリオにおいて、許容可能な復旧時間を定義し、その要件を満たすかどうかをテストする必要があります。
Direct Connect 接続を使用して VPC をデータセンターに接続することにし、この接続を高可用性にする必要がある場合は、各データセンターから冗長化した Direct Connect 接続を使用します。冗長接続では、最初の接続とは異なる場所から 2 番目の Direct Connect 接続を使用する必要があります。複数のデータセンターがある場合は、接続が異なる場所で終端するようにしてください。このセットアップに役立てるため [Direct Connect Resiliency Toolkit](https://docs.aws.amazon.com/directconnect/latest/UserGuide/resiliency_toolkit.html) を使用します。
Site-to-Site VPN を使用してインターネット経由で VPN にフェイルオーバーする場合、VPN トンネルごとに最大 1.25 Gbps のスループットはサポートしますが、同じ VGW 上で終端する AWS マネージド VPN トンネルが複数ある場合、アウトバウンドトラフィック用の Equal Cost Multi Path (ECMP) はサポートしないということを理解しておくことが重要です。フェイルオーバー中に 1 Gbps 未満の速度を許容できないのであれば、Direct Connect 接続のバックアップとして AWS マネージド VPN を使用することはお勧めしません。
VPC エンドポイントを使用して、VPC を、パブリックインターネットを経由せずに、サポートされている AWS のサービスおよび AWS PrivateLink が提供する VPC エンドポイントサービスにプライベートに接続することもできます。エンドポイントは仮想デバイスです。これは、水平にスケーリングされ、冗長性と可用性に優れた VPC コンポーネントです。仮想デバイスにより、ネットワークトラフィックに可用性のリスクや帯域幅の制約を課すことなく、VPC 内のインスタンスとサービス間の通信が可能になります。
**一般的なアンチパターン:**
+ オンサイトネットワークと AWS の間に接続プロバイダを 1 つだけ持つ。
+ AWS Direct Connect 接続の接続機能を消費するが、接続は 1 つのみである。
+ VPN 接続用のパスは 1 つだけである。
**このベストプラクティスを活用するメリット:** クラウド環境と企業/オンプレミス環境の間に冗長接続を実装することで、2 つの環境間で依存するサービスが確実に通信できるようになります。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
+ AWS とオンプレミス環境との間に高可用性接続を確保します。個別にデプロイされたプライベートネットワーク間で複数の AWS Direct Connect 接続または VPN トンネルを使用します。高可用性のために複数の Direct Connect ロケーションを使用します。複数の AWS リージョン を使用している場合は、少なくとも 2 つのリージョンで冗長性を確保してください。VPN を終端する AWS Marketplace アプライアンスを評価したい場合があります。AWS Marketplace アプライアンスを使用する場合は、さまざまなアベイラビリティーゾーンで高可用性を実現するために冗長インスタンスをデプロイします。
+ オンプレミス環境への冗長接続を確保する可用性ニーズを達成するには、複数の AWS リージョン への冗長接続が必要な場合があります。
+ [AWS Direct Connect の回復性に関する推奨事項](https://aws.amazon.com/directconnect/resiliency-recommendation/)
+ [冗長な Site-to-Site VPN 接続を使用してフェイルオーバーを提供する](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPNConnections.html)
+ サービス API オペレーションを使用して Direct Connect 回線の適切な使用方法を明確にします。
+ [DescribeConnections](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeConnections.html)
+ [DescribeConnectionsOnInterconnect](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeConnectionsOnInterconnect.html)
+ [DescribeDirectConnectGatewayAssociations](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGatewayAssociations.html)
+ [DescribeDirectConnectGatewayAttachments](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGatewayAttachments.htmll)
+ [DescribeDirectConnectGateways](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGateways.html)
+ [DescribeHostedConnections](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeHostedConnections.html)
+ [DescribeInterconnects](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeInterconnects.html)
+ Direct Connect 接続が 1 つだけあるか、1 つもない場合は、仮想プライベートゲートウェイへの冗長 VPN トンネルを設定します。
+ [AWS Site-to-Site VPN とは?](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_VPN.html)
+ 現在の接続をキャプチャします (例えば、Direct Connect、仮想プライベートゲートウェイ、AWS Marketplace アプライアンス)。
+ サービス API オペレーションを使用して、Direct Connect 接続の設定をクエリします。
+ [DescribeConnections](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeConnections.html)
+ [DescribeConnectionsOnInterconnect](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeConnectionsOnInterconnect.html)
+ [DescribeDirectConnectGatewayAssociations](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGatewayAssociations.html)
+ [DescribeDirectConnectGatewayAttachments](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGatewayAttachments.htmll)
+ [DescribeDirectConnectGateways](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGateways.html)
+ [DescribeHostedConnections](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeHostedConnections.html)
+ [DescribeInterconnects](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeInterconnects.html)
+ サービス API オペレーションを使用して、ルートテーブルが使用している仮想プライベートゲートウェイを収集します。
+ [DescribeVpnGateways](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeVpnGateways.html)
+ [DescribeRouteTables](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeRouteTables.html)
+ サービス API オペレーションを使用してルートテーブルが使用している AWS Marketplace アプリケーションを収集します。
+ [DescribeRouteTables](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeRouteTables.html)
## リソース
**関連するドキュメント:**
+ [APN パートナー: ネットワークの計画を支援できるパートナー](https://aws.amazon.com/partners/find/results/?keyword=network)
+ [AWS Direct Connect の回復性に関する推奨事項](https://aws.amazon.com/directconnect/resiliency-recommendation/)
+ [ネットワークインフラストラクチャ向け AWS Marketplace](https://aws.amazon.com/marketplace/b/2649366011)
+ [Amazon Virtual Private Cloud 接続オプションホワイトペーパー](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html)
+ [Multiple data center HA network connectivity](https://aws.amazon.com/answers/networking/aws-multiple-data-center-ha-network-connectivity/)
+ [冗長な Site-to-Site VPN 接続を使用してフェイルオーバーを提供する](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPNConnections.html)
+ [Direct Connect Resiliency Toolkit を使用して開始する](https://docs.aws.amazon.com/directconnect/latest/UserGuide/resilency_toolkit.html)
+ [VPC Endpoints and VPC Endpoint Services (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-services-overview.html)
+ [「Amazon VPC とは?」](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)
+ [Transit Gateway とは?](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)
+ [AWS Site-to-Site VPN とは?](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_VPN.html)
+ [Direct Connect ゲートウェイの操作](https://docs.aws.amazon.com/directconnect/latest/UserGuide/direct-connect-gateways.html)
**関連動画:**
+ [AWS re:Invent 2018: Advanced VPC Design and New Capabilities for Amazon VPC (NET303)](https://youtu.be/fnxXNZdf6ew)
+ [AWS re:Invent 2019: AWS Transit Gateway reference architectures for many VPCs (NET406-R1)](https://youtu.be/9Nikqn_02Oc)
# REL02-BP03 拡張性と可用性を考慮した IP サブネットの割り当てを確実に行う
Amazon VPC IP アドレスの範囲は、将来の拡張や アベイラビリティゾーンをまたがるサブネットへの IP アドレスの割り当てを考慮し て、ワークロードの要件に対応するのに十分な大きさでなければなりません。これには、ロードバランサー、EC2 インスタンス、コンテナーベースのアプリケーションが含まれます。
ネットワークトポロジの計画は、IP アドレス空間の定義から始めます。プライベート IP アドレス範囲 (RFC 1918 ガイドラインに準拠) は、VPC ごとに割り当てる必要があります。このプロセスの一環として、次の要件を満たすようにします。
+ リージョンごとに複数の VPC 用の IP アドレス空間を割り当てる。
+ VPC 内で、複数のアベイラビリティーゾーンにまたがる複数のサブネット用の空間を割り当てます。
+ 将来の拡張のために、常に未使用の CIDR ブロック空間を VPC 内に残しておきます。
+ 機械学習用のスポットフリート、Amazon EMR クラスター、Amazon Redshift クラスターなど、使用する可能性のある EC2 インスタンスの一時的なフリートのニーズを満たす IP アドレス空間があることを確認します。
+ 各サブネット CIDR ブロックの最初の 4 つの IP アドレスと最後の IP アドレスはリザーブドのため、お客様はご使用いただけません。
+ 大きな VPC CIDR ブロックのデプロイを計画する必要があります。VPC に割り当てられた最初の VPC CIDR ブロックは変更または削除することはできませんが、重複していない CIDR ブロックを VPC に追加することはできます。サブネット IPv4 CIDR は変更できませんが、IPv6 CIDR は変更できます。最大規模の VPC (/16) をデプロイする場合、65,000 を超える IP アドレスが割り当てられることになります。ベース 10.x.x.x IP アドレス空間だけで、そのような VPC を 255 個プロビジョニングできます。したがって、VPC の管理を容易にするためには、小さすぎて失敗するよりも、大きすぎて失敗するほうが良いでしょう。
**一般的なアンチパターン:**
+ 小さな VPC を作成する。
+ 小さなサブネットを作成するため、増大に伴ってサブネットを設定に追加する必要がある。
+ Elastic Load Balancing が使用できる IP アドレスの数を不正確に見積もる。
+ 多数の高トラフィックロードバランサーを同じサブネットにデプロイする。
**このベストプラクティスを確立するメリット:** これにより、ワークロードの増大に対応し、スケールアップ時に可用性を引き続き提供できます。
**このベストプラクティスが確立されていない場合のリスクレベル:** ミディアム
## 実装のガイダンス
+ 拡張、コンプライアンス、他のネットワークとの統合に対応できるようにネットワークを計画します。適切に計画しないと、拡張の見積もりが甘くなったり、規制コンプライアンスが変わったり、取得やプライベートネットワーク接続の設定が難しくなったりする場合があります。
+ サービス要件、レイテンシー、規制、およびディザスタリカバリ (DR) 要件に基づいて、関連する AWS アカウント とリージョンを選択します。
+ リージョン別 VPC デプロイのニーズを明確にします。
+ VPC のサイズを明確にします。
+ マルチ VPC 接続をデプロイするかどうかを判断します。
+ [Transit Gateway とは?](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)
+ [単一リージョンの複数 VPC 接続](https://aws.amazon.com/answers/networking/aws-single-region-multi-vpc-connectivity/)
+ 規制要件のためネットワークの分離が必要かどうかを判断します。
+ VPC を可能な限り大きくします。VPC に割り当てられた最初の VPC CIDR ブロックは変更または削除することはできませんが、重複していない CIDR ブロックを VPC に追加することはできます。ただし、この場合、アドレス範囲が断片化される可能性があります。
+ VPC を可能な限り大きくします。VPC に割り当てられた最初の VPC CIDR ブロックは変更または削除することはできませんが、重複していない CIDR ブロックを VPC に追加することはできます。ただし、この場合、アドレス範囲が断片化される可能性があります。
## リソース
**関連するドキュメント:**
+ [APN パートナー: ネットワークの計画を支援できるパートナー](https://aws.amazon.com/partners/find/results/?keyword=network)
+ [ネットワークインフラストラクチャ向け AWS Marketplace](https://aws.amazon.com/marketplace/b/2649366011)
+ [Amazon Virtual Private Cloud の接続オプションホワイトペーパー](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html)
+ [Multiple data center HA network connectivity](https://aws.amazon.com/answers/networking/aws-multiple-data-center-ha-network-connectivity/)
+ [単一リージョンの複数 VPC 接続](https://aws.amazon.com/answers/networking/aws-single-region-multi-vpc-connectivity/)
+ [「Amazon VPC とは?」](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)
**関連動画:**
+ [AWS re:Invent 2018: Advanced VPC Design and New Capabilities for Amazon VPC (NET303) (高度な VPC 設計と Amazon VPC の新機能)](https://youtu.be/fnxXNZdf6ew)
+ [AWS re:Invent 2019: AWS Transit Gateway reference architectures for many VPCs (NET406-R1) (多くの VPC に対応した AWS Transit Gateway のリファレンスアーキテクチャ)](https://youtu.be/9Nikqn_02Oc)
# REL02-BP04 多対多メッシュよりもハブアンドスポークトポロジを優先する
3 つ以上のネットワークアドレス空間 (VPC およびオンプレミスネットワークなど) が VPC ピア接続、AWS Direct Connect、または VPN 経由で接続されている場合は、AWS Transit Gateway が提供するようなハブアンドスポークモデルを使用します。
そのようなネットワークが 2 つしかない場合は、それらを互いに接続するだけで済みますが、ネットワークの数が増えるにつれて、そのようなメッシュ接続の複雑さは維持できないものになります。AWS Transit Gateway は、維持しやすいハブアンドスポークモデルを提供し、複数のネットワーク間でトラフィックをルーティングできるようにします。
![\[AWS Transit Gateway を使用していない場合の図\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2022-03-31/framework/images/without-transit-gateway.png)
![\[AWS Transit Gateway を使用した場合の図\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2022-03-31/framework/images/with-transit-gateway.png)
**一般的なアンチパターン:**
+ VPC ピア接続を使用して 3 つ以上の VPC を接続する。
+ 各 VPC に対して複数の BGP セッションを確立し、複数の AWS リージョン における仮想プライベートクラウド (VPC) にまたがる接続を確立する。
**このベストプラクティスを確立するメリット:** ネットワークの数が増えるにつれて、このようなメッシュ接続の複雑さは受容できないものになります。AWS Transit Gateway は、維持しやすいハブアンドスポークモデルを提供し、複数のネットワーク間でトラフィックをルーティングできるようにします。
**このベストプラクティスが確立されていない場合のリスクレベル:** ミディアム
## 実装のガイダンス
+ 多対多メッシュよりもハブアンドスポークトポロジを優先します。3 つ以上のネットワークアドレス空間 (VPC およびオンプレミスネットワークなど) が VPC ピア接続、AWS Direct Connect、または VPN 経由で接続されている場合は、AWS Transit Gateway が提供するようなハブアンドスポークモデルを使用します。
+ そのような 2 つのネットワークのみについては、それらを互いに接続するだけで済みますが、ネットワークの数が増えるにつれて、そのようなメッシュ接続の複雑さは受容できないものになります。AWS Transit Gateway は、維持しやすいハブアンドスポークモデルを提供し、複数のネットワーク間でトラフィックをルーティングできるようにします。
+ [Transit Gateway とは?](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)
## リソース
**関連するドキュメント:**
+ [APN パートナー: ネットワークの計画を支援できるパートナー](https://aws.amazon.com/partners/find/results/?keyword=network)
+ [ネットワークインフラストラクチャ向け AWS Marketplace](https://aws.amazon.com/marketplace/b/2649366011)
+ [Multiple data center HA network connectivity](https://aws.amazon.com/answers/networking/aws-multiple-data-center-ha-network-connectivity/)
+ [VPC Endpoints and VPC Endpoint Services (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-services-overview.html)
+ [「Amazon VPC とは?」](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)
+ [Transit Gateway とは?](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)
**関連動画:**
+ [AWS re:Invent 2018: Advanced VPC Design and New Capabilities for Amazon VPC (NET303) (高度な VPC 設計と Amazon VPC の新機能)](https://youtu.be/fnxXNZdf6ew)
+ [AWS re:Invent 2019: AWS Transit Gateway reference architectures for many VPCs (NET406-R1) (多くの VPC に対応した AWS Transit Gateway のリファレンスアーキテクチャ)](https://youtu.be/9Nikqn_02Oc)
# REL02-BP05 接続されているすべてのプライベートアドレス空間において、重複しないプライベート IP アドレス範囲を指定する
各 VPC の IP アドレス範囲が、ピア接続時または VPN 経由での接続時に重複しないようにする必要があります。同様に、VPC とオンプレミス環境の間、または使用する他のクラウドプロバイダーとの IP アドレスの競合を回避する必要があります。また、必要に応じてプライベート IP アドレス範囲を割り当てる方法を用意する必要もあります。
これには、IP アドレス管理 (IPAM) システムが役立ちます。複数の IPAM は AWS Marketplace から入手できます。
**一般的なアンチパターン:**
+ オンプレミスまたは社内ネットワークにあるのと同じ IP 範囲を VPC で使用する。
+ ワークロードのデプロイに使用されている VPC の IP 範囲を追跡しない。
**このベストプラクティスを確立するメリット:** ネットワークを積極的に計画することで、相互接続されたネットワークで同じ IP アドレスが複数出現しないようにできます。これにより、異なるアプリケーションを使用しているワークロードの一部でルーティングの問題が発生するのを防ぐことができます。
**このベストプラクティスが確立されていない場合のリスクレベル:** ミディアム
## 実装のガイダンス
+ CIDR の使用をモニタリングし、管理します。AWS での予想される使用量を評価して、CIDR の範囲を既存の VPC に追加し、計画的な使用量の増加を可能にする VPC を作成します。
+ 現在の CIDR 消費量 (VPC、サブネットなど) を把握します。
+ サービス API オペレーションを使用して、現在の CIDR 消費量を収集します。
+ 現在のサブネットの使用量を把握します。
+ サービス API オペレーションを使用して、各リージョンの VPC ごとにサブネットを収集します。
+ [DescribeSubnets](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeSubnets.html)
+ 現在の使用量を記録します。
+ 重複している IP 範囲を作成したかどうか確認します。
+ 予備容量を計算します。
+ 重複している IP 範囲を特定します。重複する範囲に接続する必要がある場合は、新しいアドレス範囲に移行するか、AWS Marketplace の Network and Port Translation (NAT) アプライアンスを使用できます。
## リソース
**関連するドキュメント:**
+ [APN パートナー: ネットワークの計画を支援できるパートナー](https://aws.amazon.com/partners/find/results/?keyword=network)
+ [ネットワークインフラストラクチャ向け AWS Marketplace](https://aws.amazon.com/marketplace/b/2649366011)
+ [Amazon Virtual Private Cloud の接続オプションホワイトペーパー](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html)
+ [Multiple data center HA network connectivity](https://aws.amazon.com/answers/networking/aws-multiple-data-center-ha-network-connectivity/)
+ [「Amazon VPC とは?」](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)
+ [IPAM とは](https://docs.aws.amazon.com/vpc/latest/ipam/what-it-is-ipam.html)
**関連動画:**
+ [AWS re:Invent 2018: Advanced VPC Design and New Capabilities for Amazon VPC (NET303) (高度な VPC 設計と Amazon VPC の新機能)](https://youtu.be/fnxXNZdf6ew)
+ [AWS re:Invent 2019: AWS Transit Gateway reference architectures for many VPCs (NET406-R1) (多くの VPC に対応した AWS Transit Gateway のリファレンスアーキテクチャ)](https://youtu.be/9Nikqn_02Oc)
# ワークロードアーキテクチャ
**Topics**
+ [REL 3 ワークロードサービスアーキテクチャをどのように設計すればよいですか?](w2aac19b9b7b5.md)
+ [REL 4 障害を防ぐために、分散システムでの操作をどのように設計すればよいですか?](w2aac19b9b7b7.md)
+ [REL 5 障害を緩和または耐えるために、分散システムの操作をどのように設計しますか?](w2aac19b9b7b9.md)
# REL 3 ワークロードサービスアーキテクチャをどのように設計すればよいですか?
サービス指向アーキテクチャ (SOA) またはマイクロサービスアーキテクチャを使用して、拡張性と信頼性の高いワークロードを構築します。サービス指向アーキテクチャ (SOA) は、サービスインターフェイスを介してソフトウェアコンポーネントを再利用できるようにする方法です。マイクロサービスアーキテクチャは、その一歩先を行き、コンポーネントをさらに小さくシンプルにしています。
**Topics**
+ [REL03-BP01 ワークロードをセグメント化する方法を選択する](rel_service_architecture_monolith_soa_microservice.md)
+ [REL03-BP02 特定のビジネスドメインと機能に重点を置いたサービスを構築する](rel_service_architecture_business_domains.md)
+ [REL03-BP03 API ごとにサービス契約を提供する](rel_service_architecture_api_contracts.md)
# REL03-BP01 ワークロードをセグメント化する方法を選択する
アプリケーションの回復力要件を決定する際に、ワークロードのセグメント化は重要です。モノリシックアーキテクチャはできるだけ避ける必要があります。代わりに、どのアプリケーションコンポーネントをマイクロサービスに分けられるかを注意深く考慮します。アプリケーションの要件によっては、最終的にサービス指向アーキテクチャ (SOA) とマイクロサービスの組み合わせになることもあります。ステートレス化が可能なワークロードは、マイクロサービスとしてデプロイすることができます。
**期待される成果:** ワークロードは、サポート可能で、スケーラブルであり、可能な限り疎結合であるべきです。
ワークロードのセグメント化について選択を行う場合は、複雑さに対してどれだけメリットがあるかを考えてください。新製品のローンチ時に適しているものは、初期からスケーリングのことを考えて構築したワークロードとは異なります。既存のモノリスをリファクタリングする場合、アプリケーションがステートレスへの分解をどの程度サポートできるかを検討する必要があります。サービスを小さく分割することで、小規模で明確なチームが開発、管理することができます。しかし、サービスの規模が小さくなると、レイテンシーの増加、デバッグの複雑化、運用負荷の増大など、複雑な問題が発生する可能性があります。
**一般的なアンチパターン:**
+ 「 [マイクロサービス *Death Star*](https://mrtortoise.github.io/architecture/lean/design/patterns/ddd/2018/03/18/deathstar-architecture.html) 」とは、アトミックコンポーネントが強く依存しあっているために、1 つの失敗がより大きな失敗となり、コンポーネントがモノリスのように柔軟性が低く、壊れやすくなっている状態のことです。
**このプラクティスを活用するメリット:**
+ より特化したセグメントは、高い俊敏性、組織の柔軟性、およびスケーラビリティにつながる。
+ サービス中断の影響が小さくなる。
+ アプリケーションコンポーネントには異なる可用性要件があり、より特化したセグメント化によってサポートされることがある。
+ ワークロードをサポートするチームの責任が明確に定義される。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
ワークロードをセグメント化する方法に基づいてアーキテクチャタイプを選択します。SOA またはマイクロサービスアーキテクチャ (場合によってはモノリシックアーキテクチャ) を選択します。モノリスアーキテクチャから開始する場合でも、それがモジュラー型で、ユーザーの導入に合わせて製品がスケールされるにつれて最終的に SOA またはマイクロサービスに進化できることを確認する必要があります。SOA とマイクロサービスは、それぞれより小さなセグメントを提供し、最新のスケーラブルで信頼性の高いアーキテクチャとして好まれていますが、特にマイクロサービスアーキテクチャを展開する際には、トレードオフを考慮しなければなりません。
主なトレードオフとしては、分散コンピューティングアーキテクチャを採用することになり、ユーザーのレイテンシー要件を達成するのが難しくなることと、ユーザーインタラクションのデバッグとトレースにさらなる複雑さが生じることが挙げられます。AWS X-Ray を使ってこの問題の解決に役立てることができます。また、管理するアプリケーションの数が増え、複数の独立したコンポーネントを配置する必要があるため、運用が複雑になることも考慮しなければなりません。
![\[モノリシック、サービス指向、マイクロサービスアーキテクチャの比較を表す図\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2022-03-31/framework/images/monolith-soa-microservices-comparison.png)
## 実装手順
+ アプリケーションのリファクタリングやビルドに適したアーキテクチャを決定します。SOA とマイクロサービスは、それぞれより小さなセグメンテーションを提供し、最新のスケーラブルで信頼性の高いアーキテクチャとして好まれます。SOA は、マイクロサービスの複雑さを回避しながら、より小さなセグメント化を達成するための優れた折衷案となり得ます。詳細については、 [マイクロサービスのトレードオフ](https://martinfowler.com/articles/microservice-trade-offs.html).
+ ワークロードが適していて、組織がサポートできる場合は、最高の俊敏性と信頼性を実現するために、マイクロサービスアーキテクチャを使用すべきです。詳細については、 [AWS でのマイクロサービスの実装](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ モノリスを [*Strangler Fig* パターン](https://martinfowler.com/bliki/StranglerFigApplication.html) に従って、より小さいコンポーネントにリファクタリングします。これには、特定のアプリケーションコンポーネントを新しいアプリケーションとサービスに徐々に置き換えることが含まれます。[AWS Migration Hub Refactor Spaces](https://docs.aws.amazon.com/migrationhub-refactor-spaces/latest/userguide/what-is-mhub-refactor-spaces.html) は、増分リファクタリングの開始点として機能します。詳細については、「 [オンプレミスのレガシーワークロードをシームレスに移行する](https://aws.amazon.com/blogs/architecture/seamlessly-migrate-on-premises-legacy-workloads-using-a-strangler-pattern/)」を参照してください。
+ マイクロサービスを実装する場合、これらの分散したサービスが互いに通信できるようにするためのサービス検出メカニズムが必要になる場合があります。[AWS App Mesh](https://docs.aws.amazon.com/app-mesh/latest/userguide/what-is-app-mesh.html) をサービス指向アーキテクチャとともに使用することで、高い信頼性をもってサービスを検出し、サービスにアクセスできます。 [AWS Cloud Map](https://aws.amazon.com/cloud-map/) は、動的 DNS ベースのサービス検出にも使用できます。
+ モノリスから SOA へ移行する場合、[Amazon MQ](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/welcome.html) は、レガシーアプリケーションをクラウドで再設計する際に、サービスバスとしてギャップを埋めるのに役立ちます。
+ 単一の共有されたデータベースがある既存のモノリスには、データを再編成して小さなセグメントにする方法を選択します。これは、ビジネスユニット、アクセスパターン、またはデータ構造によって行うことができます。リファクタリングプロセスのこの時点では、リレーショナルまたは非リレーショナル (NoSQL) タイプのデータベースを選択して進めていく必要があります。詳細については、「 [SQL から NoSQL へ](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/SQLtoNoSQL.html)」を参照してください。
**実装計画に必要な工数レベル:** 高
## リソース
**関連するベストプラクティス:**
+ [REL03-BP02 特定のビジネスドメインと機能に重点を置いたサービスを構築する](rel_service_architecture_business_domains.md)
**関連するドキュメント:**
+ [Amazon API Gateway: OpenAPI を使用した REST API の設定](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [サービス指向アーキテクチャとは](https://aws.amazon.com/what-is/service-oriented-architecture/)
+ [境界付けられたコンテキスト (ドメイン駆動設計の中心的なパターン)](https://martinfowler.com/bliki/BoundedContext.html)
+ [AWS でのマイクロサービスの実装](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [マイクロサービスのトレードオフ](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [Microservices - a definition of this new architectural term](https://www.martinfowler.com/articles/microservices.html)
+ [AWS でのマイクロサービス](https://aws.amazon.com/microservices/)
+ [AWS App Mesh とは](https://docs.aws.amazon.com/app-mesh/latest/userguide/what-is-app-mesh.html)
**関連する例:**
+ [Iterative App Modernization Workshop](https://catalog.us-east-1.prod.workshops.aws/workshops/f2c0706c-7192-495f-853c-fd3341db265a/en-US/intro)
**関連動画:**
+ [Delivering Excellence with Microservices on AWS](https://www.youtube.com/watch?v=otADkIyugzY)
# REL03-BP02 特定のビジネスドメインと機能に重点を置いたサービスを構築する
サービス指向アーキテクチャ (SOA) は、ビジネスニーズに合わせて明確に定義された機能を備えたサービスを構築します。マイクロサービスはドメインモデルと境界付けられたコンテキストを使用してこれをさらに制限し、各サービスが 1 つのことだけを実行するようにします。特定の機能に焦点を当てることで、さまざまなサービスの信頼性要件を差別化し、より具体的に的を絞って投資することができます。簡潔なビジネス上の問題と各サービスに関連付けられた小さなチームにより、組織のスケーリングも容易になります。
マイクロサービスアーキテクチャを設計する際は、ドメイン駆動設計 (DDD) を使用して、エンティティでビジネス上の問題をモデル化すると便利です。例えば、Amazon.com ウェブサイトの場合、エンティティには、パッケージ、配送、スケジュール、料金、割引、通貨などがあります。その後、モデルは [https://martinfowler.com/bliki/BoundedContext.html](https://martinfowler.com/bliki/BoundedContext.html)、そこで類似した機能と属性を共有するエンティティがグループ化されます。したがって、Amazon.com の例で言うと、パッケージ、配送、スケジュールは発送コンテキストの一部となり、料金、割引、通貨は料金コンテキストの一部となります。モデルをコンテキストに分割したら、マイクロサービスを境界で区切る方法のテンプレートが現れます。
![\[マイクロサービスを境界で区切る方法のモデルテンプレート\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2022-03-31/framework/images/building-services.png)
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
+ ビジネスドメインとそれぞれの機能に基づいてワークロードを設計します。特定の機能に焦点を当てることで、さまざまなサービスの信頼性要件を差別化し、より具体的に的を絞って投資することができます。簡潔なビジネス上の問題と各サービスに関連付けられた小さなチームにより、組織のスケーリングも容易になります。
+ ドメイン分析を実行して、ワークロードのドメイン駆動型設計 (DDD) をマッピングします。次に、ワークロードのニーズを満たすアーキテクチャタイプを選択できます。
+ [モノリスをマイクロサービスに分割する方法](https://martinfowler.com/articles/break-monolith-into-microservices.html)
+ [レガシーシステムに囲まれているときの DDD の使用開始](https://domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf)
+ [Eric Evans “Domain-Driven Design: Tackling Complexity in the Heart of Software”](https://www.amazon.com/gp/product/0321125215)
+ [AWS でのマイクロサービスの実装](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ サービスをできるだけ小さなコンポーネントに分解します。マイクロサービスアーキテクチャを使用すると、最小限の機能でワークロードをコンポーネントに分割し、全社的なスケーリングと俊敏性を実現できます。
+ ワークロードの API とその設計目標、制約、使用に関するその他の検討事項を定義します。
+ API を定義します。
+ 拡張と追加パラメータが実現可能になるように API を定義します。
+ 設計時の可用性を定義します。
+ さまざまな機能に関して API の設計目標を複数立てることができます。
+ 制約を決める
+ テスティングを利用して、ワークロードの能力の上限を定義します。
## リソース
**関連するドキュメント:**
+ [Amazon API Gateway: OpenAPI を使用した REST API の設定](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [境界付けられたコンテキスト (ドメイン駆動設計の中心的なパターン)](https://martinfowler.com/bliki/BoundedContext.html)
+ [Eric Evans “Domain-Driven Design: Tackling Complexity in the Heart of Software”](https://www.amazon.com/gp/product/0321125215)
+ [レガシーシステムに囲まれているときの DDD の使用開始](https://domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf)
+ [モノリスをマイクロサービスに分割する方法](https://martinfowler.com/articles/break-monolith-into-microservices.html)
+ [AWS でのマイクロサービスの実装](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [マイクロサービスのトレードオフ](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [Microservices - a definition of this new architectural term](https://www.martinfowler.com/articles/microservices.html)
+ [AWS でのマイクロサービス](https://aws.amazon.com/microservices/)
# REL03-BP03 API ごとにサービス契約を提供する
サービス契約は、サービス統合に関するチーム間で文書化した合意で、機械で読み取ることができる API 定義、レート制限、パフォーマンスの期待値が含まれます。バージョニング戦略により、クライアントは既存の API を引き続き使用し、準備ができたらアプリケーションを新しい API に移行できます。契約に違反しない限り、デプロイはいつでも行うことができます。サービスプロバイダーチームは、選択した技術スタックを使用して、API 契約の条件を満たすことができます。同様に、サービスコンシューマーは独自のテクノロジーを使用できます。
マイクロサービスはサービス指向アーキテクチャ (SOA) という概念の進化形であり、マイクロサービスでは最小限の機能を備えたサービスを構築します。各サービスでは、サービスを使用するための API、設計目標、制限、その他の考慮事項が公開されています。これにより、アプリケーションの呼び出しを備えた *契約* が確立されます。これには次のような 3 つのメリットがあります。
+ このサービスでは、対応すべきビジネスの課題が簡潔で、それを共有するチームの規模は小さくなります。これにより組織の拡大が可能となります。
+ API の要件やその他の契約条件を満たしている限り、チームはいつでもデプロイできます。
+ API の要件やその他の契約条件を満たしている限り、チームはあらゆる技術スタックを使用することができます。
Amazon API Gateway は、デベロッパーがあらゆる規模の API の作成、公開、保守、モニタリング、保護を簡単に行えるようにするためのフルマネージド型サービスです。Amazon API Gateway は、トラフィック管理、認可とアクセスコントロール、モニタリング、API バージョン管理など、最大数十万個の同時 API 呼び出しの受け入れと処理に伴うすべてのタスクを取り扱います。以前は Swagger 仕様として知られていた OpenAPI 仕様 (OAS) を使用して、API 契約を定義し、API Gateway にインポートできます。API Gateway を使用すると、API をバージョン管理してデプロイできます。
**このベストプラクティスを活用しない場合のリスクレベル:** 低
## 実装のガイダンス
+ API ごとにサービス契約を提供するサービス契約は、サービス統合に関するチーム間の文書化された合意であり、機械で読み取ることができる API 定義、レート制限、パフォーマンスの期待値が含まれます。
+ [Amazon API Gateway: OpenAPI を使用した REST API の設定](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ バージョニング戦略により、クライアントは既存の API を引き続き使用し、準備ができたらアプリケーションを新しい API に移行できます。
+ Amazon API Gateway は、開発者が規模を問わず簡単に API を作成できる完全マネージド型サービスです。以前は Swagger 仕様として知られていた OpenAPI 仕様 (OAS) を使用して、API 契約を定義し、API Gateway にインポートできます。API Gateway を使用すると、API をバージョン管理してデプロイできます。
## リソース
**関連するドキュメント:**
+ [Amazon API Gateway: OpenAPI を使用した REST API の設定](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [境界付けられたコンテキスト (ドメイン駆動設計の中心的なパターン)](https://martinfowler.com/bliki/BoundedContext.html)
+ [AWS でのマイクロサービスの実装](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [マイクロサービスのトレードオフ](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [Microservices - a definition of this new architectural term](https://www.martinfowler.com/articles/microservices.html)
+ [AWS でのマイクロサービス](https://aws.amazon.com/microservices/)
# REL 4 障害を防ぐために、分散システムでの操作をどのように設計すればよいですか?
分散システムは、サーバーやサービスなどのコンポーネントを相互接続するために通信ネットワークを利用しています。このネットワークでデータの損失やレイテンシーがあっても、ワークロードは確実に動作する必要があります。分散システムのコンポーネントは、他のコンポーネントやワークロードに悪影響を与えない方法で動作する必要があります。これらのベストプラクティスは、故障を防ぎ、平均故障間隔 (MTBF) を改善します。
**Topics**
+ [REL04-BP01 必要な分散システムの種類を特定する](rel_prevent_interaction_failure_identify.md)
+ [REL04-BP02 疎結合の依存関係を実装する](rel_prevent_interaction_failure_loosely_coupled_system.md)
+ [REL04-BP03 継続動作を行う](rel_prevent_interaction_failure_constant_work.md)
+ [REL04-BP04 すべての応答に冪等性を持たせる](rel_prevent_interaction_failure_idempotent.md)
# REL04-BP01 必要な分散システムの種類を特定する
ハードなリアルタイム分散システムでは、応答を同期的かつ迅速に行えるようにする必要がありますが、ソフトなリアルタイムシステムでは、応答に数分以上の余裕をもった時間枠があります。オフラインシステムは、バッチ処理または非同期処理を通じて応答を処理します。ハードなリアルタイム分散システムは、最も厳格な信頼性要件を持っています。
最も難しい [分散型システムの課題](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/) は、リクエスト / 応答サービスとも呼ばれるハードなリアルタイム分散システムです。それを困難にしているのは、リクエストが前触れもなく送信され、直ちに応答しなくてはならないという点です (お客様がレスポンスを待っているなど)。この例には、フロントエンドウェブサーバー、オーダーパイプライン、クレジットカードトランザクション、すべての AWS API、テレフォニーなどがあります。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
+ 必要な分散システムの種類を特定します。分散型システムの課題としては、レイテンシー、スケーリング、ネットワーキング API の理解、データのマーシャリングとアンマーシャリング、および Paxos などのアルゴリズムの複雑性に関するものがありました。システムが大きくなり、分散化が進むにつれて、理論上のエッジケースが日常的に発生するようになります。
+ [The Amazon Builders' Library: 分散システムの課題](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ ハードなリアルタイム分散システムでは、応答を同期的かつ迅速に与える必要があります。
+ ソフトなリアルタイムシステムでは、応答に数分以上の余裕をもった時間枠があります。
+ オフラインシステムは、バッチ処理または非同期処理を通じて応答を処理します。
+ ハードなリアルタイム分散システムは、最も厳格な信頼性要件を持っています。
## リソース
**関連するドキュメント:**
+ [Amazon EC2: Ensuring Idempotency](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
+ [The Amazon Builders' Library: 分散システムの課題](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ [The Amazon Builders' Library: 信頼性、動作の継続、一杯のコーヒー](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
+ [「Amazon EventBridge とは?」](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [「Amazon Simple Queue Service とは何ですか?」](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)
**関連動画:**
+ [AWS New York Summit 2019: Intro to Event-driven Architectures and Amazon EventBridge (MAD205)](https://youtu.be/tvELVa9D9qU)
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small ARC337 (疎結合、継続動作、静的安定性を含む)](https://youtu.be/O8xLxNje30M)
+ [AWS re:Invent 2019: Moving to event-driven architectures (SVS308)](https://youtu.be/h46IquqjF3E)
# REL04-BP02 疎結合の依存関係を実装する
キューイングシステム、ストリーミングシステム、ワークフロー、ロードバランサーなどの依存関係は、緩やかに結合しています。疎結合は、コンポーネントの動作をそれに依存する他のコンポーネントから分離するのに役立ち、弾力性と俊敏性を高めます。
1 つのコンポーネントを変更すると、それに依存する他のコンポーネントも強制的に変更される場合、それらは *緊密に* 結合されています。 *疎* 結合はこの依存関係を壊すため、依存コンポーネントが知る必要があるのは、バージョン管理されて公開されたインターフェイスのみです。依存関係があるコンポーネント間に疎結合を実装すると、あるコンポーネントの障害が別のコンポーネントに影響を及ぼさないようにすることができます。
疎結合により、そのコンポーネントに依存する他のコンポーネントのリスクを最小限に抑えながら、コンポーネントにコードまたは機能を自由に追加できます。また、スケールアウトしたり、依存関係の基盤となる実装を変更したりできるため、スケーラビリティが向上します。
疎結合によって弾力性をさらに向上させるには、可能な場合はコンポーネント間のやりとりを非同期にします。このモデルは、即時応答を必要とせず、リクエストが登録されていることの確認で十分な状況では、どのような対話にも最適です。イベントを生成するコンポーネントと、イベントを消費するコンポーネントがあります。2 つのコンポーネントは、直接的なポイントツーポイントのやりとりではなく、通常、SQS キューのような中間的な耐久性の高いストレージレイヤーや Amazon Kinesis のようなストリーミングデータプラットフォーム、または AWS Step Functions を介して統合されます。
![\[キューイングシステムやロードバランサーなどの依存関係が疎結合されていることを示す図\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2022-03-31/framework/images/loosely-coupled-dependencies.png)
Amazon SQS キューと Elastic Load Balancing は、疎結合の中間レイヤーを追加する方法のうちの 2 つにすぎません。イベント駆動型アーキテクチャは、Amazon EventBridge を使用して AWS クラウド に構築することもできます。これにより、依存しているサービス (イベントコンシューマー) からクライアント (イベントプロデューサー) を抽出することができます。Amazon Simple Notification Service (Amazon SNS) は、高スループット、プッシュベースの多対多メッセージングが必要な場合に効果的なソリューションです。Amazon SNS トピックを使用すると、パブリッシャーシステムは、メッセージを多数のサブスクライバーエンドポイントにファンアウトして、並列処理できます。
キューにはいくつかの利点がありますが、ほとんどのハードリアルタイムシステムでは、しきい値の時間 (多くの場合、数秒) よりも長時間かかっているリクエストは古くなっていると見なされ (クライアントが停止し、応答を待機しなくなる)、処理されません。このように、古くなったリクエストの代わりに、より新しい (そしておそらくまだ有効な) リクエストを処理することができます。
**一般的なアンチパターン:**
+ ワークロードの一部としてシングルトンをデプロイする。
+ リクエストのフェイルオーバーや非同期処理を行うことはできない状態で、ワークロード層間で直接 API を呼び出す。
**このベストプラクティスを活用するメリット:** 疎結合は、コンポーネントの動作をそれに依存する他のコンポーネントから分離するのに役立ち、弾力性と俊敏性を高めます。1 つのコンポーネントの障害は他のコンポーネントから分離されます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
+ 疎結合の依存関係を実装します。キューイングシステム、ストリーミングシステム、ワークフロー、ロードバランサーなどの依存関係は、緩やかに結合しています。疎結合は、コンポーネントの動作をそれに依存する他のコンポーネントから分離するのに役立ち、弾力性と俊敏性を高めます。
+ [AWS re:Invent 2019: Moving to event-driven architectures (SVS308)](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [「Amazon EventBridge とは?」](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [「Amazon Simple Queue Service とは何ですか?」](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)
+ Amazon EventBridge では、疎結合で分散されたイベント駆動型アーキテクチャを構築できます
+ [AWS New York Summit 2019: Intro to Event-driven Architectures and Amazon EventBridge (MAD205)](https://youtu.be/tvELVa9D9qU)
+ 1 つのコンポーネントを変更すると、それに依存する他のコンポーネントも強制的に変更される場合、それらは密結合されています。疎結合はこの依存関係を壊すため、依存関係コンポーネントが知る必要があるのは、バージョン付きで公開されたインターフェイスのみです。
+ 可能な限り、コンポーネントのインタラクションを非同期にします。このモデルは、即時応答を必要とせず、要求が登録されていることの確認が十分である状況では、どのような対話にも最適です。
+ [AWS re:Invent 2019: Scalable serverless event-driven applications using Amazon SQS and Lambda (API304)](https://youtu.be/2rikdPIFc_Q)
## リソース
**関連するドキュメント:**
+ [AWS re:Invent 2019: Moving to event-driven architectures (SVS308)](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Amazon EC2: 冪等性の確保](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
+ [The Amazon Builders' Library: 分散システムの課題](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ [The Amazon Builders' Library: 信頼性、動作の継続、一杯のコーヒー](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
+ [「Amazon EventBridge とは?」](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [「Amazon Simple Queue Service とは何ですか?」](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)
**関連動画:**
+ [AWS New York Summit 2019: Intro to Event-driven Architectures and Amazon EventBridge (MAD205)](https://youtu.be/tvELVa9D9qU)
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small ARC337 (疎結合、継続動作、静的安定性を含む)](https://youtu.be/O8xLxNje30M)
+ [AWS re:Invent 2019: Moving to event-driven architectures (SVS308)](https://youtu.be/h46IquqjF3E)
+ [AWS re:Invent 2019: Scalable serverless event-driven applications using Amazon SQS and Lambda (API304)](https://youtu.be/2rikdPIFc_Q)
# REL04-BP03 継続動作を行う
負荷が急激に大きく変化すると、システム障害が発生することがあります。例えば、ワークロードで何千台ものサーバーのヘルスをモニタリングするヘルスチェックを実行する場合、毎回同じサイズのペイロード (現在の状態の完全なスナップショット) を送信しています。障害が発生しているサーバーがなくても、またはそのすべてに障害が発生していても、ヘルスチェックシステムは、大規模で急激な変更なしに常に作業を行っています。
たとえば、ヘルスチェックシステムが 100,000 台のサーバーをモニタリングしている場合、通常のサーバー障害率が軽いときは、その負荷はわずかです。ただし、重大なイベントによってこれらのサーバーの半分が異常な状態になると、ヘルスチェックシステムは、通知システムを更新し、クライアントに状態を通知しようとして過負荷になるでしょう。したがって、ヘルスチェックシステムは現在の状態の完全なスナップショットを毎回送信する必要があります。サーバー 100,000 台 のヘルス状態 (それぞれ 1 ビットで表される) のペイロードは、12.5 KB にすぎません。サーバーに障害が発生していないか、またはすべてに発生しているかにかかわらず、ヘルスチェックシステムは定期的に作業を行っているため、大規模の急激な変化はシステムの安定性を脅かすものではありません。これは実際に Amazon Route 53 がエンドポイントのヘルスチェック (IP アドレスなど) によってエンドユーザーがどのようにルーティングされているかを調べる際の方法です。
**このベストプラクティスが確立されていない場合のリスクレベル:** 低
## 実装のガイダンス
+ 負荷が急激に変化してシステム障害が発生しないように、継続動作を行います。
+ 疎結合の依存関係を実装します。キューイングシステム、ストリーミングシステム、ワークフロー、ロードバランサーなどの依存関係は、緩やかに結合しています。疎結合は、コンポーネントの動作をそれに依存する他のコンポーネントから分離するのに役立ち、弾力性と俊敏性を高めます。
+ [The Amazon Builders' Library: 信頼性、動作の継続、一杯のコーヒー](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small ARC337 (ループを閉じ、発想を開く: 大小さまざまなシステムをコントロールする方法) ARC337 (継続動作を含む)](https://youtu.be/O8xLxNje30M?t=2482)
+ 100,000 台のサーバーをモニタリングする健康診断システムの例の場合、成功または失敗の数に関係なく、ペイロードサイズが一定になるように、ワークロードを設計します。
## リソース
**関連するドキュメント:**
+ [Amazon EC2: べき等性の確保](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
+ [The Amazon Builders' Library: 分散システムの課題](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ [The Amazon Builders' Library: 信頼性、動作の継続、一杯のコーヒー](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
**関連動画:**
+ [AWS New York Summit 2019: Intro to Event-driven Architectures and Amazon EventBridge (MAD205) (イベント駆動型アーキテクチャーと Amazon EventBridge 入門)](https://youtu.be/tvELVa9D9qU)
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small ARC337 (ループを閉じ、発想を開く: 大小さまざまなシステムをコントロールする方法) ARC337 (継続動作を含む)](https://youtu.be/O8xLxNje30M?t=2482)
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small ARC337 (ループを閉じ、発想を開く: 大小さまざまなシステムをコントロールする方法) ARC337 (疎結合、継続動作、静的安定性を含む)](https://youtu.be/O8xLxNje30M)
+ [AWS re:Invent 2019: Moving to event-driven architectures (SVS308) (イベント駆動型アーキテクチャへの移行)](https://youtu.be/h46IquqjF3E)
# REL04-BP04 すべての応答に冪等性を持たせる
べき等のサービスは、各リクエストが 1 回だけで完了することを約束します。そのため、同一のリクエストを複数回行っても、リクエストを 1 回行ったのと同じ効果しかありません。べき等サービスを使用すると、リクエストが誤って複数回処理されることを恐れる必要がなくなるため、クライアントが再試行を行いやすくなります。このために、クライアントはべき等性トークンを使用して API リクエストを発行できます。リクエストが繰り返される場合は常に同じトークンが使われます。べき等サービス API はトークンを使用して、リクエストが最初に完了したときに返された応答と同じ応答を返します。
分散システムでは、アクションを最大で 1 回 (クライアントがリクエストを 1 回だけ行う)、または少なくとも 1 回 (クライアントが成功を確認するまでリクエストを続ける) 実行するのは簡単です。ただし、アクションがべき等であることを保証することは困難です。つまり、 *正確に* 1 回だけ実行し、同一のリクエストを複数回行っても、リクエストを 1 回行うのと同じ効果を得るようにするということです。API でべき等性トークンを使用すると、サービスは、重複レコードや副作用を生むことなく、変更リクエストを 1 回または複数回受け取ることができます。
**このベストプラクティスを活用しない場合のリスクレベル:** ミディアム
## 実装のガイダンス
+ すべての応答に冪等性を持たせます。べき等のサービスは、各リクエストが 1 回だけで完了することを約束します。そのため、同一のリクエストを複数回行っても、リクエストを 1 回行ったのと同じ効果しかありません。
+ クライアントはべき等性トークンを使用して API リクエストを発行できます。リクエストが繰り返される場合は常に同じトークンが使われます。べき等サービス API はトークンを使用して、リクエストが最初に完了したときに返された応答と同じ応答を返します。
+ [Amazon EC2: 冪等性の確保](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
## リソース
**関連するドキュメント:**
+ [Amazon EC2: Ensuring Idempotency](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
+ [The Amazon Builders' Library: 分散システムの課題](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ [The Amazon Builders' Library: 信頼性、動作の継続、一杯のコーヒー](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
**関連動画:**
+ [AWS New York Summit 2019: Intro to Event-driven Architectures and Amazon EventBridge (MAD205)](https://youtu.be/tvELVa9D9qU)
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small ARC337 (疎結合、継続動作、静的安定性を含む)](https://youtu.be/O8xLxNje30M)
+ [AWS re:Invent 2019: Moving to event-driven architectures (SVS308)](https://youtu.be/h46IquqjF3E)
# REL 5 障害を緩和または耐えるために、分散システムの操作をどのように設計しますか?
分散システムは、サーバーやサービスなどのコンポーネントを相互接続するために通信ネットワークを利用しています。このネットワークでデータの損失やレイテンシーがあっても、ワークロードは確実に動作する必要があります。分散システムのコンポーネントは、他のコンポーネントやワークロードに悪影響を与えない方法で動作する必要があります。これらのベストプラクティスに従うことで、ワークロードはストレスや障害に耐え、より迅速に復旧し、そのような障害の影響を軽減できます。その結果、平均復旧時間 (MTTR) が向上します。
**Topics**
+ [REL05-BP01 該当するハードな依存関係をソフトな依存関係に変換するため、グレイスフルデグラデーションを実装する](rel_mitigate_interaction_failure_graceful_degradation.md)
+ [REL05-BP02 リクエストのスロットル](rel_mitigate_interaction_failure_throttle_requests.md)
+ [REL05-BP03 再試行呼び出しを制御および制限する](rel_mitigate_interaction_failure_limit_retries.md)
+ [REL05-BP04 フェイルファストとキューの制限](rel_mitigate_interaction_failure_fail_fast.md)
+ [REL05-BP05 クライアントタイムアウトを設定する](rel_mitigate_interaction_failure_client_timeouts.md)
+ [REL05-BP06 可能な限りサービスをステートレスにする](rel_mitigate_interaction_failure_stateless.md)
+ [REL05-BP07 緊急レバーを実装する](rel_mitigate_interaction_failure_emergency_levers.md)
# REL05-BP01 該当するハードな依存関係をソフトな依存関係に変換するため、グレイスフルデグラデーションを実装する
コンポーネントの依存関係が異常な場合でも、コンポーネント自体は機能しますが、パフォーマンスが低下します。たとえば、依存関係の呼び出しが失敗した場合、事前に定義された静的レスポンスにフェイルオーバーします。
サービス A によって呼び出されたサービス B が、次にサービス C を呼び出すとします。
![\[サービス B から呼び出されるとサービス C が失敗することを示す図。サービス B は、低下した応答をサービス A に返します。\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2022-03-31/framework/images/graceful-degradation.png)
サービス B がサービス C を呼び出すと、エラーまたはタイムアウトを受け取ります。サービス B は、サービス C (およびそれに含まれるデータ) からの応答がないため、返せるものを返します。これは、最後にキャッシュされた適切な値であるかもしれません。または、サービス B は、サービス C から受け取るはずだったものを所定の静的応答に置き換える可能性もあります。次に、低下した応答を呼び出し元のサービス A に返すことでしょう。この静的応答がない場合、サービス C で障害が発生すると、サービス B を介してサービス A にカスケードされ、可用性が失われます。
強い依存関係の可用性方程式の乗数的因子により (「 [https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html#dbedbedda68f9a15ACLX122](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html#dbedbedda68f9a15ACLX122)」を参照)、C の可用性が低下すると、B の有効な可用性に重大な影響を与えます。静的応答を返すことによりサービス B は、C での障害を軽減し、パフォーマンスが低下しますが、サービス C が 100% の可用性を実現しているように見せます (エラー条件下で確実に静的応答を返すと仮定します)。静的応答は単純にエラーを返す代わりに行う手段で、別の手段を使って応答を再計算する試みではないことに注意してください。まったく異なるメカニズムで同じ結果を達成しようとする試みは、フォールバック動作と呼ばれ、回避すべきアンチパターンです。
グレースフルデグラデーションのもう 1 つの例は *サーキットブレーカーパターン*.障害が一時的な場合は、再試行戦略を用いるのがよいでしょう。障害が一時的ではなく、操作が失敗する可能性が高い場合、サーキットブレーカーパターンは、失敗する可能性が高いリクエストをクライアントが実行できないようにします。リクエストが正常に処理されると、サーキットブレーカーは閉じられ、リクエストは正常に流されます。リモートシステムがエラーを返し始めるか、レイテンシーが高くなると、サーキットブレーカーが開かれ、依存関係が無視されるか、結果的に返される応答は単純に取得されたが包括的ではない応答 (単なる応答キャッシュである場合もあります) に置き換えられます。システムは、依存性が回復したかどうかを判断するために、依存関係を定期的に呼び出そうとします。依存関係が確認できたら、サーキットブレーカーは閉じられます。
![\[サーキットブレーカーが開いた状態と閉じた状態を示した図。\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2022-03-31/framework/images/circuit-breaker.png)
図に示されている閉じた状態と開いた状態に加えて、開いた状態で設定可能な期間が経過すると、サーキットブレーカーは半分開いた状態に移行することもあります。この状態では、通常よりはるかに低いレートで定期的にサービスを呼び出そうとします。このプローブは、サービスの状態を確認するために使用します。半開状態で何度か成功すると、サーキットブレーカーは閉じた状態に移行し、通常のリクエストフローが再開されます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
+ 該当するハードな依存関係をソフトな依存関係に変換するため、グレイスフルデグラデーションを実装します。コンポーネントの依存関係が異常な場合でも、コンポーネント自体は機能しますが、パフォーマンスが低下します。たとえば、依存関係の呼び出しが失敗した場合、事前に定義された静的レスポンスにフェイルオーバーします。
+ 静的応答を返すことで、ワークロードは依存関係で発生する障害を軽減します。
+ [Well-Architected ラボ: レベル 300: ヘルスチェックを実装し依存関係を管理して、信頼性を向上する](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html)
+ 再試行オペレーションが失敗する可能性がある場合を検出し、クライアントがサーキットブレーカーパターンで失敗した呼び出しを行わないようにします。
+ [CircuitBreaker](https://martinfowler.com/bliki/CircuitBreaker.html)
## リソース
**関連するドキュメント:**
+ [Amazon API Gateway: スループット向上に向けた API リクエストのスロットリング](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [CircuitBreaker (「Release It\$1」よりサーキットブレーカーをまとめたもの)](https://martinfowler.com/bliki/CircuitBreaker.html)
+ [AWS でのエラーの再試行とエクスポネンシャルバックオフ](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [Michael Nygard「Release It\$1 Design and Deploy Production-Ready Software」](https://pragprog.com/titles/mnee2/release-it-second-edition/)
+ [The Amazon Builders' Library: 分散システムでのフォールバックの回避](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [The Amazon Builders' Library: 克服できないキューバックログの回避](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [The Amazon Builders' Library: キャッシュの課題と戦略](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
+ [The Amazon Builders' Library: タイムアウト、再試行、ジッターによるバックオフ](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
**関連動画:**
+ [再試行、バックオフ、ジッター: AWS re:Invent 2019: Introducing The Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
**関連する例:**
+ [Well-Architected ラボ: レベル 300: ヘルスチェックを実装し依存関係を管理して、信頼性を向上する](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html)
# REL05-BP02 リクエストのスロットル
リクエストのスロットリングは、予想外の需要の増加に対応するための軽減パターンです。一部のリクエストは受け入れられますが、定義された制限を超えるリクエストは拒否され、スロットルされたことを示すメッセージが返されます。クライアントの期待は、リクエストが戻されて放棄されるか、遅い速度で再試行することです。
サービスは、各ノードまたはセルが処理できる既知のリクエスト容量に合わせて設計する必要があります。この容量は、負荷テストによって設定できます。リクエストの到着率をトラッキングし、到着率が一時的に制限を超えると、リクエストが適切にスロットリングされたことを示す応答があります。これにより、ユーザーは、利用可能なキャパシティを持つ可能性のある別のノードまたはセルに再試行することができます。Amazon API Gateway には、リクエストをスロットリングするためのメソッドが用意されています。Amazon SQS と Amazon Kinesis はリクエストをバッファリングし、リクエスト率を平準化し、非同期で対応できるリクエストのスロットリングの必要性を軽減することができます。
**このベストプラクティスが確立されていない場合のリスクレベル:** 高
## 実装のガイダンス
+ リクエストをスロットリングします。これは、予想外の需要の増加に対応するための軽減パターンです。一部のリクエストは受け入れられますが、定義された制限を超えるリクエストは拒否され、スロットルされたことを示すメッセージが返されます。クライアントの期待は、リクエストが戻されて放棄されるか、遅い速度で再試行することです。
+ Amazon API Gateway を使用します。
+ [スループット向上に向けた API リクエストのスロットリング](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
## リソース
**関連するドキュメント:**
+ [Amazon API Gateway: スループット向上に向けた API リクエストのスロットリング](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [AWS でのエラー再試行とエクスポネンシャルバックオフ](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [The Amazon Builders' Library: 分散システムでのフォールバックの回避](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [The Amazon Builders' Library: 克服できないキューバックログの回避](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [The Amazon Builders' Library: タイムアウト、再試行、ジッターによるバックオフ](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
+ [スループット向上に向けた API リクエストのスロットリング](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
**関連動画:**
+ [Retry, backoff, and jitter (再試行、バックオフ、ジッター): AWS re:Invent 2019: Introducing The Amazon Builders’ Library (DOP328) (The Amazon Builders’ Library のご紹介)](https://youtu.be/sKRdemSirDM?t=1884)
# REL05-BP03 再試行呼び出しを制御および制限する
エクスポネンシャルバックオフを使用して、徐々に長い間隔で再試行します。これらの再試行間隔をランダム化するジッターを導入し、再試行の最大数を制限します。
分散ソフトウェアシステムの一般的なコンポーネントには、サーバー、ロードバランサー、データベース、DNS サーバーが含まれます。操作中に障害が発生すると、これらのコンポーネントのいずれかにエラーが発生し始める可能性があります。エラーを処理するデフォルトの手法は、クライアント側で再試行を行うことです。この手法により、アプリケーションの信頼性と可用性が向上します。ただし、再試行が大規模に行われた場合 (またエラーが発生してからすぐにクライアントが失敗した操作を再試行しようとすると)、ネットワークは、新しいリクエストと再試行されたリクエストですぐに飽和状態になり、それぞれがネットワーク帯域幅を奪い合うことになる可能性があります。これにより *再試行の大混乱が生じて、* サービスの可用性が低下します。このパターンは、システムが完全にダウンするまで続くかもしれません。
このようなシナリオを回避するには、一般的なエクスポネンシャルバックオフなどの *バックオフアルゴリズム* を使用する必要があります。エクスポネンシャルバックオフアルゴリズムは、再試行が行われる速度を徐々に下げて、ネットワークの輻輳を回避します。
多くの SDK およびソフトウェアライブラリ (AWS のものを含む) は、これらのアルゴリズムのバージョンを実装しています。ただし、 **バックオフアルゴリズムが存在することは想定しないでください。必ずこれをテストして検証してください。**
分散システムでは、すべてのクライアントが同時にバックオフし、再試行呼び出しのクラスターが発生する可能性があるため、単にバックオフするだけでは不十分です。Marc Brooker 氏のブログ記事「 [エクスポネンシャルバックオフとジッター](https://aws.amazon.com/blogs/architecture/exponential-backoff-and-italics%0djitter/)は、エクスポネンシャルバックオフで wait() 関数を変更して、再試行呼び出しのクラスターを防ぐ方法を説明しています。解決策は、 *ジッター* を wait() 関数に追加することです。時間がかかり過ぎる再試行を行わないようにするには、実装ではバックオフを最大値に制限する必要があります。
最後に、 *再試行の最大数* または最大経過時間を設定し、これを超えると再試行が失敗するようにすることが重要です。AWS SDK はデフォルトでこれを実装しており、設定を変更することもできます。スタックの下位にあるサービスの場合、再試行の上限を 0 または 1 にするとリスクが緩和されますが、スタックの上位にあるサービスに再試行が委任されるため、効果的な方法です。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
+ 再試行呼び出しを制御および制限します。エクスポネンシャルバックオフを使用して、徐々に長い間隔で再試行します。これらの再試行間隔をランダム化するジッターを導入し、再試行の最大数を制限します。
+ [AWS でのエラーの再試行とエクスポネンシャルバックオフ](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ Amazon SDK は、デフォルトで再試行とエクスポネンシャルバックオフを実装しています。お客様独自の依存サービスを呼び出す場合は、同類のロジックを依存関係レイヤーに実装します。タイムアウトの時間と、再試行をいつ停止するのかをユースケースに基づいて決めます。
## リソース
**関連するドキュメント:**
+ [Amazon API Gateway: スループット向上に向けた API リクエストのスロットリング](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [AWS でのエラーの再試行とエクスポネンシャルバックオフ](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [The Amazon Builders' Library: 分散システムでのフォールバックの回避](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [The Amazon Builders' Library: 克服できないキューバックログの回避](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [The Amazon Builders' Library: キャッシュの課題と戦略](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
+ [The Amazon Builders' Library: タイムアウト、再試行、ジッターによるバックオフ](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
**関連動画:**
+ [再試行、バックオフ、ジッター: AWS re:Invent 2019: Introducing The Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
# REL05-BP04 フェイルファストとキューの制限
ワークロードがリクエストに正常に応答できない場合は、すぐに失敗するようにします。これにより、リクエストに関連付けられたリソースを解放でき、リソースが不足した場合にサービスを復旧できます。ワークロードは正常に応答できるが、リクエスト頻度が高すぎる場合は、代わりにキューを使用してリクエストをバッファします。ただし、長いキューは許可しないでください。クライアントがすでに処理を停止している古いリクエストを処理する原因となる可能性があるためです。
このベストプラクティスは、サーバー側、つまりリクエストのレシーバーに当てはまります。
キューはシステムの複数のレベルで作成される可能性があるため、応答が必要な新しいリクエストの前に (もはや応答を必要としない) 古い応答が処理されると、迅速に復旧する能力が著しく阻害される可能性があることに注意してください。キューがどこに存在するかに注意を払ってください。ワークフローや、データベースに記録された作業の中に隠れていることもよくあります。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
+ すぐに失敗し、キューを制限します。ワークロードがリクエストに正常に応答できない場合は、すぐに失敗するようにします。これにより、リクエストに関連付けられたリソースを解放でき、リソースが不足した場合にサービスを復旧できます。ワークロードは正常に応答できるが、リクエスト頻度が高すぎる場合は、代わりにキューを使用してリクエストをバッファします。ただし、長いキューは許可しないでください。クライアントがすでに処理を停止している古いリクエストを処理する原因となる可能性があるためです。
+ サービスへの負荷が過剰になったときのフェイルファストを実装します。
+ [速やかな失敗](https://www.martinfowler.com/ieeeSoftware/failFast.pdf)
+ キューベースのシステムでは、処理が停止してもメッセージが到着し続けると、メッセージの負債が蓄積されて、大きなバックログになり、処理時間が長くなることがあります。作業の完了が遅すぎて、結果が役に立たなくなることがあります。これにより、基本的にキューイングが防御することを意図していた、可用性への悪影響が発生します。
+ [The Amazon Builders' Library: 克服できないキューバックログの回避](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
## リソース
**関連するドキュメント:**
+ [AWS でのエラーの再試行とエクスポネンシャルバックオフ](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [速やかな失敗](https://www.martinfowler.com/ieeeSoftware/failFast.pdf)
+ [The Amazon Builders' Library: 分散システムでのフォールバックの回避](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [The Amazon Builders' Library: 克服できないキューバックログの回避](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [The Amazon Builders' Library: キャッシュの課題と戦略](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
+ [The Amazon Builders' Library: タイムアウト、再試行、ジッターによるバックオフ](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
**関連動画:**
+ [再試行、バックオフ、ジッター: AWS re:Invent 2019: Introducing The Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
# REL05-BP05 クライアントタイムアウトを設定する
タイムアウトを適切に設定し、体系的に検証します。デフォルト値は通常高すぎるため、デフォルト値のままにしないでください。
このベストプラクティスは、クライアント側、つまりリクエストの送信者に当てはまります。
リモート呼び出しに接続タイムアウトとリクエストタイムアウトの両方を設定します。またこの設定は、プロセス全体のすべての呼び出しに一般的に行います。多くのフレームワークには組み込みのタイムアウト機能がありますが、その多くのデフォルト値は無限または高すぎるため、注意が必要です。値が高すぎると、クライアントがタイムアウトの発生を待機している間もリソースが消費され続けるため、タイムアウトの有用性が低下します。値が小さすぎると、再試行されるリクエストが多くなりすぎるため、バックエンドのトラフィックが増加し、レイテンシーが高くなってしまいます。場合によっては、すべてのリクエストが再試行されることになるため、完全な機能停止につながる恐れもあります。
Amazon がタイムアウト、再試行、およびジッターによるバックオフを使用する方法について詳しくは [https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/?did=ba_card&trk=ba_card](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/?did=ba_card&trk=ba_card).
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
+ リモート呼び出しに接続タイムアウトとリクエストタイムアウトの両方を設定します。またこの設定は、プロセス全体のすべての呼び出しに一般的に行います。多くのフレームワークには組み込みのタイムアウト機能がありますが、その多くのデフォルト値は無限または高すぎるため、注意が必要です。値が高すぎると、クライアントがタイムアウトの発生を待機している間もリソースが消費され続けるため、タイムアウトの有用性が低下します。値が小さすぎると、再試行されるリクエストが多くなりすぎるため、バックエンドのトラフィックが増加し、レイテンシーが高くなってしまいます。場合によっては、すべてのリクエストが再試行されることになるため、完全な機能停止につながる恐れもあります。
+ [AWS SDK: 再試行とタイムアウト](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html)
## リソース
**関連するドキュメント:**
+ [AWS SDK: 再試行とタイムアウト](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html)
+ [Amazon API Gateway: スループット向上に向けた API リクエストのスロットリング](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [AWS でのエラーの再試行とエクスポネンシャルバックオフ](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [The Amazon Builders' Library: タイムアウト、再試行、ジッターによるバックオフ](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
**関連動画:**
+ [再試行、バックオフ、ジッター: AWS re:Invent 2019: Introducing The Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
# REL05-BP06 可能な限りサービスをステートレスにする
サービスは、ステートを必要としないか、またはステートをオフロードして、異なるクライアントのリクエスト間で、ディスクやメモリのローカルに保存されたデータに依存しないようにする必要があります。これにより、可用性に影響を与えずにサーバーをいつでも交換できます。Amazon ElastiCache または Amazon DynamoDB は、オフロード状態の送信先として適しています。
![\[このステートレスウェブアプリケーションでは、セッション状態は Amazon ElastiCache にオフロードされます。\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2022-03-31/framework/images/stateless-webapp.png)
ユーザーまたはサービスがアプリケーションと対話するとき、セッションを形成する一連のやりとりを頻繁に実行します。セッションは、ユーザーがアプリケーションを使用している間、リクエスト間で持続するユーザー固有のデータです。ステートレスアプリケーションは、以前のやりとりの知識を必要とせず、セッション情報を保存しません。
ステートレスな設計にすれば、あとは AWS Lambda や AWS Fargate などのサーバーレスコンピューティングサービスを利用できます。
サーバーの置き換えに加えて、ステートレスアプリケーションのもう 1 つの利点は、利用可能なコンピューティングリソース (EC2 インスタンスや AWS Lambda 関数など) がどのようなリクエストにも対応できるため、水平方向にスケーリングできることです。
**このベストプラクティスが確立されていない場合のリスクレベル:** ミディアム
## 実装のガイダンス
+ アプリケーションをステートレスにします。ステートレスアプリケーションは、水平方向へのスケーリングが可能であり、個別ノードのエラーに耐性があります。
+ リクエストパラメータに実際に格納できるステートを削除する
+ ステートが必要かどうかを調べてから、あらゆるステート追跡を Amazon ElastiCache、Amazon RDS、Amazon DynamoDB などの回復力のあるマルチゾーンキャッシュやデータストア、またはサードパーティの分散データソリューションに移動します。移動できないステートをエラーに強いデータストアに格納します。
+ 一部のデータ (Cookie など) は、ヘッダーまたはクエリパラメータで渡すことができます。
+ リクエストですばやく渡すことができるステートを削除するためにリファクタリングします。
+ 実際には毎回のリクエストで必要のないデータはオンデマンドで取得できます。
+ 非同期で取得できるデータを削除します。
+ 必要なステートの条件を満たしているデータストアを決めます。
+ リレーショナル型ではないデータには NoSQL データベースを検討します。
## リソース
**関連するドキュメント:**
+ [The Amazon Builders' Library: 分散システムでのフォールバックの回避](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [The Amazon Builders' Library: 克服できないキューバックログの回避](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [The Amazon Builders' Library: キャッシュの課題と戦略](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
# REL05-BP07 緊急レバーを実装する
緊急レバーは、ワークロードの可用性に対する影響を軽減できる迅速なプロセスです。
**このベストプラクティスを活用しない場合のリスクレベル:** ミディアム
## 実装のガイダンス
+ 緊急レバーを実装します。これは、ワークロードの可用性に対する影響を軽減できる可能性がある迅速なプロセスです。根本原因がなくても操作できます。緊急レバーは、完全に決定的なアクティブ化と非アクティブ化の基準を提供することにより、リゾルバーの認知負荷をゼロに減らせるものが理想的です。緊急レバーは多くの場合手動ですが、自動化することもできます
+ 例えば、次のようなレバーがあります。
+ すべてのロボットトラフィックをブロックする
+ 動的ページの代わりに静的ページを表示する
+ 依存関係への呼び出しの頻度を減らす
+ 依存関係からの呼び出しをスロットリングする
+ 緊急レバーを実装して使用するためのヒント
+ 緊急レバーがアクティブになったら、実行数を増やすのではなく、減らす
+ シンプルに保ち、バイモーダルな行動は避ける
+ 緊急レバーを定期的にテストする
+ これらは、緊急レバーではないアクションの例です
+ キャパシティーを追加する
+ サービスに依存するクライアントのサービス所有者を呼び出して、呼び出しを減らすよう依頼する
+ コードを変更してリリースする
# 変更管理
**Topics**
+ [REL 6 ワークロードリソースをモニタリングするにはどうすればよいですか?](w2aac19b9b9b5.md)
+ [REL 7 需要の変化に適応するようにワークロードを設計するには、どうすればよいですか?](w2aac19b9b9b7.md)
+ [REL 8 変更はどのように実装するのですか?](w2aac19b9b9b9.md)
# REL 6 ワークロードリソースをモニタリングするにはどうすればよいですか?
ログとメトリクスは、ワークロードの状態についての洞察を得るための強力なツールです。ワークロードは、しきい値を超えたり重大なイベントが発生したりしたときに、ログとメトリクスがモニタリングされて通知が送信されるように構成できます。モニタリングにより、ワークロードは、低パフォーマンスのしきい値を超えたときや障害が発生したときにそれを認識できるため、それに応じて自動的に復旧できます。
**Topics**
+ [REL06-BP01 ワークロードのすべてのコンポーネントをモニタリングする (生成)](rel_monitor_aws_resources_monitor_resources.md)
+ [REL06-BP02 メトリクスを定義および計算する (集計)](rel_monitor_aws_resources_notification_aggregation.md)
+ [REL06-BP03 通知を送信する (リアルタイム処理とアラーム)](rel_monitor_aws_resources_notification_monitor.md)
+ [REL06-BP04 レスポンスを自動化する (リアルタイム処理とアラーム)](rel_monitor_aws_resources_automate_response_monitor.md)
+ [REL06-BP05 分析](rel_monitor_aws_resources_storage_analytics.md)
+ [REL06-BP06 定期的にレビューを実施する](rel_monitor_aws_resources_review_monitoring.md)
+ [REL06-BP07 システムを通じたリクエストのエンドツーエンドのトレースをモニタリングする](rel_monitor_aws_resources_end_to_end.md)
# REL06-BP01 ワークロードのすべてのコンポーネントをモニタリングする (生成)
ワークロードのコンポーネントは、Amazon CloudWatch またはサードパーティー製ツールを使用してモニタリングします。AWS サービスを AWS Health ダッシュボードでモニタリングします。
フロントエンド、ビジネスロジック、ストレージ層など、ワークロードのすべてのコンポーネントをモニタリングする必要があります。主要なメトリクスと、必要に応じてそれをログから抽出する方法を定義し、対応するアラームイベントを起動させるためのしきい値を設定します。メトリクスがワークロードの重要業績評価指標 (KPI) に関連していることを確認し、メトリクスとログを使用して、サービス低下の早期警告サインを識別します。例えば、1 分間に正常に処理されたオーダー数など、ビジネス成果に関するメトリクスは、CPU 使用率などの技術的メトリクスより早く、ワークロード問題を示すことができます。AWS Health ダッシュボードは、AWS リソースの基盤となる AWS のサービスのパフォーマンスと可用性をパーソナライズして表示するために使用します。
クラウドでのモニタリングは新しい機会をもたらします。ほとんどのクラウドプロバイダーは、カスタマイズ可能なフックを開発して、ワークロードの複数のレイヤーをモニタリングする際に役立つインサイトを提供しています。Amazon CloudWatch などの AWS サービスは、統計的な機械学習アルゴリズムを応用して、システムとアプリケーションのメトリクスを継続的に分析し、正常なベースラインを決定し、最小限のユーザー介入で異常を表面化します。異常検出アルゴリズムでは、メトリクスの季節変動とトレンドの変化が考慮されます。
AWS では、豊富なモニタリングおよびログ情報を公開しており、これらを使用して、ワークロード固有のメトリクスと需要変化プロセスを定義し、機械学習の知識に関わらず、機械学習技法を適応させることができます。
さらに、すべての外部エンドポイントをモニタリングし、それらがベースとなる実装から独立していることを確認します。このアクティブモニタリングは、合成トランザクション ( *ユーザーカナリア*と呼ばれることもありますが、canary デプロイと混同しないでください) で行うことができます。これは、ワークロードのクライアントによって実行されるアクションに相当する多数の一般的タスクを定期的に実行するというものです。これらのタスクは、短期間に保ち、テスト中にワークロードに負荷をかけすぎないようにしてください。Amazon CloudWatch Synthetics を使用すると、 [Synthetics Canary を作成して、](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) エンドポイントと API をモニタリングできます。合成 Canary クライアントノードと AWS X-Ray コンソールを組み合わせて、選択した期間中にエラー、障害、スロットリング率で問題が発生している合成 Canary を特定することもできます。
**期待される成果:**
ワークロードのすべてのコンポーネントから重要なメトリクスを収集して使用し、ワークロードの信頼性と最適なユーザーエクスペリエンスを確保します。ワークロードがビジネス成果を達成していないことを検出した場合は、障害を迅速に宣言して、インシデントから復旧できます。
**一般的なアンチパターン:**
+ ワークロードへの外部インターフェイスのみをモニタリングする。
+ ワークロード固有のメトリクスを生成せず、ワークロードが使用している AWS から提供されるメトリクスにのみ依存する。
+ ワークロードの技術的メトリクスを使用するだけで、ワークロードが貢献する非技術的な KPI に関するメトリクスをモニタリングしない。
+ 本番トラフィックとシンプルなヘルスチェックに依存して、ワークロード状態をモニタリングし、評価する。
**このベストプラクティスを確立するメリット:** ワークロードのすべての階層でモニタリングすることで、ワークロードを構成するコンポーネントの問題をより迅速に予測し、解決できます。
**このベストプラクティスが確立されていない場合のリスクレベル:** 高
## 実装のガイダンス
1. **可能な限りログを有効にします。** ワークロードのすべてのコンポーネントからモニタリングデータを取得する必要があります。S3 Access Logs など、追加のロギングをオンにして、ワークロードがワークロード固有のデータをログに記録できるようにします。Amazon ECS、Amazon EKS、Amazon EC2、Elastic Load Balancing、AWS Auto Scaling、Amazon EMR などのサービスから、CPU、ネットワーク I/O、およびディスク I/O の平均に関するメトリクスを収集します。把握 [CloudWatch メトリクスを発行する AWS のサービス](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html) で、CloudWatch にメトリクスを発行する AWS のサービスのリストを確認できます。
1. **デフォルトのメトリクスをすべてレビューし、データ収集にギャップがないか確認します。** すべてのサービスはデフォルトのメトリクスを生成します。デフォルトのメトリクスを収集することで、ワークロードのコンポーネント間の依存関係と、コンポーネントの信頼性とパフォーマンスがワークロードに及ぼす影響をより深く理解できます。また、独自のメトリクスを [作成して、](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) AWS CLI または API を使用して CloudWatch に発行することもできます。 \$1\$1\$1 please leave this segment blank since the source does not make any sense in context \$1\$1\$1
1. **すべてのメトリクスを評価して、ワークロード内の各 AWS サービスに対してどのメトリクスでアラートを出すかを決定します。** ワークロードの信頼性に大きな影響を持つメトリクスのサブセットを選択することもできます。重要なメトリクスとしきい値に焦点を当てることで、 [アラート](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) の数を絞り込み、偽陽性を最小化できます。
1. **アラートを定義し、アラートが起動された後のワークロードの復旧プロセスを定義します。** アラートを定義することで、通知とエスカレーションを迅速に行い、インシデントからの復旧に必要なステップに従い、所定の目標復旧時間 (RTO) を満たすことができます。専用のインフラストラクチャで [https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-actions](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-actions) を使用すると、定義されたしきい値に基づいて自動ワークフローを起動し、回復手順を開始することができます。
1. **合成トランザクションを使用して、ワークロードの状態に関する関連データを収集することを検討しましょう。** 合成モニタリングは、顧客と同じルートに従って同じアクションを実行するため、ワークロードに顧客のトラフィックがない場合でも、継続的にカスタマーエクスペリエンスを検証することが可能になります。また、 [合成トランザクション](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)を使用することで、顧客より先に問題を発見できます。
## リソース
**関連するベストプラクティス:**
+ [REL11-BP03 すべてのレイヤーの修復を自動化する](rel_withstand_component_failures_auto_healing_system.md)
**関連するドキュメント:**
+ [Getting started with your AWS Health Dashboard – Your account health (AWS Health ダッシュボードの使用開始 - アカウントのヘルス)](https://docs.aws.amazon.com/health/latest/ug/getting-started-health-dashboard.html)
+ [CloudWatch メトリクスを発行する AWS のサービス](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html)
+ [Network Load Balancer のアクセスログ](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-access-logs.html)
+ [Application Load Balancer のアクセスログ](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-access-logs.html)
+ [Accessing Amazon CloudWatch Logs for AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-functions-logs.html)
+ [Amazon S3 サーバーアクセスのログ記録](https://docs.aws.amazon.com/AmazonS3/latest/dev/ServerLogs.html)
+ [Classic Load Balancer のアクセスログの有効化](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/enable-access-logs.html)
+ [Amazon S3 へのログデータのエクスポート](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/S3Export.html)
+ [CloudWatch エージェントを Amazon EC2 インスタンスにインストールする](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/install-CloudWatch-Agent-on-EC2-Instance.html)
+ [カスタムメトリクスの発行](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ [Amazon CloudWatch ダッシュボードの使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
+ [Using Amazon CloudWatch Metrics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)
+ [Canary の使用 (Amazon CloudWatch Synthetics)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [Amazon CloudWatch Logs とは](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)
**ユーザーガイド:**
+ [追跡の作成](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-a-trail-using-the-console-first-time.html)
+ [Amazon EC2 Linux インスタンスのメモリとディスクのメトリクスのモニタリング](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/mon-scripts.html)
+ [コンテナインスタンスでの CloudWatch Logs の使用](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_cloudwatch_logs.html)
+ [VPC フローログ](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/flow-logs.html)
+ [Amazon DevOps Guru とは](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html)
+ [「AWS X-Ray とは何ですか。」](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
**関連ブログ:**
+ [Debugging with Amazon CloudWatch Synthetics and AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/)
**関連する例とワークショップ:**
+ [AWS Well-Architected ラボ: 運用上の優秀性 - 依存関係のモニタリング](https://wellarchitectedlabs.com/operational-excellence/100_labs/100_dependency_monitoring/)
+ [The Amazon Builders' Library: 分散システムを装備して、運用の可視性を高める](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
+ [Observability workshop (可観測性ワークショップ)](https://catalog.workshops.aws/observability/en-US)
# REL06-BP02 メトリクスを定義および計算する (集計)
ログデータを保存し、必要に応じてフィルターを適用します。これにより、特定のログイベントのカウントや、ログイベントのタイムスタンプから計算されたレイテンシーなどのメトリクスを計算できます。
Amazon CloudWatch と Amazon S3 は、主要な集約レイヤーおよびストレージレイヤーとして機能します。AWS Auto Scaling や Elastic Load Balancing などの一部のサービスでは、クラスターまたはインスタンス全体の CPU 負荷または平均的なリクエストのレイテンシーについて、デフォルトのメトリクスが提供されます。VPC フローログや AWS CloudTrail などのストリーミングサービスの場合、イベントデータは CloudWatch Logs に転送されるため、メトリクスフィルターを定義して適用し、イベントデータからメトリクスを抽出する必要があります。これにより、時系列データが提供されます。これは、アラートをトリガーするために定義した CloudWatch アラームへの入力データとして機能します。
**このベストプラクティスが確立されていない場合のリスクレベル:** 高
## 実装のガイダンス
+ メトリクスを定義および計算します (集計)。特定のログイベントのカウントや、ログイベントのタイムスタンプから計算されたレイテンシーなどのメトリクスを計算するため、ログデータを保存し、必要に応じてフィルターを適用する
+ メトリクスフィルターは、CloudWatch Logs に送信されるログデータから検索する条件とパターンを定義します。CloudWatch Logs は、これらのメトリクスフィルターを使用して、ログデータを数値の CloudWatch メトリクスに変換し、グラフ化やアラームの設定を可能にします。
+ [ログデータの検索およびフィルタリング](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html)
+ 信頼できるサードパーティーを使用してログを集計します。
+ サードパーティーの指示に従います。ほとんどのサードパーティー製品は、CloudWatch および Amazon S3 と統合されています。
+ 一部の AWS のサービスでは、ログを直接 Amazon S3 に発行できます。ログを Amazon S3 に保存することが主な要件であれば、追加のインフラを設定することなく、ログを生成するサービスに直接 Amazon S3 に送信させることが簡単にできます。
+ [Sending Logs Directly to Amazon S3 (Amazon S3 へのログの直接送信)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Sending-Logs-Directly-To-S3.html)
## リソース
**関連するドキュメント:**
+ [Amazon CloudWatch Logs Insights Sample Queries](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax-examples.html)
+ [Debugging with Amazon CloudWatch Synthetics and AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/)
+ [1 つの可観測性ワークショップ](https://observability.workshop.aws/)
+ [ログデータの検索およびフィルタリング](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html)
+ [Sending Logs Directly to Amazon S3 (Amazon S3 へのログの直接送信)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Sending-Logs-Directly-To-S3.html)
+ [The Amazon Builders' Library: 分散システムを装備して、運用の可視性を高める](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
# REL06-BP03 通知を送信する (リアルタイム処理とアラーム)
重要なイベントが発生すると、把握する必要のある組織に通知が送信されます。
Amazon Simple Notification Service (Amazon SNS) トピックにアラートを送信し、任意の数の登録者にプッシュすることができます。例えば Amazon SNS では、E メールエイリアスにアラートを転送して、技術スタッフが対応できるようにしています。
**一般的なアンチパターン:**
+ 低すぎるしきい値でアラームを設定することで、多すぎる通知が送信される。
+ 今後の調査のためにアラームをアーカイブしない。
**このベストプラクティスを確立するメリット:** イベントの通知 (対応し、自動的に解決できるものであっても) により、イベントの記録を保持し、将来的に別の方法で対処できる場合があります。
**このベストプラクティスが確立されていない場合のリスクレベル:** 高
## 実装のガイダンス
+ リアルタイムの処理とアラームを実行します。重要なイベントが発生すると、把握しておく必要のある組織が通知を受信します
+ Amazon CloudWatch ダッシュボードは、CloudWatch コンソール内のカスタマイズ可能なホームページであり、これを使用すると、異なるリージョンにまたがっているリソースであっても、単一のビューでリソースをモニタリングできます。
+ [Amazon CloudWatch ダッシュボードの使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
+ メトリクスが制限を超える場合にアラームを作成します。
+ [Amazon CloudWatch アラームの使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
## リソース
**関連するドキュメント:**
+ [1 つの可観測性ワークショップ](https://observability.workshop.aws/)
+ [The Amazon Builders' Library: 分散システムを装備して、運用の可視性を高める](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
+ [Amazon CloudWatch アラームの使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Amazon CloudWatch ダッシュボードの使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
+ [Using Amazon CloudWatch Metrics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)
# REL06-BP04 レスポンスを自動化する (リアルタイム処理とアラーム)
自動化を使用して、イベントが検出されたときにアクションを実行します (例えば、障害が発生したコンポーネントを交換します)。
アラートは、クラスターが需要の変化に対応できるように、AWS Auto Scaling イベントをトリガーします。アラートは、サードパーティチケットシステムの統合ポイントとして機能する Amazon Simple Queue Service (Amazon SQS) に送信できます。AWS Lambda は、アラートをサブスクライブして、変更に対して動的に対応する非同期サーバーレスモデルをユーザーに提供することもできます。AWS Config は AWS リソースの構成を継続的にモニタリングして記録し、 [AWS Systems Manager Automation をトリガーして](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) 問題を修復できます。
Amazon DevOps Guru は、異常な動作についてアプリケーションリソースを自動的にモニタリングし、的を絞ったレコメンデーションを提供することにより、問題の識別を速めて修復時間を短縮します。
**このベストプラクティスを活用しない場合のリスクレベル:** ミディアム
## 実装のガイダンス
+ Amazon DevOps Guru を使用して、自動化アクションを実行します。Amazon DevOps Guru は、異常な動作についてアプリケーションリソースを自動的にモニタリングし、的を絞ったレコメンデーションを提供することにより、問題の識別を速めて修復時間を短縮します。
+ [「Amazon DevOps Guru とは何ですか?」](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html)
+ AWS Systems Manager を使用して、自動化アクションを実行します。AWS Config は AWS リソースの設定を継続的にモニタリングおよび記録し、AWS Systems Manager Automation をトリガーして問題を修復できます。
+ [AWS Systems Manager Automation をトリガーして](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ Systems Manager Automation ドキュメントを作成して使用します。これらは、オートメーションプロセスの実行時に Systems Manager がマネージドインスタンスおよび他の AWS リソースに対して実行するアクションを定義します。
+ [オートメーションドキュメント (プレイブック) の使用](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html)
+ Amazon CloudWatch は、状態変更イベントを Amazon EventBridge に警告します。EventBridge ルールを作成して、レスポンスを自動化します。
+ [AWS リソースからのイベントでトリガーする EventBridge ルールの作成](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-rule.html)
+ 応答を自動化する計画を作成して実行します。
+ すべてのアラート応答手順をインベントリします。タスクをランク付けする前に、アラートレスポンスを計画する必要があります。
+ 実行する必要がある特定のアクションを含むすべてのタスクをインベントリします。これらのアクションのほとんどは、ランブックに記載されています。また、予期しないイベントのアラートに対するプレイブックも必要です。
+ すべての自動化可能なアクションについて、ランブックとプレイブックを調べます。一般に、アクションを定義できる場合は、ほとんどの場合、自動化できます。
+ エラーが発生しやすいアクティビティや時間のかかるアクティビティを上位にランク付けます。エラーの原因を取り除き、解決までの時間を短縮することが最も有益です。
+ オートメーションを完了する計画を立てます。自動化と、自動化を更新するためのアクティブな計画を維持します。
+ オートメーションの機会に関する手動要件を調べます。手動プロセスの自動化機会に挑戦します。
## リソース
**関連するドキュメント:**
+ [AWS Systems Manager Automation をトリガーして](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [AWS リソースからのイベントでトリガーする EventBridge ルールの作成](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-rule.html)
+ [1 つの可観測性ワークショップ](https://observability.workshop.aws/)
+ [The Amazon Builders' Library: 分散システムを装備して、運用の可視性を高める](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
+ [「Amazon DevOps Guru とは何ですか?」](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html)
+ [オートメーションドキュメント (プレイブック) の使用](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html)
# REL06-BP05 分析
ログファイルとメトリクスの履歴を収集し、これらを分析して、幅広いトレンドとワークロードの洞察が得られます。
Amazon CloudWatch Logs Insights は、 [シンプルかつ強力なクエリ言語をサポートし、](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax.html) ログデータの分析に使用できます。Amazon CloudWatch Logs ではさらに、シームレスにデータを Amazon S3 に送ってデータを使用したり、または Amazon Athena に送ってデータをクエリしたりできるサブスクリプションもサポートしています。豊富な種類のフォーマットのクエリがサポートされています。把握 [サポートされる SerDes とデータ形式](https://docs.aws.amazon.com/athena/latest/ug/supported-format.html) 詳細については、Amazon Athena ユーザーガイドを参照してください。巨大なログファイルセットの分析では、Amazon EMR クラスターを実行してペタバイト規模の分析を実行できます。
集計、処理、保存、分析を実行できる多数のツールが AWS パートナーやサードパーティによって提供されています。このようなツールには、New Relic、Splunk、Loggly、Logstash、CloudHealth、Nagios などがあります。ただし、システムやアプリケーションログの外で行うデータ生成は各クラウドプロバイダーに固有であり、また多くの場合サービスごとに固有です。
モニタリングプロセスで見落とされがちな点は、データ管理です。モニタリングのためのデータ保存要件を決定し、それに応じたライフサイクルポリシーを適用する必要があります。Amazon S3 はS3 バケットレベルのライフサイクル管理をサポートしています。このライフサイクル管理には、バケット内のパスごとに異なる管理方法を適用できます。ライフサイクルの最終段階では、データを Amazon Glacier に移行して長期保存し、保存期間の終了後には期限切れにすることができます。S3 Intelligent-Tiering ストレージクラスは、パフォーマンスへの影響や運用のオーバーヘッドなしに、データを最も費用対効果の高いアクセス階層に自動的に移動することにより、コストを最適化できるように設計されています。
**このベストプラクティスを活用しない場合のリスクレベル:** ミディアム
## 実装のガイダンス
+ CloudWatch Logs Insights を使用すると、Amazon CloudWatch Logs でログデータをインタラクティブに検索して分析できます。
+ [CloudWatch Logs Insights を使用したログデータの分析](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_cloudwatch_logs.html)
+ [Amazon CloudWatch Logs Insights Sample Queries](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)
+ 使用できる場合は、Amazon CloudWatch Logs を使用してログを Amazon S3 に送信するか、Amazon Athena を使用してデータをクエリします。
+ [Athena を使用して Amazon S3 サーバーのアクセスログを分析するにはどうすればよいですか?](https://aws.amazon.com/premiumsupport/knowledge-center/analyze-logs-athena/)
+ サーバーアクセスログバケットの S3 ライフサイクルポリシーを作成します。ライフサイクルポリシーを設定して、定期的にログファイルを削除します。そうすることで、Athena が各クエリについて分析するデータ量が削減されます。
+ [S3 バケットのライフサイクルポリシーを作成する方法](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/create-lifecycle.html)
## リソース
**関連するドキュメント:**
+ [Amazon CloudWatch Logs Insights Sample Queries](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax-examples.html)
+ [CloudWatch Logs Insights を使用したログデータの分析](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_cloudwatch_logs.html)
+ [Debugging with Amazon CloudWatch Synthetics and AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/)
+ [S3 バケットのライフサイクルポリシーを作成する方法](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/create-lifecycle.html)
+ [Athena を使用して Amazon S3 サーバーのアクセスログを分析するにはどうすればよいですか?](https://aws.amazon.com/premiumsupport/knowledge-center/analyze-logs-athena/)
+ [1 つの可観測性ワークショップ](https://observability.workshop.aws/)
+ [The Amazon Builders' Library: 分散システムを装備して、運用の可視性を高める](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
# REL06-BP06 定期的にレビューを実施する
ワークロードモニタリングがどのように実装されているかを頻繁に確認し、重要なイベントや変更に基づいて更新します。
効果的なモニタリングは、主要なビジネスメトリクスが原動力になります。ビジネスの優先順位が変化したときに、メトリクスがワークロードに確実に対応できるようにします。
モニタリングを監査することで、アプリケーションがどのタイミングで可用性の目標を満たしているかを確実に把握できます。根本原因の分析には、障害発生時に何が起こったかを発見する機能が必要です。AWS は、インシデント時にサービスの状態を追跡できるサービスを提供しています。
+ **Amazon CloudWatch Logs:** このサービスにログを保存してその内容を調査できます。
+ **Amazon CloudWatch Logs Insights**: 数秒で大量のログを分析できるフルマネージドサービスです。高速でインタラクティブなクエリと視覚化が行えます。
+ **AWS Config:** さまざまな時点でどの AWS インフラストラクチャが使用されているかを確認できます。
+ **AWS CloudTrail:** どの AWS API が、いつどのプリンシパルに呼び出されたかを確認できます。
AWS では、週に一度のミーティングを実施して、 [運用パフォーマンスをレビューし、](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html) 学んだ教訓をチーム間で共有しています。AWS には多数のチームが存在するため、 [私たちは The Wheel を作成し、](https://aws.amazon.com/blogs/opensource/the-wheel/) ワークロードをランダムに選んで確認できるようにしました。運用パフォーマンスのレビューと知識の共有を定期的に行うことで、運用チームのパフォーマンスを向上させることができます。
**一般的なアンチパターン:**
+ デフォルトのメトリクスのみを収集する。
+ モニタリング戦略を設定し、見直さない。
+ 主要な変更がデプロイされる際に、モニタリングについて話し合わない。
**このベストプラクティスを活用するメリット:** モニタリングを定期的にレビューすることで、予期される問題が実際に発生したときに通知に反応する代わりに、潜在的な問題を予測できるようになります。
**このベストプラクティスを活用しない場合のリスクレベル:** ミディアム
## 実装のガイダンス
+ ワークロード用に複数のダッシュボードを作成します。主要なビジネスメトリクスと、使用状況の変化に応じて予測されるワークロードの状態に最も関連性があるものとして特定した技術メトリクスを含む最上位のダッシュボードが必要です。また、検査が可能なさまざまなアプリケーション層や依存関係のダッシュボードも必要があります。
+ [Amazon CloudWatch ダッシュボードの使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
+ ワークロードダッシュボードの定期的なレビューをスケジュールし、実施します。ダッシュボードの定期的な検査を行います。検査する深度に応じて異なる頻度にすることができます。
+ メトリクスの傾向を検査します。メトリクス値と履歴値を比較して、調査が必要なものを示唆している可能性がある傾向があるかどうかを確認します。これには、レイテンシーの増加、主要なビジネス機能の減少、失敗レスポンスの増加などがあります。
+ メトリクスの外れ値/異常を検査します。平均値または中央値は、外れ値と異常値を覆い隠すことがあります。期間中の最大値と最低値を調べ、極端なスコアの原因を調査します。これらの原因の排除を続行しながら、極値の定義を低くしていくことで、ワークロードパフォーマンスの一貫性を継続して向上させることができます。
+ 行動の急変を探します。メトリクスの数量または方向性の突然の変化は、アプリケーションに変更があったこと、または追跡するためにさらなるメトリクスを追加する必要がある外部要因があることを示唆している可能性があります。
## リソース
**関連するドキュメント:**
+ [Amazon CloudWatch Logs Insights Sample Queries](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax-examples.html)
+ [Debugging with Amazon CloudWatch Synthetics and AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/)
+ [1 つの可観測性ワークショップ](https://observability.workshop.aws/)
+ [The Amazon Builders' Library: 分散システムを装備して、運用の可視性を高める](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
+ [Amazon CloudWatch ダッシュボードの使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
# REL06-BP07 システムを通じたリクエストのエンドツーエンドのトレースをモニタリングする
AWS X-Ray またはサードパーティ製のツールを使用することで、デベロッパーは分散システムの分析とデバッグをより簡単に行い、アプリケーションとその基盤となるサービスのパフォーマンスを把握できます。
**このベストプラクティスを活用しない場合のリスクレベル:** ミディアム
## 実装のガイダンス
+ システムを通じたリクエストのエンドツーエンドのトレースをモニタリングします。AWS X-Ray は、アプリケーションが処理するリクエストに関するデータを収集するサービスであり、データの表示、フィルタリング、インサイトの取得によって、問題や最適化の機会を特定するためのツールを提供します。アプリケーションへのトレースされたリクエストについて、リクエストとレスポンスだけでなく、アプリケーションがダウンストリーム AWS リソース、マイクロサービス、データベース、ウェブ API に対して行う呼び出しに関する詳細情報も確認できます。
+ [「AWS X-Ray とは何ですか。」](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
+ [Debugging with Amazon CloudWatch Synthetics and AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/)
## リソース
**関連するドキュメント:**
+ [Debugging with Amazon CloudWatch Synthetics and AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/)
+ [1 つの可観測性ワークショップ](https://observability.workshop.aws/)
+ [The Amazon Builders' Library: 分散システムを装備して、運用の可視性を高める](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
+ [模擬モニタリングの使用 (Amazon CloudWatch Synthetics)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [「AWS X-Ray とは何ですか。」](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
# REL 7 需要の変化に適応するようにワークロードを設計するには、どうすればよいですか?
スケーラブルなワークロードには、リソースを自動で追加または削除する伸縮性があるので、リソースは常に、現行の需要に厳密に適合します。
**Topics**
+ [REL07-BP01 リソースの取得またはスケーリング時に自動化を使用する](rel_adapt_to_changes_autoscale_adapt.md)
+ [REL07-BP02 ワークロードの障害を検出したときにリソースを取得する](rel_adapt_to_changes_reactive_adapt_auto.md)
+ [REL07-BP03 ワークロードにより多くのリソースが必要であることを検出した時点でリソースを取得する](rel_adapt_to_changes_proactive_adapt_auto.md)
+ [REL07-BP04 ワークロードの負荷テストを実施する](rel_adapt_to_changes_load_tested_adapt.md)
# REL07-BP01 リソースの取得またはスケーリング時に自動化を使用する
障害のあるリソースを交換したり、ワークロードをスケーリングしたりする場合は、Amazon S3 や AWS Auto Scaling などのマネージド型の AWS のサービスを使用してプロセスを自動化します。サードパーティのツールや AWS SDK を使用して、スケーリングを自動化することもできます。
マネージド型の AWS のサービスとしては、Amazon S3、Amazon CloudFront、AWS Auto Scaling、AWS Lambda、Amazon DynamoDB、AWS Fargate、および Amazon Route 53 があります。
AWS Auto Scaling では、障害のあるインスタンスを検出して置き換えることができます。また、以下を含むリソースのスケーリングプランを構築することもできます。 [Amazon EC2](https://aws.amazon.com/ec2/) インスタンスとスポットフリート、 [Amazon ECS](https://aws.amazon.com/ecs/) タスク、 [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) テーブルとインデックス、および [Amazon Aurora](https://aws.amazon.com/aurora/) レプリカ。
EC2 インスタンスをスケーリングする場合は、複数のアベイラビリティゾーン (できれば少なくとも 3 つ) を使用し、容量を追加または削除して、これらのアベイラビリティゾーン間のバランスを維持します。ECS タスクまたは Kubernetes ポッド (Amazon Elastic Kubernetes Service を使用しているとき) も複数のアベイラビリティゾーンに分散してください。
AWS Lambda を使用しているときには、インスタンスは自動的にスケーリングされます。AWS Lambda は、関数のイベント通知を受信するたびに、コンピューティングフリート内の空き容量をすばやく見つけ、割り当てられた同時実行数までコードを実行します。特定の Lambda とService Quotas で、必要な同時実行数が確実に設定されているようにしてください。
Amazon S3 は、高いリクエスト頻度を処理できるように自動的にスケーリングします。たとえば、アプリケーションはバケット内のプレフィックスごとに 1 秒あたり 3,500 件以上の PUT/COPY/POST/DELETE リクエストまたは 5,500 件以上の GET/HEAD リクエストを送信できます。バケット内のプレフィックス数に制限はありません。読み取りを並列化することで、読み取りまたは書き込みのパフォーマンスを向上させることができます。例えば、Amazon S3 バケットに 10 個のプレフィックスを作成して読み取りを並列化する場合、読み取りパフォーマンスを 1 秒あたり 55,000 件の読み取りリクエストにスケーリングできます。
Amazon CloudFront または信頼できるコンテンツ配信ネットワーク (CDN) を設定して使用します。CDN は、より迅速なエンドユーザーレスポンスタイムを提供でき、コンテンツのリクエストをキャッシュから処理できるため、ワークロードをスケーリングする必要性が少なくなります。
**一般的なアンチパターン:**
+ 自動ヒーリングのために Auto Scaling グループを実装しますが、伸縮性は実装しません。
+ トラフィックの大幅な増加に対応するために自動スケーリングを使用する。
+ ステートフル性が高いアプリケーションをデプロイし、伸縮性を排除する。
**このベストプラクティスを活用するメリット:** 自動化により、リソースのデプロイと廃棄で手動エラーが発生する可能性がなくなります。自動化は、デプロイや廃棄のニーズへの応答が遅いことによるコストの超過やサービス拒否のリスクを排除します。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
+ AWS Auto Scaling を設定して使用します。これにより、アプリケーションをモニタリングし、安定した予測可能なパフォーマンスを可能な限り低いコストで維持するためのキャパシティーを自動的に調整します。AWS Auto Scaling を使用すると、複数のサービスにまたがる複数のリソースに対してアプリケーションのスケーリングをセットアップできます。
+ [「AWS Auto Scaling とは何ですか?」](https://docs.aws.amazon.com/autoscaling/plans/userguide/what-is-aws-auto-scaling.html)
+ Amazon EC2 インスタンスとスポットフリート、Amazon ECS タスク、Amazon DynamoDB のテーブルとインデックス、Amazon Aurora のレプリカ、および AWS Marketplace アプライアンスなど、該当する者に対して Auto Scaling を設定します。
+ [DynamoDB Auto Scaling によるスループットキャパシティの自動管理](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html)
+ サービス API を操作して、アラーム、スケーリングポリシー、ウォームアップ時間、およびクールダウン時間を指定します。
+ Elastic Load Balancing を使用します。ロードバランサーは、パスまたはネットワーク接続ごとに負荷を分散することができます。
+ [「Elastic Load Balancing とは何ですか?」](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html)
+ Application Load Balancers は、負荷をパスごとに分散できます。
+ [Application Load Balancer とは?](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html)
+ Application Load Balancer を設定して、ドメイン名の下のパスに基づいてトラフィックをさまざまなワークロードに分散します。
+ Application Load Balancers を使用すると、AWS Auto Scaling と統合して需要を管理するという方法で負荷を分散できます。
+ [Auto Scaling グループでロードバランサーを使用する](https://docs.aws.amazon.com/autoscaling/ec2/userguide/autoscaling-load-balancer.html)
+ Network Load Balancers は、接続ごとに負荷を分散することができます。
+ [Network Load Balancer とは?](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html)
+ Network Load Balancer は、TCP を使用してトラフィックをさまざまなワークロードに分散するか、ワークロードの IP アドレスの一定のセットが含まれるように設定します。
+ Network Load Balancer を使用すると、AWS Auto Scaling と統合して需要を管理するという方法で負荷を分散できます。
+ 可用性の高い DNS プロバイダーを使用します。DNS 名により、ユーザーは、IP アドレスの代わりに DNS 名を入力してワークロードにアクセスでき、この情報を、定義されたスコープ (通常はワークロードのユーザーに対してグローバルに定義されたスコープ) に分散できます。
+ Amazon Route 53 または信頼できる DNS プロバイダーを使用します。
+ [「Amazon Route 53 とは何ですか?」](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html)
+ Route 53 を使用して、CloudFront ディストリビューションとロードバランサーを管理します。
+ 管理する予定のドメインとサブドメインを決定します。
+ ALIAS レコードまたは CNAME レコードを使用して適切なレコードセットを作成します。
+ [レコードの操作](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/rrsets-working-with.html)
+ AWS グローバルネットワークを使用して、ユーザーからアプリケーションへのパスを最適化します。AWS Global Accelerator は、アプリケーションエンドポイントの状態を継続的にモニタリングし、トラフィックを 30 秒未満で正常なエンドポイントにリダイレクトします。
+ AWS Global Accelerator は、ローカルまたはグローバルユーザーが使用するアプリケーションの可用性とパフォーマンスを向上させるサービスです。Application Load Balancers、Network Load Balancer、Amazon EC2 インスタンスなど、単一または複数の AWS リージョンのアプリケーションエンドポイントへの固定エントリポイントとして機能する静的 IP アドレスが提供されます。
+ [AWS Global Accelerator とは?](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html)
+ Amazon CloudFront または信頼できるコンテンツ配信ネットワーク (CDN) を設定して使用します。コンテンツ配信ネットワークは、エンドユーザーの応答時間を短縮し、ワークロードの不要なスケーリングを引き起こす原因となるコンテンツのリクエストを処理できます。
+ [「Amazon CloudFront とは」](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html)
+ ワークロード用の Amazon CloudFront ディストリビューションを設定するか、サードパーティの CDN を使用します。
+ エンドポイントセキュリティグループまたはアクセスポリシーで CloudFront の IP 範囲を使用することで、ワークロードへのアクセスを CloudFront からのみに制限できます。
## リソース
**関連するドキュメント:**
+ [APN Partner: partners that can help you create automated compute solutions](https://aws.amazon.com/partners/find/results/?facets=%27Product%20:%20Compute%27)
+ [AWS Auto Scaling: スケーリングプランの仕組み](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ [AWS Marketplace: Auto Scaling で使用できる製品](https://aws.amazon.com/marketplace/search/results?searchTerms=Auto+Scaling)
+ [Managing Throughput Capacity Automatically with DynamoDB Auto Scaling](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html)
+ [Auto Scaling グループでロードバランサーを使用する](https://docs.aws.amazon.com/autoscaling/ec2/userguide/autoscaling-load-balancer.html)
+ [AWS Global Accelerator とは?](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html)
+ [「What Is Amazon EC2 Auto Scaling?」](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
+ [「AWS Auto Scaling とは何ですか?」](https://docs.aws.amazon.com/autoscaling/plans/userguide/what-is-aws-auto-scaling.html)
+ [「Amazon CloudFront とは」](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html?ref=wellarchitected)
+ [「Amazon Route 53 とは何ですか?」](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html)
+ [「Elastic Load Balancing とは何ですか?」](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html)
+ [Network Load Balancer とは?](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html)
+ [Application Load Balancer とは?](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html)
+ [レコードの操作](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/rrsets-working-with.html)
# REL07-BP02 ワークロードの障害を検出したときにリソースを取得する
可用性が影響を受ける場合、必要に応じてリソースをリアクティブにスケールし、ワークロードの可用性を復元します。
まず、ヘルスチェックとこのチェックの基準を設定して、リソースの不足が可用性に影響を与えるタイミングを示す必要があります。次に、適切な担当者に通知してリソースを手動でスケーリングするか、自動操作をトリガーしてリソースを自動的にスケーリングします。
スケーリングはワークロードに合わせて手動で調整できます。例えば、Auto Scaling グループの EC2 インスタンスの数の変更や、DynamoDB テーブルのスループットの変更は、AWS マネジメントコンソール または AWS CLI で行うことができます。ただし、可能な限りオートメーションを使用する必要があります (詳細は **リソースの取得またはスケーリング時に自動化を使用する**) を指定する必要があります。
**このベストプラクティスを活用しない場合のリスクレベル:** ミディアム
## 実装のガイダンス
+ ワークロードの障害を検出したときにリソースを取得します。可用性が影響を受ける場合、必要に応じてリソースをリアクティブにスケールし、ワークロードの可用性を復元します。
+ AWS Auto Scaling のコアコンポーネントであるスケーリングプランを使用して、リソースをスケーリングするための一連の指示を設定します。AWS CloudFormation を操作する場合や、タグを AWS リソースに追加する場合、アプリケーションごとに、さまざまなリソースセットのスケーリングプランをセットアップできます。AWS Auto Scaling は各リソースに応じてカスタマイズされたスケーリング戦略についてレコメンデーションを提供します。スケーリングプランを作成すると、AWS Auto Scaling は、動的スケーリングと予測スケーリング方法を組み合わせて、スケーリング戦略をサポートします。
+ [AWS Auto Scaling: スケーリングプランの仕組み](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ Amazon EC2 Auto Scaling を使用すると、アプリケーションの負荷を処理するための正しい数の Amazon EC2 インスタンスを利用できます。Auto Scaling グループと呼ばれる EC2 インスタンスのコレクションを作成します。各 Auto Scaling グループのインスタンスの最小数を指定でき、Amazon EC2 Auto Scaling では、グループがこのサイズを下回ることはありません。各 Auto Scaling グループのインスタンスの最小数を指定でき、Amazon EC2 Auto Scaling では、グループがこのサイズを上回ることはありません。
+ [「What Is Amazon EC2 Auto Scaling?」](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
+ Amazon DynamoDB Auto Scaling は、AWS Application Auto Scaling サービスを使用して、実際のトラフィックパターンに応じて、お客様に代わってプロビジョニングされたスループットキャパシティを動的に調整します。これにより、テーブルまたはグローバルセカンダリインデックスは、プロビジョニングされた読み込みおよび書き込みキャパシティーを増やすことができ、スロットリングなしでトラフィックの急激な増加を処理できます。
+ [Managing Throughput Capacity Automatically with DynamoDB Auto Scaling](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html)
## リソース
**関連するドキュメント:**
+ [APN Partner: partners that can help you create automated compute solutions](https://aws.amazon.com/partners/find/results/?facets=%27Product%20:%20Compute%27)
+ [AWS Auto Scaling: スケーリングプランの仕組み](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ [AWS Marketplace: Auto Scaling で使用できる製品](https://aws.amazon.com/marketplace/search/results?searchTerms=Auto+Scaling)
+ [Managing Throughput Capacity Automatically with DynamoDB Auto Scaling](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html)
+ [「What Is Amazon EC2 Auto Scaling?」](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
# REL07-BP03 ワークロードにより多くのリソースが必要であることを検出した時点でリソースを取得する
需要に合わせてリソースをプロアクティブにスケールし、可用性への影響を回避します。
多くの AWS サービスは、需要に合わせて自動的にスケールします。Amazon EC2 インスタンスまたは Amazon ECS クラスターを使用している場合、ワークロードの需要に対応する使用状況のメトリクスに基づいて Auto Scaling を実行するように設定できます。Amazon EC2 では、平均 CPU 使用率、ロードバランサーリクエスト数、またはネットワーク帯域幅を使用して、EC2 インスタンスをスケールアウト (またはスケールイン) できます。Amazon ECS では、平均 CPU 使用率、ロードバランサーリクエスト数、およびメモリ使用率を使用して、ECS タスクをスケールアウト (またはスケールイン) できます。AWS で Target Auto Scaling を使用すると、オートスケーラーは家庭用サーモスタットのように機能し、指定したターゲット値 (例えば、CPU 使用率 70%) を維持するためにリソースを追加または削除します。
AWS Auto Scaling はまた、 [Predictive Auto Scaling ](https://aws.amazon.com/blogs/aws/new-predictive-scaling-for-ec2-powered-by-machine-learning/)も実行できます。これは、機械学習を使用して各リソースの過去のワークロードを分析し、次の 2 日間の負荷を定期的に予測します。
リトルの法則は、必要なコンピューティングインスタンス (EC2 インスタンス、同時実行の Lambda 関数など) 数を計算するのに役立ちます。
*L* = *λW*
L = インスタンス数 (またはシステムの平均同時実行数)
λ = リクエストが到着する平均レート (リクエスト/秒)
W = 各リクエストがシステムで費やす平均時間 (秒)
例えば、100 rps では、各リクエストの処理に 0.5 秒かかる場合、需要に対応するには 50 インスタンスが必要です。
**このベストプラクティスを活用しない場合のリスクレベル:** ミディアム
## 実装のガイダンス
+ ワークロードにより多くのリソースが必要であることを検出した時点でリソースを取得します。需要に合わせてリソースをプロアクティブにスケールし、可用性への影響を回避します。
+ 特定のリクエストレートを処理するために必要なコンピューティングリソースの数 (コンピューティングの同時実行) を計算します。
+ [リトルの法則について語る](https://brooker.co.za/blog/2018/06/20/littles-law.html)
+ 使用状況の履歴パターンがあるときには、Amazon EC2 Auto Scaling のスケジュールされたスケーリングをセットアップします。
+ [Amazon EC2 Auto Scaling のスケジュールされたスケーリング](https://docs.aws.amazon.com/autoscaling/ec2/userguide/schedule_time.html)
+ AWS 予測スケーリングを使用します。
+ [機械学習を利用した EC2 の予測スケーリング](https://aws.amazon.com/blogs/aws/new-predictive-scaling-for-ec2-powered-by-machine-learning/)
## リソース
**関連するドキュメント:**
+ [AWS Auto Scaling: スケーリングプランの仕組み](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ [AWS Marketplace: Auto Scaling で使用できる製品](https://aws.amazon.com/marketplace/search/results?searchTerms=Auto+Scaling)
+ [Managing Throughput Capacity Automatically with DynamoDB Auto Scaling](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html)
+ [機械学習を利用した EC2 の予測スケーリング](https://aws.amazon.com/blogs/aws/new-predictive-scaling-for-ec2-powered-by-machine-learning/)
+ [Amazon EC2 Auto Scaling のスケジュールされたスケーリング](https://docs.aws.amazon.com/autoscaling/ec2/userguide/schedule_time.html)
+ [リトルの法則について語る](https://brooker.co.za/blog/2018/06/20/littles-law.html)
+ [「What Is Amazon EC2 Auto Scaling?」](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
# REL07-BP04 ワークロードの負荷テストを実施する
負荷テスト手法を採用して、スケーリングアクティビティがワークロード要件を満たすかどうかを測定します。
持続的な負荷テストを実行することが重要です。負荷テストによって、ブレークポイントを発見し、ワークロードのパフォーマンスをテストします。AWS は、生産ワークロードのスケールをモデル化する一次的なテスト環境のセットアップを容易にします。クラウド上では、本稼働スケールのテスト環境をオンデマンドで作成し、テスト完了後にリソースを解放できます。テスト環境の⽀払いは実⾏時にのみ発⽣するため、オンプレミスでテストを実施する場合と比べてわずかなコストで、本番環境をシミュレートできます。
本番環境での負荷テストは、ゲームデーの一部として考える必要もあります。その中で、顧客の使用率が低い時間帯に本番システムに負荷をかけ、担当者全員がテスト結果を解釈して発生した問題に対処できるようにします。
**一般的なアンチパターン:**
+ 本稼働環境と同じ設定ではないデプロイで負荷テストを実行する。
+ ワークロード全体ではなく、ワークロードの個々の部分に対してのみ負荷テストを実行する。
+ 実際のリクエストの代表的なセットではなく、リクエストのサブセットを使用して負荷テストを実行する。
+ 予想される負荷を超える小さな安全率に対して負荷テストを実行する。
**このベストプラクティスを活用するメリット:** 負荷がかかっているときにアーキテクチャのどのコンポーネントが失敗するかを把握し、問題に対処すべく、その負荷が近づいていることを示すために監視するメトリクスを特定し、その障害の影響を防ぐことができます。
**このベストプラクティスを活用しない場合のリスクレベル:** ミディアム
## 実装のガイダンス
+ 負荷テストを実行して、キャパシティを追加または削除する必要があるワークロードの側面を特定します。負荷テストには、本稼働環境で受け取るものと同様の代表的なトラフィックを用いる必要があります。設定したメトリクスを監視しながら負荷を増やし、リソースを追加または削除する必要があるタイミングをどのメトリクスが示唆しているのかを判断します。
+ [AWS での分散負荷テスト: 接続された数千のユーザーをシミュレートする](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/)
+ リクエストの組み合わせを特定します。なされるリクエストの組み合わせはさまざまであるため、トラフィックの混在を組み合わせを特定する際は、さまざまな時間枠を確認する必要があります。
+ ロードドライバーを実装します。カスタムコード、オープンソース、または商用ソフトウェアを使用して、ロードドライバーを実装できます。
+ 最初は小さなキャパシティを使用して負荷テストを実施します。1 つのインスタンスまたはコンテナと同じくらいの少なさのキャパシティーに負荷をかけることで、すぐに効果が現れます。
+ 大きなキャパシティに対して負荷テストを実施します。この効果は分散された負荷によって異なるため、できるだけ製品環境に近いに対してテストする必要があります。
## リソース
**関連するドキュメント:**
+ [AWS での分散負荷テスト: 接続された数千のユーザーをシミュレートする](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/)
# REL 8 変更はどのように実装するのですか?
変更制御は、新しい機能をデプロイしたり、アプリケーションと運用環境で既知のソフトウェアが実行されており、予測できる方法でパッチを適用または置換できることを確認したりするために必要です。変更が制御されていないと、変更の影響を予測したり、変更によって発生した問題に対処したりすることが困難になります。
**Topics**
+ [REL08-BP01 デプロイなどの標準的なアクティビティにランブックを使用する](rel_tracking_change_management_planned_changemgmt.md)
+ [REL08-BP02 デプロイの一部として機能テストを統合する](rel_tracking_change_management_functional_testing.md)
+ [REL08-BP03 デプロイの一部として回復力テストを統合する](rel_tracking_change_management_resiliency_testing.md)
+ [REL08-BP04 イミュータブルなインフラストラクチャを使用してデプロイする](rel_tracking_change_management_immutable_infrastructure.md)
+ [REL08-BP05 オートメーションを使用して変更をデプロイする](rel_tracking_change_management_automated_changemgmt.md)
# REL08-BP01 デプロイなどの標準的なアクティビティにランブックを使用する
ランブックは、特定の成果を達成するための事前定義された手順です。手動または自動のどちらでも、標準的なアクティビティを実行するにはランブックを使用します。例えば、ワークロードのデプロイ、ワークロードへのパッチの適用、DNS の変更などがあります。
例えば、デプロイ中のロールバックの安全性を [確保するためのプロセスを導入します](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments)。顧客側の中断なしでデプロイをロールバックできるようにすることは、サービスの信頼性を高める上で重要です。
ランブックの手順については、有効で効果的な手動プロセスから開始し、それをコードで実装して、適切な場合は自動実行をトリガーします。
高度に自動化された高機能のワークロードの場合でも、ランブックは [本番環境で実行したり、](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/test-reliability.html#GameDays) 厳格なレポートや監査の要件を満たしたりするのに役立ちます。
プレイブックは特定のインシデントに対応するために用いられ、ランブックは特定の結果を達成するために使用されます。多くの場合、ランブックは日常的なアクティビティ用で、プレイブックは非日常的なイベントに応えるために使用します。
**一般的なアンチパターン:**
+ 本稼働環境の設定に対して、計画されていない変更を実行する。
+ デプロイを高速化するために計画の手順をスキップすることで、デプロイを失敗させる。
+ 変更を戻すことができるかどうかをテストせずに変更を加える。
**このベストプラクティスを確立するメリット:** 効果的な変更計画は、影響を受けるすべてのシステムを考慮しているため、変更を正常に実行する能力を強化します。テスト環境で変更を検証すると、信頼が強化されます。
**このベストプラクティスが確立されていない場合のリスクレベル:** 高
## 実装のガイダンス
+ ランブックに手順を文書化することにより、一貫性を保ち、汎用イベントにすみやかに対応できるようになります。
+ [AWS Well-Architected Framework: Concepts: Runbook (AWS Well-Architected フレームワーク: 概念: ランブック)](https://wa.aws.amazon.com/wat.concept.runbook.en.html)
+ Infrastructure as Code の原則を適用して、インフラストラクチャを定義します。AWS CloudFormation (または信頼できるサードパーティ) を使用してインフラストラクチャを定義することにより、バージョン管理ソフトウェアを使用して、バージョン管理および変更の追跡を行うことができます。
+ AWS CloudFormation (または信頼できるサードパーティプロバイダー) を使用して、インフラストラクチャを定義します。
+ [AWS CloudFormation とは](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)
+ 優れたソフトウェア設計の原則を使用して、単一または分離されたテンプレートを作成します。
+ 実装にあたって、必要な権限、テンプレート、責任者を決定します。
+ [AWS Identity and Access Management によるアクセスの制御 ](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-iam-template.html)
+ バージョン管理には、AWS CodeCommit や信頼できるサードパーティ製ツールのようなバージョン管理用ソースコントロールを使用します。
+ [AWS CodeCommit とは](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html)
## リソース
**関連するドキュメント:**
+ [APN パートナー: 自動化されたデプロイソリューションの作成を支援できるパートナー](https://aws.amazon.com/partners/find/results/?keyword=devops)
+ [AWS Marketplace: products that can be used to automate your deployments](https://aws.amazon.com/marketplace/search/results?searchTerms=DevOps)
+ [AWS Well-Architected Framework: Concepts: Runbook (AWS Well-Architected フレームワーク: 概念: ランブック)](https://wa.aws.amazon.com/wat.concept.runbook.en.html)
+ [AWS CloudFormation とは](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)
+ [AWS CodeCommit とは](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html)
**関連する例:**
+ [Automating operations with Playbooks and Runbooks (プレイブックとランブックによるオペレーションの自動化)](https://wellarchitectedlabs.com/operational-excellence/200_labs/200_automating_operations_with_playbooks_and_runbooks/)
# REL08-BP02 デプロイの一部として機能テストを統合する
機能テストは、自動デプロイの一部として実行されます。成功条件を満たさない場合、パイプラインは停止またはロールバックされます。
このようなテストは、パイプラインの本番稼働前にステージングされた本番稼働前環境で実行されます。これは、デプロイパイプラインの一部として行うのが理想的です。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
+ デプロイの一部として機能テストを統合します。機能テストは、自動デプロイの一部として実行されます。成功条件を満たさない場合、パイプラインは停止またはロールバックされます。
+ AWS CodePipeline でモデル化されたソフトウェアリリースパイプラインの「テストアクション」中に AWS CodeBuild を呼び出します。この機能により、ユニットテスト、静的コード分析、統合テストなど、コードに対してさまざまなテストを簡単に実行できます。
+ [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/solutions/devops/software-test-automation)
## リソース
**関連するドキュメント:**
+ [AWS CodePipeline が、AWS CodeBuild を使用したユニットテストおよびカスタム統合テストのサポートを追加](https://aws.amazon.com/about-aws/whats-new/2017/03/aws-codepipeline-adds-support-for-unit-testing/)
+ [ソフトウェアテストのオートメーション](https://aws.amazon.com/marketplace/solutions/devops/software-test-automation)
+ [「AWS CodePipeline とは何ですか?」](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html)
# REL08-BP03 デプロイの一部として回復力テストを統合する
回復力テスト ( [カオスエンジニアリングの原則](https://principlesofchaos.org/)を使用した) は、本番稼働前環境で自動デプロイパイプラインの一部として実行されます。
このようなテストはステージングされ、本番稼働前にパイプラインで実行されます。ゲームデーの一部としても実行してください。 [https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/test-reliability.html#GameDays](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/test-reliability.html#GameDays).
**このベストプラクティスを活用しない場合のリスクレベル:** ミディアム
## 実装のガイダンス
+ デプロイの一部として回復力テストを統合します。ワークロードの実験規律であるカオスエンジニアリングを使用して、本番環境での絶えず変化する条件に耐えるワークロードの能力に信頼を築きます。
+ 回復力テストでは、障害やリソースの低下を挿入して、設計した回復力をもってワークロードが応答することを評価します。
+ [Well-Architected ラボ: レベル 300: EC2 RDS と S3 の回復力をテストする](https://wellarchitectedlabs.com/Reliability/300_Testing_for_Resiliency_of_EC2_RDS_and_S3/README.html)
+ これらのテストは、自動デプロイパイプラインの本番稼働前の環境で定期的に実行できます。
+ また、スケジュールされたゲームデーの一環として、本稼働環境で実行する必要があります。
+ カオスエンジニアリングの原則を使用して、さまざまな障害下でワークロードがどのように実行されるかについての仮説を提案し、回復力テストを使用して仮説をテストします。
+ [カオスエンジニアリングの原則](https://principlesofchaos.org/)
## リソース
**関連するドキュメント:**
+ [カオスエンジニアリングの原則](https://principlesofchaos.org/)
+ [AWS Fault Injection Simulator とは?](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html)
**関連する例:**
+ [Well-Architected ラボ: レベル 300: EC2 RDS と S3 の回復力をテストする](https://wellarchitectedlabs.com/Reliability/300_Testing_for_Resiliency_of_EC2_RDS_and_S3/README.html)
# REL08-BP04 イミュータブルなインフラストラクチャを使用してデプロイする
イミュータブルなインフラストラクチャは、本番ワークロードで更新、セキュリティパッチ、または設定変更がインプレースで行われないように義務付けるモデルです。変更が必要な場合、アーキテクチャは新しいインフラストラクチャに構築され、本番環境にデプロイされます。
イミュータブルインフラストラクチャパラダイムを実装したものとして最も一般的なのが、 ***イミュータブルサーバーです***。つまり、サーバーに更新または修正が必要な場合、既存のサーバーを更新するのではなく、新しいサーバーをデプロイします。そのため、アプリケーションのすべての変更は、SSH 経由でサーバーにログインしてソフトウェアバージョンを更新するのではなく、コードリポジトリにソフトウェアをプッシュすることから始まります (たとえば git push)。イミュータブルインフラストラクチャでは変更が許可されていないため、デプロイされたシステムの状態をしっかりと把握します。イミュータブルインフラストラクチャは、本質的に一貫性があり、信頼性が高く、予測可能であり、ソフトウェアの開発と運用の多くの側面を簡素化します。
イミュータブルインフラストラクチャにアプリケーションをデプロイする場合は、Canary デプロイまたはブルー/グリーンデプロイを使用します。
[https://martinfowler.com/bliki/CanaryRelease.html](https://martinfowler.com/bliki/CanaryRelease.html) は、通常は単一のサービスインスタンス (Canary) で実行される新しいバージョンに、少数の顧客を誘導する方法です。次に、生じた動作の変更やエラーを詳細に調べます。重大な問題が発生した場合、Canary からトラフィックを削除して、ユーザーを以前のバージョンに戻すことができます。デプロイが成功したら、変更やエラーをモニタリングしながら、希望の速度で完全にデプロイされるまでデプロイを続行できます。AWS CodeDeploy では、デプロイ設定で Canary デプロイを有効にすることでことができます。
[https://martinfowler.com/bliki/BlueGreenDeployment.html](https://martinfowler.com/bliki/BlueGreenDeployment.html) は Canary デプロイに似ていますが、アプリケーション全体が並行してデプロイされる点が異なります。2 つのスタック (青と緑) 間でデプロイを交互に行います。この場合も、トラフィックを新しいバージョンに送信したときにデプロイに問題が発生した場合は、古いバージョンにフォールバックできます。通常、すべてのトラフィックが一度に切り替えられますが、各バージョンへのトラフィックの一部を使用し、Amazon Route 53 の加重 DNS ルーティング機能を使用して、新しいバージョンの採用をダイヤルアップすることもできます。AWS CodeDeploy と AWS Elastic Beanstalk は、ブルー/グリーンデプロイを有効にするデプロイ構成で設定できます。
![\[AWS Elastic Beanstalk と Amazon Route 53 によるブルー/グリーンデプロイを示す図\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2022-03-31/framework/images/blue-green-deployment.png)
イミュータブルインフラストラクチャの利点:
+ **設定ドリフトの削減:** サーバーをバージョン管理された既知の基本設定から頻繁に交換することにより、インフラストラクチャは既知の状態に **リセットされ、** 設定ドリフトを回避できます。
+ **簡単なデプロイ**: アップグレードをサポートする必要がないため、デプロイが簡素化されます。単に新たにデプロイすることが、アップグレードになります。
+ **信頼性の高いアトミックデプロイ: ** デプロイは正常に完了するか、何も変更されません。デプロイプロセスの信頼性が高まります。
+ **迅速なロールバックと復旧プロセスによる安全なデプロイ: ** 以前の作業バージョンは変更されないため、より安全にデプロイできます。エラーが検出された場合は、ロールバックできます。
+ **一貫したテスト環境とデバッグ環境: ** すべてのサーバーが同じイメージを使用するため、環境間による違いはありません。1 つのビルドが複数の環境にデプロイされます。また、環境の整合性が失われるのを防ぎ、テストとデバッグが簡素化されます。
+ **スケーラビリティの向上: ** サーバーはベースイメージを使用し、一貫性があり、再現性があるため、とても簡単に自動スケーリングできます。
+ **簡素化されたツールチェーン**: 本番用ソフトウェアのアップグレードを管理する設定管理ツールが不要になるため、ツールチェーンが簡素化されます。サーバーにツールやエージェントが追加でインストールされることはありません。変更はベースイメージに加えられ、テストされてロールアウトされます。
+ **セキュリティの向上: ** サーバーへのすべての変更を拒否することで、インスタンスの SSH 接続を無効にし、キーを削除できます。これにより攻撃経路が減少し、組織のセキュリティ体制が向上します。
**このベストプラクティスを活用しない場合のリスクレベル:** ミディアム
## 実装のガイダンス
+ イミュータブルなインフラストラクチャを使用してデプロイします。イミュータブルインフラストラクチャは、更新、セキュリティパッチ、または設定の変更が本番システムで *インプレースで* 行われないように義務付けるモデルです。変更が必要な場合、新しいバージョンのアーキテクチャが構築され、本番環境にデプロイされます。
+ [ブルー/グリーンデプロイの概要](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html#welcome-deployment-overview-blue-green)
+ [サーバーレスアプリケーションの段階的なデプロイ](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/automating-updates-to-serverless-apps.html)
+ [イミュータブルなインフラストラクチャ: 不変性を通じた信頼性、一貫性、確信](https://medium.com/@adhorn/immutable-infrastructure-21f6613e7a23)
+ [CanaryRelease](https://martinfowler.com/bliki/CanaryRelease.html)
## リソース
**関連するドキュメント:**
+ [CanaryRelease](https://martinfowler.com/bliki/CanaryRelease.html)
+ [サーバーレスアプリケーションの段階的なデプロイ](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/automating-updates-to-serverless-apps.html)
+ [イミュータブルなインフラストラクチャ: 不変性を通じた信頼性、一貫性、確信](https://medium.com/@adhorn/immutable-infrastructure-21f6613e7a23)
+ [ブルー/グリーンデプロイの概要](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html#welcome-deployment-overview-blue-green)
+ [The Amazon Builders' Library: デプロイ時におけるロールバックの安全性の確保](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments)
# REL08-BP05 オートメーションを使用して変更をデプロイする
デプロイとパッチ適用は自動化されて、悪影響を排除します。
本番システムに変更を加えることは、多くの企業にとって最大級のリスクの 1 つです。当社は、ソフトウェアで解決するビジネス課題と同じくらい、デプロイを最優先課題としてとらえています。今日においてデプロイとは、変更のテストと導入、容量の追加と削除、データの移行など、実運用のあらゆる場所における自動化の導入を意味します。AWS CodePipeline により、ワークロードを解放するために必要なステップを管理できます。これには、AWS CodeDeploy を使用してデプロイされた状態が含まれ、Amazon EC2 インスタンス、オンプレミスインスタンス、サーバーレス Lambda 関数、または Amazon ECS サービスへのアプリケーションコードのデプロイを自動化します。
**推奨**
運用上の最も難しい手順に人を関与させることが一般通念で推奨されていますが、最も難しい手順については、まさにこの理由から自動化を推奨します。
**一般的なアンチパターン:**
+ 手動で変更を実行する。
+ 緊急ワークフローを通じて自動化の手順をスキップする。
+ 計画に従わない。
**このベストプラクティスを確立するメリット:** 自動化を使用してすべての変更をデプロイすると、人為的ミスの発生の可能性がなくなり、本番環境を変更する前にテストして、計画が完了したことを確認できます。
**このベストプラクティスが確立されていない場合のリスクレベル:** ミディアム
## 実装のガイダンス
+ デプロイパイプラインを自動化します。デプロイパイプラインを使用すると、自動テストおよび異常の検出を呼び出せるようになります。また、本番環境へのデプロイを行う前の特定のステップでパイプラインを休止したり、変更を自動的にロールバックしたりできます。
+ [The Amazon Builders' Library: デプロイ時におけるロールバックの安全性の確保](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments)
+ [The Amazon Builders' Library: 継続的デリバリーによる高速化](https://aws.amazon.com/builders-library/going-faster-with-continuous-delivery/)
+ AWS CodePipeline (または信頼できるサードパーティ製品) を使用して、パイプラインを定義し実行します。
+ 変更がコードリポジトリにコミットされた時点で処理を開始するようにパイプラインを設定します。
+ [AWS CodePipeline とは?](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html)
+ Amazon Simple Notification Service (Amazon SNS) と Amazon Simple Email Service (Amazon SES) を使用して、パイプラインの問題に関する通知を送信するか、Amazon Chime などのチームチャットツールに統合します。
+ [Amazon Simple Notification Service とは](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)
+ [Amazon SES とは?](https://docs.aws.amazon.com/ses/latest/DeveloperGuide/Welcome.html)
+ [Amazon Chime とは?](https://docs.aws.amazon.com/chime/latest/ug/what-is-chime.html)
+ [Webhook を使用してチャットメッセージを自動化する](https://docs.aws.amazon.com/chime/latest/ug/webhooks.html)
## リソース
**関連するドキュメント:**
+ [APN パートナー: 自動化されたデプロイソリューションの作成を支援できるパートナー](https://aws.amazon.com/partners/find/results/?keyword=devops)
+ [AWS Marketplace: products that can be used to automate your deployments](https://aws.amazon.com/marketplace/search/results?searchTerms=DevOps)
+ [Webhook を使用してチャットメッセージを自動化する](https://docs.aws.amazon.com/chime/latest/ug/webhooks.html)
+ [The Amazon Builders' Library: デプロイ時におけるロールバックの安全性の確保](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments)
+ [The Amazon Builders' Library: 継続的デリバリーによる高速化](https://aws.amazon.com/builders-library/going-faster-with-continuous-delivery/)
+ [「AWS CodePipeline とは何ですか?」](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html)
+ [「What Is CodeDeploy?」](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)
+ [AWS Systems Manager パッチマネージャーを使用して](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html)
+ [Amazon SES とは?](https://docs.aws.amazon.com/ses/latest/DeveloperGuide/Welcome.html)
+ [Amazon Simple Notification Service とは](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)
**関連動画:**
+ [AWS Summit 2019: CI/CD on AWS (AWS における CI/CD)](https://youtu.be/tQcF6SqWCoY)
# 障害管理
**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)