# パフォーマンス効率
パフォーマンス効率の柱には、システムの要件を満たすためにコンピューティングリソースを効率的に使用し、要求の変化とテクノロジーの進化に対してその効率性を維持する能力が含まれます。実装に関する規範的なガイダンスとして [パフォーマンス効率の柱に関するホワイトペーパーを参照してください。](https://docs.aws.amazon.com/wellarchitected/latest/performance-efficiency-pillar/welcome.html?ref=wellarchitected-wp).
**Topics**
+ [アーキテクチャの選択](a-selection.md)
+ [コンピューティングとハードウェア](a-compute-hardware.md)
+ [データ管理](a-data-management.md)
+ [ネットワークとコンテンツ配信](a-networking-delivery.md)
+ [プロセスと文化](a-process-culture.md)
# アーキテクチャの選択
**Topics**
+ [PERF 1。ワークロードに適切なクラウドリソースとアーキテクチャを選択するにはどうすればよいでしょうか?](perf-01.md)
# PERF 1。ワークロードに適切なクラウドリソースとアーキテクチャを選択するにはどうすればよいでしょうか?
特定のワークロードに適したソリューションはさまざまで、大抵の場合、ソリューションには複数のアプローチが組み合わされています。優れた設計のワークロードは、パフォーマンスを向上させるために複数のソリューションを使用し、異なる機能を有効化します。
**Topics**
+ [PERF01-BP01 利用可能なクラウドサービスと機能について学び、理解する](perf_architecture_understand_cloud_services_and_features.md)
+ [PERF01-BP02 クラウドプロバイダーまたは適切なパートナーからのガイダンスを使用して、アーキテクチャパターンとベストプラクティスについて学ぶ](perf_architecture_guidance_architecture_patterns_best_practices.md)
+ [PERF01-BP03 アーキテクチャに関する意思決定においてコストを考慮する](perf_architecture_factor_cost_into_architectural_decisions.md)
+ [PERF01-BP04 トレードオフが顧客とアーキテクチャの効率にどのように影響するかを評価する](perf_architecture_evaluate_trade_offs.md)
+ [PERF01-BP05 ポリシーとリファレンスアーキテクチャを使用する](perf_architecture_use_policies_and_reference_architectures.md)
+ [PERF01-BP06 ベンチマークを使用してアーキテクチャに関する意思決定を行う](perf_architecture_use_benchmarking.md)
+ [PERF01-BP07 データ駆動型のアプローチでアーキテクチャを選択する](perf_architecture_use_data_driven_approach.md)
# PERF01-BP01 利用可能なクラウドサービスと機能について学び、理解する
利用可能なサービスや設定について継続的に学び、発見することで、アーキテクチャに関する意思決定をより適切に行い、ワークロードアーキテクチャのパフォーマンス効率を向上させることができます。
**一般的なアンチパターン:**
+ クラウドをコロケーションされたデータセンターとして使用する。
+ クラウドへの移行後、アプリケーションをモダナイズしない。
+ 永続化する必要があるすべてのものに対して、1 つのストレージタイプのみを使用する。
+ 現在の基準に最も近いインスタンスタイプを使用するが、必要に応じてより大きいインスタンスタイプを使用する。
+ マネージドサービスとして使用できるテクノロジーをデプロイおよび管理する。
**このベストプラクティスを活用するメリット:** 新しいサービスと設定を検討することで、パフォーマンスを大幅に向上させ、コストを削減し、ワークロードの維持に必要な労力を最適化できる場合があります。また、クラウド対応製品の価値実現までの時間を短縮できる可能性もあります。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
AWS では、パフォーマンスを向上させ、クラウドワークロードのコストを削減するための新しいサービスや機能を継続的にリリースしています。クラウドでのパフォーマンスの有効性を維持するためには、こうした新しいサービスや機能に関する最新情報を常に把握しておくことが重要です。ワークロードアーキテクチャのモダナイズは、生産性の向上、イノベーションの促進、成長機会の拡大にも役立ちます。
### 実装手順
+ 関連サービスのワークロードソフトウェアとアーキテクチャを棚卸しします。どのカテゴリの製品について詳しく調べるかを決めます。
+ AWS の提供サービスを調べ、パフォーマンスの向上、コストの削減、運用の煩雑さの軽減に役立つ関連サービスと設定オプションを特定、把握します。
+ [AWS の最新情報](https://aws.amazon.com/new/)
+ [AWS ブログ](https://aws.amazon.com/blogs/)
+ [AWS Skill Builder](https://skillbuilder.aws/)
+ [AWS イベントスケジュール](https://aws.amazon.com/events/)
+ [AWS トレーニング と認定](https://www.aws.training/)
+ [AWS YouTube チャンネル](https://www.youtube.com/channel/UCd6MoB9NC6uYN2grvUNT-Zg)
+ [AWS ワークショップ](https://workshops.aws/)
+ [AWS コミュニティ](https://aws.amazon.com/events/asean/community-and-events/)
+ サンドボックス (非実稼働) 環境を使用して、追加コストをかけずに新しいサービスについて学び、試してみます。
## リソース
**関連するドキュメント:**
+ [AWS アーキテクチャセンター](https://aws.amazon.com/architecture/)
+ [AWS Partner Network](https://aws.amazon.com/partners/)
+ [AWS ソリューションライブラリ](https://aws.amazon.com/solutions/)
+ [AWS ナレッジセンター](https://aws.amazon.com/premiumsupport/knowledge-center/)
+ [AWS でモダンアプリケーションを構築する](https://aws.amazon.com/modern-apps/)
**関連動画:**
+ [This is my Architecture](https://aws.amazon.com/architecture/this-is-my-architecture/)
**関連サンプル:**
+ [AWS Samples](https://github.com/aws-samples)
+ [AWS SDK サンプル](https://github.com/awsdocs/aws-doc-sdk-examples)
# PERF01-BP02 クラウドプロバイダーまたは適切なパートナーからのガイダンスを使用して、アーキテクチャパターンとベストプラクティスについて学ぶ
アーキテクチャに関する意思決定の指針として、ドキュメント、ソリューションアーキテクト、プロフェッショナルサービス、適切なパートナーなどのクラウド企業のリソースを活用します。こうしたリソースを利用することで、アーキテクチャを評価、改善し、最適なパフォーマンスを実現できます。
**一般的なアンチパターン:**
+ AWS を一般的なクラウドプロバイダーとして使用する。
+ 意図されていない方法で AWS のサービスを利用する。
+ ビジネス上の背景を考慮せずに、すべてのガイダンスに従う。
**このベストプラクティスを活用するメリット:** クラウドプロバイダーや適切なパートナーからのガイダンスを利用することで、ワークロードに適したアーキテクチャを選択し、自信を持って意思決定を行うことができます。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
AWS には、効率的なクラウドワークロードの構築と管理に役立つさまざまなガイダンス、ドキュメント、リソースが用意されています。AWS ドキュメントには、コードサンプル、チュートリアルのほか、サービスについての詳細な説明が記載されています。ドキュメントの他にも、AWS では、お客様がクラウドサービスのさまざまな側面を探求し、AWS で効率的なクラウドアーキテクチャを実装するのに役立つトレーニングおよび認定プログラム、ソリューションアーキテクト、プロフェッショナルサービスを提供しています。
こうしたリソースを活用して、貴重な知識やベストプラクティスに関するインサイトを導き出し、AWS クラウド での時間の節約、成果の向上につなげましょう。
### 実装手順
+ AWS ドキュメントとガイダンスを確認し、ベストプラクティスに従ってください。こうしたリソースは、サービスの効果的な選定および設定、パフォーマンスの向上に役立ちます。
+ [AWS ドキュメント](https://docs.aws.amazon.com/) (ユーザーガイドやホワイトペーパーなど)
+ [AWS ブログ](https://aws.amazon.com/blogs/)
+ [AWS トレーニング と認定](https://www.aws.training/)
+ [AWS YouTube チャンネル](https://www.youtube.com/channel/UCd6MoB9NC6uYN2grvUNT-Zg)
+ AWS パートナーイベント (AWS Global Summits, AWS re:Invent、ユーザーグループ、ワークショップなど) に参加して、AWS のエキスパートから AWS のサービスを利用する際のベストプラクティスを学びましょう。
+ [AWS イベントスケジュール](https://aws.amazon.com/events/)
+ [AWS ワークショップ](https://workshops.aws/)
+ [AWS コミュニティ](https://aws.amazon.com/events/asean/community-and-events/)
+ 追加のガイダンス、または製品情報が必要な場合は、AWS までお問い合わせください。AWS ソリューションアーキテクトおよび [AWS プロフェッショナルサービス](https://aws.amazon.com/professional-services/) は、ソリューションの実装に関するガイダンスを提供します。 [AWS パートナー](https://aws.amazon.com/partners/) は、ビジネスの俊敏性とイノベーションを引き出すために AWS の専門知識を提供します。
+ サービスを効果的に使用するためにテクニカルサポートが必要な場合は、 [サポート](https://aws.amazon.com/contact-us/) を使用します。 [AWS サポートプランは、](https://aws.amazon.com/premiumsupport/plans/) お客様がパフォーマンスを最適化し、リスクとコストを管理しながら AWS をうまく活用できるように、適切なツールと専門知識へのアクセスを提供するように設計されています。
## リソース
**関連するドキュメント:**
+ [AWS アーキテクチャセンター](https://aws.amazon.com/architecture/)
+ [AWS ソリューションライブラリ](https://aws.amazon.com/solutions/)
+ [AWS ナレッジセンター](https://aws.amazon.com/premiumsupport/knowledge-center/)
+ [AWS エンタープライズサポート](https://aws.amazon.com/premiumsupport/plans/enterprise/)
**関連動画:**
+ [This is my Architecture](https://aws.amazon.com/architecture/this-is-my-architecture/)
**関連サンプル:**
+ [AWS Samples](https://github.com/aws-samples)
+ [AWS SDK サンプル](https://github.com/awsdocs/aws-doc-sdk-examples)
# PERF01-BP03 アーキテクチャに関する意思決定においてコストを考慮する
アーキテクチャに関する意思決定でコストを考慮すると、クラウドワークロードのリソース使用率とパフォーマンス効率が向上します。クラウドワークロードがコストに及ぼす影響を認識していれば、効率的なリソースを活用し、無駄な作業を減らせる可能性が高くなります。
**一般的なアンチパターン:**
+ インスタンスの 1 つのファミリーのみを使用する。
+ ライセンスソリューションとオープンソースソリューションを比較しない。
+ ストレージライフサイクルポリシーを定義しない。
+ AWS クラウド の新しいサービスや機能を確認しない。
+ あなたは、ブロックストレージのみを使用します。
**このベストプラクティスを活用するメリット:** 意思決定にコストを考慮することで、より効率的なリソースを使用し、他の投資を検討できるようになります。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
コストを考慮してワークロードを最適化することで、リソース使用率を向上させ、クラウドワークロードの無駄を省くことができます。アーキテクチャ上の意思決定にコストを考慮に入れることには、通常、ワークロードコンポーネントのライトサイジングと伸縮性の有効化が含まれます。これにより、クラウドワークロードのパフォーマンス効率が向上します。
### 実装手順
+ クラウドワークロードの予算制限などのコスト目標を設定します。
+ ワークロードのコストを左右する主要コンポーネント (インスタンスやストレージなど) を特定します。AWS 料金見積りツール [お](https://calculator.aws/#/) よび [AWS Cost Explorer を使用して、](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) ワークロードの主なコスト要因を特定できます。
+ Well-Architected コスト最適化の [ベストプラクティスを使用して、](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/welcome.html) 主なコスト要因を最適化します。
+ コストを継続的にモニタリングおよび分析して、ワークロードにおけるコスト最適化の機会を特定します。
+ AWS Budgets [を使用して、](https://aws.amazon.com/aws-cost-management/aws-budgets/) 許容できないコストに関するアラートを受け取ります。
+ AWS Compute Optimizer [ま](https://aws.amazon.com/compute-optimizer/) たは [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/) を使用して、コスト最適化に関する推奨事項を確認します。
+ AWS [Cost Anomaly Detection ](https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/) を使用して、異常なコストの検出と根本原因の分析を自動化します。
## リソース
**関連するドキュメント:**
+ [A Detailed Overview of the Cost Intelligence Dashboard](https://aws.amazon.com/blogs/aws-cloud-financial-management/a-detailed-overview-of-the-cost-intelligence-dashboard/)
+ [AWS アーキテクチャセンター](https://aws.amazon.com/architecture/)
+ [AWS Partner Network](https://aws.amazon.com/partners/)
+ [AWS ソリューションライブラリ](https://aws.amazon.com/solutions/)
+ [AWS ナレッジセンター](https://aws.amazon.com/premiumsupport/knowledge-center/)
**関連動画:**
+ [This is my Architecture](https://aws.amazon.com/architecture/this-is-my-architecture/)
+ [Optimize performance and cost for your AWS compute](https://www.youtube.com/watch?v=zt6jYJLK8sg&ref=wellarchitected)
**関連する例:**
+ [AWS Samples](https://github.com/aws-samples)
+ [AWS SDK サンプル](https://github.com/awsdocs/aws-doc-sdk-examples)
+ [Rightsizing with Compute Optimizer and Memory utilization enabled](https://www.wellarchitectedlabs.com/cost/200_labs/200_aws_resource_optimization/5_ec2_computer_opt/)
+ [AWS Compute Optimizer デモコード](https://github.com/awslabs/ec2-spot-labs/tree/master/aws-compute-optimizer)
# PERF01-BP04 トレードオフが顧客とアーキテクチャの効率にどのように影響するかを評価する
パフォーマンス関連の改善を評価する際には、どの選択肢が顧客、そしてワークロードの効率性に影響するかを特定します。例えば、key-value データストアを使用することでシステムパフォーマンスが向上する場合、その結果整合性の特性がお客様に与える影響を評価することが重要です。
**一般的なアンチパターン:**
+ 結果整合性などのトレードオフがある場合でも、すべてのパフォーマンス改善が実装されるべきであると考えている。
+ パフォーマンスの問題が限界に達した場合にのみ、ワークロードの変更を評価する。
**このベストプラクティスを活用するメリット:** パフォーマンス関連の改善の可能性を評価する場合は、変更のトレードオフがワークロード要件で許容できるかどうかを判断する必要があります。場合によっては、トレードオフを補うために追加のコントロールを実装する必要があります。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
パフォーマンスと顧客への影響の観点から、アーキテクチャの重要な領域を特定します。どのように改善できるか、その改善によってどのようなトレードオフがもたらされるか、およびそれらがシステムとユーザーエクスペリエンスにどのように影響するかを判断します。例えば、データのキャッシングを実装すると、パフォーマンスが劇的に向上しますが、システムの不正な動作を防止するためにキャッシュデータをいつどのように更新または無効化するかに関する明確な戦術が必要になります。
### 実装手順
+ ワークロード要件と SLA を理解します。
+ 評価要因を明確に定義します。要因は、ワークロードのコスト、信頼性、セキュリティ、パフォーマンスに関連する場合があります。
+ 要件に対応できるアーキテクチャとサービスを選択します。
+ 実験と概念実証 (POC) を実施して、トレードオフ要因と顧客やアーキテクチャ効率への影響を評価します。通常、可用性とパフォーマンスが高く、安全なワークロードは、顧客体験を向上させるものの、消費するクラウドリソースは多くなります。
## リソース
**関連するドキュメント:**
+ [Amazon Builders’ Library](https://aws.amazon.com/builders-library)
+ [Quick KPI](https://docs.aws.amazon.com/quicksight/latest/user/kpi.html)
+ [Amazon CloudWatch RUM](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html)
+ [X-Ray ドキュメント](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
+ [ Understand resiliency patterns and trade-offs to architect efficiently in the cloud ](https://aws.amazon.com/blogs/architecture/understand-resiliency-patterns-and-trade-offs-to-architect-efficiently-in-the-cloud/)
**関連動画:**
+ [モニタリング計画を立てる](https://www.youtube.com/watch?v=OMmiGETJpfU&ref=wellarchitected)
+ [Optimize applications through Amazon CloudWatch RUM](https://www.youtube.com/watch?v=NMaeujY9A9Y)
+ [Amazon CloudWatch Synthetics のデモ](https://www.youtube.com/watch?v=hF3NM9j-u7I)
**関連サンプル:**
+ [Measure page load time with Amazon CloudWatch Synthetics](https://github.com/aws-samples/amazon-cloudwatch-synthetics-page-performance)
+ [Amazon CloudWatch RUM Web Client](https://github.com/aws-observability/aws-rum-web)
# PERF01-BP05 ポリシーとリファレンスアーキテクチャを使用する
サービスと設定を選択するときは、ワークロードの設計と実装をより効率的に行うために、社内ポリシーと既存のリファレンスアーキテクチャを使用します。
**一般的なアンチパターン:**
+ 会社の管理諸経費に影響を与える可能性のある幅広い種類のテクノロジーを許可している。
**このベストプラクティスを活用するメリット:** アーキテクチャ、テクノロジー、ベンダーの選択に関するポリシーを確立することで、迅速な意思決定が可能になります。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
リソースとアーキテクチャを選択する際の内部ポリシーを設けることで、アーキテクチャを選択する際に従うべき標準とガイドラインが得られます。これらのガイドラインは、適切なクラウドサービスを選択する際の意思決定プロセスを合理化し、パフォーマンス効率の向上に役立ちます。ポリシーまたはリファレンスアーキテクチャを使用してワークロードをデプロイし、サービスをクラウドデプロイに統合します。次に、パフォーマンステストを使用して、引き続きパフォーマンス要件を満たせることを確認します。
### 実装手順
+ クラウドワークロードの要件を明確に把握します。
+ 社内ポリシーと外部ポリシーを確認し、最も関連性の高いポリシーを特定します。
+ AWS または業界のベストプラクティスで提供されている適切なリファレンスアーキテクチャを使用します。
+ ポリシー、標準、リファレンスアーキテクチャ、および一般的な状況に対応する規範的なガイドラインで構成される一連の流れを作成します。そうすることで、チームがより迅速に行動できるようになります。該当する場合は、業種に合わせてアセットを調整します。
+ サンドボックス環境のワークロードに対して、これらのポリシーとリファレンスアーキテクチャを検証します。
+ 業界標準や AWS の最新情報を常に把握して、ポリシーとリファレンスアーキテクチャがクラウドワークロードの最適化に役立つことを確認します。
## リソース
**関連するドキュメント:**
+ [AWS アーキテクチャセンター](https://aws.amazon.com/architecture/)
+ [AWS Partner Network](https://aws.amazon.com/partners/)
+ [AWS ソリューションライブラリ](https://aws.amazon.com/solutions/)
+ [AWS ナレッジセンター](https://aws.amazon.com/premiumsupport/knowledge-center/)
**関連動画:**
+ [This is my Architecture](https://aws.amazon.com/architecture/this-is-my-architecture/)
**関連サンプル:**
+ [AWS Samples](https://github.com/aws-samples)
+ [AWS SDK サンプル](https://github.com/awsdocs/aws-doc-sdk-examples)
# PERF01-BP06 ベンチマークを使用してアーキテクチャに関する意思決定を行う
既存のワークロードのパフォーマンスをベンチマークに照らして評価すると、クラウドでのパフォーマンスを把握し、そのデータに基づいてアーキテクチャに関する意思決定を行うことができます。
**一般的なアンチパターン:**
+ ワークロードの特性を反映していない一般的なベンチマークを使用している。
+ 顧客からのフィードバックと認識を唯一のベンチマークとして使用している。
**このベストプラクティスを活用するメリット:** 現在の実装をベンチマークすることで、パフォーマンスの向上を測定できます。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
総合テストでベンチマークを使用して、ワークロードのコンポーネントがどのように機能するかを評価します。ベンチマークは概して負荷テストよりも迅速にセットアップでき、特定のコンポーネントに対するテクノロジーを評価するために使用されます。ベンチマークは、まだ負荷テストができるほどソリューションが完成していないプロジェクトの初期段階によく使用されます。
独自のカスタムベンチマークテストを構築するか、 [TPC-DS ](http://www.tpc.org/tpcds/)などの業界標準テストを使用して、ワークロードのベンチマークを実施できます。業界ベンチマークは、環境を比較する場合に有用です。カスタムベンチマークは、アーキテクチャで採用する予定の特殊なオペレーションを対象にするときに役立ちます。
ベンチマーキングを実施するときは、有効な結果が得られるようにテスト環境の暖気運転を行うことが重要です。同じベンチマークを複数回実行して、時系列での変動を捉えるようにしてください。
ベンチマークは概して負荷テストよりも速く実行されるため、デプロイパイプラインの早い時期に使用でき、パフォーマンスの逸脱に関するフィードバックもより迅速に提供されます。ベンチマークは、コンポーネント、またはサービスにおける大幅な変更を評価する場合に、その変更を行う労力を正当化できるかどうかを見極める近道となり得ます。負荷テストでは、ワークロードが本番環境でどのように機能するかに関する情報が得られることから、ベンチマークは負荷テストと併せて使用することが重要です。
### 実装手順
+ メトリクス (CPU 使用率、レイテンシー、スループットなど) を定義して、ワークロードのパフォーマンスを評価します。
+ ワークロードに適したベンチマークツールを特定し、セットアップします。AWS のサービス ( [Amazon CloudWatch など) ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)またはワークロードと互換性のあるサードパーティーツールを使用できます。
+ ベンチマークテストを実行し、テスト中のメトリクスをモニタリングします。
+ ベンチマーク結果を分析して文書化し、ボトルネックや問題を特定します。
+ テスト結果を使用してアーキテクチャに関する意思決定を行い、ワークロードを調整します。これには、サービスの変更や新機能の導入が含まれる場合があります。
+ 調整後、ワークロードを再テストします。
## リソース
**関連するドキュメント:**
+ [AWS アーキテクチャセンター](https://aws.amazon.com/architecture/)
+ [AWS Partner Network](https://aws.amazon.com/partners/)
+ [AWS ソリューションライブラリ](https://aws.amazon.com/solutions/)
+ [AWS ナレッジセンター](https://aws.amazon.com/premiumsupport/knowledge-center/)
+ [Amazon CloudWatch RUM を使用する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html)
+ [Amazon CloudWatch Synthetics とは](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
**関連動画:**
+ [This is my Architecture](https://aws.amazon.com/architecture/this-is-my-architecture/)
+ [Optimize applications through Amazon CloudWatch RUM](https://www.youtube.com/watch?v=NMaeujY9A9Y)
+ [Amazon CloudWatch Synthetics のデモ](https://www.youtube.com/watch?v=hF3NM9j-u7I)
**関連サンプル:**
+ [AWS Samples](https://github.com/aws-samples)
+ [AWS SDK サンプル](https://github.com/awsdocs/aws-doc-sdk-examples)
+ [分散負荷テスト](https://aws.amazon.com/solutions/implementations/distributed-load-testing-on-aws/)
+ [Measure page load time with Amazon CloudWatch Synthetics](https://github.com/aws-samples/amazon-cloudwatch-synthetics-page-performance)
+ [Amazon CloudWatch RUM Web Client](https://github.com/aws-observability/aws-rum-web)
# PERF01-BP07 データ駆動型のアプローチでアーキテクチャを選択する
アーキテクチャを選択するための明確でデータ駆動型のアプローチを定義して、特定のビジネスニーズを満たす適切なクラウドサービスと設定が使用されていることを確認します。
**一般的なアンチパターン:**
+ 現在のアーキテクチャが静的であり、今後更新されないと考えている。
+ 推測や仮定を基にアーキテクチャを選択している。
+ あなたは、理由なしで、時間の経過とともにアーキテクチャの変更を導入します。
**このベストプラクティスを活用するメリット:** アーキテクチャを選択するための明確なアプローチを持つことで、ワークロードの設計にデータを活用し、情報に基づいた意思決定を長期的に行うことができます。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
クラウドに関する社内の経験や知識、あるいは公開されているユースケース、関連ドキュメント、ホワイトペーパーなどの外部リソースを利用して、アーキテクチャのリソースとサービスを選択します。ワークロードで利用できるサービスについて、実験とベンチマークを促す明確なプロセスを用意してください。
重要なワークロードのバックログには、ビジネスやユーザーに関連する機能を提供するユーザー関連の背景情報だけでなく、ワークロードのアーキテクチュラルランウェイを形成するテクニカルな背景情報も含める必要があります。このランウェイは、テクノロジーの進歩と新しいサービスからの情報を基に形成され、データと適切な理由に基づいてこうしたテクノロジーやサービスが採用されます。これにより、アーキテクチャの将来性が保たれ、停滞化を防ぐことができます。
### 実装手順
+ 主要な利害関係者と協力して、パフォーマンス、可用性、コストに関する考慮事項を反映したワークロード要件を定義します。ユーザー数やワークロードの使用パターンなどの要素を考慮してください。
+ アーキテクチュラルランウェイやテクノロジーバックログを作成して、機能的バックログとともに優先順位を付けます。
+ さまざまなクラウドサービスを審査および評価します (詳細については、 [PERF01-BP01 利用可能なクラウドサービスと機能について学び、理解する](perf_architecture_understand_cloud_services_and_features.md)を参照)。
+ マイクロサービスやサーバーレスなど、パフォーマンス要件を満たすさまざまなアーキテクチャパターンを検討します (詳細については、 [PERF01-BP02 クラウドプロバイダーまたは適切なパートナーからのガイダンスを使用して、アーキテクチャパターンとベストプラクティスについて学ぶ](perf_architecture_guidance_architecture_patterns_best_practices.md)を参照)。
+ アーキテクチャ図を参照する、または他のチームやAWS ソリューションアーキテクト、 [AWS アーキテクチャセンターなどのリソースに問い合わせてください。](https://aws.amazon.com/architecture/)また、 [AWS Partner Network](https://aws.amazon.com/partners/)は、ワークロードに適したアーキテクチャを選択するのに役立ちます。
+ ワークロードのパフォーマンスを評価するのに役立つスループットや応答時間などのパフォーマンスメトリクスを定義します。
+ 定義したメトリクスを試用し、選択したアーキテクチャのパフォーマンスを検証します。
+ アーキテクチャの最適なパフォーマンスを維持するために、継続的にモニタリングし、必要に応じて調整を行います。
+ 選択したアーキテクチャと決定事項を、今後のアップデートや学習の参考として文書化します。
+ 学習したことや新しいテクノロジー、さらに現在のアプローチで必要とされる変更や問題を示す指標に基づいて、アーキテクチャの選択アプローチを継続的に見直し、更新します。
## リソース
**関連するドキュメント:**
+ [AWS ソリューションライブラリ](https://aws.amazon.com/solutions/)
+ [AWS ナレッジセンター](https://aws.amazon.com/premiumsupport/knowledge-center/)
**関連動画:**
+ [This is my Architecture](https://aws.amazon.com/architecture/this-is-my-architecture/)
**関連サンプル:**
+ [AWS Samples](https://github.com/aws-samples)
+ [AWS SDK サンプル](https://github.com/awsdocs/aws-doc-sdk-examples)
# コンピューティングとハードウェア
# PERF 2。コンピューティングリソースを選択し、ワークロードで使用するにはどうすればよいでしょうか?
特定のワークロードに対する最適なコンピューティングの選択は、アプリケーションの設計、利用パターン、および構成設定に応じて異なります。アーキテクチャによって、各種コンポーネントに異なるコンピューティングを使用し、異なる機能を有効化してパフォーマンスを向上させることができます。アーキテクチャに誤ったコンピューティングを選択することは、パフォーマンス効率の低下につながる可能性があります。
**Topics**
+ [PERF02-BP01 ワークロードに最適なコンピューティングオプションを選択する](perf_compute_hardware_select_best_compute_options.md)
+ [PERF02-BP02 利用可能なコンピューティング設定と機能について理解する](perf_compute_hardware_understand_compute_configuration_features.md)
+ [PERF02-BP03 コンピューティング関連のメトリクスを収集する](perf_compute_hardware_collect_compute_related_metrics.md)
+ [PERF02-BP04 コンピューティングリソースの設定とライトサイジングを行う](perf_compute_hardware_configure_and_right_size_compute_resources.md)
+ [PERF02-BP05 コンピューティングリソースを動的にスケールする](perf_compute_hardware_scale_compute_resources_dynamically.md)
+ [PERF02-BP06 最適化されたハードウェアベースのコンピューティングアクセラレーターを使用する](perf_compute_hardware_compute_accelerators.md)
# PERF02-BP01 ワークロードに最適なコンピューティングオプションを選択する
ワークロードに最適なコンピューティングオプションを選択することで、パフォーマンスを高め、不要なインフラストラクチャコストを削減し、ワークロードを維持するために必要な運用工数を軽減できます。
**一般的なアンチパターン:**
+ オンプレミスで使用されていたものと同じコンピューティングオプションを使用している。
+ クラウドコンピューティングのオプション、機能、ソリューション、およびそうしたソリューションがコンピューティング性能の向上にどのように役立つかについての認識が足りない。
+ ワークロードの特性により的確に適合する代替のコンピューティングオプションがあるにもかかわらず、スケーリングやパフォーマンスの要件を満たすために既存のコンピューティングオプションを過剰にプロビジョニングしている。
**このベストプラクティスを活用するメリット:** コンピューティング要件を特定し、利用可能なオプションに照らし合わせて評価することで、ワークロードのリソース効率を高めることができます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
クラウドワークロードを最適化してパフォーマンスを効率化するには、ユースケースとパフォーマンス要件に最適なコンピューティングオプションを選択することが重要です。AWS では、クラウド内のさまざまなワークロードに対応するさまざまなコンピューティングオプションを用意しています。例えば、 [Amazon EC2 ](https://docs.aws.amazon.com/ec2/) を使用した仮想サーバーの起動および管理、[AWS Lambda](https://docs.aws.amazon.com/lambda/?icmpid=docs_homepage_featuredsvcs) を使用したサーバーのプロビジョニングや管理が不要なコードの実行、[Amazon ECS ](https://aws.amazon.com/ecs/) または [Amazon EKS ](https://aws.amazon.com/eks/) を使用したコンテナの実行と管理、または [AWS Batch](https://aws.amazon.com/batch/) を使用した大量データの並列処理を行えます。スケールとコンピューティングニーズを基に、状況に最適なコンピューティングソリューションを選んで構成する必要があります。また、コンピューティングソリューションにもそれぞれ利点と欠点があるため、1 つのワークロードで複数のタイプを使用することも検討できます。
次の手順では、ワークロードの特性とパフォーマンス要件に合わせて適切なコンピューティングオプションを選択する方法を説明します。
## 実装手順
1. ワークロードのコンピューティング要件を把握します。主な要件には、処理ニーズ、トラフィックパターン、データアクセスパターン、スケーリングの必要性、レイテンシー要件があります。
1. AWS 上のワークロードで使用できるさまざまなコンピューティングオプションについて学びます (概要については、 [PERF01-BP01 利用可能なクラウドサービスと機能について学び、理解する](perf_architecture_understand_cloud_services_and_features.md)を参照)。AWS の主要なコンピューティングオプション、その特徴、一般的な使用例は次のとおりです。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2023-10-03/framework/perf_compute_hardware_select_best_compute_options.html)
1. 各コンピューティングオプションに関連するコスト (時間単位の料金やデータ転送など) と管理諸経費 (パッチ適用やスケーリングなど) を評価します。
1. 非運用環境で実験とベンチマーキングを行い、どのコンピューティングオプションがワークロード要件に最も適しているかを特定します。
1. 実験を通じて新しいコンピューティングソリューションを特定したら、移行を計画し、パフォーマンスメトリクスを検証します。
1. Amazon CloudWatch のような [AWS モニタリングツールや](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) AWS Compute Optimizer のような [最適化サービスを使用し、](https://aws.amazon.com/compute-optimizer/) 実際の使用パターンに基づいてコンピューティングリソースを継続的に最適化します。
## リソース
**関連ドキュメント:**
+ [AWS を使用したクラウドコンピューティング ](https://aws.amazon.com/products/compute/?ref=wellarchitected)
+ [Amazon EC2 インスタンスタイプ ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html?ref=wellarchitected)
+ [Amazon EKS コンテナ: Amazon EKS ワーカーノード ](https://docs.aws.amazon.com/eks/latest/userguide/worker.html?ref=wellarchitected)
+ [Amazon ECS コンテナ: Amazon ECS コンテナインスタンス ](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ECS_instances.html?ref=wellarchitected)
+ [関数: Lambda 関数の設定](https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html?ref=wellarchitected#function-configuration)
+ [コンテナに関する規範ガイダンス](https://aws.amazon.com/prescriptive-guidance/?apg-all-cards.sort-by=item.additionalFields.sortText&apg-all-cards.sort-order=desc&awsf.apg-new-filter=*all&awsf.apg-content-type-filter=*all&awsf.apg-code-filter=*all&awsf.apg-category-filter=categories%23containers&awsf.apg-rtype-filter=*all&awsf.apg-isv-filter=*all&awsf.apg-product-filter=*all&awsf.apg-env-filter=*all)
+ [サーバーレスに関する規範ガイダンス](https://aws.amazon.com/prescriptive-guidance/?apg-all-cards.sort-by=item.additionalFields.sortText&apg-all-cards.sort-order=desc&awsf.apg-new-filter=*all&awsf.apg-content-type-filter=*all&awsf.apg-code-filter=*all&awsf.apg-category-filter=categories%23serverless&awsf.apg-rtype-filter=*all&awsf.apg-isv-filter=*all&awsf.apg-product-filter=*all&awsf.apg-env-filter=*all)
**関連動画:**
+ [スタートアップ企業向けコンピューティングオプションの選択方法](https://aws.amazon.com/startups/start-building/how-to-choose-compute-option/)
+ [Optimize performance and cost for your AWS compute ](https://www.youtube.com/watch?v=zt6jYJLK8sg)
+ [Amazon EC2 foundations](https://www.youtube.com/watch?v=kMMybKqC2Y0&ref=wellarchitected)
+ [Powering next-gen Amazon EC2: Deep dive into the Nitro system ](https://www.youtube.com/watch?v=rUY-00yFlE4&ref=wellarchitected)
+ [Deploy ML models for inference at high performance and low cost](https://www.youtube.com/watch?v=4FqHt5bmS2o)
+ [Better, faster, cheaper compute: Cost-optimizing Amazon EC2](https://www.youtube.com/watch?v=_dvh4P2FVbw&ref=wellarchitected)
**関連する例:**
+ [Migrating the Web application to containers](https://application-migration-with-aws.workshop.aws/en/container-migration.html)
+ [Run a Serverless Hello World](https://aws.amazon.com/getting-started/hands-on/run-serverless-code/)
# PERF02-BP02 利用可能なコンピューティング設定と機能について理解する
コンピューティングサービスで利用できる設定オプションと機能を理解しておくと、適切な量のリソースをプロビジョニングしてパフォーマンス効率を向上させることができます。
**一般的なアンチパターン:**
+ コンピューティングオプションや利用可能なインスタンスファミリーをワークロードの特性に照らして評価しない。
+ ピーク需要の要件を満たすために、コンピューティングリソースを過剰にプロビジョニングしている。
** このベストプラクティスを活用するメリット:** AWS のコンピューティングの機能と設定に精通していれば、ワークロードの特性とニーズに合わせて最適化されたコンピューティングソリューションを使用できます。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
各コンピューティングソリューションは、さまざまなワークロードの特性と要件に対応するために、それぞれ異なる設定や機能を備えています。こうしたオプションがワークロードをどのように補完するかを理解し、アプリケーションにどの設定オプションが最適か判断します。これらのオプションの例には、インスタンスのファミリー、サイズ、機能 (GPU、I/O)、バースト、タイムアウト、関数サイズ、コンテナインスタンス、並行性などがあります。ワークロードで同じコンピューティングオプションを 4 週間以上使用しており、その特性が今後も変わらないと予想される場合は、 [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/) を使用して、現在のコンピューティングオプションがワークロードに適しているかどうかを、CPU とメモリの観点から確認できます。
## 実装手順
1. ワークロード要件 (CPU ニーズ、メモリ、レイテンシーなど) を把握します。
1. AWS ドキュメントとベストプラクティスで、コンピューティングパフォーマンスの向上に役立つ推奨構成オプションについて確認します。考慮すべき主な設定オプションは次のとおりです。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2023-10-03/framework/perf_compute_hardware_understand_compute_configuration_features.html)
## リソース
**関連ドキュメント:**
+ [AWS を使用したクラウドコンピューティング ](https://aws.amazon.com/products/compute/?ref=wellarchitected)
+ [Amazon EC2 インスタンスタイプ ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html?ref=wellarchitected)
+ [Amazon EC2 インスタンスのプロセッサのステート制御 ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/processor_state_control.html?ref=wellarchitected)
+ [Amazon EKS コンテナ: Amazon EKS ワーカーノード ](https://docs.aws.amazon.com/eks/latest/userguide/worker.html?ref=wellarchitected)
+ [Amazon ECS コンテナ: Amazon ECS コンテナインスタンス ](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ECS_instances.html?ref=wellarchitected)
+ [Functions: Lambda Function Configuration (関数: Lambda 関数の設定)](https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html?ref=wellarchitected#function-configuration)
**関連動画:**
+ [Amazon EC2 foundations](https://www.youtube.com/watch?v=kMMybKqC2Y0&ref=wellarchitected)
+ [Powering next-gen Amazon EC2: Deep dive into the Nitro system ](https://www.youtube.com/watch?v=rUY-00yFlE4&ref=wellarchitected)
+ [Optimize performance and cost for your AWS compute](https://www.youtube.com/watch?v=zt6jYJLK8sg&ref=wellarchitected)
**関連する例:**
+ [Rightsizing with Compute Optimizer and Memory utilization enabled](https://www.wellarchitectedlabs.com/cost/200_labs/200_aws_resource_optimization/5_ec2_computer_opt/)
+ [AWS Compute Optimizer デモコード](https://github.com/awslabs/ec2-spot-labs/tree/master/aws-compute-optimizer)
# PERF02-BP03 コンピューティング関連のメトリクスを収集する
コンピューティング関連のメトリクスを記録および追跡することで、コンピューティングリソースのパフォーマンスをよりよく理解し、パフォーマンスと使用率を向上させます。
**一般的なアンチパターン:**
+ メトリクスの検索に手動ログファイルのみを使用している。
+ 一部のモニタリングソフトウェアで記録されるデフォルトのメトリクスのみを使用している。
+ 問題が発生したときにだけメトリクスを確認している。
**このベストプラクティスを活用するメリット:** パフォーマンス関連のメトリクスを収集することで、アプリケーションのパフォーマンスとビジネス要件の整合性をとり、ワークロードのニーズを満たすことができます。また、ワークロードにおけるリソースのパフォーマンスと使用率を継続的に改善するのにも役立ちます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
クラウドワークロードでは、メトリクス、ログ、イベントなどのデータが大量に生成される可能性があります。AWS クラウド では、メトリクスの収集は、セキュリティ、コスト効率、パフォーマンス、持続可能性を向上させるために不可欠なステップです。AWS では、 [Amazon CloudWatch ](https://aws.amazon.com/cloudwatch/) のようなモニタリングサービスを使用して、有益なインサイトにつながるさまざまなパフォーマンス関連のメトリクスを提供しています。CPU 使用率、メモリ使用率、ディスク I/O、ネットワークのインバウンドとアウトバウンドなどのメトリクスにより、使用率レベルやパフォーマンスのボトルネックを把握できます。これらのメトリクスをデータ駆動型のアプローチの一部として使用し、ワークロードのリソースを積極的に調整および最適化します。 理想は、コンピューティングリソースに関連するすべてのメトリクスを単一のプラットフォームで収集し、コストと運用上の目標をサポートするための保持ポリシーを実装することです。
## 実装手順
1. ワークロードに関連するパフォーマンス関連の指標を特定します。リソース使用率やクラウドワークロードの動作状況 (応答時間やスループットなど) に関するメトリクスを収集する必要があります。
1. [Amazon EC2 のデフォルトのメトリクス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/viewing_metrics_with_cloudwatch.html)
1. [Amazon ECS のデフォルトのメトリクス](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/cloudwatch-metrics.html)
1. [Amazon EKS のデフォルトのメトリクス](https://docs.aws.amazon.com/prescriptive-guidance/latest/implementing-logging-monitoring-cloudwatch/kubernetes-eks-metrics.html)
1. [Lambda のデフォルトのメトリクス](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-functions-access-metrics.html)
1. [Amazon EC2 のメモリとディスクのメトリクス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/mon-scripts.html)
1. ワークロードに適したログ記録とモニタリングのソリューションを選んでセットアップします。
1. [AWS native Observability](https://catalog.workshops.aws/observability/en-US/aws-native)
1. [AWS Distro for OpenTelemetry](https://aws.amazon.com/otel/)
1. [Amazon Managed Service for Prometheus](https://docs.aws.amazon.com/grafana/latest/userguide/prometheus-data-source.html)
1. ワークロード要件に基づいて、メトリクスに必要なフィルターと集計を定義します。
1. [Quantify custom application metrics with Amazon CloudWatch Logs and metric filters](https://aws.amazon.com/blogs/mt/quantify-custom-application-metrics-with-amazon-cloudwatch-logs-and-metric-filters/)
1. [Collect custom metrics with Amazon CloudWatch strategic tagging](https://aws.amazon.com/blogs/infrastructure-and-automation/collect-custom-metrics-with-amazon-cloudwatch-strategic-tagging/)
1. セキュリティと運用の目標に合わせて、メトリクスのデータ保持ポリシーを設定します。
1. [CloudWatch メトリクスのデフォルトのデータ保持](https://aws.amazon.com/cloudwatch/faqs/#AWS_resource_.26_custom_metrics_monitoring)
1. [CloudWatch Logs のデフォルトのデータ保持](https://aws.amazon.com/cloudwatch/faqs/#Log_management)
1. パフォーマンス関連の問題に積極的に対応できるよう、必要に応じて、メトリクスのアラームと通知を作成します。
1. [Create alarms for custom metrics using Amazon CloudWatch anomaly detection](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/create-alarms-for-custom-metrics-using-amazon-cloudwatch-anomaly-detection.html)
1. [Create metrics and alarms for specific web pages with Amazon CloudWatch RUM](https://aws.amazon.com/blogs/mt/create-metrics-and-alarms-for-specific-web-pages-amazon-cloudwatch-rum/)
1. 自動化を利用して、メトリクス・ログ集計エージェントをデプロイします。
1. [AWS Systems Manager automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html?ref=wellarchitected)
1. [OpenTelemetry Collector](https://aws-otel.github.io/docs/getting-started/collector)
## リソース
**関連するドキュメント:**
+ [Amazon CloudWatch のドキュメント](https://docs.aws.amazon.com/cloudwatch/index.html?ref=wellarchitected)
+ [CloudWatch エージェントを使用して Amazon EC2 インスタンスとオンプレミスサーバーからのメトリクスとログを収集する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html?ref=wellarchitected)
+ [Accessing Amazon CloudWatch Logs for AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-functions-logs.html?ref=wellarchitected)
+ [コンテナインスタンスでの CloudWatch Logs の使用](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_cloudwatch_logs.html?ref=wellarchitected)
+ [カスタムメトリクスをパブリッシュする](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html?ref=wellarchitected)
+ [AWS の回答: 集中ログ記録](https://aws.amazon.com/answers/logging/centralized-logging/?ref=wellarchitected)
+ [CloudWatch メトリクスを発行する AWS のサービス](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html?ref=wellarchitected)
+ [AWS Fargate での Amazon EKS のモニタリング](https://aws.amazon.com/blogs/containers/monitoring-amazon-eks-on-aws-fargate-using-prometheus-and-grafana/)
**関連動画:**
+ [Application Performance Management on AWS (AWS でのアプリケーションパフォーマンス管理)](https://www.youtube.com/watch?v=5T4stR-HFas&ref=wellarchitected)
**関連する例:**
+ [Level 100: Monitoring with CloudWatch Dashboards (レベル 100: CloudWatch ダッシュボードを使ったモニタリング)](https://wellarchitectedlabs.com/performance-efficiency/100_labs/100_monitoring_with_cloudwatch_dashboards/)
+ [Level 100: Monitoring Windows EC2 instance with CloudWatch Dashboards (レベル 100: ダッシュボードを使った Windows EC2 インスタンスのモニタリング)](https://wellarchitectedlabs.com/performance-efficiency/100_labs/100_monitoring_windows_ec2_cloudwatch/)
+ [Level 100: Monitoring an Amazon Linux EC2 instance with CloudWatch Dashboards (レベル 100: CloudWatch ダッシュボードを使った Amazon Linux EC2 インスタンスのモニタリング)](https://wellarchitectedlabs.com/performance-efficiency/100_labs/100_monitoring_linux_ec2_cloudwatch/)
# PERF02-BP04 コンピューティングリソースの設定とライトサイジングを行う
ワークロードのパフォーマンス要件に合わせてコンピューティングリソースの設定とライトサイジングを行うことで、リソースの過不足を防ぎます。
**一般的なアンチパターン:**
+ ワークロードのパフォーマンス要件を無視した結果、コンピューティングリソースのプロビジョニングが過剰になったり不足したりする。
+ 使用できる最大または最小のインスタンスのみをすべてのワークロードに対して選択する。
+ 管理を容易にするため、1 つのインスタンスファミリーのみを使用する。
+ AWS Cost Explorer または Compute Optimizer からのライトサイジングに関する推奨事項を無視する。
+ 新しいインスタンスタイプが適合するかどうかについてワークロードを再評価しない。
+ 組織で使用できるインスタンス設定としてごく少数のみを認証する。
**このベストプラクティスを活用するメリット:** コンピューティングリソースをライトサイジングすることで、リソースの過剰プロビジョニングやプロビジョニング不足を回避できるため、クラウドでの運用が最適化されます。通常、コンピューティングリソースのサイズを適切に設定すると、パフォーマンスが上がり、カスタマーエクスペリエンスが向上すると同時に、コストも削減されます。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
ライトサイジングにより、組織はビジネスニーズに対応しながら、効率的かつ費用対効果の高い方法でクラウドインフラストラクチャを運用できます。クラウドリソースを過剰にプロビジョニングすると余分なコストが発生する可能性があり、プロビジョニングが不十分だと、パフォーマンスが低下し、カスタマーエクスペリエンスが低下する可能性があります。AWS の [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/) や [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/) のようなツールは、履歴データを使用して、コンピューティングリソースを適切なサイズにするための推奨事項を提供します。
### 実装手順
+ ニーズに最適なインスタンスタイプを選択します。
+ [ワークロードに適切な Amazon EC2 インスタンスタイプを選択する方法を教えてください。](https://aws.amazon.com/premiumsupport/knowledge-center/ec2-instance-choose-type-for-workload/)
+ [Amazon EC2 フリートの属性ベースのインスタンスタイプの選択](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-fleet-attribute-based-instance-type-selection.html)
+ [属性ベースのインスタンスタイプの選択を使用して Auto Scaling グループを作成する](https://docs.aws.amazon.com/autoscaling/ec2/userguide/create-asg-instance-type-requirements.html)
+ [Optimizing your Kubernetes compute costs with Karpenter consolidation](https://aws.amazon.com/blogs/containers/optimizing-your-kubernetes-compute-costs-with-karpenter-consolidation/)
+ ワークロードのさまざまなパフォーマンス特性と、それらの特性とメモリ、ネットワーク、CPU 使用率との関連を分析します。このデータを使用して、ワークロードのプロファイルとパフォーマンス目標に最適なリソースを選択します。
+ Amazon CloudWatch などのモニタリングツールを使用して、AWS リソースの使用状況をモニタリングします。
+ コンピューティングリソースの適切な構成を選択します。
+ 一時的なワークロードについては、 [インスタンス Amazon CloudWatch メトリクス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/viewing_metrics_with_cloudwatch.html) ( `CPUUtilization ` など) を評価して、インスタンスの過剰または過少な使用を特定します。
+ 安定したワークロードの場合は、AWS のライトサイジングツール (AWS Compute Optimizer、AWS Trusted Advisor など) を定期的にチェックし、インスタンスの最適化とライトサイジングの機会を特定します。
+ [Well-Architected Lab - Rightsizing Recommendations (Well-Architected ラボ - サイズ最適化のレコメンデーション) ](https://wellarchitectedlabs.com/cost/100_labs/100_aws_resource_optimization/)
+ [Well-Architected Lab - Rightsizing with Compute Optimizer (Well-Architected ラボ - Compute Optimizer を使用したサイズ最適化) ](https://wellarchitectedlabs.com/cost/200_labs/200_aws_resource_optimization/)
+ 構成の変更は、本番環境に実装する前に非運用環境でテストします。
+ 継続的に新しいコンピューティングサービスを再評価し、ワークロードのニーズと照らし合わせます。
## リソース
**関連ドキュメント:**
+ [AWS を使用したクラウドコンピューティング](https://aws.amazon.com/products/compute/)
+ [Amazon EC2 インスタンスタイプ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html)
+ [Amazon ECS コンテナ: Amazon ECS コンテナインスタンス](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ECS_instances.html)
+ [Amazon EKS コンテナ: Amazon EKS ワーカーノード](https://docs.aws.amazon.com/eks/latest/userguide/worker.html)
+ [関数: Lambda 関数の設定](https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html#function-configuration)
+ [Amazon EC2 インスタンスのプロセッサのステート制御](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/processor_state_control.html)
**関連動画:**
+ [Amazon EC2 foundations](https://www.youtube.com/watch?v=kMMybKqC2Y0)
+ [Better, faster, cheaper compute: Cost-optimizing Amazon EC2](https://www.youtube.com/watch?v=_dvh4P2FVbw)
+ [Deploy ML models for inference at high performance and low cost](https://www.youtube.com/watch?v=4FqHt5bmS2o)
+ [Optimize performance and cost for your AWS compute](https://www.youtube.com/watch?v=zt6jYJLK8sg)
+ [Powering next-gen Amazon EC2: Deep dive into the Nitro system](https://www.youtube.com/watch?v=rUY-00yFlE4)
+ [Simplifying Data Processing to Enhance Innovation with Serverless Tools](https://aws.amazon.com/startups/start-building/how-to-choose-compute-option/)
**関連する例:**
+ [Rightsizing with Compute Optimizer and Memory utilization enabled](https://www.wellarchitectedlabs.com/cost/200_labs/200_aws_resource_optimization/5_ec2_computer_opt/)
+ [AWS Compute Optimizer デモコード](https://github.com/awslabs/ec2-spot-labs/tree/master/aws-compute-optimizer)
# PERF02-BP05 コンピューティングリソースを動的にスケールする
クラウドの伸縮性を利用して、ニーズに合わせてコンピューティングリソースを動的にスケールアップまたはスケールダウンすることで、ワークロードのキャパシティが過剰または過少になるのを防ぐことができます。
**一般的なアンチパターン:**
+ アラームに対応するために手動でキャパシティを増やす。
+ オンプレミスと同じサイズ設定ガイドライン (通常は静的インフラストラクチャ) を使用する。
+ スケーリングイベントの後、スケールダウンして元に戻すのではなく、キャパシティを増加させたままにする。
**このベストプラクティスを活用するメリット:** コンピューティングリソースの伸縮性を設定してテストすることで、コストの節約、パフォーマンスベンチマークの維持、トラフィックの変化に応じた信頼性の向上に役立ちます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
AWS は、需要の変化に対応するためのさまざまなスケーリングメカニズムを通じて、リソースを動的にスケールアップまたはスケールダウンする柔軟性を備えています。コンピューティング関連のメトリクスと組み合わせると、動的スケーリングにより、ワークロードが自動的に変化に対応し、最適なコンピューティングリソースを使用して目標を達成できるようになります。
リソースの需要と供給は、さまざまなアプローチで一致させることができます。
+ **ターゲット追跡アプローチ**: スケーリングメトリクスをモニタリングし、必要に応じて容量を自動的に増減します。
+ **予測スケーリング**: 日単位および週単位の傾向を見越してスケールします。
+ **スケジュールベースのアプローチ**: 予測できる負荷の変化に従って、独自のスケーリングスケジュールを設定します。
+ **サービススケーリング**: 設計により自動的にスケーリングされるサービス (サーバーレスなど) を選択します。
ワークロードのデプロイメントで、確実にスケールアップおよびスケールダウンイベントを対処できるようにしてください。
### 実装手順
+ コンピューティングインスタンス、コンテナ、関数のいずれにも、伸縮性の仕組みが備わっています。サービスの機能として実装されている場合も、自動スケーリングと組み合わせて実現する場合もあります。自動スケーリングメカニズムの例を次に示します。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2023-10-03/framework/perf_compute_hardware_scale_compute_resources_dynamically.html)
+ スケーリングは大抵、Amazon EC2 インスタンスや AWS Lambda 関数などのコンピューティングサービスに関連して取り上げられます。AWS Glue のようなコンピューティング以外のサービスの設定も、 [需要に合わせて](https://docs.aws.amazon.com/glue/latest/dg/auto-scaling.html) 考慮するようにしてください。
+ スケーリングのメトリクスが、デプロイされているワークロードの特性と一致していることを確認します。動画トランスコーディングアプリケーションをデプロイしようとする場合、100% の CPU 使用率が想定されるため、プライマリメトリクスにするべきではありません。代わりに、トランスコーディングジョブのキュー深度を使用してください。必要な場合は、スケーリングポリシーとして [カスタマイズされたメトリクス](https://aws.amazon.com/blogs/mt/create-amazon-ec2-auto-scaling-policy-memory-utilization-metric-linux/) を使用できます。適切なメトリクスを選ぶには、Amazon EC2 の以下のガイダンスを考慮してください。
+ メトリクスは有効な利用率メトリクスでなければならず、インスタンスのどの程度ビジーかを記述する必要があります。
+ メトリクス値は、Auto Scaling グループ内のインスタンス数に比例して増減する必要があります。
+ 必ず [手動スケーリング](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scale-based-on-demand.html) ではなく [動的スケーリング](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-manual-scaling.html) を Auto Scaling グループに使用します。また、動的スケーリングでは、 [ターゲット追跡スケーリングポリシー](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scaling-target-tracking.html) を使用することをお勧めします。
+ ワークロードのデプロイがスケーリングイベント (アップとダウン) の両方に対応処理できることを確認します。例えば、 [アクティビティ履歴](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-verify-scaling-activity.html) を使用して、Auto Scaling グループのスケーリングアクティビティを確認することができます。
+ ワークロードを評価して予測可能なパターンを見つけ、あらかじめわかっていた、および計画的な需要の変化を予測してプロアクティブにスケールします。予測スケーリングを使用すると、容量を過剰にプロビジョニングする必要がなくなります。詳細については、 [「Amazon EC2 Auto Scaling での予測スケーリング」](https://aws.amazon.com/blogs/compute/introducing-native-support-for-predictive-scaling-with-amazon-ec2-auto-scaling/)を参照してください。
## リソース
**関連ドキュメント:**
+ [AWS を使用したクラウドコンピューティング](https://aws.amazon.com/products/compute/)
+ [Amazon EC2 インスタンスタイプ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html)
+ [Amazon ECS コンテナ: Amazon ECS コンテナインスタンス](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ECS_instances.html)
+ [Amazon EKS コンテナ: Amazon EKS ワーカーノード](https://docs.aws.amazon.com/eks/latest/userguide/worker.html)
+ [関数: Lambda 関数の設定](https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html#function-configuration)
+ [Amazon EC2 インスタンスのプロセッサのステート制御](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/processor_state_control.html)
+ [Amazon ECS クラスター Auto Scaling の詳細](https://aws.amazon.com/blogs/containers/deep-dive-on-amazon-ecs-cluster-auto-scaling/)
+ [Introducing Karpenter – An Open-Source High-Performance Kubernetes Cluster Autoscaler](https://aws.amazon.com/blogs/aws/introducing-karpenter-an-open-source-high-performance-kubernetes-cluster-autoscaler/)
**関連動画:**
+ [Amazon EC2 foundations](https://www.youtube.com/watch?v=kMMybKqC2Y0)
+ [Better, faster, cheaper compute: Cost-optimizing Amazon EC2](https://www.youtube.com/watch?v=_dvh4P2FVbw)
+ [Optimize performance and cost for your AWS compute](https://www.youtube.com/watch?v=zt6jYJLK8sg)
+ [Powering next-gen Amazon EC2: Deep dive into the Nitro system](https://www.youtube.com/watch?v=rUY-00yFlE4)
+ [Build a cost-, energy-, and resource-efficient compute environment (コスト面、エネルギー面、リソース面で効率的なコンピューティング環境の構築)](https://www.youtube.com/watch?v=8zsC5e1eLCg)
**関連する例:**
+ [Amazon EC2 Auto Scaling グループの例](https://github.com/aws-samples/amazon-ec2-auto-scaling-group-examples)
+ [Implement Autoscaling with Karpenter](https://www.eksworkshop.com/beginner/085_scaling_karpenter/)
# PERF02-BP06 最適化されたハードウェアベースのコンピューティングアクセラレーターを使用する
ハードウェアアクセラレーターを使用すると、CPU ベースの代替手段よりも効率的に特定の機能を実行できます。
**一般的なアンチパターン:**
+ 現在のワークロードで、より高いパフォーマンスとより低いコストを実現できる専用のインスタンスに対する汎用インスタンスのベンチマーキングを行ったことがない。
+ CPU ベースのコンピューティングアクセラレーターを使用した方が効率的なタスクに、ハードウェアベースのコンピューティングアクセラレーターを使用している。
+ GPU の使用状況を監視していない。
**このベストプラクティスを活用するメリット:** GPU (グラフィックス処理ユニット) や FPGA (フィールドプログラマブルゲートアレイ) などのハードウェアベースのアクセラレーターを使用することで、特定の処理機能をより効率的に実行できます。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
高速コンピューティングインスタンスを使用すると、GPU や FPGA などのハードウェアベースのコンピューティングアクセラレーターにアクセスできます。これらのハードウェアアクセラレーターは、グラフィック処理やデータパターンマッチングなどの特定の機能を、CPU ベースの代替手段よりも効率的に実行します。レンダリング、トランスコーディング、機械学習など、多くの高速ワークロードは、リソースの使用量に大きなばらつきがあります。このハードウェアは必要な時間だけ実行し、必要のない場合は自動で廃止することで、全体的なパフォーマンス効率を向上させることができます。
### 実装手順
+ どの [高速コンピューティングインスタンスが](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/accelerated-computing-instances.html) お客様の要件に対応できるかを特定します。
+ 機械学習のワークロードには、 [AWS Trainium](https://aws.amazon.com/machine-learning/trainium/)、 [AWS Inferentia](https://aws.amazon.com/machine-learning/inferentia/)、 [Amazon EC2 DL1 など、ワークロードに特化した専用ハードウェアを利用します](https://aws.amazon.com/ec2/instance-types/dl1/)。Inf2 インスタンスなどの AWS Inferentia インスタンスは、 [Amazon EC2 インスタンスと比較して、ワットあたりのパフォーマンスが最大 50% 向上します](https://aws.amazon.com/machine-learning/inferentia/)。
+ 高速コンピューティングインスタンスの使用状況メトリクスを収集します。例えば、CloudWatch エージェントを使用して、GPU の `utilization_gpu` および `utilization_memory` などのメトリクスを収集できます ( [「Amazon CloudWatch で NVIDIA GPU メトリクスを収集する」を参照)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-NVIDIA-GPU.html)。
+ ハードウェアアクセラレーターのコード、ネットワーク操作、設定を最適化し、基盤となるハードウェアが十分に活用されるようにします。
+ [GPU 設定を最適化する](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/optimize_gpu.html)
+ [Deep Learning AMI での GPU のモニタリングと最適化](https://docs.aws.amazon.com/dlami/latest/devguide/tutorial-gpu.html)
+ [Amazon SageMaker AI における深層学習トレーニングの GPU パフォーマンスチューニングのための I/O の最適化](https://aws.amazon.com/blogs/machine-learning/optimizing-i-o-for-gpu-performance-tuning-of-deep-learning-training-in-amazon-sagemaker/)
+ 最新の高性能ライブラリと GPU ドライバーを使用します。
+ 使用しないときは、自動化を使用して GPU インスタンスを解放します。
## リソース
**関連するドキュメント:**
+ [分散された機械学習トレーニング](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/accelerated-computing-instances.html#gpu-instances)
+ [AWS Trainium を搭載したインスタンス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/accelerated-computing-instances.html#aws-trainium-instances)
+ [AWS Inferentia を搭載したインスタンス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/accelerated-computing-instances.html#aws-inferentia-instances)
+ [Let’s Architect\$1 Architecting with custom chips and accelerators](https://aws.amazon.com/blogs/architecture/lets-architect-custom-chips-and-accelerators/)
+ [高速コンピューティング](https://aws.amazon.com/ec2/instance-types/#Accelerated_Computing)
+ [Amazon EC2 VT1 インスタンス](https://aws.amazon.com/ec2/instance-types/vt1/)
+ [ワークロードに適切な Amazon EC2 インスタンスタイプを選択する方法を教えてください。](https://aws.amazon.com/premiumsupport/knowledge-center/ec2-instance-choose-type-for-workload/)
+ [ Choose the best AI accelerator and model compilation for computer vision inference with Amazon SageMaker AI ](https://aws.amazon.com/blogs/machine-learning/choose-the-best-ai-accelerator-and-model-compilation-for-computer-vision-inference-with-amazon-sagemaker/)
**関連動画:**
+ [深層学習用の Amazon EC2 GPU インスタンスの選択方法](https://www.youtube.com/watch?v=4bVrIbgGWEA&ab_channel=AWSEvents)
+ [Deploying Cost-Effective Deep Learning Inference (費用対効果の高い深層学習推論の導入)](https://www.youtube.com/watch?v=WiCougIDRsw&ab_channel=AWSOnlineTechTalks)
# データ管理
# PERF 3。ワークロード内のデータはどのように保存、管理、アクセスすればよいでしょうか?
特定のシステムに最適なデータ管理ソリューションは、データの種類 (ブロック、ファイル、またはオブジェクト)、アクセスパターン (ランダムまたはシーケンシャル)、必要なスループット、アクセス頻度 (オンライン、オフライン、アーカイブ)、更新頻度 (WORM、動的)、および可用性と耐久性に関する制約に応じて異なります。Well-Architected ワークロードは、さまざまな機能によってパフォーマンスを向上させることができる専用のデータストアを使用します。
**Topics**
+ [PERF03-BP01 データアクセスとストレージ要件に最適な専用データストアを使用する](perf_data_use_purpose_built_data_store.md)
+ [PERF03-BP02 データストアで利用可能な設定オプションを評価する](perf_data_evaluate_configuration_options_data_store.md)
+ [PERF03-BP03 データストアのパフォーマンスメトリクスを収集・記録する](perf_data_collect_record_data_store_performance_metrics.md)
+ [PERF03-BP04 データストアのクエリパフォーマンスを向上させるための戦略を実装する](perf_data_implement_strategies_to_improve_query_performance.md)
+ [PERF03-BP05 キャッシュを利用するデータアクセスパターンを実装する](perf_data_access_patterns_caching.md)
# PERF03-BP01 データアクセスとストレージ要件に最適な専用データストアを使用する
データの特性 (共有可能、サイズ、キャッシュサイズ、アクセスパターン、レイテンシー、スループット、データの持続性など) を理解して、ワークロードに適した専用データストア (ストレージまたはデータベース) を選択します。
**一般的なアンチパターン:**
+ 特定のタイプのデータストアに関する社内知識と経験があるため、1 つのデータベースソリューションに固執する。
+ すべてのワークロードのデータの保存とアクセスの要件が類似していると考えている。
+ データアセットのインベントリにデータカタログを実装していない。
**このベストプラクティスを活用するメリット:** データの特性と要件を理解することで、ワークロードのニーズに適した、最も効率的でパフォーマンスの高いストレージテクノロジーを判別できます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
データストレージを選択して実装する際は、クエリ、スケーリング、ストレージの特性がワークロードのデータ要件をサポートしていることを確認します。AWS では、ブロックストレージ、オブジェクトストレージ、ストリーミングストレージ、ファイルシステム、リレーショナル、key-value、ドキュメント、インメモリ、グラフ、時系列、台帳などのデータベースをはじめとした、さまざまなデータストレージとデータベーステクノロジーを提供しています。各データ管理ソリューションには、ユースケースとデータモデルをサポートするために使用できるオプションと設定があります。データの特性と要件を理解することで、モノリシックなストレージテクノロジーや制約の多い汎用的なアプローチから脱却し、データの適切な管理に集中できます。
### 実装手順
+ ワークロードに存在するさまざまなデータタイプを棚卸しします。
+ 次のようなデータの特性と要件を理解して文書化します。
+ データタイプ (非構造化、半構造化、リレーショナル)
+ データ量と増加
+ データ保存期間: 永続、一時的、一過性
+ ACID 特性 (原子性、一貫性、独立性、耐久性) の要件
+ データアクセスパターン (読み取りが多い、または書き込みが多い)
+ レイテンシー
+ スループット
+ IOPS (1 秒あたりの入出力操作数)
+ データの保管期間
+ 各自のデータ特性に合致する、AWS 上のワークロードで使用できるさまざまなデータストアについて確認します (「 [PERF01-BP01 利用可能なクラウドサービスと機能について学び、理解する](perf_architecture_understand_cloud_services_and_features.md)」で説明されています)。AWS のストレージ技術とその主な特徴を例としていくつか挙げます。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2023-10-03/framework/perf_data_use_purpose_built_data_store.html)
+ データプラットフォームを構築する場合は、AWS の [最新のデータアーキテクチャ](https://aws.amazon.com/big-data/datalakes-and-analytics/modern-data-architecture/) を活用して、データレイク、データウェアハウス、専用データストアを統合します。
+ ワークロードのデータストアを選択する際に考慮すべき主なポイントは次のとおりです。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2023-10-03/framework/perf_data_use_purpose_built_data_store.html)
+ 非運用環境で実験とベンチマーキングを行い、どのデータストアがワークロード要件に対応できるかを特定します。
## リソース
**関連ドキュメント:**
+ [Amazon EBS Volume Types](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html)
+ [Amazon EC2 ストレージ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Storage.html)
+ [Amazon EFS: Amazon EFS Performance](https://docs.aws.amazon.com/efs/latest/ug/performance.html)
+ [Amazon FSx for Lustre Performance](https://docs.aws.amazon.com/fsx/latest/LustreGuide/performance.html)
+ [Amazon FSx for Windows File Server Performance](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/performance.html)
+ [Amazon Glacier: Amazon Glacier ドキュメント](https://docs.aws.amazon.com/amazonglacier/latest/dev/introduction.html)
+ [Amazon S3: リクエストレートとパフォーマンスに関する考慮事項](https://docs.aws.amazon.com/AmazonS3/latest/dev/request-rate-perf-considerations.html)
+ [AWS でのクラウドストレージ](https://aws.amazon.com/products/storage/)
+ [Amazon EBS I/O の特性](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ebs-io-characteristics.html)
+ [AWS でのクラウドデータベース ](https://aws.amazon.com/products/databases/?ref=wellarchitected)
+ [AWS Database Caching ](https://aws.amazon.com/caching/database-caching/?ref=wellarchitected)
+ [DynamoDB Accelerator](https://aws.amazon.com/dynamodb/dax/?ref=wellarchitected)
+ [Amazon Aurora を使用する際のベストプラクティス ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.BestPractices.html?ref=wellarchitected)
+ [Amazon Redshift performance ](https://docs.aws.amazon.com/redshift/latest/dg/c_challenges_achieving_high_performance_queries.html?ref=wellarchitected)
+ [Amazon Athena top 10 performance tips ](https://aws.amazon.com/blogs/big-data/top-10-performance-tuning-tips-for-amazon-athena/?ref=wellarchitected)
+ [Amazon Redshift Spectrum ベストプラクティス ](https://aws.amazon.com/blogs/big-data/10-best-practices-for-amazon-redshift-spectrum/?ref=wellarchitected)
+ [Amazon DynamoDB ベストプラクティス](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/BestPractices.html?ref=wellarchitected)
+ [Choose between Amazon EC2 and Amazon RDS](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-sql-server/comparison.html)
+ [ Best Practices for Implementing Amazon ElastiCache ](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/BestPractices.html)
**関連動画:**
+ [Deep dive on Amazon EBS](https://www.youtube.com/watch?v=wsMWANWNoqQ)
+ [Optimize your storage performance with Amazon S3](https://www.youtube.com/watch?v=54AhwfME6wI)
+ [Modernize apps with purpose-built databases](https://www.youtube.com/watch?v=V-DiplATdi0)
+ [ Amazon Aurora storage demystified: How it all works ](https://www.youtube.com/watch?v=uaQEGLKtw54)
+ [ Amazon DynamoDB deep dive: Advanced design patterns ](https://www.youtube.com/watch?v=6yqfmXiZTlM)
**関連する例:**
+ [Amazon EFS CSI Driver](https://github.com/kubernetes-sigs/aws-efs-csi-driver)
+ [Amazon EBS CSI Driver](https://github.com/kubernetes-sigs/aws-ebs-csi-driver)
+ [Amazon EFS Utilities](https://github.com/aws/efs-utils)
+ [Amazon EBS Autoscale](https://github.com/awslabs/amazon-ebs-autoscale)
+ [Amazon S3 のサンプル](https://docs.aws.amazon.com/sdk-for-javascript/v2/developer-guide/s3-examples.html)
+ [Optimize Data Pattern using Amazon Redshift Data Sharing](https://wellarchitectedlabs.com/sustainability/300_labs/300_optimize_data_pattern_using_redshift_data_sharing/)
+ [データベースの移行](https://github.com/aws-samples/aws-database-migration-samples)
+ [MS SQL Server - AWS Database Migration Service (AWS DMS) Replication Demo](https://github.com/aws-samples/aws-dms-sql-server)
+ [Database Modernization Hands On Workshop](https://github.com/aws-samples/amazon-rds-purpose-built-workshop)
+ [Amazon Neptune サンプル](https://github.com/aws-samples/amazon-neptune-samples)
# PERF03-BP02 データストアで利用可能な設定オプションを評価する
データストアで使用できるさまざまな機能と設定オプションを理解して評価し、ワークロードに合わせてストレージ容量とパフォーマンスを最適化します。
**一般的なアンチパターン:**
+ すべてのワークロードに対して、Amazon EBS などの 1 つのストレージタイプのみを使用する。
+ すべてのストレージ層に対して実際のテストを行うことなく、すべてのワークロードにプロビジョンド IOPS を使用する。
+ 選択したデータ管理ソリューションの設定オプションを把握していない。
+ 使用できる設定オプションを確認せずに、インスタンスサイズを増やすことのみに頼っている。
+ データストアのスケーリング特性をテストしていない。
**このベストプラクティスを活用するメリット:** データストア設定を確認し、試してみることで、インフラストラクチャのコストを削減し、パフォーマンスを高め、ワークロードの維持に必要な労力を軽減できる場合があります。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
ワークロードには、データストレージとアクセス要件に基づいて 1 つまたは複数のデータストアを使用できます。パフォーマンス効率とコストを最適化するには、データアクセスパターンを評価し、適切なデータストア設定を判別する必要があります。データストアのオプションを検討する際には、ストレージオプション、メモリ、コンピューティング、リードレプリカ、整合性要件、接続プーリング、キャッシュオプションなど、さまざまな側面を考慮します。こうしたさまざまな設定オプションを試し、パフォーマンス効率のメトリクスを改善します。
### 実装手順
+ データストアの現在の設定 (インスタンスタイプ、ストレージサイズ、データベースエンジンのバージョンなど) を把握します。
+ AWS ドキュメントとベストプラクティスで、データストアのパフォーマンス向上に推奨される設定オプションについて確認します。考慮すべき主なデータストアのオプションは次のとおりです。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2023-10-03/framework/perf_data_evaluate_configuration_options_data_store.html)
+ 非運用環境で実験とベンチマーキングを行い、どの設定オプションがワークロード要件に対応できるかを特定します。
+ 実験が終わったら、移行を計画し、パフォーマンスメトリクスを検証します。
+ AWS のモニタリングツール ( [Amazon CloudWatch ](https://aws.amazon.com/cloudwatch/)など) と最適化ツール ( [Amazon S3 Storage Lens](https://aws.amazon.com/s3/storage-lens/)) などを使用して、実際の使用パターンに基づいてデータストアを継続的に最適化します。
## リソース
**関連ドキュメント:**
+ [AWS でのクラウドストレージ](https://aws.amazon.com/products/storage/?ref=wellarchitected)
+ [Amazon EBS Volume Types](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html)
+ [Amazon EC2 ストレージ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Storage.html)
+ [Amazon EFS: Amazon EFS Performance](https://docs.aws.amazon.com/efs/latest/ug/performance.html)
+ [Amazon FSx for Lustre Performance](https://docs.aws.amazon.com/fsx/latest/LustreGuide/performance.html)
+ [Amazon FSx for Windows File Server Performance](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/performance.html)
+ [Amazon Glacier: Amazon Glacier ドキュメント](https://docs.aws.amazon.com/amazonglacier/latest/dev/introduction.html)
+ [Amazon S3: リクエストレートとパフォーマンスに関する考慮事項](https://docs.aws.amazon.com/AmazonS3/latest/dev/request-rate-perf-considerations.html)
+ [AWS でのクラウドストレージ](https://aws.amazon.com/products/storage/)
+ [AWS でのクラウドストレージ](https://aws.amazon.com/products/storage/?ref=wellarchitected)
+ [Amazon EBS I/O の特性](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ebs-io-characteristics.html)
+ [AWS でのクラウドデータベース ](https://aws.amazon.com/products/databases/?ref=wellarchitected)
+ [AWS Database Caching ](https://aws.amazon.com/caching/database-caching/?ref=wellarchitected)
+ [DynamoDB Accelerator](https://aws.amazon.com/dynamodb/dax/?ref=wellarchitected)
+ [Amazon Aurora を使用する際のベストプラクティス ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.BestPractices.html?ref=wellarchitected)
+ [Amazon Redshift performance ](https://docs.aws.amazon.com/redshift/latest/dg/c_challenges_achieving_high_performance_queries.html?ref=wellarchitected)
+ [Amazon Athena top 10 performance tips ](https://aws.amazon.com/blogs/big-data/top-10-performance-tuning-tips-for-amazon-athena/?ref=wellarchitected)
+ [Amazon Redshift Spectrum ベストプラクティス ](https://aws.amazon.com/blogs/big-data/10-best-practices-for-amazon-redshift-spectrum/?ref=wellarchitected)
+ [Amazon DynamoDB ベストプラクティス](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/BestPractices.html?ref=wellarchitected)
**関連動画:**
+ [Deep dive on Amazon EBS](https://www.youtube.com/watch?v=wsMWANWNoqQ)
+ [Optimize your storage performance with Amazon S3](https://www.youtube.com/watch?v=54AhwfME6wI)
+ [Modernize apps with purpose-built databases](https://www.youtube.com/watch?v=V-DiplATdi0)
+ [ Amazon Aurora storage demystified: How it all works ](https://www.youtube.com/watch?v=uaQEGLKtw54)
+ [ Amazon DynamoDB deep dive: Advanced design patterns ](https://www.youtube.com/watch?v=6yqfmXiZTlM)
**関連する例:**
+ [Amazon EFS CSI Driver](https://github.com/kubernetes-sigs/aws-efs-csi-driver)
+ [Amazon EBS CSI Driver](https://github.com/kubernetes-sigs/aws-ebs-csi-driver)
+ [Amazon EFS Utilities](https://github.com/aws/efs-utils)
+ [Amazon EBS Autoscale](https://github.com/awslabs/amazon-ebs-autoscale)
+ [Amazon S3 のサンプル](https://docs.aws.amazon.com/sdk-for-javascript/v2/developer-guide/s3-examples.html)
+ [Amazon DynamoDB サンプル](https://github.com/aws-samples/aws-dynamodb-examples)
+ [AWS データベース移行サンプル](https://github.com/aws-samples/aws-database-migration-samples)
+ [Database Modernization Workshop](https://github.com/aws-samples/amazon-rds-purpose-built-workshop)
+ [Working with parameters on your Amazon RDS for Postgress DB](https://github.com/awsdocs/amazon-rds-user-guide/blob/main/doc_source/Appendix.PostgreSQL.CommonDBATasks.Parameters.md)
# PERF03-BP03 データストアのパフォーマンスメトリクスを収集・記録する
データストアに関連するパフォーマンスメトリクスを追跡して記録することで、データ管理ソリューションのパフォーマンスを把握できます。こうしたメトリクスは、データストアの最適化を行い、ワークロードの要件が満たされていることを確認し、ワークロードのパフォーマンスを明確に把握するのに役立ちます。
**一般的なアンチパターン:**
+ メトリクスの検索に手動ログファイルのみを使用している。
+ チームが使用する内部ツールにのみメトリクスを発行しており、ワークロードの全体像を把握できていない。
+ 一部のモニタリングソフトウェアで記録されるデフォルトのメトリクスのみを使用している。
+ 問題が発生したときにだけメトリクスを確認している。
+ システムレベルのメトリクスのみをモニタリングし、データアクセスや使用状況に関するメトリクスを把握していない。
**このベストプラクティスを活用するメリット:** パフォーマンスのベースラインを確立すると、ワークロードの通常の動作とワークロードの要件を理解するのに役立ちます。異常なパターンをより迅速に特定してデバッグできるため、データストアのパフォーマンスと信頼性が向上します。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
データストアのパフォーマンスをモニタリングするには、一定期間にわたって複数のパフォーマンスメトリクスを記録する必要があります。これにより、異常を検出できるだけでなく、ビジネスメトリクスに照らしてパフォーマンスを測定して、ワークロードのニーズを満たしていることを確認できます。
メトリクスは、データストアをサポートする基盤システムとデータストア自体の両方のメトリクスが含まれている必要があります。基盤システムのメトリクスには、CPU 使用率、メモリ、使用可能なディスク容量、ディスク I/O、キャッシュヒット率、ネットワークのインバウンドとアウトバウンドに関するメトリクスなどがあり、データストアのメトリクスには 1 秒あたりのトランザクション数、上位のクエリ、平均クエリレート、応答時間、インデックス使用率、テーブルロック、クエリのタイムアウトの数、開いている接続の数などがあります。このデータは、ワークロードのパフォーマンスやデータ管理ソリューションの使用状況を理解するために不可欠です。これらのメトリクスをデータ駆動型アプローチの一部として使用し、ワークロードのリソースを調整および最適化します。
データベースのパフォーマンスに関連するパフォーマンスの測定値を記録するツール、ライブラリ、システムを使用します。
## 実装手順
1. データストアで追跡すべき主要なパフォーマンスメトリクスを特定します。
1. [Amazon S3 のメトリクスとディメンション](https://docs.aws.amazon.com/AmazonS3/latest/userguide/metrics-dimensions.html)
1. [Amazon RDS インスタンスのモニタリングメトリクス](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Monitoring.html)
1. [Amazon RDS での Performance Insights を使用した DB 負荷のモニタリング](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.html)
1. [Enhanced Monitoring の概要](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.overview.html)
1. [DynamoDBのメトリクスとディメンション](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html)
1. [DynamoDB Accelerator のモニタリング](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/DAX.Monitoring.html)
1. [Amazon CloudWatch を使用した Amazon MemoryDB のモニタリング](https://docs.aws.amazon.com/memorydb/latest/devguide/monitoring-cloudwatch.html)
1. [モニタリングすべきメトリクス](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/CacheMetrics.WhichShouldIMonitor.html)
1. [Amazon Redshift クラスターのパフォーマンスのモニタリング](https://docs.aws.amazon.com/redshift/latest/mgmt/metrics.html)
1. [Timestream のメトリクスとディメンション](https://docs.aws.amazon.com/timestream/latest/developerguide/metrics-dimensions.html)
1. [Amazon Aurora での Amazon CloudWatch メトリクス](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.AuroraMonitoring.Metrics.html)
1. [Amazon Keyspaces (for Apache Cassandra) でのログ記録とモニタリング](https://docs.aws.amazon.com/keyspaces/latest/devguide/monitoring.html)
1. [Amazon Neptune リソースのモニタリング](https://docs.aws.amazon.com/neptune/latest/userguide/monitoring.html)
1. 承認されたロギングおよびモニタリングソリューションを使用して、これらのメトリクスを収集します。 [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) では、アーキテクチャ内のリソース全体のメトリクスを収集できます。また、カスタムメトリクスを収集および発行して、ビジネスメトリクスまたは導出メトリクスを表面化することも可能です。CloudWatch またはサードパーティーのソリューションを使用して、しきい値を超過したことを示すアラームを設定します。
1. データストアのモニタリングに、パフォーマンスの異常を検出する機械学習ソリューションが役立つかどうかを確認します。
1. [Amazon DevOps Guru for Amazon RDS](https://docs.aws.amazon.com/devops-guru/latest/userguide/working-with-rds.overview.how-it-works.html) は、パフォーマンス上の問題を可視化し、是正措置についての推奨事項を提供します。
1. セキュリティと運用の目標に合わせて、モニタリングおよびログ記録ソリューションのデータ保持を設定します。
1. [CloudWatch メトリクスのデフォルトのデータ保持](https://aws.amazon.com/cloudwatch/faqs/#AWS_resource_.26_custom_metrics_monitoring)
1. [CloudWatch Logs のデフォルトのデータ保持](https://aws.amazon.com/cloudwatch/faqs/#Log_management)
## リソース
**関連ドキュメント:**
+ [AWS Database Caching (AWS データベースキャッシング)](https://aws.amazon.com/caching/database-caching/)
+ [Amazon Athena top 10 performance tips](https://aws.amazon.com/blogs/big-data/top-10-performance-tuning-tips-for-amazon-athena/)
+ [Amazon Aurora を使用する際のベストプラクティス](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.BestPractices.html)
+ [DynamoDB Accelerator](https://aws.amazon.com/dynamodb/dax/)
+ [Amazon DynamoDB ベストプラクティス](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/BestPractices.html)
+ [Amazon Redshift Spectrum ベストプラクティス](https://aws.amazon.com/blogs/big-data/10-best-practices-for-amazon-redshift-spectrum/)
+ [Amazon Redshift performance](https://docs.aws.amazon.com/redshift/latest/dg/c_challenges_achieving_high_performance_queries.html)
+ [AWS でのクラウドデータベース](https://aws.amazon.com/products/databases/)
+ [Amazon RDS Performance Insights](https://aws.amazon.com/rds/performance-insights/)
**関連動画:**
+ [AWS purpose-built databases](https://www.youtube.com/watch?v=q81TVuV5u28)
+ [Amazon Aurora storage demystified: How it all works](https://www.youtube.com/watch?v=uaQEGLKtw54)
+ [Amazon DynamoDB deep dive: Advanced design patterns](https://www.youtube.com/watch?v=6yqfmXiZTlM)
+ [Best Practices for Monitoring Redis Workloads on Amazon ElastiCache](https://www.youtube.com/watch?v=c-hTMLN35BY&ab_channel=AWSOnlineTechTalks)
**関連する例:**
+ [Level 100: Monitoring with CloudWatch Dashboards](https://wellarchitectedlabs.com/performance-efficiency/100_labs/100_monitoring_with_cloudwatch_dashboards/)
+ [AWS Dataset Ingestion Metrics Collection Framework](https://github.com/awslabs/aws-dataset-ingestion-metrics-collection-framework)
+ [Amazon RDS Monitoring Workshop](https://www.workshops.aws/?tag=Enhanced%20Monitoring)
# PERF03-BP04 データストアのクエリパフォーマンスを向上させるための戦略を実装する
データを最適化し、データクエリを改善する戦略を実装して、ワークロードのスケーラビリティとパフォーマンスを向上させます。
**一般的なアンチパターン:**
+ データストア内のデータをパーティション化しない。
+ データストアへのデータの格納に 1 つのファイル形式のみを使用する。
+ データストアでインデックスを使用しない。
**このベストプラクティスを活用するメリット:** データとクエリのパフォーマンスを最適化することで、効率の向上、コストの削減、ユーザーエクスペリエンスの向上につながります。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
データ最適化とクエリチューニングはデータストアのパフォーマンス効率の重要な側面であり、クラウドワークロード全体のパフォーマンスと応答性に影響を与えます。クエリが最適化されていないと、リソースの使用量が増え、ボトルネックが発生し、データストアの全体的な効率が低下する可能性があります。
データ最適化には、効率的なデータストレージとアクセスを確保する手法がいくつかあります。これは、データストアでのクエリパフォーマンスの向上にも役立ちます。主な戦略には、データのパーティション化、データ圧縮、データ非正規化などがあり、ストレージとアクセスの両方でデータを最適化するのに役立ちます。
### 実装手順
+ データストアで実行される重要なデータクエリを把握して分析します。
+ データストア内で処理速度の遅いクエリを特定し、クエリプランを使用して現在の状態を把握します。
+ [Amazon Redshift でのクエリプランの分析](https://docs.aws.amazon.com/redshift/latest/dg/c-analyzing-the-query-plan.html)
+ [Athena での EXPLAIN および EXPLAIN ANALYZE の使用](https://docs.aws.amazon.com/athena/latest/ug/athena-explain-statement.html)
+ クエリのパフォーマンスを向上させるための戦略を実装します。主な戦略には次のものがあります。
+ 列指向ファイル形式 [を使用する](https://docs.aws.amazon.com/athena/latest/ug/columnar-storage.html) (Parquet または ORC など)。
+ データストア内のデータを圧縮して、ストレージ容量と I/O 操作を削減する。
+ データのパーティション化によりデータを細かく分割し、データスキャン時間を短縮する。
+ [ Athena でのデータのパーティション化 ](https://docs.aws.amazon.com/athena/latest/ug/partitions.html)
+ [ パーティションとデータ分散 ](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.Partitions.html)
+ クエリでよく使用される列にデータインデックスを作成する。
+ クエリに適した結合操作を選択する。2 つのテーブルを結合する場合、結合の左側に大きい方のテーブルを指定し、結合の右側に小さい方のテーブルを指定します。
+ 分散キャッシュソリューションでレイテンシーを改善し、データベースの I/O 操作の数を減らす。
+ 統計の実行などの定期的なメンテナンスを実施する。
+ 非運用環境で実験し、戦略をテストする。
## リソース
**関連するドキュメント:**
+ [Amazon Aurora を使用する際のベストプラクティス ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.BestPractices.html?ref=wellarchitected)
+ [Amazon Redshift performance ](https://docs.aws.amazon.com/redshift/latest/dg/c_challenges_achieving_high_performance_queries.html?ref=wellarchitected)
+ [Amazon Athena top 10 performance tips](https://aws.amazon.com/blogs/big-data/top-10-performance-tuning-tips-for-amazon-athena/?ref=wellarchitected)
+ [AWS Database Caching ](https://aws.amazon.com/caching/database-caching/?ref=wellarchitected)
+ [Best Practices for Implementing Amazon ElastiCache](https://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/BestPractices.html)
+ [Partitioning data in Athena](https://docs.aws.amazon.com/athena/latest/ug/partitions.html)
**関連動画:**
+ [Optimize Data Pattern using Amazon Redshift Data Sharing](https://wellarchitectedlabs.com/sustainability/300_labs/300_optimize_data_pattern_using_redshift_data_sharing/)
+ [Optimize Amazon Athena Queries with New Query Analysis Tools ](https://www.youtube.com/watch?v=7JUyTqglmNU&ab_channel=AmazonWebServices)
**関連する例:**
+ [Amazon EFS CSI Driver](https://github.com/kubernetes-sigs/aws-efs-csi-driver)
# PERF03-BP05 キャッシュを利用するデータアクセスパターンを実装する
頻繁にアクセスされるデータを高速に取得できるようにデータをキャッシュする利点が得られるアクセスパターンを実装します。
**一般的なアンチパターン:**
+ 頻繁に変更されるデータをキャッシュする。
+ あたかも永続的に保存され、常に利用できるかのように、キャッシュされたデータに依存する。
+ キャッシュされたデータの一貫性が考慮されない。
+ キャッシュ実装の効率をモニタリングしない。
**このベストプラクティスを活用するメリット:** データをキャッシュに保存すると、読み取りレイテンシー、読み取りスループット、ユーザーエクスペリエンス、全体的な効率が向上し、コストも削減されます。
**このベストプラクティスを活用しない場合のリスクレベル**: 中程度
## 実装のガイダンス
キャッシュとは、同じデータに対する今後のリクエストの処理を高速化したり効率性を向上したりするために、データを保存することを目的としたソフトウェアまたはハードウェアコンポーネントです。キャッシュに保存されたデータは、失われた場合でも、前の計算を繰り返すか、別のデータストアから取得することで再構築できます。
データキャッシュは、アプリケーション全体のパフォーマンスを向上させ、基盤となるプライマリデータソースの負担を軽減するうえで、最も効果的な戦略の 1 つです。データは、アプリケーション内の複数のレベルでキャッシュできます。例えば、 *クライアント側のキャッシュ*と呼ばれ、リモートコールを実行するアプリケーション内のキャッシュ、または *リモートキャッシュ*と呼ばれる、データ保存用の高速セカンダリサービスを使ってデータを保存することもできます。
**クライアント側のキャッシュ**
クライアント側のキャッシュを使用すると、各クライアント (バックエンドデータストアにクエリを実行するアプリケーションまたはサービス) は、独自のクエリの結果を指定された期間、ローカルに保存できます。これにより、最初にローカルのクライアントキャッシュを確認することで、ネットワーク経由でデータストアに送信されるリクエストの数を低減できます。結果がキャッシュに存在しない場合、アプリケーションはデータストアにクエリを実行し、その結果をローカルに保存できます。このパターンにより、各クライアントは可能な限り最も近い場所 (クライアント自体) にデータを保存できるため、レイテンシーを最小限に抑えることができます。また、バックエンドデータストアが使用できない場合でも、クライアントは引き続きクエリの一部を処理できるため、システム全体の可用性が向上します。
この方法の欠点の 1 つは、複数のクライアントが関係する場合、同じキャッシュデータをローカルに保存する可能性があることです。その結果、このようなクライアント間でストレージが重複して使用されることになり、データの不整合が発生します。あるクライアントがクエリの結果をキャッシュし、1 分後に別のクライアントが同じクエリを実行して別の結果を取得する場合もあります。
**リモートキャッシュ**
クライアント間で重複するデータの問題を解決するには、高速外部サービス、つまり *リモートキャッシュ*を使用してクエリしたデータを保存します。ローカルデータストアをチェックする代わりに、各クライアントはバックエンドデータストアへのクエリを実行する前にリモートキャッシュをチェックします。この戦略により、クライアント間の応答の一貫性が強化され、保存されたデータの効率が向上し、ストレージスペースがクライアントとは別個にスケールされるため、キャッシュされたデータの量が増大します。
リモートキャッシュの欠点は、リモートキャッシュをチェックするために追加のネットワークホップが必要になるため、システム全体のレイテンシーが増大する可能性がある点です。クライアント側のキャッシュをリモートキャッシュと併用してマルチレベルキャッシュを行うことで、レイテンシーを短縮できます。
### 実装手順
1. キャッシュの利点を活用できるデータベース、API、ネットワークサービスを特定します。読み取りワークロードが高いサービス、読み取りと書き込み率が高いサービス、またはスケールするのにコストがかかるサービスなどが、キャッシュの候補となります。
+ [データベースのキャッシュ](https://aws.amazon.com/caching/database-caching/)
+ [API キャッシュを有効にして応答性を強化する](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-caching.html)
1. アクセスパターンに最適なキャッシュ戦略の種類を特定します。
+ [キャッシュ戦略](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Strategies.html)
+ [AWS キャッシュソリューション](https://aws.amazon.com/caching/aws-caching/)
1. データストアについては、 [キャッシュのベストプラクティス](https://aws.amazon.com/caching/best-practices/) に従います。
1. すべてのデータに対して有効期間 (TTL) などのキャッシュ無効化戦略を設定し、データの鮮度とバックエンドデータストアへの負荷の軽減の間でバランスをとります。
1. 自動接続再試行、エクスポネンシャルバックオフ、クライアント側のタイムアウト、接続プーリングなどの機能が利用できる場合は、クライアントで有効にします。これにより、パフォーマンスと信頼性が向上します。
+ [ベストプラクティス: Redis クライアントと Amazon ElastiCache (Redis OSS)](https://aws.amazon.com/blogs/database/best-practices-redis-clients-and-amazon-elasticache-for-redis/)
1. 80% 以上を目標にキャッシュヒットレートをモニタリングします。値が低い場合は、キャッシュサイズが不十分であるか、キャッシュの利点を活用できないアクセスパターンである可能性があります。
+ [モニタリングすべきメトリクス](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/CacheMetrics.WhichShouldIMonitor.html)
+ [Amazon ElastiCache での Redis ワークロードモニタリングのベストプラクティス](https://www.youtube.com/watch?v=c-hTMLN35BY)
+ [Amazon CloudWatch を使用した Amazon ElastiCache (Redis OSS) のモニタリングのベストプラクティス](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/)
1. [データレプリケーション](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Replication.Redis.Groups.html) を実装して読み取りを複数のインスタンスにオフロードし、データ読み取りのパフォーマンスと可用性を向上させます。
## リソース
**関連するドキュメント:**
+ [Amazon ElastiCache Well-Architected レンズの使用](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/WellArchitechtedLens.html)
+ [Amazon CloudWatch を使用した Amazon ElastiCache (Redis OSS) のモニタリングのベストプラクティス](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/)
+ [モニタリングすべきメトリクス](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/CacheMetrics.WhichShouldIMonitor.html)
+ [「Amazon ElastiCache を使用した大規模環境でのパフォーマンス」ホワイトペーパー](https://docs.aws.amazon.com/whitepapers/latest/scale-performance-elasticache/scale-performance-elasticache.html)
+ [キャッシングの課題と戦略](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
**関連動画:**
+ [Amazon ElastiCache ラーニングパス](https://pages.awscloud.com/GLB-WBNR-AWS-OTT-2021_LP_0003-DAT_AmazonElastiCache.html)
+ [Amazon ElastiCache 設計のベストプラクティス](https://youtu.be/_4SkEy6r-C4)
**関連する例:**
+ [Amazon ElastiCache (Redis OSS) を使用したMySQL データベースのパフォーマンス向上](https://aws.amazon.com/getting-started/hands-on/boosting-mysql-database-performance-with-amazon-elasticache-for-redis/)
# ネットワークとコンテンツ配信
# PERF 4。ワークロード内のネットワークリソースはどのように選択して構成すればよいでしょうか?
システムにとって効果的なデータベースソリューションは、可用性、整合性、分断耐性、レイテンシー、耐久性、スケーラビリティ、クエリ機能などの要件に応じて異なります。多くのシステムでは、各種サブシステムに異なるデータベースソリューションを使用しているため、パフォーマンスを向上させるために活用する機能を有効にします。システムに対して適切でないデータベースソリューションや機能を選択すると、パフォーマンス効率が低下する場合があります。
**Topics**
+ [PERF04-BP01 ネットワークがパフォーマンスに与える影響を理解する](perf_networking_understand_how_networking_impacts_performance.md)
+ [PERF04-BP02 使用可能なネットワーク機能を評価する](perf_networking_evaluate_networking_features.md)
+ [PERF04-BP03 ワークロードに適した専用接続または VPN を選択する](perf_networking_choose_appropriate_dedicated_connectivity_or_vpn.md)
+ [PERF04-BP04 ロードバランシングを使用してトラフィックを複数のリソースに分散する](perf_networking_load_balancing_distribute_traffic.md)
+ [PERF04-BP05 パフォーマンスを高めるネットワークプロトコルを選択する](perf_networking_choose_network_protocols_improve_performance.md)
+ [PERF04-BP06 ネットワーク要件に基づいてワークロードのロケーションを選択する](perf_networking_choose_workload_location_network_requirements.md)
+ [PERF04-BP07 メトリクスに基づいてネットワーク設定を最適化する](perf_networking_optimize_network_configuration_based_on_metrics.md)
# PERF04-BP01 ネットワークがパフォーマンスに与える影響を理解する
ネットワーク関連の意思決定がワークロードに与える影響を分析して理解し、効率的なパフォーマンスとユーザーエクスペリエンスの向上を実現します。
**一般的なアンチパターン:**
+ すべてのトラフィックが既存のデータセンターを通過する。
+ クラウドネイティブなネットワークセキュリティツールを使用せずに、すべてのトラフィックを中央のファイアウォール経由でルーティングする。
+ 実際の使用要件を理解せずに AWS Direct Connect 接続をプロビジョニングする。
+ ワークロードの特性および暗号化にかかるコストを考慮しない。
+ クラウドのネットワーク戦略にオンプレミスのコンセプトと戦略を使用する。
**このベストプラクティスを活用するメリット:** ネットワークがワークロードのパフォーマンスに与える影響を理解することで、潜在的なボトルネックの特定、ユーザーエクスペリエンスの改善、信頼性の向上を実現しながら、ワークロードの変化に伴う運用保守業務を軽減できます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
ネットワークは、アプリケーションコンポーネント、クラウドサービス、エッジネットワーク、オンプレミスデータ間の接続を担っているため、ワークロードのパフォーマンスに大きな影響を与える可能性があります。ワークロードのパフォーマンスに加え、ユーザーエクスペリエンスも、ネットワークのレイテンシー、帯域幅、プロトコル、場所、ネットワークの混雑、ジッター、スループット、ルーティングルールの影響を受ける可能性があります。
レイテンシー、パケットサイズ、ルーティングルール、プロトコル、サポートするトラフィックパターンなど、ワークロードのネットワーク要件をまとめて文書化します。利用可能なネットワークソリューションを確認し、ワークロードのネットワーク特性に適合するサービスを特定します。クラウドベースのネットワークは迅速に再構築できるため、パフォーマンス効率を向上させるためにもネットワーク アーキテクチャを時間とともに進化させる必要があります。
### 実装手順:
1. ネットワークのレイテンシー、帯域幅、プロトコル、場所、トラフィックパターン (急増とその頻度)、スループット、暗号化、点検、ルーティングルールなどのメトリクスを含め、ネットワークパフォーマンス要件を定義し、文書化します。
1. AWS の主要なネットワークサービス ( [VPC](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)、[AWS Direct Connect](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/aws-direct-connect.html)、[Elastic Load Balancing (ELB)](https://aws.amazon.com/elasticloadbalancing/)、 [Amazon Route 53](https://aws.amazon.com/r53/)など) について学びます。
1. 次の主要なネットワーク特性を把握します。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2023-10-03/framework/perf_networking_understand_how_networking_impacts_performance.html)
1. ネットワークパフォーマンスをベンチマーキングし、テストします。
1. [ネットワークスループットをベンチマーキング](https://aws.amazon.com/premiumsupport/knowledge-center/network-throughput-benchmark-linux-ec2/) する: インスタンスが同じ VPC 内にある場合、いくつかの要因が Amazon EC2 のネットワークパフォーマンスに影響する可能性があるため。同じ VPC 内で Amazon EC2 Linux インスタンス間のネットワーク帯域幅を測定します。
1. 負荷 [テスト](https://aws.amazon.com/solutions/implementations/distributed-load-testing-on-aws/) を実行し、ネットワークソリューションとオプションを試します。
## リソース
**関連するドキュメント:**
+ [Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html)
+ [Linux での EC2 拡張ネットワーキング](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/enhanced-networking.html)
+ [Windows での EC2 拡張ネットワーキング](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/enhanced-networking.html)
+ [EC2 プレイスメントグループ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html)
+ [Linux インスタンスで Elastic Network Adapter (ENA) を使用して拡張ネットワークを有効にする](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/enhanced-networking-ena.html)
+ [Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html)
+ [AWS ネットワークとコンテンツ配信](https://aws.amazon.com/products/networking/)
+ [Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw)
+ [Amazon Route 53 でレイテンシーベースルーティングへ移行する](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/TutorialTransitionToLBR.html)
+ [VPC エンドポイント](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints.html)
+ [VPC フローログ](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html)
**関連動画:**
+ [Connectivity to AWS and hybrid AWS network architectures](https://www.youtube.com/watch?v=eqW6CPb58gs)
+ [Optimizing Network Performance for Amazon EC2 Instances](https://www.youtube.com/watch?v=DWiwuYtIgu0)
+ [Improve Global Network Performance for Applications](https://youtu.be/vNIALfLTW9M)
+ [EC2 Instances and Performance Optimization Best Practices](https://youtu.be/W0PKclqP3U0)
+ [Optimizing Network Performance for Amazon EC2 Instances](https://youtu.be/DWiwuYtIgu0)
+ [Networking best practices and tips with the Well-Architected Framework](https://youtu.be/wOMNpG49BeM)
+ [AWS networking best practices in large-scale migrations](https://youtu.be/qCQvwLBjcbs)
**関連する例:**
+ [AWS Transit Gateway and Scalable Security Solutions](https://github.com/aws-samples/aws-transit-gateway-and-scalable-security-solutions)
+ [AWS Networking Workshops](https://networking.workshop.aws/)
# PERF04-BP02 使用可能なネットワーク機能を評価する
パフォーマンスの向上に役立つ可能性のあるクラウドのネットワーク機能を評価します。これらの機能の影響を、テスト、メトリクス、および分析を使って測定してください。例えば、レイテンシー、ネットワーク距離、またはジッターを低減するために利用できるネットワークレベルの機能を活用します。
**一般的なアンチパターン:**
+ 本社の物理的な所在地を理由に、1 つのリージョン内に留まる。
+ セキュリティグループの代わりにファイアウォールを使用してトラフィックをフィルタリングする。
+ セキュリティグループ、エンドポイントポリシー、その他のクラウドネイティブ機能に頼らず、トラフィック検査のために TLS を破る。
+ セキュリティグループではなく、サブネットベースのセグメンテーションのみを使用する。
**このベストプラクティスを活用するメリット:** すべてのサービス機能とオプションを評価することにより、ワークロードパローマンスを向上させ、インフラストラクチャのコストを削減し、ワークロードを維持するために必要な労力を減らし、全体的なセキュリティ体制を強化できます。グローバルな AWS のバックボーンを活用すれば、最適なネットワークエクスペリエンスを顧客に提供することができます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
AWS は、 [AWS Global Accelerator](https://aws.amazon.com/global-accelerator/) や [Amazon CloudFront](https://aws.amazon.com/cloudfront/) などのサービスを提供します。これはネットワークパフォーマンスの向上に役立ちますが、ほとんどの AWS サービスには製品機能 ( [Amazon S3 Transfer Acceleration](https://aws.amazon.com/s3/transfer-acceleration/) 機能) があり、ネットワークトラフィックを最適化します。
ネットワーク関連の設定オプションにはどのようなものがあるか、またそれらがワークロードにどのような影響を与えるかを確認します。パフォーマンスの最適化は、これらのオプションがアーキテクチャとどのように相互作用し、測定されたパフォーマンスとユーザーエクスペリエンスの両方に与える影響をいかに理解できるかにかかっています。
### 実装手順
+ ワークロードコンポーネントのリストを作成します。
+ 統一されたグローバルネットワークを構築する場合は、 [AWS クラウド WAN](https://aws.amazon.com/cloud-wan/) を使用して組織のネットワークを構築、管理、監視することを検討します。
+ グローバルネットワークとコアネットワークを [Amazon CloudWatch Logs のメトリクス](https://docs.aws.amazon.com/network-manager/latest/tgwnm/monitoring-cloudwatch-metrics.html)でモニタリングします。ユーザーのデジタルエクスペリエンスを特定、把握、強化するために役立つインサイトを提供する [Amazon CloudWatch RUM](https://aws.amazon.com/about-aws/whats-new/2021/11/amazon-cloudwatch-rum-applications-client-side-performance/) を活用します。
+ AWS リージョン とアベイラビリティーゾーン、各アベイラビリティーゾーン内の合計ネットワークレイテンシーを [AWS Network Manager](https://aws.amazon.com/transit-gateway/network-manager/) を使用して表示することで、アプリケーションのパフォーマンスと基礎となる AWS ネットワークのパフォーマンスとの関係を把握できます。
+ 既存の構成管理データベース (CMDB) ツールまたはサービス ( [AWS Config](https://aws.amazon.com/config/) など) を使用して、ワークロードや設定方法のインベントリを作成します。
+ これが既存のワークロードである場合、ボトルネックや改善すべき領域に特化して、パフォーマンスメトリクスのベンチマークを特定し、文書化します。パフォーマンスに関連するネットワークメトリクスは、ビジネス要件やワークロード特性により、ワークロードごとに異なります。最初のうちは、帯域幅、レイテンシー、パケットロス、ジッター、再送信などのメトリックスを確認することが重要かもしれません。
+ これが新しいワークロードである場合は、 [負荷テスト](https://aws.amazon.com/solutions/implementations/distributed-load-testing-on-aws/) を実施して、パフォーマンスのボトルネックを特定します。
+ 特定したパフォーマンスのボトルネックに対して、ソリューションの設定オプションを確認し、パフォーマンス改善の機会を見つけます。次の主要なネットワークオプションと特徴を確認してください:
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2023-10-03/framework/perf_networking_evaluate_networking_features.html)
## リソース
**関連ドキュメント:**
+ [Amazon EBS – 最適化インスタンス ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-optimized.html)
+ [Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html)
+ [Linux での EC2 拡張ネットワーキング ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/enhanced-networking.html)
+ [Windows での EC2 拡張ネットワーキング ](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/enhanced-networking.html)
+ [EC2 プレイスメントグループ ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html)
+ [Linux インスタンスで Elastic Network Adapter (ENA) を使用して拡張ネットワークを有効にする ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/enhanced-networking-ena.html)
+ [Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html)
+ [AWS ネットワークとコンテンツ配信](https://aws.amazon.com/products/networking/)
+ [AWS Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)
+ [Amazon Route 53 でレイテンシーベースルーティングへ移行する](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/TutorialTransitionToLBR.html)
+ [VPC エンドポイント](https://docs.aws.amazon.com/vpc/latest/privatelink/concepts.html)
+ [VPC フローログ](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html)
**関連動画:**
+ [Connectivity to AWS and hybrid AWS network architectures](https://www.youtube.com/watch?v=eqW6CPb58gs)
+ [Optimizing Network Performance for Amazon EC2 Instances](https://www.youtube.com/watch?v=DWiwuYtIgu0)
+ [AWS Global Accelerator](https://www.youtube.com/watch?v=Docl4julOQw)
**関連する例:**
+ [AWS Transit Gateway and Scalable Security Solutions ](https://github.com/aws-samples/aws-transit-gateway-and-scalable-security-solutions)
+ [AWS Networking Workshops](https://catalog.workshops.aws/networking/en-US)
# PERF04-BP03 ワークロードに適した専用接続または VPN を選択する
オンプレミスのリソースとクラウドのリソースを接続するためにハイブリッド接続が必要な場合は、パフォーマンス要件を満たす十分な帯域幅をプロビジョニングします。ハイブリッドワークロードの帯域幅とレイテンシーの要件を見積もります。これらの値によってサイズ要件が決まります。
**一般的なアンチパターン:**
+ ネットワークの暗号化要件の VPN ソリューションのみを評価する。
+ バックアップ接続または冗長接続の選択肢を評価しない。
+ ワークロードのすべての要件 (暗号化、プロトコル、帯域幅、トラフィックのニーズ) を特定しない。
**このベストプラクティスを活用するメリット:** 適切な接続ソリューションを選択して構成することで、ワークロードの信頼性を高め、パフォーマンスを最大化できます。ワークロード要件を特定して事前計画を行い、ハイブリッドソリューションを評価することで、時間対価値を高めながら、コストの高いネットワークの物理的変更と運用上の諸経費を最小限に抑えることができます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
帯域幅要件に基づいてハイブリッドネットワーキングアーキテクチャを開発します。[Direct Connect](https://aws.amazon.com/directconnect/) を使用すると、オンプレミスネットワークを AWS にプライベート接続できます。一貫したパフォーマンスを達成しながら、高帯域幅、低レイテンシーが求められる場合に適しています。VPN 接続は、インターネット上で安全な接続を確立します。一時的な接続のみが必要な場合、コストが重要な場合、または Direct Connect 使用時に耐障害性のある物理ネットワーク接続が確立されるのを待つ間、不測の事態に備えて使用されます。
帯域幅の要件が高い場合は、Direct Connect または VPN サービスを複数使用することを検討します。トラフィックはサービス間で負荷分散できますが、レイテンシ―と帯域幅の違いから、Direct Connect と VPN 間でのロードバランシングはお勧めしません。
### 実装手順
1. 既存のアプリケーションの帯域幅とレイテンシーの要件を見積もります。
1. AWS に移行している既存のワークロードについては、内部ネットワークモニタリングシステムからのデータを活用します。
1. モニタリングデータがない新規または既存のワークロードついては、プロダクトオーナーと相談のうえ、適切なパフォーマンスメトリクスを導き出し、優れたユーザーエクスペリエンスを提供します。
1. 接続オプションとして専用接続または VPN 接続を選択します。すべてのワークロード要件 (暗号化、帯域幅、トラフィックのニーズ) に基づいて、AWS Direct Connect または [Site-to-Site VPN](https://aws.amazon.com/vpn/) (あるいは両方) を選択できます。下の図は、適切な接続タイプの選択に役立ちます。
1. [AWS Direct Connect](https://aws.amazon.com/directconnect/) は、専用接続またはホスト接続を使用して、50 Mbps から 100 Gbps の AWS 環境への専用接続を提供します。これにより、管理および制御されたレイテンシーとプロビジョニングされた帯域幅が提供され、ワークロードが効率の良い方法でその他の環境に接続できます。AWS Direct Connect パートナーを使用すると、複数の環境からエンドツーエンドの接続を確立し、一貫性あるパフォーマンスを備えた拡張ネットワークを実現できます。AWS を使用すると、ネイティブ 100 Gbps、Link Aggregation Group (LAG)、または BGP Equal-cost multipath (ECMP) のいずれかを使用して、直接接続の帯域幅をスケールできます。
1. AWS の [Site-to-Site VPN](https://aws.amazon.com/vpn/) は、インターネットプロトコルセキュリティ (IPsec) をサポートするマネージド VPN サービスを提供します。VPN 接続が作成されると、高可用性に向けて 各 VPN 接続に 2 つのトンネルが含まれています。
1. AWS のドキュメントに従って、適切な接続オプションを選択します。
1. Direct Connect を使用する場合は、接続に適した帯域幅を選択してください。
1. 複数のロケーションで AWS Site-to-Site VPN を使用して AWS リージョン に接続している場合は、 [高速 Site-to-Site VPN 接続](https://docs.aws.amazon.com/vpn/latest/s2svpn/accelerated-vpn.html) を使用すると、ネットワークのパフォーマンスが向上する可能性があります。
1. ネットワーク設計が [AWS Direct Connect](https://aws.amazon.com/directconnect/) を使用した IPSec VPN 接続で構成されている場合は、プライベート IP VPN を使用してセキュリティを強化し、セグメンテーションを実現することを検討してください。 [AWS サイト間プライベート IP VPN](https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-aws-site-to-site-vpn-private-ip-vpns/) は、トランジット仮想インターフェイス (VIF) の上にデプロイされます。
1. [AWS Direct Connect SiteLink](https://aws.amazon.com/blogs/aws/new-site-to-site-connectivity-with-aws-direct-connect-sitelink/) では、データを [AWS Direct Connectロケーション間の最速の経路で ](https://aws.amazon.com/directconnect/locations/)AWS リージョン をバイパスして送信することで、世界中のデータセンター間で低レイテンシ―の冗長な接続を確立できます。
1. 本番環境にデプロイする前に、接続設定を検証します。セキュリティとパフォーマンスのテストを実施して、帯域幅、信頼性、レイテンシ―、コンプライアンスの要件を満たしていることを確認します。
1. 接続のパフォーマンスと使用状況を定期的に監視し、必要に応じて最適化します。
![\[ネットワークで決定論的なパフォーマンスが必要かどうかを判断する際に考慮すべきオプションを説明するフローチャート。\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2023-10-03/framework/images/deterministic-networking-flowchart.png)
## リソース
**関連するドキュメント:**
+ [Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html)
+ [AWS ネットワークとコンテンツ配信 ](https://aws.amazon.com/products/networking/)
+ [AWS Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)
+ [ Amazon Route 53 でレイテンシーベースルーティングへ移行する ](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/TutorialTransitionToLBR.html)
+ [ VPC エンドポイント ](https://docs.aws.amazon.com/vpc/latest/privatelink/concepts.html)
+ [Site-to-Site VPN](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html)
+ [スケーラブルで安全なマルチ VPC の AWS ネットワークインフラストラクチャを構築する](https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/welcome.html)
+ [Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html)
+ [Client VPN](https://docs.aws.amazon.com/vpn/latest/clientvpn-admin/what-is.html)
**関連動画:**
+ [ Connectivity to AWS and hybrid AWS network architectures ](https://www.youtube.com/watch?v=eqW6CPb58gs)
+ [ Optimizing Network Performance for Amazon EC2 Instances ](https://www.youtube.com/watch?v=DWiwuYtIgu0)
+ [AWS Global Accelerator](https://www.youtube.com/watch?v=lAOhr-5Urfk)
+ [Direct Connect](https://www.youtube.com/watch?v=DXFooR95BYc&t=6s)
+ [AWS Transit Gateway Connect](https://www.youtube.com/watch?v=_MPY_LHSKtM&t=491s)
+ [VPN Solutions](https://www.youtube.com/watch?v=qmKkbuS9gRs)
+ [Security with VPN Solutions](https://www.youtube.com/watch?v=FrhVV9nG4UM)
**関連する例:**
+ [AWS Transit Gateway and Scalable Security Solutions](https://github.com/aws-samples/aws-transit-gateway-and-scalable-security-solutions)
+ [AWS Networking Workshops](https://networking.workshop.aws/)
# PERF04-BP04 ロードバランシングを使用してトラフィックを複数のリソースに分散する
トラフィックを複数のリソースやサービスに分散させ、ワークロードがクラウドの伸縮性を活用できるようにします。また、ロードバランシングを使用して暗号化ターミネーションをオフロードし、パフォーマンスと信頼性を向上させ、トラフィックを効率的に管理およびルーティングすることもできます。
**一般的なアンチパターン:**
+ ロードバランサーの種類を選択する際にワークロードの要件を考慮していない。
+ パフォーマンスの最適化のためにロードバランサー機能を活用していない。
+ ワークロードがロードバランサーなしで直接インターネットに公開されている。
+ 既存のロードバランサーを介して、すべてのインターネットトラフィックをルーティングしている。
+ 汎用 TCP ロードバランシングを使用して、各コンピューティングノードが SSL 暗号化を処理するようにしている。
**このベストプラクティスを活用するメリット:** ロードバランサーは、単一のアベイラビリティーゾーンまたは複数のアベイラビリティーゾーンにおけるアプリケーショントラフィックのさまざまな負荷を処理し、ワークロードの高可用性、自動スケーリング、効率的な使用を可能にします。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
ロードバランサーは、ワークロードのエントリポイントとして機能し、そこからコンピューティングインスタンスやコンテナなどのバックエンドターゲットにトラフィックを分散して使用率を改善します。
適切なロードバランサーの種類を選択することが、アーキテクチャを最適化するうえでの最初のステップとなります。まず、プロトコル (TCP、HTTP、TLS、または WebSocket など)、ターゲットの種類 (インスタンス、コンテナ、またはサーバーレスなど)、アプリケーション要件 (長時間実行される接続、ユーザー認証、またはスティッキーなど) や配置 (リージョン、ローカルゾーン、アウトポスト、ゾーン分離など) のワークロードの特性をリストアップすることから始めます。
AWS は、アプリケーションでロードバランシングを使用するためのモデルを複数提供しています。[Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html) は、HTTP トラフィックと HTTPS トラフィックのロードバランシングに最適です。マイクロサービスやコンテナといった最新のアプリケーションアーキテクチャを対象とした高度なリクエストルーティングを実現できます。
[Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html) は、きわめて高いパフォーマンスが要求される TCP トラフィックのロードバランシングに最適です。超低レイテンシーを維持しながら 1 秒あたり数百万件ものリクエストを処理することができ、突発的、または変動しやすいトラフィックパターンを処理するために最適化されています。
[Elastic Load Balancing](https://aws.amazon.com/elasticloadbalancing/) は、統合された証明書管理と SSL/TLS 復号化を提供するため、ロードバランサーの SSL 設定を一元的に管理し、CPU に負荷のかかる SSL/TLS 処理をお客様のワークロードからオフロードすることができます。
適切なロードバランサーを選択したら、ロードバランサーの機能を活用して、バックエンドが必要とするトラフィック処理のための労力を削減できます。
例えば、Application Load Balancer (ALB) と Network Load Balancer (NLB) の両方を使用して、SSL/TLS 暗号化オフロードを実行できます。これにより、CPU 負荷が高い TLS ハンドシェイクのターゲットによる終了を回避して、証明書管理を改善する機会が得られます。
ロードバランサーで SSL/TLS オフロードを設定すると、暗号化されていないトラフィックをバックエンドに配信すると同時に、クライアントとの間のトラフィックの暗号化の役目を果たすため、バックエンドリソースが解放され、クライアントにとっての応答時間が改善されます。
Application Load Balancer は、ターゲットでのサポートを必要とせずに HTTP2 トラフィックを処理することもできます。このようなシンプルな決断をすることで、HTTP2 は TCP 接続をより効率的に使用するようになり、アプリケーションの応答時間を改善できます。
アーキテクチャを定義する際は、ワークロードのレイテンシー要件を考慮する必要があります。例えば、レイテンシーの影響を受けやすいアプリケーションがある場合、非常に低レイテンシーを実現する Network Load Balancer を使用するよう決定することができます。または、Application Load Balancer を [AWS Local Zones](https://aws.amazon.com/about-aws/global-infrastructure/localzones/) 、あるいは [AWS Outposts](https://aws.amazon.com/outposts/rack/) で活用して、ワークロードをより顧客の近くに配置する方法を採用することもできます。
レイテンシーの影響を受けやすいワークロードに関して考慮すべきもう 1 つの点は、クロスゾーン負荷分散です。クロスゾーン負荷分散を使用すると、各ロードバランサーノードは許可されたすべてのアベイラビリティーゾーン内の登録済みターゲットにトラフィックを分散します。
ロードバランサーと統合された Auto Scaling を使用します。パフォーマンス効率に優れたシステムの重要な側面の 1 つに、バックエンドリソースのサイズの適切な設定があります。これを実現するには、バックエンドターゲットリソースのロードバランサー統合を利用できます。Auto Scaling グループと統合したロードバランサーを使用することで、受信トラフィックに対応して、必要に応じてターゲットがロードバランサーに追加されたり削除されたりします。コンテナ化されたワークロードのために、ロードバランサーを [Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-load-balancing.html) や [Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/alb-ingress.html) と統合することもできます。
+ [Amazon ECS - サービスの負荷分散](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-load-balancing.html)
+ [Amazon EKS でのアプリケーション負荷分散](https://docs.aws.amazon.com/eks/latest/userguide/alb-ingress.html)
+ [Amazon EKS でのネットワーク負荷分散](https://docs.aws.amazon.com/eks/latest/userguide/network-load-balancing.html)
### 実装手順
+ 膨大な量、可用性、アプリケーションのスケーラビリティなど、ロードバランシングの要件を定義します。
+ アプリケーションに適したロードバランサータイプを選択します。
+ HTTP/HTTPS のワークロードには、Application Load Balancer を使用します。
+ TCP または UDP で実行される HTTP 以外のワークロードには、Network Load Balancer を使用します。
+ 両方の製品の機能を活用したい場合は、両方を組み合わせて ([ALB を NLB のターゲットとして](https://aws.amazon.com/blogs/networking-and-content-delivery/application-load-balancer-type-target-group-for-network-load-balancer/)) 使用します。例えば、NLB の静的 IP を ALB からの HTTP ヘッダーベースのルーティングと組み合わせて使用する場合や、HTTP のワークロードを [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/privatelink-share-your-services.html) に公開する場合に使用します。
+ すべてのロードバランサーの比較については、 [「ELB の製品の比較」](https://aws.amazon.com/elasticloadbalancing/features/)を参照してください。
+ 可能であれば SSL/TLS オフロードを使用します
+ 。 [Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html) と [Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/create-tls-listener.html) の両方で統合された [AWS Certificate Manager で HTTPS/TLS リスナーを設定します](https://aws.amazon.com/certificate-manager/)。
+ ワークロードによっては、コンプライアンス上の理由で、エンドツーエンドの暗号化が必要になる場合があることに注意します。この場合は、ターゲットで暗号化を許可する必要があります。
+ セキュリティのベストプラクティスについては、「 [SEC09-BP02 伝送中に暗号化を適用する](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_protect_data_transit_encrypt.html)」を参照してください。
+ 適切なルーティングアルゴリズムを選択します (ALB のみ)。
+ ルーティングアルゴリズムは、バックエンドターゲットの使用状況に変化をもたらし、パフォーマンスへの影響を左右します。たとえば、ALB には以下の [2 つのルーティングアルゴリズムのオプション](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-target-groups.html#modify-routing-algorithm)があります。
+ **最小未処理リクエスト:** アプリケーションのリクエストの複雑性が異なる場合や、ターゲットの処理能力が異なる場合に、バックエンドターゲットへのロードバランシングを改善するために使用します。
+ **ラウンドロビン:** リクエストとターゲットが同様の場合、またはリクエストをターゲット間で均等に分散する必要がある場合に使用します。
+ クロスゾーンまたはゾーン分離を検討します。
+ レイテンシーの改善とゾーンの障害ドメイン対策として、クロスゾーンをオフ (ゾーン分離) で使用します。NLB ではデフォルトでオフになっていますが、 [ALB ではターゲットグループごとにオフに設定できます](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/disable-cross-zone.html)。
+ 可用性と柔軟性の向上のために、クロスゾーンをオンにします。クロスゾーンは ALB ではデフォルトでオンになっていますが、 [NLB ではターゲットグループごとにオンに設定できます](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/target-group-cross-zone.html)。
+ HTTP ワークロードの HTTP キープアライブをオンにします (ALB のみ)。この機能を使用すると、ロードバランサーはキープアライブタイムアウトが期限切れになるまでバックエンド接続を再利用できるため、HTTP リクエストと応答時間が改善され、バックエンドターゲットでのリソース使用率も低減します。Apache と Nginx でこれを実行する方法の詳細については、 [「ELB のバックエンドサーバーとして Apache または NGINX を使用するための最適な設定を教えてください。」を参照してください。](https://aws.amazon.com/premiumsupport/knowledge-center/apache-backend-elb/)
+ ロードバランサーのモニタリングをオンにします。
+ まず [Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/enable-access-logging.html) および [Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-access-logs.html) のアクセスログをオンにします。
+ ALB の場合に考慮すべき主なフィールドは以下のとおりです。 `request_processing_time`、 `request_processing_time`、 `response_processing_time`。
+ NLB の場合に考慮すべき主なフィールドは以下のとおりです。 `connection_time` および `tls_handshake_time`。
+ 必要な際にログをクエリできるように準備を整えておきます。Amazon Athena を使用すると、 [ALB ログ](https://docs.aws.amazon.com/athena/latest/ug/application-load-balancer-logs.html) と [NLB ログ](https://docs.aws.amazon.com/athena/latest/ug/networkloadbalancer-classic-logs.html)の両方をクエリできます。
+ ALB の [`TargetResponseTime` などのパフォーマンス関連メトリクスのアラームを作成します](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html)。
## リソース
**関連するドキュメント:**
+ [「ELB の製品の比較」 ](https://aws.amazon.com/elasticloadbalancing/features/)
+ [AWS グローバルインフラストラクチャ ](https://aws.amazon.com/about-aws/global-infrastructure/)
+ [Improving Performance and Reducing Cost Using Availability Zone Affinity ](https://aws.amazon.com/blogs/architecture/improving-performance-and-reducing-cost-using-availability-zone-affinity/)
+ [Step by step for Log Analysis with Amazon Athena ](https://github.com/aws/elastic-load-balancing-tools/tree/master/amazon-athena-for-elb)
+ [Application Load Balancer ログのクエリ](https://docs.aws.amazon.com/athena/latest/ug/application-load-balancer-logs.html)
+ [Application Load Balancers を監視する](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-monitoring.html)
+ [Network Load Balancer を監視する](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-monitoring.html)
+ [Elastic Load Balancing を使用して Auto Scaling グループ内のインスタンス全体にトラフィックを分散する](https://docs.aws.amazon.com/autoscaling/ec2/userguide/autoscaling-load-balancer.html)
**関連動画:**
+ [AWS re:Invent 2018: Elastic Load Balancing: Deep Dive and Best Practices](https://www.youtube.com/watch?v=VIgAT7vjol8)
+ [AWS re:Invent 2021 - How to choose the right load balancer for your AWS workloads ](https://www.youtube.com/watch?v=p0YZBF03r5A)
+ [AWS re:Inforce 2022 - How to use Elastic Load Balancing to enhance your security posture at scale](https://www.youtube.com/watch?v=YhNc5VSzOGQ)
+ [AWS re:Invent 2019: Get the most from Elastic Load Balancing for different workloads](https://www.youtube.com/watch?v=HKh54BkaOK0)
**関連する例:**
+ [CDK and CloudFormation samples for Log Analysis with Amazon Athena ](https://github.com/aws/elastic-load-balancing-tools/tree/master/log-analysis-elb-cdk-cf-template)
# PERF04-BP05 パフォーマンスを高めるネットワークプロトコルを選択する
ワークロードのパフォーマンスに対する影響に基づいて、システムとネットワーク間における通信のためのプロトコルを決定します。
スループットの達成には、レイテンシーと帯域幅間の関係が関与します。ファイル転送で Transmission Control Protocol (TCP) を使用している場合は、レイテンシ―が高くなると全体的なスループットを低下させる可能性が高くなります。これを解決するアプローチには、TCP チューニングと最適化された転送プロトコルを使うものもありますが、1 つの解決策として User Datagram Protocol (UDP) を使用する方法があります。
**一般的なアンチパターン:**
+ パフォーマンス要件に関係なく、すべてのワークロードに TCP を使用する。
**このベストプラクティスを活用するメリット:** ユーザーとワークロードコンポーネント間の通信に適切なプロトコルが使用されていることを確認すると、アプリケーションのユーザーエクスペリエンスが全体的に向上します。例えば、コネクションレス型 UDP では高速通信が可能ですが、再送信や高い信頼性は提供されません。TCP はフル機能のプロトコルですが、パケットの処理にはより大きなオーバーヘッドが必要です。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
アプリケーションに合わせて異なるプロトコルを選択する能力があり、この分野の専門知識を持っている場合は、異なるプロトコルを使用してアプリケーションとエンドユーザーエクスペリエンスを最適化してください。このアプローチは非常に難しいため、先に他の方法でアプリケーションを最適化したことがある場合にのみ試してください。
レイテンシーとスループットの要件を理解し、パフォーマンスを最適化するネットワークプロトコルを選択することが、ワークロードのパフォーマンスを向上するうえで重要となる考慮事項です。
**TCP の使用を検討するべきケース**
TCP は信頼性に優れたデータ配信を提供し、データの信頼性と確実な配信が重要となるワークロードのコンポーネント間の通信に利用できます。多くのウェブベースのアプリケーションは、HTTP や HTTPS などの TCP ベースのプロトコルを使用して TCP ソケットを開き、アプリケーションコンポーネント間の通信を行っています。TCP はアプリケーションコンポーネント間のシンプルで信頼性の高い転送メカニズムであるため、メールやファイルのデータ転送などのアプリケーションでも一般的に TCP が利用されます。TCP で TLS を使用すると通信のオーバーヘッドが増加し、レイテンシーが増加して、スループットが低下する可能性がありますが、セキュリティ上のメリットがあります。このオーバーヘッドは主にハンドシェークプロセスの追加オーバーヘッドにより発生し、完了するまでに数回のラウンドトリップが必要になる場合があります。ハンドシェイクが完了すると、データの暗号化と復号化のオーバーヘッドは比較的少なくなります。
**UDP の使用を検討するべきケース**
UDP はコネクションレス型のプロトコルであるため、ログ、モニタリング、VoIP データなどの、高速かつ効率的な転送が必要なアプリケーションに適しています。また、多数のクライアントからの小型のクエリに対応するワークロードのコンポーネントがある場合は、ワークロードの最適なパフォーマンスを確保するために UDP の使用を検討します。UDP では、Datagram Transport Layer Security (DTLS) が Transport Layer Security (TLS) に相当します。UDP で DTLS を使用する場合、ハンドシェイクプロセスは簡素化され、オーバーヘッドはデータの暗号化と復号化から発生します。また、DTLS には、セキュリティパラメータを提示し、改ざんを検出するための追加フィールドが含まれているため、UDP パケットに少量のオーバーヘッドが追加されます。
**SRD の使用を検討するべきケース**
Scalable Reliable Datagram (SRD) は、複数のパス間でトラフィックの負荷分散を行い、パケットドロップやリンク障害から迅速に回復できる機能を備えており、高スループットのワークロード向けに最適化されたネットワークトランスポートプロトコルです。そのため、SRD は、コンピューティングノード間で高スループットと低レイテンシー通信を必要とするハイパフォーマンスコンピューティング (HPC) ワークロードに最適です。ノード間で大量のデータ転送を伴うシミュレーション、モデリング、データ分析などの並列処理タスクなどで利用される場合があります。
### 実装手順
1. オンラインファイル転送アプリケーションのスループット向上のために、 [AWS Global Accelerator](https://aws.amazon.com/global-accelerator/) と [AWS Transfer Family](https://aws.amazon.com/aws-transfer-family/) サービスを使用します。AWS Global Accelerator サービスを使用すると、クライアントデバイスと AWS 上のワークロード間のレイテンシーが低減されます。AWS Transfer Family では、Secure Shell File Transfer Protocol (SFTP) と File Transfer Protocol over SSL (FTPS) などの TCP ベースのプロトコルを使用して、AWS ストレージサービスへのファイル転送を安全にスケールおよび管理できます。
1. ワークロードコンポーネント間の通信に TCP が適切かどうかを判断するには、ネットワークレイテンシーに注目します。クライアントアプリケーションとサーバー間のネットワークレイテンシーが高い場合、3 方向ハンドシェイクに時間がかかり、アプリケーションの応答性に影響を与える可能性があります。Time to First Byte (TTFB) や Round-Trip Time (RTT) などのメトリクスを使用すると、ネットワークレイテンシーを測定できます。ワークロードがユーザーに動的コンテンツを提供する場合は、 [Amazon CloudFront](https://aws.amazon.com/cloudfront/)の使用を検討します。これにより、動的コンテンツの各オリジンへの永続的な接続が確立され、各クライアントリクエストの速度を低下させる接続設定時間が必要なくなります。
1. TCP や UDP で TLS を使用すると、暗号化と復号化の影響により、レイテンシーが増大し、ワークロードのスループットが低下する可能性があります。このようなワークロードの場合、バックエンドインスタンスではなく、 [Elastic Load Balancing](https://aws.amazon.com/elasticloadbalancing/) で SSL/TLS オフロードを行い、ロードバランサーで SSL/TLS 暗号化および復号化プロセスの処理を行ってワークロードのパフォーマンスを向上させることを検討します。これは、バックエンドインスタンスの CPU 使用率の低減、パフォーマンスの向上、キャパシティー増大につながります。
1. 認証と認可、ロギング、DNS、IoT、ストリーミングメディアなどの UDP プロトコルに依存するサービスを展開し、ワークロードのパフォーマンスと信頼性を向上させるには、 [Network Load Balancer (NLB)](https://aws.amazon.com/elasticloadbalancing/network-load-balancer/) を使用します。NLB は着信 UDP トラフィックを複数のターゲットに分散するため、ワークロードの水平方向のスケーリング、キャパシティの増大、単一のターゲットのオーバーヘッドの低減につながります。
1. ハイパフォーマンスコンピューティング (HPC) のワークロードの場合は、SRD プロトコルを使用する [Elastic Network Adapter (ENA) Express](https://aws.amazon.com/about-aws/whats-new/2022/11/elastic-network-adapter-ena-express-amazon-ec2-instances/) 機能を利用することを検討します。この機能は、EC2 インスタンス間のネットワークトラフィックでシングルフロー帯域幅を増大し (25 Gbps)、テールレイテンシーを短縮して (99.9 パーセンタイル)、ネットワークパフォーマンスを向上させます。
1. ワークロードコンポーネント間または gRPC クライアントとサービス間で gRPC (リモートプロシージャコール) トラフィックをルーティングして負荷分散するには、 [Application Load Balancer (ALB)](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html) を使用します。gRPC は TCP ベースの HTTP/2 プロトコルをトランスポートに使用しており、ネットワークフットプリントの軽量化、圧縮、効率的なバイナリ形式のシリアル化、多言語サポート、双方向ストリーミングなどのパフォーマンス上の利点が得られます。
## リソース
**関連ドキュメント:**
+ [Amazon EBS – 最適化インスタンス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-optimized.html)
+ [Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html)
+ [Linux での EC2 拡張ネットワーキング](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/enhanced-networking.html)
+ [Windows での EC2 拡張ネットワーキング](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/enhanced-networking.html)
+ [EC2 プレイスメントグループ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html)
+ [Linux インスタンスで Elastic Network Adapter (ENA) を使用して拡張ネットワークを有効にする](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/enhanced-networking-ena.html)
+ [Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html)
+ [AWS ネットワークとコンテンツ配信](https://aws.amazon.com/products/networking/)
+ [AWS Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw)
+ [Amazon Route 53 でレイテンシーベースルーティングへ移行する](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/TutorialTransitionToLBR.html)
+ [VPC エンドポイント](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints.html)
+ [VPC フローログ](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html)
**関連動画:**
+ [Connectivity to AWS and hybrid AWS network architectures](https://www.youtube.com/watch?v=eqW6CPb58gs)
+ [Optimizing Network Performance for Amazon EC2 Instances](https://www.youtube.com/watch?v=DWiwuYtIgu0)
**関連する例:**
+ [AWS Transit Gateway and Scalable Security Solutions](https://github.com/aws-samples/aws-transit-gateway-and-scalable-security-solutions)
+ [AWS Networking Workshops](https://networking.workshop.aws/)
# PERF04-BP06 ネットワーク要件に基づいてワークロードのロケーションを選択する
ネットワークのレイテンシー短縮、スループット向上、ページの読み込み時間とデータ転送時間の短縮による最適なユーザーエクスペリエンス提供に向けて、リソースプレイスメントのオプションを評価します。
**一般的なアンチパターン:**
+ すべてのワークロードリソースを 1 つの地理的場所に統合する。
+ ワークロードのエンドユーザーではなく、自分の所在地に最も近いリージョンを選んでいる。
**このベストプラクティスを活用するメリット:** ユーザーエクスペリエンスは、ユーザーとアプリケーションの間のレイテンシーの影響を大きく受けます。適切な AWS リージョン と AWS のプライベートなグローバルネットワークを使用することで、レイテンシ―を減らし、リモートユーザーにより良いエクスペリエンスを提供できます。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
Amazon EC2 インスタンスなどのリソースは、 [AWS リージョン](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/)、[AWS Local Zones](https://aws.amazon.com/about-aws/global-infrastructure/localzones/)、[AWS Outposts](https://aws.amazon.com/outposts/)、 [AWS Wavelength](https://aws.amazon.com/wavelength/) ゾーン内のアベイラビリティーゾーンに配置します。このロケーション選択が、特定のユーザーのロケーションからのネットワークレイテンシーとスループットに影響を及ぼします。例えば、 [Amazon CloudFront](https://aws.amazon.com/cloudfront/) や [AWS Global Accelerator](https://aws.amazon.com/global-accelerator/) などのエッジサービスを利用して、エッジロケーションにコンテンツをキャッシュするか、AWS グローバルネットワークを介してユーザーにワークロードへの最適なパスを提供することにより、ネットワークパフォーマンスを改善することもできます。
Amazon EC2 にはネットワーク用のプレイスメントグループが用意されています。プレイスメントグループは、レイテンシーを減らすためにインスタンスを論理的にグループ化したものです。サポートされているインスタンスタイプを使ったプレイスメントグループと Elastic Network Adapter (ENA) を使用することにより、ワークロードを低レイテンシー、低ジッターの 25 Gbps ネットワークに参加させることができます。プレイスメントグループは、低ネットワークレイテンシー、高ネットワークスループット、またはその両方からメリットを得るワークロードに推奨されます。
レイテンシーの影響を受けやすいサービスは、AWS グローバルネットワークを使用してエッジロケーションで提供されます ( [Amazon CloudFront](https://aws.amazon.com/cloudfront/) など)。これらのエッジロケーションは一般に、コンテンツ配信ネットワーク (CDN) およびドメインネームシステム (DNS) などのサービスを提供します。これらのサービスをエッジで使用することにより、ワークロードがコンテンツまたは DNS 解決のリクエストに低いレイテンシーで応答できるようになります。これらのサービスは、コンテンツのジオターゲティング (エンドユーザーの位置に基づいて異なるコンテンツを提供) などの地理的なサービス、またはエンドユーザーを最寄りのリージョンに誘導するレイテンシーベースルーティング (最小レイテンシー) も提供します。
エッジサービスを使用してレイテンシーを低減し、コンテンツキャッシングを有効化します。これらのアプローチから最大限のメリットを得るために、DNS と HTTP/HTTPS の両方でキャッシュ制御を正しく設定してください。
### 実装手順
+ VPC のネットワークインターフェイスとの間で行き来する IP トラフィックに関する情報を把握します。
+ [ VPC フローログを使用した IP トラフィックのログ記録 ](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html)
+ [ How the client IP address is preserved in AWS Global Accelerator](https://docs.aws.amazon.com/global-accelerator/latest/dg/preserve-client-ip-address.headers.html)
+ ワークロードのネットワークアクセスパターンを分析して、ユーザーがアプリケーションをどのように使用しているかを特定します。
+ ネットワーク活動に関するデータを収集するため、 [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) および [AWS CloudTrail](https://aws.amazon.com/cloudtrail/)のようなツールを使用します。
+ データを分析して、ネットワークアクセスパターンを特定します。
+ 以下の主な要素に基づいて、ワークロードのデプロイに適切なリージョンを選択します。
+ **データの場所:** 大量のデータを使用するアプリケーション (ビッグデータや機械学習など) では、アプリケーションコードをできるだけデータの近くで実行してください。
+ **ユーザーの所在地**: ユーザー向けアプリケーションの場合は、ワークロードのユーザーに近いリージョン (1 つまたは複数) を選択します。
+ **その他の制約**: 以下で説明されているように、コストやコンプライアンスなどの制約を考慮します。 [What to Consider when Selecting a Region for your Workloads。](https://aws.amazon.com/blogs/architecture/what-to-consider-when-selecting-a-region-for-your-workloads/)
+ 動画レンダリングのようなワークロードは、 [AWS Local Zones](https://aws.amazon.com/about-aws/global-infrastructure/localzones/) を使用して実行します。ローカルゾーンでは、エンドユーザーの近くにコンピューティングリソースやストレージリソースがあるというメリットが得られます。
+ オンプレミスに置いておく必要があるが、AWS にある他のワークロードとシームレスに連携させたいワークロードには、 [AWS Outposts](https://aws.amazon.com/outposts/) を使用します。
+ 高解像度ライブビデオストリーミング、Hi-Fi 音源、拡張現実および仮想現実 (AR/VR) などのアプリケーションでは、5G デバイス向けに超低レイテンシーが必要です。このようなアプリケーションについては、 [AWS Wavelength](https://aws.amazon.com/wavelength/) を検討します。AWS Wavelength は AWS のコンピューティングおよびストレージサービスを 5G ネットワーク内に組み込み、超低レイテンシーアプリケーションの開発、デプロイ、スケーリングのためのモバイルエッジコンピューティングインフラストラクチャを提供します。
+ ローカルキャッシュまたは [AWS キャッシュソリューション](https://aws.amazon.com/caching/aws-caching/) を、頻繁に使用するアセットに使用すると、パフォーマンスを向上させ、データ移動を削減し、環境への影響を低減できます。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2023-10-03/framework/perf_networking_choose_workload_location_network_requirements.html)
+ 以下のように、ワークロードのユーザーの近くでコードを実行できるサービスを使用します。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2023-10-03/framework/perf_networking_choose_workload_location_network_requirements.html)
+ アプリケーションによっては、最初のバイトのレイテンシーとジッターを低減してスループットを向上することによる、固定エントリポイントまたはより高いパフォーマンスが必要となります。これらのアプリケーションは、静的なエニーキャスト IP アドレスとエッジロケーションでの TCP ターミネーションを提供するネットワークサービスの恩恵を受けることができます。[AWS Global Accelerator](https://aws.amazon.com/global-accelerator/) を使用すると、アプリケーションのパフォーマンスを最大 60% 向上させ、マルチリージョンアーキテクチャの迅速なフェイルオーバーを実現できます。AWS Global Accelerator では、1 つまたは複数の AWS リージョンでホストされるアプリケーションの固定エントリポイントとして機能する静的エニーキャスト IP アドレスを利用できます。このような IP アドレスを使用すると、トラフィックはユーザーのできるだけ近くの AWS グローバルネットワークに入ることができます。AWS Global Accelerator は、クライアントとクライアントに最も近い AWS エッジロケーションの間で TCP 接続を確立することにより、初期接続設定時間を短縮します。TCP/UDP ワークロードのパフォーマンス向上、マルチリージョンアーキテクチャの迅速なフェイルオーバーを実現するには、AWS Global Accelerator の使用を検討します。
## リソース
**関連するベストプラクティス:**
+ [ COST07-BP02 コストに基づいてリージョンを選択する ](https://docs.aws.amazon.com/wellarchitected/latest/framework/cost_pricing_model_region_cost.html)
+ [ COST08-BP03 データ転送コストを削減するサービスを実装する ](https://docs.aws.amazon.com/wellarchitected/latest/framework/cost_data_transfer_implement_services.html)
+ [ REL10-BP01 複数の場所にワークロードをデプロイする ](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_fault_isolation_multiaz_region_system.html)
+ [ REL10-BP02 マルチロケーションデプロイ用の適切な場所の選択 ](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_fault_isolation_select_location.html)
+ [ SUS01-BP01 ビジネス要件と持続可能性の目標の両方に基づいてリージョンを選択する ](https://docs.aws.amazon.com/wellarchitected/latest/framework/sus_sus_region_a2.html)
+ [ SUS02-BP04 ネットワーク要件に基づいてワークロードの地理的配置を最適化する ](https://docs.aws.amazon.com/wellarchitected/latest/framework/sus_sus_user_a5.html)
+ [ SUS04-BP07 ネットワーク間でのデータ移動を最小限に抑える ](https://docs.aws.amazon.com/wellarchitected/latest/framework/sus_sus_data_a8.html)
**関連するドキュメント:**
+ [AWS グローバルインフラストラクチャ ](https://aws.amazon.com/about-aws/global-infrastructure/)
+ [AWS Local Zones and AWS Outposts, choosing the right technology for your edge workload ](https://aws.amazon.com/blogs/compute/aws-local-zones-and-aws-outposts-choosing-the-right-technology-for-your-edge-workload/)
+ [ プレイスメントグループ ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html)
+ [AWS Local Zones ](https://aws.amazon.com/about-aws/global-infrastructure/localzones/)
+ [AWS Outposts](https://aws.amazon.com/outposts/)
+ [AWS Wavelength](https://aws.amazon.com/wavelength/)
+ [ Amazon CloudFront ](https://aws.amazon.com/cloudfront/)
+ [AWS Global Accelerator](https://aws.amazon.com/global-accelerator/)
+ [AWS Direct Connect](https://aws.amazon.com/directconnect/)
+ [AWS Site-to-Site VPN](https://aws.amazon.com/vpn/site-to-site-vpn/)
+ [ Amazon Route 53 ](https://aws.amazon.com/route53/)
**関連動画:**
+ [AWS Local Zones Explainer Video ](https://www.youtube.com/watch?v=JHt-D4_zh7w)
+ [AWS Outposts: Overview and How it Works ](https://www.youtube.com/watch?v=ppG2FFB0mMQ)
+ [AWS re:Invent 2021 - AWS Outposts: Bringing the AWS experience on premises ](https://www.youtube.com/watch?v=FxVF6A22498)
+ [AWS re:Invent 2020: AWS Wavelength: Run apps with ultra-low latency at 5G edge ](https://www.youtube.com/watch?v=AQ-GbAFDvpM)
+ [AWS re:Invent 2022 - AWS Local Zones: Building applications for a distributed edge ](https://www.youtube.com/watch?v=bDnh_d-slhw)
+ [AWS re:Invent 2021 - Building low-latency websites with Amazon CloudFront ](https://www.youtube.com/watch?v=9npcOZ1PP_c)
+ [AWS re:Invent 2022 - Improve performance and availability with AWS Global Accelerator](https://www.youtube.com/watch?v=s5sjsdDC0Lg)
+ [AWS re:Invent 2022 - Build your global wide area network using AWS](https://www.youtube.com/watch?v=flBieylTwvI)
+ [AWS re:Invent 2020: Global traffic management with Amazon Route 53 ](https://www.youtube.com/watch?v=E33dA6n9O7I)
**関連する例:**
+ [AWS Global Accelerator ワークショップ ](https://catalog.us-east-1.prod.workshops.aws/workshops/effb1517-b193-4c59-8da5-ce2abdb0b656/en-US)
+ [ Handling Rewrites and Redirects using Edge Functions ](https://catalog.us-east-1.prod.workshops.aws/workshops/814dcdac-c2ad-4386-98d5-27d37bb77766/en-US)
# PERF04-BP07 メトリクスに基づいてネットワーク設定を最適化する
収集して分析したデータを使用して、ネットワーク設定の最適化に関する十分な知識に基づいた意思決定を行います。
**一般的なアンチパターン:**
+ パフォーマンス関連の問題はすべてアプリケーション関連であると想定している。
+ ワークロードをデプロイしたロケーションに近いロケーションからのみ、ネットワークパフォーマンスをテストする。
+ ネットワークサービスの設定はすべてデフォルトにしている。
+ 十分なキャパシティを提供するためにネットワークリソースを過剰プロビジョニングしている。
**このベストプラクティスを活用するメリット:** AWS ネットワークの必要なメトリクスを収集し、ネットワークモニタリングツールを実装すると、ネットワークパフォーマンスを把握し、ネットワーク設定を最適化できます。
**このベストプラクティスを活用しない場合のリスクレベル:** 低
## 実装のガイダンス
AWS ネットワークリソースの利用方法とネットワーク設定を最適化する方法を理解するには、VPC、サブネット、またはネットワークインターフェイス間のトラフィックをモニタリングすることが重要です。以下の AWS ネットワークツールを使用すると、トラフィックの使用状況、ネットワークアクセス状況、ログに関する情報を詳細に調査できます。
### 実装手順
+ レイテンシーやパケットロスなど、収集する主要なパフォーマンスメトリクスを特定します。AWS には、これらのメトリクスの収集に役立ついくつかのツールが用意されています。以下のツールを使用すると、トラフィックの使用状況、ネットワークアクセス状況、ログに関する情報を詳細に調査できます。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2023-10-03/framework/perf_networking_optimize_network_configuration_based_on_metrics.html)
+ VPC AWS Transit Gateway とフローログを使用して、上位の送信元やアプリケーショントラフィックのパターンを特定します。
+ VPC、サブネット、ルーティングなど、現在のネットワークアーキテクチャを評価して最適化します。例として、異なる VPC ピアリングや AWS Transit Gateway がアーキテクチャ内のネットワークの改善にどのように役立つかを評価できます。
+ ネットワーク内のルーティングパスを評価して、宛先間の最短パスが常に使用されていることを確認します。その際に Network Access Analyzer が役立ちます。
## リソース
**関連ドキュメント:**
+ [VPC フローログ](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html)
+ [パブリック DNS クエリのログ記録](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/query-logs.html)
+ [IPAM とは](https://docs.aws.amazon.com/vpc/latest/ipam/what-it-is-ipam.html)
+ [Reachability Analyzer とは](https://docs.aws.amazon.com/vpc/latest/reachability/what-is-reachability-analyzer.html)
+ [Network Access Analyzer とは](https://docs.aws.amazon.com/vpc/latest/network-access-analyzer/what-is-network-access-analyzer.html)
+ [VPC の CloudWatch メトリクス](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-cloudwatch.html)
+ [Optimize performance and reduce costs for network analytics with VPC Flow Logs in Apache Parquet format ](https://aws.amazon.com/blogs/big-data/optimize-performance-and-reduce-costs-for-network-analytics-with-vpc-flow-logs-in-apache-parquet-format/)
+ [Amazon CloudWatch メトリクスを使用してグローバルとコアネットワークをモニタリングする](https://docs.aws.amazon.com/vpc/latest/tgwnm/monitoring-cloudwatch-metrics.html)
+ [Continuously monitor network traffic and resources](https://docs.aws.amazon.com/whitepapers/latest/security-best-practices-for-manufacturing-ot/continuously-monitor-network-traffic-and-resources.html)
**関連動画:**
+ [Networking best practices and tips with the AWS Well-Architected Framework ](https://www.youtube.com/watch?v=wOMNpG49BeM)
+ [Monitoring and troubleshooting network traffic ](https://www.youtube.com/watch?v=Ed09ReWRQXc)
**関連する例:**
+ [AWS Networking Workshops](https://networking.workshop.aws/)
+ [AWS Network Monitoring](https://github.com/aws-samples/monitor-vpc-network-patterns)
# プロセスと文化
# PERF 5。組織の慣行と文化は、ワークロードのパフォーマンス効率にどのように貢献していますか？
ワークロードを設計する際には、効率的で高性能なクラウドワークロードをより効率的に実行するために採用できる原則と慣行があります。クラウドワークロードのパフォーマンス効率を高める文化を採用するには、以下の重要な原則と慣行を検討してください。
**Topics**
+ [PERF05-BP01 ワークロードの状態とパフォーマンスを測定するための主要業績評価指標 (KPI) を設定する](perf_process_culture_establish_key_performance_indicators.md)
+ [PERF05-BP02 モニタリングソリューションを活用して、パフォーマンスが最も重要な分野について把握する](perf_process_culture_use_monitoring_solutions.md)
+ [PERF05-BP03 ワークロードのパフォーマンス向上プロセスを定める](perf_process_culture_workload_performance.md)
+ [PERF05-BP04 ワークロードの負荷テストを実施する](perf_process_culture_load_test.md)
+ [PERF05-BP05 自動化でパフォーマンス関連の問題をプロアクティブに修正する](perf_process_culture_automation_remediate_issues.md)
+ [PERF05-BP06 ワークロードとサービスを最新の状態に保つ](perf_process_culture_keep_workload_and_services_up_to_date.md)
+ [PERF05-BP07 メトリクスを定期的に見直す](perf_process_culture_review_metrics.md)
# PERF05-BP01 ワークロードの状態とパフォーマンスを測定するための主要業績評価指標 (KPI) を設定する
ワークロードのパフォーマンスを定量的および定性的に測定する KPI を特定します。KPI は、ビジネス目標に関連するワークロードの健全性とパフォーマンスを測定するのに役立ちます。
**一般的なアンチパターン:**
+ ワークロードについて把握するためだけにシステムレベルのメトリクスをモニタリングし、こうしたメトリクスがビジネスに与える影響を理解していない。
+ KPI が標準的なメトリクスデータとして既に発行され、共有されていると思っている。
+ 定量的で測定可能な KPI を定義していない。
+ KPI をビジネスの目標や戦略とすり合わせていない。
**このベストプラクティスを活用するメリット:** ワークロードの正常性とパフォーマンスを表す具体的な KPI を特定することで、チームの優先順位をすり合わせ、目指すべきビジネス成果とは何かを定義できます。これらのメトリクスをすべての部門と共有することで、しきい値、期待値、ビジネスへの影響が可視化され、調整を図ることができます。
**このベストプラクティスが確立されていない場合のリスクレベル:** 高
## 実装のガイダンス
KPI を使用すると、ビジネスチームとエンジニアリングチームが、目標と戦略の測定と、こうした要因がどのように組み合わさってビジネス成果を生み出すかについての認識をすり合わせることができます。例えば、ウェブサイトのワークロードには、ページの読み込み時間を全体的なパフォーマンスの指標として使用する場合があります。このメトリクスは、ユーザーエクスペリエンスを測定する複数のデータポイントのうちの 1 つとなります。ページの読み込み時間のしきい値を特定することに加えて、パフォーマンスが満たされない場合に期待される結果やビジネスリスクを文書化する必要があります。ページの読み込み時間が長いと、エンドユーザーに直接影響し、ユーザーエクスペリエンスの評価の低下、ひいては顧客の損失につながる可能性があります。KPI のしきい値を定義するときは、業界のベンチマークとエンドユーザーの期待値の両方を組み合わせます。例えば、現時点での業界のウェブページの読み込みベンチマークが 2 秒以内であっても、エンドユーザーが 1 秒以内での読み込みを期待する場合、KPI を設定する際にこれらのデータポイントの両方を考慮する必要があります。
チームは、リアルタイムの詳細なデータと参照用の履歴データを使用してワークロード KPI を評価し、KPI データにメトリクス計算を実行するダッシュボードを作成して、運用と使用状況に関する洞察を導き出す必要があります。KPI は文書化され、ビジネス目標と戦略をサポートするしきい値を含み、かつモニタリング対象のメトリクスに対応付けられている必要があります。ビジネスの目標および戦略、またはエンドユーザーの要件が変わった場合は、KPI を再検討する必要があります。
## 実装手順
1. ビジネスの利害関係者を特定して文書化します。
1. 特定した利害関係者と協力して、ワークロードの目標を定義し、文書化します。
1. 業界のベストプラクティスを確認して、ワークロードの目標に沿った関連 KPI を特定します。
1. 業界のベストプラクティスとワークロードの目標を使用して、ワークロード KPI のターゲットを設定します。この情報を使用して、重要度またはアラームレベルの KPI しきい値を設定します。
1. KPI が満たされない場合のリスクと影響を特定して文書化します。
1. KPI の確立に役立つメトリクスを特定して文書化します。
1. Amazon CloudWatch [ま](https://aws.amazon.com/cloudwatch/) たは [AWS Config](https://aws.amazon.com/config/) などのモニタリングツールを使用して、メトリクスを収集して KPI を測定します。
1. ダッシュボードを使用して KPI を視覚化し、利害関係者に報告します。
1. メトリクスを定期的に見直して分析し、改善が必要なワークロードの領域を特定します。
1. ビジネス目標やワークロードのパフォーマンスが変化した場合は、KPI を再検討します。
## リソース
**関連するドキュメント:**
+ [CloudWatch documentation (CloudWatch ドキュメント)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)
+ [Monitoring, Logging, and Performance AWS Partners](https://aws.amazon.com/devops/partner-solutions/#_Monitoring.2C_Logging.2C_and_Performance)
+ [X-Ray ドキュメント](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
+ [Amazon CloudWatch ダッシュボードの使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html?ref=wellarchitected)
+ [Quick KPI](https://docs.aws.amazon.com/quicksight/latest/user/kpi.html)
**関連動画:**
+ [AWS re:Invent 2019: Scaling up to your first 10 million users](https://www.youtube.com/watch?v=kKjm4ehYiMs&ref=wellarchitected)
+ [Cut through the chaos: Gain operational visibility and insight](https://www.youtube.com/watch?v=nLYGbotqHd0&ref=wellarchitected)
+ [モニタリング計画を立てる](https://www.youtube.com/watch?v=OMmiGETJpfU&ref=wellarchitected)
**関連サンプル:**
+ [Creating a dashboard with Quick (Quick でダッシュボードを作成する)](https://github.com/aws-samples/amazon-quicksight-sdk-proserve)
# PERF05-BP02 モニタリングソリューションを活用して、パフォーマンスが最も重要な分野について把握する
ワークロードのパフォーマンスの向上が効率性やカスタマーエクスペリエンスにプラスの影響を与える分野を理解し、特定します。たとえば、カスタマーインタラクションが多いウェブサイトは、エッジサービスを使用してコンテンツ配信をお客様に近い場所へ移動させることでメリットを得ることができます。
**一般的なアンチパターン:**
+ パフォーマンスの問題を検出するには、CPU 使用率やメモリプレッシャーなどの標準的なコンピューティングメトリクスで十分であると考えている。
+ 一部のモニタリングソフトウェアで記録されるデフォルトのメトリクスのみを使用している。
+ 問題が発生したときにだけメトリクスを確認している。
**このベストプラクティスを活用するメリット:** パフォーマンスの重要な領域を理解することで、ワークロードの所有者は KPI をモニタリングし、影響の大きいパフォーマンスの改善に優先順位をつけることができます。
**このベストプラクティスが確立されていない場合のリスクレベル:** 高
## 実装のガイダンス
エンドツーエンドの追跡を構築して、トラフィックパターン、レイテンシー、重要なパフォーマンス領域を特定します。データアクセスパターンをモニタリングして、低速なクエリや不十分にフラグメント化されパーティション化されたデータを検出します。負荷テストまたはモニタリングを使用して、ワークロードのボトルネックを特定します。
アーキテクチャ、トラフィックパターン、データアクセスパターンを理解し、レイテンシーと処理時間を特定することで、パフォーマンス効率を高めることができます。ワークロードが増加するにつれて、顧客エクスペリエンスに影響を及ぼす可能性のある潜在的なボトルネックを特定できます。この領域を調査したら、デプロイできるソリューションを調査し、パフォーマンスの懸念を取り除きます。
### 実装手順
1. エンドツーエンドのモニタリングを構築して、すべてのワークロードコンポーネントおよびメトリクスをキャプチャします。以下は、AWS のモニタリングソリューションの一部です。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2023-10-03/framework/perf_process_culture_use_monitoring_solutions.html)
1. テストを実行してメトリクスを生成し、トラフィックパターン、ボトルネック、および重要なパフォーマンス領域を特定します。テストの実行方法の例として、次のようなものがあります。
+ CloudWatch Synthetic Canaries [を設定し、](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) Linux の cron ジョブまたは rate 式を使用してブラウザベースのユーザーアクティビティをプログラムで模倣するように設定し、長期にわたって一貫したメトリクスを生成します。
+ AWS Distributed Load Testing [ソリューションを使用して、](https://aws.amazon.com/solutions/implementations/distributed-load-testing-on-aws/) ピークトラフィックの生成、または予想される増加率でのワークロードのテストを行います。
1. メトリクスとテレメトリを評価して、重要なパフォーマンス領域を特定します。これらの領域をチームと一緒にレビューして、モニタリングおよびボトルネックを防ぐためのソリューションについて話し合います。
1. パフォーマンスの改善をテストし、データを使用してこれらの変更を計測します。例えば、 [CloudWatch Evidently ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Evidently.html) を使用して、ワークロードに対する新しい改善点やパフォーマンスへの影響をテストできます。
## リソース
**関連するドキュメント:**
+ [Amazon Builders’ Library](https://aws.amazon.com/builders-library)
+ [X-Ray ドキュメント](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
+ [Amazon CloudWatch RUM](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html)
+ [Amazon DevOps Guru](https://aws.amazon.com/devops-guru/)
**関連動画:**
+ [The Amazon Builders’ Library: 25 years of Amazon operational excellence](https://www.youtube.com/watch?v=DSRhgBd_gtw)
+ [Visual Monitoring of Applications with Amazon CloudWatch Synthetics](https://www.youtube.com/watch?v=_PCs-ucZz7E)
**関連する例:**
+ [Measure page load time with Amazon CloudWatch Synthetics](https://github.com/aws-samples/amazon-cloudwatch-synthetics-page-performance)
+ [Amazon CloudWatch RUM Web Client](https://github.com/aws-observability/aws-rum-web)
+ [X-Ray SDK for Node.js](https://github.com/aws/aws-xray-sdk-node)
+ [X-Ray SDK for Python](https://github.com/aws/aws-xray-sdk-python)
+ [X-Ray SDK for Java](https://github.com/aws/aws-xray-sdk-java)
+ [X-Ray SDK for .Net](https://github.com/aws/aws-xray-sdk-dotnet)
+ [X-Ray SDK for Ruby](https://github.com/aws/aws-xray-sdk-ruby)
+ [X-Ray Daemon](https://github.com/aws/aws-xray-daemon)
+ [AWS での分散負荷テスト](https://aws.amazon.com/solutions/implementations/distributed-load-testing-on-aws/)
# PERF05-BP03 ワークロードのパフォーマンス向上プロセスを定める
新しいサービス、設計パターン、リソースの種類、設定が利用できるようになった時点で、これらを評価するプロセスを明確に定めます。たとえば、新しいインスタンス製品で既存のパフォーマンステストを実行して、ワークロードを向上させる可能性を判断します。
**一般的なアンチパターン:**
+ 現在のアーキテクチャが静的であり、今後更新されないと考えている。
+ メトリクスに基づく理由なしで、時間の経過とともにアーキテクチャの変更を導入する。
**このベストプラクティスを活用するメリット:** アーキテクチャの変更を行うためのプロセスを定義することで、ワークロード設計に経時的な影響を与えるために、収集されたデータを使用できます。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
ワークロードのパフォーマンスには重要な制約がいくつかあります。その制約を文書化すれば、どのような種類のイノベーションがワークロードのパフォーマンス向上につながるかを把握できます。新しいサービスやテクノロジーが利用できるようになった場合、この情報を利用して、制約やボトルネックを軽減する方法を見つけます。
ワークロードの重要なパフォーマンス上の制約を特定します。どのようなイノベーションがワークロードパフォーマンスの向上につながるかを知ることができるように、ワークロードのパフォーマンスの制約を文書化します。
### 実装手順
+ 「 [PERF05-BP01 ワークロードの状態とパフォーマンスを測定するための主要業績評価指標 (KPI) を設定する](perf_process_culture_establish_key_performance_indicators.md) 」で概説されているように、ワークロードのパフォーマンス KPI を特定して、ワークロードのベースラインを作成します。
+ AWS オブザーバビリティツール [を使用して](https://docs.aws.amazon.com/wellarchitected/latest/management-and-governance-guide/aws-observability-tools.html) パフォーマンスメトリクスを収集し、KPI を測定します。
+ 「 [PERF05-BP02 モニタリングソリューションを活用して、パフォーマンスが最も重要な分野について把握する](perf_process_culture_use_monitoring_solutions.md)」で説明されているように、詳細な分析を実施して、ワークロードの中でパフォーマンスが低い領域 (設定やアプリケーションコードなど) を特定します
+ 分析ツールとパフォーマンスツールを使用して、パフォーマンス最適化戦略を特定します。
+ サンドボックス環境または本番前環境を使用して、戦略の有効性を検証します。
+ 変更を本番環境に実装し、ワークロードのパフォーマンスを継続的にモニタリングします。
+ 改善点を文書化し、利害関係者に報告します。
## リソース
**関連するドキュメント:**
+ [AWS ブログ](https://aws.amazon.com/blogs/)
+ [AWS の最新情報](https://aws.amazon.com/new/?ref=wellarchitected)
**関連動画:**
+ [AWS Events YouTube チャンネル](https://www.youtube.com/channel/UCdoadna9HFHsxXWhafhNvKw)
+ [AWS Online Tech Talks YouTube チャンネル](https://www.youtube.com/user/AWSwebinars)
+ [Amazon Web Services YouTube チャンネル](https://www.youtube.com/channel/UCd6MoB9NC6uYN2grvUNT-Zg)
**関連サンプル:**
+ [AWS Github](https://github.com/aws)
+ [AWS Skill Builder](https://explore.skillbuilder.aws/learn)
# PERF05-BP04 ワークロードの負荷テストを実施する
ワークロードの負荷テストを実施して、本番環境の負荷に対応できることを確認し、パフォーマンスのボトルネックを特定します。
**一般的なアンチパターン:**
+ あなたは、ワークロード全体ではなく、ワークロードの個々の部分について負荷テストを行います。
+ あなたは、本番環境とは異なるインフラストラクチャで負荷テストを行います。
+ あなたは、今後問題が発生する可能性を予測するのに役立てるため、予想される負荷に対してのみ、負荷テストを実施し、それを超える負荷に対しては負荷テストを実施しません。
+ 負荷テストを、 [Amazon EC2 テストポリシー](https://aws.amazon.com/ec2/testing/) を確認したり、シミュレーションイベントサブミッションフォームを提出したりすることなく実行します。これは、サービス妨害イベントとみなされ、テストの実行の失敗につながります。
**このベストプラクティスを活用するメリット:** 負荷テストでパフォーマンスを測定すると、負荷の増加に伴って影響を受ける場所が判明します。これにより、必要な変更がワークロードに影響を与える前に予測できるようになります。
**このベストプラクティスが確立されていない場合のリスクレベル:** 低
## 実装のガイダンス
クラウドでの負荷テストは、予想されるユーザー負荷を考慮して、現実的な条件下でクラウドワークロードのパフォーマンスを測定するプロセスです。このプロセスでは、本番環境と同様のクラウド環境をプロビジョニングし、負荷テストツールを使用して負荷を生成したうえで、メトリクスを分析してワークロードが現実的な負荷に対応できるかを評価します。ロードテストは、本番データの合成バージョンまたはサニタイズバージョン (機密情報または識別情報を削除) を使用して実行する必要があります。デリバリーパイプラインの一環として負荷テストを自動的に実行し、その結果を事前定義された KPI およびしきい値と比較します。このプロセスにより、必要なパフォーマンスを継続的に達成できます。
### 実装手順
+ 本番環境に基づいてテスト環境を設定します。AWS のサービスを使用して、アーキテクチャをテストするための本番規模の環境を実行することができます。
+ ワークロードに適した負荷テストツールを選択して設定します。
+ 負荷テストのシナリオとパラメータ (テスト期間やユーザー数など) を定義します。
+ テストシナリオを大規模に実行します。AWS クラウドを活用してワークロードをテストし、どこでスケールしないのか、あるいは非線形にスケールしているのかを発見してください例えば、低コストで負荷を生成し、本番前にボトルネックを発見するには、スポットインスタンスを使用します。
+ パフォーマンスメトリクス (スループットや応答時間など) をモニタリングして記録します。Amazon CloudWatch では、アーキテクチャ内のリソース全体のメトリクスを収集できます。また、カスタムメトリクスを収集および発行して、ビジネスメトリクスまたは導出メトリクスを表面化することも可能です。
+ 結果を分析して、パフォーマンスのボトルネックおよび改善が必要な領域を特定します。
+ 負荷テストのプロセスと結果を文書化して報告します。
## リソース
**関連するドキュメント:**
+ [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)
+ [Amazon CloudWatch RUM](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html)
+ [Amazon CloudWatch Synthetics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [AWS での分散負荷テスト](https://docs.aws.amazon.com/solutions/latest/distributed-load-testing-on-aws/welcome.html)
**関連動画:**
+ [Solving with AWS Solutions: Distributed Load Testing](https://www.youtube.com/watch?v=Y-2rk0sSyOM)
+ [Optimize applications through Amazon CloudWatch RUM](https://www.youtube.com/watch?v=NMaeujY9A9Y)
+ [Amazon CloudWatch Synthetics のデモ](https://www.youtube.com/watch?v=hF3NM9j-u7I)
**関連サンプル:**
+ [AWS での分散負荷テスト](https://aws.amazon.com/solutions/implementations/distributed-load-testing-on-aws/)
# PERF05-BP05 自動化でパフォーマンス関連の問題をプロアクティブに修正する
主要業績評価指標 (KPI) をモニタリングおよびアラート発行システムと組み合わせて使用し、パフォーマンス関連の問題に積極的に対処します。
**一般的なアンチパターン:**
+ 運用スタッフのみに対して、ワークロードに運用上の変更を加えることを許可する。
+ プロアクティブな修復を行うことなく、すべてのアラームが運用チームに届くようにしている。
**このベストプラクティスを活用するメリット:** アラームアクションをプロアクティブに修正することで、サポートスタッフは自動的に実行できない項目に集中できます。これにより、運用スタッフがすべてのアラームの対応に忙殺されることがなくなり、代わりに重要なアラームのみに集中できます。
**このベストプラクティスを活用しない場合のリスクレベル:** 低
## 実装のガイダンス
アラームを使用して、可能な場合には自動的に問題を修正するアクションを呼び出します。自動化された対応が不可能な場合は、対応できるシステムにアラームをエスカレートします。例えば、期待される主要業績評価指標 (KPI) 値を予測し、それらが特定のしきい値を超えた場合にアラームを発行できるシステム、または KPI が期待される値の範囲外である場合に、デプロイメントを自動的に停止、またはロールバックできるツールなどが考えられます。
実行中のワークロードのパフォーマンスを目で見て確認できるようにするプロセスを実装します。モニタリングダッシュボードを構築し、パフォーマンス期待のベースラインとなる基準を確立して、ワークロードが最適に機能しているかどうかを判断します。
### 実装手順
+ 自動的に修正できるパフォーマンスの問題を特定して把握します。Amazon CloudWatch やAmazon CloudWatch などの [AWS](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) モニタリングソリューションを使用して、問題の根本原因をよりよく理解します。
+ 問題の自動修正に使用できるステップバイステップの修正計画とプロセスを作成します。
+ 修正プロセスを自動的に開始するようにトリガーを設定します。例えば、CPU 使用率が特定のしきい値に達したときにインスタンスを自動的に再起動するトリガーを定義できます。
+ AWS のサービスとテクノロジーを使用して修正プロセスを自動化します。例えば、 [AWS Systems Manager Automation を使用すると、](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) 安全かつスケーラブルに修正プロセスを自動化できます。
+ 自動修正プロセスを本番前環境でテストします。
+ テスト後、修正プロセスを本番環境に実装し、継続的にモニタリングして改善が必要な領域を特定します。
## リソース
**関連するドキュメント:**
+ [CloudWatch ドキュメント](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)
+ [モニタリング、ログ記録、およびパフォーマンス AWS Partner Network パートナー](https://aws.amazon.com/devops/partner-solutions/#_Monitoring.2C_Logging.2C_and_Performance)
+ [X-Ray ドキュメント](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
+ [Using Alarms and Alarm Actions in CloudWatch](https://docs.aws.amazon.com/sdk-for-go/v1/developer-guide/cw-example-using-alarm-actions.html)
**関連動画:**
+ [Intelligently automating cloud operations](https://www.youtube.com/watch?v=m0S8eAF0l54)
+ [Setting up controls at scale in your AWS environment](https://www.youtube.com/watch?v=NkE9_okfPG8)
+ [Automating patch management and compliance using AWS](https://www.youtube.com/watch?v=gL3baXQJvc0)
+ [How Amazon uses better metrics for improved website performance](https://www.youtube.com/watch?v=_uaaCiyJCFA&ab_channel=AWSEvents)
**関連する例:**
+ [CloudWatch Logs Customize Alarms](https://github.com/awslabs/cloudwatch-logs-customize-alarms)
# PERF05-BP06 ワークロードとサービスを最新の状態に保つ
新しいクラウドサービスと機能の最新情報を入手し、効率的な機能を取り入れ、問題を取り除き、ワークロードの全体的なパフォーマンス効率を向上させます。
**一般的なアンチパターン:**
+ 現在のアーキテクチャが今後は静的なものとなり、しばらく更新されないと考えている。
+ 更新されたソフトウェアおよびパッケージがワークロードと互換性があるかどうかを評価するためのシステムまたは定期的な予定がない。
**このベストプラクティスを活用するメリット:** 新しいサービスやオファリングに関する最新情報を入手するプロセスを確立することで、新しい機能を取り入れ、問題を解決し、ワークロードパフォーマンスを向上させることができます。
**このベストプラクティスを活用しない場合のリスクレベル:** 低
## 実装のガイダンス
新しいサービス、設計パターン、製品が利用可能になったら、パフォーマンスを向上させる方法を検討します。評価、社内でのディスカッション、または外部分析を通じて、これらのリリースとサービスのどれがワークロードのパフォーマンスまたは効率性を向上させるかを判断します。ワークロードに関連するアップデート、新しい機能、サービスを評価するプロセスを定義します。例えば、新テクノロジーを使用する PoC (概念実証) の構築や内部グループとの協議などのプロセスが考えられます。新しいアイデアやサービスを試す場合、パフォーマンステストを実施して、ワークロードのパフォーマンスへの影響を測定します。
## 実装手順
+ ワークロードソフトウェアおよびアーキテクチャをインベントリに登録して、更新する必要があるコンポーネントを特定する。
+ ワークロードコンポーネントに関連するニュースとアップデートソースを特定します。例えば、 [AWS の最新情報ブログを購読して、](https://aws.amazon.com/new/) ワークロードコンポーネントに適した製品の情報を入手できます。RSS フィードを購読したり、E メールサブスクリプションを [管理したりして、購読できます](https://pages.awscloud.com/communication-preferences.html)。
+ ワークロード用の新しいサービスと機能を評価するためのスケジュールを設定します。
+ この場合、 [AWS Systems Manager インベントリ](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-inventory.html) を使用して、Amazon EC2 インスタンスからオペレーティングシステム (OS)、アプリケーション、インスタンスのメタデータを収集し、どのインスタンスがソフトウェアポリシーで要求されるソフトウェアと設定を実行しているか、どのインスタンスがアップデートする必要があるかを迅速に把握することが可能です。
+ ワークロードのコンポーネントを更新する方法を理解します。クラウドの俊敏性を利用して、新しい機能によってワークロードがどのように改善するかをすばやくテストし、パフォーマンス効率を向上させます。
+ 更新プロセスにオートメーションを使用して、新しい機能をデプロイする労力のレベルを軽減し、手動プロセスに起因するエラーを抑制します。
+ この場合、 [CI/CD ](https://aws.amazon.com/blogs/devops/complete-ci-cd-with-aws-codecommit-aws-codebuild-aws-codedeploy-and-aws-codepipeline/) を使用して、AMI、コンテナイメージなど、クラウドアプリケーションに関連するアーティファクトを自動的に更新できます。
+ AWS Systems Manager Patch Manager [などの](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html) ツールを使用して、システム更新のプロセスを自動化し、 [AWS Systems Manager メンテナンスウィンドウを使用してアクティビティをスケジューリングします](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-maintenance.html)。
+ アップデートと新しいサービスの評価プロセスを文書化します。アップデートや新しいサービスを調査、テスト、実験、検証するために必要な時間と場所を所有者に提供します。文書化したビジネスの要件と KPI を参照して、どのアップデートがビジネスにメリットをもたらすかの優先順位を付けます。
## リソース
**関連するドキュメント:**
+ [AWS ブログ](https://aws.amazon.com/blogs/)
+ [AWS の最新情報](https://aws.amazon.com/new/?ref=wellarchitected)
**関連動画:**
+ [AWS Events YouTube チャンネル](https://www.youtube.com/channel/UCdoadna9HFHsxXWhafhNvKw)
+ [AWS Online Tech Talks YouTube チャンネル](https://www.youtube.com/user/AWSwebinars)
+ [Amazon Web Services YouTube チャンネル](https://www.youtube.com/channel/UCd6MoB9NC6uYN2grvUNT-Zg)
**関連する例:**
+ [Well-Architected ラボ - インベントリおよびパッチ管理](https://wellarchitectedlabs.com/operational-excellence/100_labs/100_inventory_patch_management/)
+ [ラボ: AWS Systems Manager](https://mng.workshop.aws/ssm.html)
# PERF05-BP07 メトリクスを定期的に見直す
定期的なメンテナンスの一環として、またはイベントやインシデントに応じて、収集対象のメトリクスを見直します。この見直しを通じて、どのメトリクスが問題対応の鍵となったか、またどのメトリクスを追加で追跡すると問題の特定、対応、防止に役立つと思われるかを特定します。
**一般的なアンチパターン:**
+ メトリクスを長期間アラーム状態のままにする。
+ 自動システムによって実行できないアラームを作成する。
**このベストプラクティスを活用するメリット:** 収集されているメトリクスを継続的に見直し、問題について適切に識別、対応、または防止します。また、メトリクスは、長期間アラーム状態のままとなった場合にも、陳腐化することがあります。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
メトリクスの収集とモニタリングを継続的に改善します。インシデントやイベントへの対応の一環として、問題解決に役立ったメトリクスと、問題解決に役立った可能性があるものの、現在は追跡されていないメトリクスを評価します。この方法を使用して収集するメトリクスの品質を高め、今後のインシデントを防止、またはより迅速に解決できるようにします。
インシデントやイベントへの対応の一環として、問題解決に役立ったメトリクスと、問題解決に役立った可能性があるものの、現在は追跡されていないメトリクスを評価します。これを使用して、収集するメトリクスの品質を高め、今後のインシデントを防止、またはより迅速に解決できるようにします。
### 実装手順
1. ワークロードの目標に合わせて、モニタリングする重要なパフォーマンスメトリクスを定義します。
1. 各メトリクスのベースラインと目標値を設定します。
1. 重要なメトリクスをレビューする頻度 (毎週、毎月など) を設定します。
1. 各レビューでは、傾向とベースライン値からの偏差を評価します。パフォーマンスのボトルネックや異常がないか調べます。
1. 特定された問題については、詳細な根本原因分析を実施して、問題の背後にある主な理由を把握します。
1. 調査結果を文書化し、戦略を使用して特定された問題やボトルネックに対処します。
1. メトリクスレビュープロセスを継続的に評価し、改善します。
## リソース
**関連するドキュメント:**
+ [CloudWatch ドキュメント](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)
+ [CloudWatch エージェントを使用して Amazon EC2 インスタンスとオンプレミスサーバーからメトリクスとログを収集する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html?ref=wellarchitected)
+ [モニタリング、ログ記録、およびパフォーマンス AWS Partner Network パートナー](https://aws.amazon.com/devops/partner-solutions/#_Monitoring.2C_Logging.2C_and_Performance)
+ [X-Ray ドキュメント](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
**関連動画:**
+ [Setting up controls at scale in your AWS environment](https://www.youtube.com/watch?v=NkE9_okfPG8)
+ [How Amazon uses better metrics for improved website performance](https://www.youtube.com/watch?v=_uaaCiyJCFA&ab_channel=AWSEvents)
**関連する例:**
+ [Creating a dashboard with Quick](https://github.com/aws-samples/amazon-quicksight-sdk-proserve)
+ [Level 100: Monitoring with CloudWatch Dashboards](https://wellarchitectedlabs.com/performance-efficiency/100_labs/100_monitoring_with_cloudwatch_dashboards/)