# 変更管理
**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)