# 選択 **Topics** + [PERF 1 どのように最良パフォーマンスのアーキテクチャを選択するのですか?](perf-01.md) + [PERF 2 コンピューティングソリューションはどのように選択すればよいですか?](perf-02.md) + [PERF 3 ストレージソリューションはどのように選択すればよいですか?](perf-03.md) + [PERF 4 データベースソリューションはどのように選択すればよいですか?](perf-04.md) + [PERF 5 ネットワーキングソリューションはどのように選択すればよいですか?](perf-05.md) # PERF 1 どのように最良パフォーマンスのアーキテクチャを選択するのですか? 多くの場合、ワークロード全体での最適なパフォーマンスのためには、複数のアプローチが必要になります。Well-Architected なシステムでは、パフォーマンスを向上させるために複数のソリューションと機能が使用されています。 **Topics** + [PERF01-BP01 利用可能なサービスやリソースを理解する](perf_performing_architecture_evaluate_resources.md) + [PERF01-BP02 アーキテクチャにかかわる選択プロセスを決める](perf_performing_architecture_process.md) + [PERF01-BP03 意思決定においてコスト要件を考慮する](perf_performing_architecture_cost.md) + [PERF01-BP04 ポリシーやリファレンスアーキテクチャを使用する](perf_performing_architecture_use_policies.md) + [PERF01-BP05 クラウドプロバイダー、または適切なパートナーからのガイダンスを利用する](perf_performing_architecture_external_guidance.md) + [PERF01-BP06 既存のワークロードのベンチマークを実施する](perf_performing_architecture_benchmark.md) + [PERF01-BP07 ワークロードの負荷テスト](perf_performing_architecture_load_test.md) # PERF01-BP01 利用可能なサービスやリソースを理解する クラウドで利用できる幅広いサービスやリソースに関する情報を取得し、その内容を理解します。お客様のワークロードに関連するサービスや設定の選択肢を認識した上で、最適なパフォーマンスを実現する方法を理解してください。 既存のワークロードを評価している場合は、それによって消費されるさまざまなサービスとリソースのインベントリを作成する必要があります。この一覧は、どのコンポーネントをマネージドサービス、および新しいテクノロジーに置き換えることができるかを評価するために役立ちます。 **一般的なアンチパターン:** + クラウドをコロケーションされたデータセンターとして使用する。 + 永続的なストレージを必要とするすべてに共有ストレージを使用する。 + 自動スケーリングを使用しない。 + 現在の基準に最も近いインスタンスタイプを使用するが、必要に応じてより大きいインスタンスタイプを使用しない。 + マネージドサービスとして使用できるテクノロジーをデプロイおよび管理する。 **このベストプラクティスを活用するメリット:** 使い慣れていないサービスを検討することで、インフラストラクチャのコストと、サービスの維持に必要な労力を大幅に削減できる可能性があります。新しいサービスや機能をデプロイすることで、市場投入までの時間を短縮できる場合があります。 **このベストプラクティスを活用しない場合のリスクレベル:** 高 ## 実装のガイダンス 関連サービスのワークロードソフトウェアとアーキテクチャの一覧を作成する: ワークロードのインベントリを収集し、詳細を確認する製品のカテゴリを決定します。パフォーマンスを向上させ、運用の複雑さを軽減するために、マネージドサービスに置き換えることができるワークロードコンポーネントを特定します。 ## リソース **関連ドキュメント:** + [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/) **関連動画:** + [Introducing The Amazon Builders’ Library (DOP328)](https://www.youtube.com/watch?v=sKRdemSirDM) + [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 アーキテクチャにかかわる選択プロセスを決める クラウドに関する社内の経験と知識、公開されたユースケース、関連ドキュメント、ホワイトペーパーなどの外部リソースを利用して、リソースとサービスを選択するプロセスを決定します。お客様のワークロードで利用できるサービスについて、実験とベンチーマークを促すプロセスを定義するようにしてください。 アーキテクチャに重要なユーザーストーリーを記述するときは、それぞれの重要なストーリーをどの程度迅速に実行する必要があるかを明記するなど、パフォーマンス要件を含めるようにしてください。これらの重要なストーリーには、要件に対してこれらのストーリーがどのように実行されるかについての可視性を確保するために、スクリプト化されたユーザージャーニーを追加で実装するようにしてください。 **一般的なアンチパターン:** + あなたは、現在のアーキテクチャが今後は静的なものとなり、しばらく更新されないと考えています。 + あなたは、理由なしで、時間の経過とともにアーキテクチャの変更を導入します。 **このベストプラクティスを活用するメリット:** アーキテクチャの変更を行うためのプロセスを定義することで、収集されたデータを使用して、時間の経過とともにワークロード設計を適宜変更します。 **このベストプラクティスを活用しない場合のリスクレベル:** 高 ## 実装のガイダンス アーキテクチャのアプローチを選択する: パフォーマンス要件を満たすアーキテクチャの種類を特定します。配信用のメディア (デスクトップ、ウェブ、モバイル、IoT)、従来の要件、統合などの制約を特定します。リファクタリングなどの再利用の機会を把握します。他のチーム、アーキテクチャ図、および AWS ソリューションアーキテクト、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/) **関連動画:** + [Introducing The Amazon Builders’ Library (DOP328)](https://www.youtube.com/watch?v=sKRdemSirDM) + [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 意思決定においてコスト要件を考慮する ワークロードには、多くの場合、運用のコスト要件があります。社内のコスト管理を使用し、予測されたリソースニーズに基づいて、リソースのタイプとサイズを選択してください。 ワークロードの各要素がマネージドデータベース、インメモリキャッシュ、ETL サービスなどのフルマネージド型サービスに置き換えることができるかを判断します。自社で運用すべきワークロードを削減することによって、リソースをビジネス成果に集中させることが可能になります。 コスト要件のベストプラクティスについては、 *費用対効果の高いリソース* セクションにある [コスト最適化の柱に関するホワイトペーパーを参照してください](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/welcome.html). **一般的なアンチパターン:** + インスタンスの 1 つのファミリーのみを使用する。 + ライセンスソリューションとオープンソースソリューションを比較しない。 + ブロックストレージのみを使用する。 + 一般的なソフトウェアを EC2 インスタンスと、マネージドサービスとして使用できる Amazon EBS ボリュームまたはエフェメラルボリュームにデプロイする。 **このベストプラクティスを活用するメリット:** 選択を行う際にコストを考慮することで、他の投資が可能となります。 **このベストプラクティスを活用しない場合のリスクレベル:** 中 ## 実装のガイダンス ワークロードコンポーネントを最適化し、伸縮性を実現することで、コストを削減し、コンポーネントの効率を最大化します。マネージドデータベース、インメモリキャッシュ、リバースプロキシなど、必要に応じてマネージドサービスに置き換えることができるワークロードコンポーネントを判断します。 ## リソース **関連ドキュメント:** + [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 Compute Optimizer](https://aws.amazon.com/compute-optimizer/) **関連動画:** + [Introducing The Amazon Builders’ Library (DOP328)](https://www.youtube.com/watch?v=sKRdemSirDM) + [This is my Architecture](https://aws.amazon.com/architecture/this-is-my-architecture/) + [Optimize performance and cost for your AWS compute (CMP323-R1) ](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 ポリシーやリファレンスアーキテクチャを使用する 内部ポリシーと既存のリファレンスアーキテクチャを評価し、独自の分析を使用してワークロードのサービスと設定を選択することによって、パフォーマンスと効率性を最大化します。 **一般的なアンチパターン:** + あなたは、会社の管理オーバーヘッドに影響する可能性のあるテクノロジーの選択を幅広く使用することを許可します。 **このベストプラクティスを確立するメリット:** アーキテクチャ、テクノロジー、ベンダーの選択に関するポリシーを確立することで、迅速な意思決定が可能になります。 **このベストプラクティスが確立されていない場合のリスクレベル:** 中 ## 実装のガイダンス 既存のポリシーまたはリファレンスアーキテクチャを使用してワークロードをデプロイする: サービスをクラウドデプロイに統合し、パフォーマンステストを使用して、パフォーマンス要件を継続的に満たすことができることを確認します。 ## リソース **関連ドキュメント:** + [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/) **関連動画:** + [Introducing The Amazon Builders’ Library (DOP328)](https://www.youtube.com/watch?v=sKRdemSirDM) + [This is my Architecture](https://aws.amazon.com/architecture/this-is-my-architecture/) **関連サンプル:** + [AWS Samples](https://github.com/aws-samples) + [AWS SDK Examples (AWS SDK サンプル)](https://github.com/awsdocs/aws-doc-sdk-examples) # PERF01-BP05 クラウドプロバイダー、または適切なパートナーからのガイダンスを利用する 判断の指針とするために、ソリューションアーキテクト、プロフェッショナルサービス、または適切なパートナーなどのクラウド企業のリソースを利用します。それらのリソースはお客様のアーキテクチャにおける最適なパフォーマンスを実現するためのレビューと改善に役立ちます。 追加のガイダンス、または製品情報が必要な場合は、AWS までお問い合わせください。AWS ソリューションアーキテクトおよび [AWS プロフェッショナルサービス](https://aws.amazon.com/professional-services/) は、ソリューションの実装に関するガイダンスを提供します。 [AWS パートナー](https://aws.amazon.com/partners/) は、ビジネスの俊敏性とイノベーションを引き出すために AWS の専門知識を提供します。 **一般的なアンチパターン:** + 一般的なデータセンタープロバイダーとして AWS を利用する。 + 意図されていない方法で AWS のサービスを利用する。 **このベストプラクティスを確立するメリット:** プロバイダーやパートナーに相談することで、意思決定に対する自信を高めることができます。 **このベストプラクティスが確立されていない場合のリスクレベル:** 中 ## 実装のガイダンス AWS リソースにサポートを依頼する: AWS ソリューションアーキテクトとプロフェッショナルサービスは、ソリューションの実装におけるガイダンスを提供します。APN パートナーは、ビジネスの俊敏性とイノベーションを引き出すために 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/) **関連動画:** + [Introducing The Amazon Builders’ Library (DOP328)](https://www.youtube.com/watch?v=sKRdemSirDM) + [This is my Architecture](https://aws.amazon.com/architecture/this-is-my-architecture/) **関連サンプル:** + [AWS Samples](https://github.com/aws-samples) + [AWS SDK Examples (AWS SDK サンプル)](https://github.com/awsdocs/aws-doc-sdk-examples) # PERF01-BP06 既存のワークロードのベンチマークを実施する 既存のワークロードのパフォーマンスにベンチマーク結果を参考に、クラウドでの実行状況を把握します。ベンチマークから収集されたデータを使用して、アーキテクチャ面での判断を導き出します。 合成テストと実際のユーザーのモニタリングによるベンチマークを使用して、ワークロードの各コンポーネントがどのように機能するかに関するデータを生成します。ベンチマークは概して負荷テストよりも迅速にセットアップでき、特定のコンポーネントに対するテクノロジーを評価するために使用されます。ベンチマークは、まだ負荷テストができるほどソリューションが完成していないプロジェクトの初期段階によく使用されます。 独自のカスタムベンチマークテストを構築するか、TPC-DS などの業界標準テストを [使用できます ](http://www.tpc.org/tpcds/) (データウェアハウジングのワークロードをベンチマークする場合)。業界ベンチマークは、環境を比較する場合に有用です。カスタムベンチマークは、アーキテクチャで採用する予定の特殊なオペレーションを対象にするときに役立ちます。 ベンチマークを実施するときは、有効な結果が得られることを確実にするためにテスト環境の事前暖気を行うことが重要です。同じベンチマークを複数回実行して、時系列での変動をとらえておくようにしてください。 ベンチマークは概して負荷テストよりも速く実行されるため、デプロイパイプラインの早い時期に使用でき、パフォーマンスの逸脱に関するフィードバックもより迅速に提供されます。ベンチマークは、コンポーネント、またはサービスにおける大幅な変更を評価する場合に、その変更を行う労力を正当化できるかどうかを見極める近道となり得ます。負荷テストでは、ワークロードが本番環境でどのように機能するかに関する情報が得られることから、ベンチマークは負荷テストと併せて使用することが重要です。 **一般的なアンチパターン:** + あなたは、ワークロードの特性を示唆しない一般的なベンチマークに依存しています。 + 顧客からのフィードバックと認識を唯一のベンチマークとして使用している。 **このベストプラクティスを活用するメリット:** 現在の実装をベンチマークすることで、パフォーマンスの向上を測定できます。 **このベストプラクティスを活用しない場合のリスクレベル:** 中 ## 実装のガイダンス 開発中にパフォーマンスをモニタリングする: ワークロードの進化に合わせて、パフォーマンスを目で見て確認できるプロセスを実装します。 配信パイプラインに統合する: 配信パイプラインで負荷テストを自動的に実行します。テスト結果を事前定義された主要業績評価指標 (KPI) やしきい値と比較して、引き続きパフォーマンス要件を満たせるようにします。 ユーザージャーニーをテストする: 負荷テストには、本番データの合成またはサニタイズされたバージョン (機密情報や個人が特定できる情報は削除する) を使用します。アプリケーション全体で再生またはプログラミング済みのユーザージャーニーを大規模に使用して、アーキテクチャ全体を練習として動かします。 実際のユーザーのモニタリング: CloudWatch RUM を使用して、アプリケーションのパフォーマンスに関するクライアント側のデータを収集、表示できます。このデータを使用して、実際のユーザーのパフォーマンスベンチマークを確立します。 ## リソース **関連ドキュメント:** + [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) **関連動画:** + [Introducing The Amazon Builders’ Library (DOP328)](https://www.youtube.com/watch?v=sKRdemSirDM) + [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 ワークロードの負荷テスト 異なるリソースタイプとサイズを使用して、最新のワークロードアーキテクチャをクラウドにデプロイします。デプロイメントをモニタリングして、ボトルネック、または過剰なキャパシティーを特定するパフォーマンスメトリクスを取得してください。このパフォーマンス情報を使用して、お客様のアーキテクチャとリソースの選択を改善します。 負荷テストでは *実際の* ワークロードを使用するため、ソリューションが本番環境でどのように機能するかを確認できます。ロードテストは、本番データの合成バージョンまたはサニタイズバージョン (機密情報または識別情報を削除) を使用して実行する必要があります。大規模にアーキテクチャ全体に対して負荷をかけるため、ユーザーのサービス利用方法をリプレイする、もしくはプログラムによって再現できるようにします。デリバリーパイプラインの一環として負荷テストを自動的に実行し、その結果を事前定義された KPI およびしきい値と比較します。こうすることで、必要とされるパフォーマンスの継続的な達成が保証されます。 **一般的なアンチパターン:** + あなたは、ワークロード全体ではなく、ワークロードの個々の部分について負荷テストを行います。 + あなたは、本番環境とは異なるインフラストラクチャで負荷テストを行います。 + あなたは、今後問題が発生する可能性を予測するのに役立てるため、予想される負荷に対してのみ、負荷テストを実施し、それを超える負荷に対しては負荷テストを実施しません。 + AWS サポート に通知することなく負荷テストを実行し、あたかもサービス拒否のようなイベントが発生することで、テストが打ち切られてしまいます。 **このベストプラクティスを確立するメリット:** 負荷テストでパフォーマンスを測定すると、負荷の増加に伴って影響を受ける場所が判明します。これにより、必要な変更がワークロードに影響を与える前に予測できるようになります。 **このベストプラクティスが確立されていない場合のリスクレベル:** 低 ## 実装のガイダンス 負荷テストによってアプローチを検証する: パフォーマンス要件を満たすかどうかを確認するために、概念実証のための負荷テストを行います。AWS のサービスを使用して、アーキテクチャをテストするための本番規模の環境を実行することができます。料金はテスト環境が必要となる場合にのみ発生することから、オンプレミス環境を使用する場合に比べてわずかなコストで本格的なテストを実施できます。 メトリクスをモニタリングする: Amazon CloudWatch では、アーキテクチャ内のリソース全体のメトリクスを収集できます。また、カスタムメトリクスを収集および発行して、ビジネスメトリクスまたは導出メトリクスを表面化することも可能です。CloudWatch またはサードパーティーのソリューションを使用して、しきい値を超過したことを示すアラームを設定します。 大規模にテストする: 負荷テストは実際のワークロードを使用するため、ソリューションが本番環境でどのように機能するかを確認できます。AWS のサービスを使用して、アーキテクチャをテストするための本番規模の環境を実行することができます。テスト環境に対する支払いはテスト環境が必要なときにのみ発生するため、オンプレミスの環境を使用する場合より低いコストで大規模なテストを実行できます。AWS クラウドを活用してワークロードをテストし、どこでスケールしないのか、あるいは非線形にスケールしているのかを発見してください例えば、低コストで負荷を生成し、本番前にボトルネックを発見するには、スポットインスタンスを使用します。 ## リソース **関連ドキュメント:** + [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) + [Building AWS CloudFormation Templates using CloudFormer (CloudFormer を使った AWS CloudFormation テンプレートの構築)](https://aws.amazon.com/blogs/devops/building-aws-cloudformation-templates-using-cloudformer/) + [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) **関連動画:** + [Introducing The Amazon Builders’ Library (DOP328)](https://www.youtube.com/watch?v=sKRdemSirDM) + [Optimize applications through Amazon CloudWatch RUM (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/) # PERF 2 コンピューティングソリューションはどのように選択すればよいですか? ワークロードにとって最適なコンピューティングソリューションは、アプリケーションの設計、使用パターン、設定に応じて異なります。各アーキテクチャでは、コンポーネントごとに異なるコンピューティングソリューションが使用される可能性があるため、パフォーマンスを向上させるための機能も異なります。アーキテクチャに不適切なコンピューティングソリューションを選択すると、パフォーマンス効率が低下する可能性があります。 **Topics** + [PERF02-BP01 使用可能なコンピューティングオプションを評価する](perf_select_compute_evaluate_options.md) + [PERF02-BP02 利用可能なコンピューティング設定オプションについて理解する](perf_select_compute_config_options.md) + [PERF02-BP03 コンピューティング関連のメトリクスを収集する](perf_select_compute_collect_metrics.md) + [PERF02-BP04 適切なサイジングによって必要な設定を決定する](perf_select_compute_right_sizing.md) + [PERF02-BP05 利用可能な伸縮性のあるリソースを使用する](perf_select_compute_elasticity.md) + [PERF02-BP06 メトリクスに基づいてコンピューティングニーズを再評価する](perf_select_compute_use_metrics.md) # PERF02-BP01 使用可能なコンピューティングオプションを評価する インスタンス、コンテナ、関数などのさまざまなコンピューティングオプションを使用することで、ワークロードにどのようなメリットがあるかを理解します。 **期待される成果:** 利用できるすべてのコンピューティングオプションを理解することにより、パフォーマンスを高め、不要なインフラストラクチャコストを削減し、ワークロードの維持に必要な運用労力を低減するための機会に気付くことができます。また、新しいサービスや機能をデプロイする際に、市場投入までの時間を短縮できます。 **一般的なアンチパターン:** + 移行後のワークロードで、オンプレミスで使用していたコンピューティングソリューションをそのまま使用する。 + クラウドコンピューティングソリューションや、そうしたソリューションがコンピューティング性能の向上にどのように役立つかについての認識が足りない。 + ワークロードの特性により的確に適合する代替のコンピューティングソリューションがあるにもかかわらず、スケーリングやパフォーマンスの要件を満たすために既存のコンピューティングソリューションのサイズを大きくしすぎる。 **このベストプラクティスを活用するメリット:** コンピューティング要件を特定し、利用できるコンピューティングソリューションを評価することにより、ビジネスステークホルダーやエンジニアリングチームが、選択したコンピューティングソリューションを使用することの利点や制限を理解できます。選択したコンピューティングソリューションは、ワークロードのパフォーマンス基準に適合している必要があります。主な基準には、処理の必要性、トラフィックパターン、データアクセスパターン、スケーリングの必要性、レイテンシー要件があります。 **このベストプラクティスを活用しない場合のリスクレベル:** 高 ## 実装のガイダンス ワークロードにメリットをもたらし、パフォーマンス要件を満たす仮想化、コンテナ化、マネジメントのソリューションを理解します。1 つのワークロードには、複数の種類のコンピューティングソリューションを含めることができます。コンピューティングソリューションにはぞれぞれ、異なる特徴があります。ワークロードのスケールとコンピューティング要件を基に、コンピューティングソリューションを選択し、ニーズを満たすように構成できます。クラウドアーキテクトは、インスタンス、コンテナ、関数の長所と短所を学ぶ必要があります。次の手順では、ワークロードの特性とパフォーマンス要件に合ったコンピューティングソリューションを選択する方法を詳しく説明しています。 | **タイプ** | **サーバー** | **コンテナ** | **関数** | | --- | --- | --- | --- | | AWS のサービス | Amazon Elastic Compute Cloud (Amazon EC2) | Amazon Elastic Container Service (Amazon ECS), Amazon Elastic Kubernetes Service (Amazon EKS) | AWS Lambda | | 主な特徴 | ハードウェアライセンス要件、プレイスメントオプション、またコンピューティングメトリクスに基づくさまざまなインスタンスファミリーの幅広い選択肢のための専用オプションがある | デプロイが簡単、環境に一貫性がある、EC2 インスタンス上で運用、スケーリングが可能 | ランタイムが短い (15 分以下)、メモリおよび CPU の上限は他のサービスほど高くない、マネージドハードウェア層、何百万の同時リクエストに対応してスケーリング | | 一般的なユースケース | リフトアンドシフトの移行、モノリシックなアプリケーション、ハイブリッド環境、エンタープライズアプリケーション | マイクロサービス、ハイブリッド環境 | マイクロサービス、イベント駆動型アプリケーション | **実装手順:** 1. 「 [PERF05-BP06 ネットワーク要件に基づいてワークロードのロケーションを選択する](perf_select_network_location.md)」セクションを評価して、コンピューティングソリューションを配置する場所を選択します。この場所により、使用できるコンピューティングソリューションのタイプが制限されます。 1. 場所の要件とアプリケーション要件に適したコンピューティングソリューションのタイプを特定します。  1. [https://aws.amazon.com/ec2/](https://aws.amazon.com/ec2/) 仮想サーバーインスタンスにはさまざまなファミリーとサイズがあります。またソリッドステートドライブ (SSD)、グラフィック処理ユニット (GPU) などさまざまな機能が使用できます。EC2 インスタンスは、インスタンスの選択において最大の柔軟性を提供します。EC2 インスタンスを起動する場合、指定するインスタンスタイプによって、インスタンスのハードウェアが決まります。インスタンスタイプごとに、コンピューティング、メモリ、ストレージの機能が異なります。インスタンスタイプは、これらの機能に基づいてインスタンスファミリーにグループ分けされます。一般的なユースケースには、エンタープライズアプリケーションの運用、ハイパフォーマンスコンピューティング (HPC)、機械学習アプリケーションのトレーニングおよびデプロイ、クラウドネイティブアプリケーションの運用などがあります。 1. [https://aws.amazon.com/ecs/](https://aws.amazon.com/ecs/) はフルマネージド型のコンテナオーケストレーションサービスで、AWS Fargate を使用したサーバーレスインスタンスまたは EC2 インスタンスでクラスターを構成し、コンテナを自動的に実行および管理できるようにします。Amazon ECS は Amazon Route 53、Secrets Manager、AWS Identity and Access Management (IAM)、Amazon CloudWatch などのサービスと併せて使用できます。Amazon ECS は、アプリケーションがコンテナ化されており、エンジニアリングチームが Docker コンテナを好む場合に推奨されます。 1. [https://aws.amazon.com/eks/](https://aws.amazon.com/eks/) は、フルマネージド型の Kubernetes サービスです。AWS Fargate を使って EKS クラスターを実行することもできるため、サーバーのプロビジョニングと管理が不要になります。Amazon EKS の管理は、Amazon CloudWatch、Auto Scaling グループ、AWS Identity and Access Management (IAM)、Amazon Virtual Private Cloud (VPC) などの AWS のサービスとの統合によって簡素化されています。コンテナを使用する場合、EC2 インスタンスまたは AWS Fargate インスタンスのタイプを選択するためにコンピューティングメトリクスを使用するのと同様に、ワークロードに最も適したタイプを選択するためにコンピューティングメトリクスを使用する必要があります。Amazon EKS は、アプリケーションがコンテナ化されており、エンジニアリングチームが Docker コンテナよりも Kubernetes 好む場合に推奨されます。 1. 専用のインフラストラクチャで [https://aws.amazon.com/lambda/](https://aws.amazon.com/lambda/) を使用すると、許可されたランタイム、メモリ、CPU のオプションをサポートするコードを実行できます。コードをアップロードするだけで、AWS Lambda がそのコードの実行とスケーリングに必要となるものすべてを管理します。コードは、他の AWS のサービスから自動的にトリガーするように設定するか、直接呼び出すことができます。Lambda は、クラウド用に開発された実行時間の短いマイクロサービスアーキテクチャに推奨されます。  1. 新しいコンピューティングソリューションを試した後、移行を計画し、パフォーマンスメトリクスを検証します。これは継続的なプロセスです。詳細については、 [PERF02-BP04 適切なサイジングによって必要な設定を決定する](perf_select_compute_right_sizing.md)を参照してください。 **実装計画に必要な工数レベル:** ワークロードがあるコンピューティングソリューションから別のコンピューティングソリューションに移行する場合は、アプリケーションのリファクタリングに *中* 程度の工数が必要になる可能性があります。   ## リソース **関連ドキュメント:** + [AWS を使用したクラウドコンピューティング ](https://aws.amazon.com/products/compute/?ref=wellarchitected) + [EC2 インスタンスタイプ ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html?ref=wellarchitected) + [EC2 インスタンスのプロセッサのステート制御 ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/processor_state_control.html?ref=wellarchitected) + [EKS コンテナ: 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 (CMP323-R1)](https://www.youtube.com/watch?v=zt6jYJLK8sg) + [Amazon EC2 foundations (CMP211-R2) ](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) + [Deliver high-performance ML inference with AWS Inferentia (CMP324-R1) ](https://www.youtube.com/watch?v=17r1EapAxpk&ref=wellarchitected) + [Better, faster, cheaper compute: Cost-optimizing Amazon EC2 (CMP202-R1) ](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 利用可能なコンピューティング設定オプションについて理解する 各コンピューティングソリューションには、ワークロードの特性をサポートするために使用できるオプションと設定があります。さまざまなオプションがワークロードをどのように補完するか、またアプリケーションにどの設定オプションが最適かをご紹介します。これらのオプションの例には、インスタンスのファミリー、サイズ、機能 (GPU、I/O)、バースト、タイムアウト、関数サイズ、コンテナインスタンス、並行性などがあります。 **期待される成果:** CPU、メモリ、ネットワークスループット、GPU、IOPS、トラフィックパターン、データアクセスパターンなどのワークロードの特性を文書化し、ワークロードの特性に合わせてコンピューティングソリューションを設定するために使用されます。これらの各メトリクスと、お客様のワークロードに特化したカスタムメトリクスを記録、監視し、コンピューティング設定を最適化することで、要件に最適に対応します。 **一般的なアンチパターン:** + オンプレミスで使用していたコンピューティングソリューションをそのまま使用する。 + ワークロードの特性に合ったコンピューティングオプションやインスタンスファミリーを見直さない。 + バースト能力を確保するためにコンピューティングを過剰にする。 + 同じワークロードに対して複数のコンピューティング管理プラットフォームを使用する。 ** このベストプラクティスを確立するメリット:** AWS のコンピューティングサービスをよく理解し、それぞれのワークロードに適したソリューションを決定できるようにしましょう。ワークロードのコンピューティングサービスを選択したら、それらがワークロードのニーズをどの程度満たしているかを迅速に実験することができます。ワークロードの特性に合うように最適化されたコンピューティングソリューションを使用することで、パフォーマンス改善、コスト削減、信頼性向上を実現できます。 **このベストプラクティスが確立されていない場合のリスクレベル:** 高 ## 実装のガイダンス ワークロードで同じコンピューティングオプションを 4 週間以上使用しており、その特性が今後も変わらないと予想される場合は、 [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/) を使用して、コンピューティング特性に基づいた推奨事項を提供することができます。メトリクスが足りない、インスタンスタイプがサポートされていない、特性が変わることが予想されるなどの理由から、AWS Compute Optimizer [を使用できない場合は、負荷テストや](https://docs.aws.amazon.com/compute-optimizer/latest/ug/requirements.html#requirements-ec2-instances) 実験を基にメトリクスを予測する必要があります。  **実装手順:** 1. EC2 インスタンスで実行していますか、それとも EC2 起動タイプのコンテナで実行していますか。 1. ワークロードで GPU を使用してパフォーマンスを高めることができますか。 1. [高速コンピューティング](https://aws.amazon.com/ec2/instance-types/?trk=36c6da98-7b20-48fa-8225-4784bced9843&sc_channel=ps&sc_campaign=acquisition&sc_medium=ACQ-P|PS-GO|Brand|Desktop|SU|Compute|EC2|US|EN|Text&s_kwcid=AL!4422!3!536392622533!e!!g!!ec2%20instance%20types&ef_id=CjwKCAjwiuuRBhBvEiwAFXKaNNRXM5FrnFg5H8RGQ4bQKuUuK1rYWmU2iH-5H3VZPqEheB-pEm-GNBoCdD0QAvD_BwE:G:s&s_kwcid=AL!4422!3!536392622533!e!!g!!ec2%20instance%20types#Accelerated_Computing) インスタンスとは GPU ベースのインスタンスで、機械学習のトレーニング、推論、ハイパフォーマンスコンピューティング向けに最も高いパフォーマンスを提供します。 1. ワークロードで機械学習推論アプリケーションを実行していますか。 1. [AWS Inferentia (Inf1)](https://aws.amazon.com/ec2/instance-types/inf1/) — Inf1 インスタンスは、機械学習推論アプリケーションをサポートするために構築されています。Inf1 インスタンスを使用すると、画像認識、音声認識、自然言語処理、パーソナライゼーション、不正行為検出といった大規模な機械学習推論アプリケーションを実行できます。モデルは、TensorFlow、PyTorch、MXNet などの一般的な機械学習フレームワークのいずれかで構築し、GPU インスタンスを使用してトレーニングできます。要件に合わせて機械学習モデルをトレーニングしたら、AWS Neuron を使用して Inf1 インスタンスにモデルをデプロイできます。 [AWS Neuron](https://aws.amazon.com/machine-learning/neuron/)は、Inferentia チップの機械学習推論パフォーマンスを最適化するコンパイラー、ランタイム、プロファイリングツールで構成される専用のソフトウェア開発キット (SDK) です。 1. パフォーマンス向上のために、ワークロードを低レベルのハードウェアと統合していますか。  1. [フィールドプログラマブルゲートアレイ (FPGA)](https://aws.amazon.com/ec2/instance-types/f1/) — FPGA を使用することで、最も要求の厳しいワークロードをカスタムハードウェアで加速して実行することができ、ワークロードを最適化することができます。サポートされる、C や Go などの一般的なプログラミング言語や、Verilog や VHDL などのハードウェア指向の言語を利用してアルゴリズムを定義できます。 1. 少なくとも 4 週間分のメトリクスがあり、トラフィックパターンとメトリクスが今後もほぼ同じになると予測できますか。 1. 予想されるコストと使用状況に合わせたカスタムの予算を設定するには、 [Compute Optimizer](https://aws.amazon.com/compute-optimizer/) を使用して、コンピューティング特性に最適なコンピューティング構成に関する機械学習の推奨事項を取得します。 1. ワークロードのパフォーマンスは CPU のメトリクスによって制限されていますか。  1. [コンピューティング最適化](https://aws.amazon.com/ec2/instance-types/?trk=36c6da98-7b20-48fa-8225-4784bced9843&sc_channel=ps&sc_campaign=acquisition&sc_medium=ACQ-P|PS-GO|Brand|Desktop|SU|Compute|EC2|US|EN|Text&s_kwcid=AL!4422!3!536392622533!e!!g!!ec2%20instance%20types&ef_id=CjwKCAjwiuuRBhBvEiwAFXKaNNRXM5FrnFg5H8RGQ4bQKuUuK1rYWmU2iH-5H3VZPqEheB-pEm-GNBoCdD0QAvD_BwE:G:s&s_kwcid=AL!4422!3!536392622533!e!!g!!ec2%20instance%20types#Compute_Optimized) インスタンスは、高性能プロセッサーを必要とするワークロードに適しています。  1. ワークロードのパフォーマンスはメモリのメトリクスによって制限されていますか。  1. [メモリ最適化](https://aws.amazon.com/ec2/instance-types/?trk=36c6da98-7b20-48fa-8225-4784bced9843&sc_channel=ps&sc_campaign=acquisition&sc_medium=ACQ-P|PS-GO|Brand|Desktop|SU|Compute|EC2|US|EN|Text&s_kwcid=AL!4422!3!536392622533!e!!g!!ec2%20instance%20types&ef_id=CjwKCAjwiuuRBhBvEiwAFXKaNNRXM5FrnFg5H8RGQ4bQKuUuK1rYWmU2iH-5H3VZPqEheB-pEm-GNBoCdD0QAvD_BwE:G:s&s_kwcid=AL!4422!3!536392622533!e!!g!!ec2%20instance%20types#Memory_Optimized) インスタンスは大量のメモリを提供し、メモリを集中的に使用するワークロードをサポートします。 1. ワークロードのパフォーマンスは IOPS によって制限されていますか。 1. [ストレージ最適化](https://aws.amazon.com/ec2/instance-types/?trk=36c6da98-7b20-48fa-8225-4784bced9843&sc_channel=ps&sc_campaign=acquisition&sc_medium=ACQ-P|PS-GO|Brand|Desktop|SU|Compute|EC2|US|EN|Text&s_kwcid=AL!4422!3!536392622533!e!!g!!ec2%20instance%20types&ef_id=CjwKCAjwiuuRBhBvEiwAFXKaNNRXM5FrnFg5H8RGQ4bQKuUuK1rYWmU2iH-5H3VZPqEheB-pEm-GNBoCdD0QAvD_BwE:G:s&s_kwcid=AL!4422!3!536392622533!e!!g!!ec2%20instance%20types#Storage_Optimized) インスタンスは、ローカルストレージへの高いシーケンシャルな読み書きアクセス (IOPS) を必要とするワークロード向けに設計されています。 1. ワークロードの特性は、すべてのメトリクスにおいてバランスの取れたニーズを示していますか。 1. ワークロードの CPU にはトラフィックの急上昇に対応するためのバーストが必要ですか。 1. [バーストパフォーマンス](https://aws.amazon.com/ec2/instance-types/?trk=36c6da98-7b20-48fa-8225-4784bced9843&sc_channel=ps&sc_campaign=acquisition&sc_medium=ACQ-P|PS-GO|Brand|Desktop|SU|Compute|EC2|US|EN|Text&s_kwcid=AL!4422!3!536392622533!e!!g!!ec2%20instance%20types&ef_id=CjwKCAjwiuuRBhBvEiwAFXKaNNRXM5FrnFg5H8RGQ4bQKuUuK1rYWmU2iH-5H3VZPqEheB-pEm-GNBoCdD0QAvD_BwE:G:s&s_kwcid=AL!4422!3!536392622533!e!!g!!ec2%20instance%20types#Instance_Features) インスタンスは、コンピューティング最適化インスタンスに似ていますが、コンピューティング最適化インスタンスに見られる固定 CPU ベースラインを超えてバーストできるという点が異なります。 1. [汎用](https://aws.amazon.com/ec2/instance-types/?trk=36c6da98-7b20-48fa-8225-4784bced9843&sc_channel=ps&sc_campaign=acquisition&sc_medium=ACQ-P|PS-GO|Brand|Desktop|SU|Compute|EC2|US|EN|Text&s_kwcid=AL!4422!3!536392622533!e!!g!!ec2%20instance%20types&ef_id=CjwKCAjwiuuRBhBvEiwAFXKaNNRXM5FrnFg5H8RGQ4bQKuUuK1rYWmU2iH-5H3VZPqEheB-pEm-GNBoCdD0QAvD_BwE:G:s&s_kwcid=AL!4422!3!536392622533!e!!g!!ec2%20instance%20types#General_Purpose) インスタンスは、あらゆる特性においてバランスが取れており、さまざまなワークロードをサポートします。 1. コンピューティングインスタンスは Linux で実行されており、ネットワークインターフェイスカードのネットワークスループットによって制限されていますか。 1. 「 [パフォーマンスに関する質問 5、ベストプラクティス 2: 使用可能なネットワーク機能を評価する](https://docs.aws.amazon.com/wellarchitected/latest/performance-efficiency-pillar/network-architecture-selection.html) 」を確認し、パフォーマンスのニーズに合った適切なインスタンスのタイプおよびファミリーを特定します。 1. ワークロードは、特定のアベイラビリティゾーンで 1 年間コミットできる、一貫性のある予測可能なインスタンスを必要としますか。  1. [リザーブドインスタンス](https://aws.amazon.com/ec2/pricing/reserved-instances/) を使用すると、特定のアベイラビリティーゾーン内でキャパシティ予約が確定されます。リザーブドインスタンスは、特定のアベイラビリティゾーンでコンピューティング性能が必要な場合に最適です。  1. ワークロードには、専用ハードウェアを必要とするライセンスがありますか。 1. [専有ホスト](https://aws.amazon.com/ec2/dedicated-hosts/) は、既存のソフトウェアライセンスをサポートし、コンプライアンス要件への準拠を支援します。 1. コンピューティングソリューションはバーストし、同期処理が必要ですか。 1. [オンデマンドインスタンス](https://aws.amazon.com/ec2/pricing/on-demand/) では、1 時間または 1 秒単位でコンピューティング性能を利用でき、長期的な契約は必要ありません。このインスタンスは、パフォーマンスのベースラインを超えるようなバースト的なニーズに適しています。 1. コンピューティングソリューションは、ステートレスでフォールト トレラント、かつ非同期ですか。  1. [スポットインスタンス](https://aws.amazon.com/ec2/spot/) では、未使用のインスタンスキャパシティをステートレスでフォールトトレラントなワークロードに活用できます。  1. コンテナを [Fargate](https://aws.amazon.com/fargate/)で実行していますか。 1. タスクのパフォーマンスはメモリまたは CPU によって制限されていますか。 1. メモリまたは CPU を調整するために、 [タスクサイズ](https://docs.aws.amazon.com/AmazonECS/latest/bestpracticesguide/capacity-tasksize.html) を使用します。 1. トラフィックパターンのバーストによって、パフォーマンスが影響を受けていますか。 1. トラフィックパターンに合わせるために、 [Auto Scaling](https://docs.aws.amazon.com/AmazonECS/latest/bestpracticesguide/capacity-autoscaling.html) の設定を使用します。 1. コンピューティングソリューションは [Lambda](https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-features.html)上にありますか。 1. 少なくとも 4 週間分のメトリクスがあり、トラフィックパターンとメトリクスが今後もほぼ同じになると予測できますか。 1. 予想されるコストと使用状況に合わせたカスタムの予算を設定するには、 [Compute Optimizer](https://aws.amazon.com/compute-optimizer/) を使用して、コンピューティング特性に最適なコンピューティング構成に関する機械学習の推奨事項を取得します。 1. AWS Compute Optimizer を使用するのに十分なメトリクスがありますか。 1. Compute Optimizer を使用するのに必要なメトリクスがない場合は、 [AWS Lambda Power Tuning](https://docs.aws.amazon.com/lambda/latest/operatorguide/profile-functions.html) を使用して最適な設定を選択できます。 1. 関数のパフォーマンスはメモリまたは CPU によって制限されていますか。 1. パフォーマンスニーズのメトリクスを満たすように [Lambda メモリ](https://docs.aws.amazon.com/lambda/latest/dg/configuration-function-common.html#configuration-memory-console) を設定します。 1. 関数が実行時にタイムアウトしていますか。 1. タイムアウトの設定 [を変更します。](https://docs.aws.amazon.com/lambda/latest/dg/configuration-function-common.html) 1. 関数のパフォーマンスはアクティビティと並行処理のバーストによって制限されていますか。  1. パフォーマンス要件を満たすように [並行処理の設定](https://docs.aws.amazon.com/lambda/latest/dg/configuration-concurrency.html) を行います。 1. 関数が非同期で実行され、再試行で失敗していますか。 1. イベントの最大経過時間と最大再試行回数を [非同期設定](https://docs.aws.amazon.com/lambda/latest/dg/invocation-async.html) で指定します。 ## 実装計画に必要な工数レベル:  このベストプラクティスを確立するには、現在のコンピューティングの特性とメトリクスを把握している必要があります。こうしたメトリクスを収集し、ベースラインを確立した上で、これらのメトリクスを使用して最適なコンピューティングオプションを特定するには、 *低* ～ *中* 程度の工数が必要です。これは、負荷テストや実験によって検証するのが最善です。 ## リソース **関連ドキュメント:** + [Cloud Compute with AWS (AWS を使用したクラウドコンピューティング) ](https://aws.amazon.com/products/compute/?ref=wellarchitected) + [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/) + [EC2 インスタンスタイプ ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html?ref=wellarchitected) + [EC2 インスタンスのプロセッサのステート制御 ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/processor_state_control.html?ref=wellarchitected) + [EKS コンテナ: 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 (CMP211-R2) ](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 (CMP323-R1) (AWS コンピューティングのパフォーマンスとコストを最適化する) ](https://www.youtube.com/watch?v=zt6jYJLK8sg&ref=wellarchitected) **関連サンプル:** + [Rightsizing with Compute Optimizer and Memory utilization enabled (Compute Optimizer とメモリ使用率を有効にした場合のライトサイジング)](https://www.wellarchitectedlabs.com/cost/200_labs/200_aws_resource_optimization/5_ec2_computer_opt/) + [AWS Compute Optimizer Demo code (AWS Compute Optimizer デモコード)](https://github.com/awslabs/ec2-spot-labs/tree/master/aws-compute-optimizer) # PERF02-BP03 コンピューティング関連のメトリクスを収集する コンピューティングリソースのパフォーマンスを理解するには、各種システムの実際の使用率を記録して追跡する必要があります。このデータは、リソース要件についてより正確な判断を行うために使用できます。  ワークロードでは、メトリクス、ログ、イベントなどのデータが大量に生成される可能性があります。既存のストレージ、モニタリング、可観測性のサービスが、生成されたデータを管理できるかどうかを判断してください。どのメトリクスがリソースの使用率を反映し、単一のプラットフォーム全体で収集、集計、相関できるかを特定します。このメトリクスは、システム全体を容易に可視化し、パフォーマンス改善の機会と問題を迅速に特定できるよう、すべてのワークロードリソース、アプリケーション、サービスを表している必要があります。 **期待される成果:** コンピューティング関連のリソースに関係するすべてのメトリクスが、単一のプラットフォーム上で特定、収集、集約されて関連付けが行われ、コストと運用の目標をサポートするために保持が実装されます。 **一般的なアンチパターン:** + メトリクスの検索に手動ログファイルのみを使用している。  + 内部ツールにのみメトリクスを発行している。 + 一部のモニタリングソフトウェアで記録されるデフォルトのメトリクスのみを使用している。 + 問題が発生したときにだけメトリクスを確認している。 **このベストプラクティスを活用するメリット:** ワークロードのパフォーマンスをモニタリングするには、一定期間にわたって複数のパフォーマンスメトリクスを記録する必要があります。これらのメトリクスにより、パフォーマンスの異常を検出できます。また、ビジネスメトリクスに照らし合わせてパフォーマンスを測定することで、ワークロードのニーズを満たしているかどうかを確認できます。 **このベストプラクティスを活用しない場合のリスクレベル:** 高 ## 実装のガイダンス コンピューティング関連のメトリクスを特定、収集、集計し、関連付けを行います。Amazon CloudWatch などのサービスを使用すると、実装をより迅速かつ簡単に維持できます。デフォルトで記録されるメトリクスに加えて、ワークロード内のシステムレベルのメトリクスを追加で特定し、追跡します。CPU 使用率、メモリ、ディスク I/O、ネットワークのインバウンドおよびアウトバウンドメトリクスなどのデータを記録し、使用状況レベルやボトルネックを把握します。このデータは、ワークロードのパフォーマンスやコンピューティングソリューションの使用状況を理解するために不可欠です。これらのメトリクスをデータ駆動型のアプローチの一部として使用し、ワークロードのリソースを積極的に調整および最適化します。  **実装手順:** 1. 追跡するのが重要なコンピューティングソリューションメトリクスはどれですか。 1. [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. [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. [EC2 のメモリとディスクのメトリクス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/mon-scripts.html) 1. 現在、承認済みのロギングおよび監視ソリューションを使用していますか。 1. [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) 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. [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. [AWS Systems Manager オートメーション](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](https://www.youtube.com/watch?v=5T4stR-HFas&ref=wellarchitected) + [モニタリング計画を立てる](https://www.youtube.com/watch?v=OMmiGETJpfU&ref=wellarchitected) **関連サンプル:** + [Level 100: Monitoring with CloudWatch Dashboards](https://wellarchitectedlabs.com/performance-efficiency/100_labs/100_monitoring_with_cloudwatch_dashboards/) + [Level 100: Monitoring Windows EC2 instance with CloudWatch Dashboards](https://wellarchitectedlabs.com/performance-efficiency/100_labs/100_monitoring_windows_ec2_cloudwatch/) + [Level 100: Monitoring an Amazon Linux EC2 instance with CloudWatch Dashboards](https://wellarchitectedlabs.com/performance-efficiency/100_labs/100_monitoring_linux_ec2_cloudwatch/) # PERF02-BP04 適切なサイジングによって必要な設定を決定する ワークロードのさまざまなパフォーマンス特性と、それらの特性に対するメモリ、ネットワーク、I/O、CPU 使用率との関連を分析します。このデータは、ワークロードのプロファイルに最適なリソースを選択するために使用します。例えば、データベースなどのメモリ集約型のワークロードの場合、コアあたりのメモリ比率が高いと、多くの利点が期待できます。ただし、コンピューティング集約型のワークロードでは、より多くのコア数とコア周波数が必要になる一方、コアあたりのメモリ量はそれほど必要ない場合があります。 **一般的なアンチパターン:** + すべてのワークロードに対して、利用できるすべてのパフォーマンス特性の最大の値を持つインスタンスを選択する。 + 管理しやすいように、すべてのインスタンスタイプを 1 つのタイプに標準化する。 + 特定のワークロードの実際の要件を検証せずに、標準的な合成ベンチマークに照らして最適化している。 + 新しいサービスを再評価して統合せずに、同じインフラストラクチャを長期間維持している。 **このベストプラクティスを活用するメリット:** ワークロードの要件を把握していれば、利用できるコンピューティングサービスとこのようなニーズを照らし合わせて、迅速に実験を行い、ワークロードのニーズを最も効率的に満たすソリューションを判断できます。これにより、不要なリソースに過大なコストを割くことなく、最適なパフォーマンスを実現できます。 **このベストプラクティスを確立しない場合のリスクレベル:** 中 ## 実装のガイダンス 適切なサイジングを行い、ワークロードの設定を変更します。パフォーマンス、全体的な効率性、費用対効果を最適化するには、まずワークロードに必要なリソースを特定します。データベースなどのメモリ集約型のワークロードには、R ファミリーのインスタンスなどのメモリ最適化インスタンスを選択します。より高いコンピューティング能力を必要とするワークロードの場合は、C ファミリーのインスタンスを選択するか、コア数またはコア周波数が高いインスタンスを選択します。標準的な合成ベンチマークとの比較によってではなく、ワークロードのニーズに基づいて I/O パフォーマンスを選択します。より高い I/O パフォーマンスを得るには、I ファミリーのインスタンスを選択するか、[I/O が最適化された Amazon EBS ボリューム](https://aws.amazon.com/premiumsupport/knowledge-center/optimize-ebs-provisioned-iops/)を選択するか、[インスタンスストア](https://aws.amazon.com/premiumsupport/knowledge-center/instance-store-vs-ebs/)を持つインスタンスを選択します。特定のインスタンスタイプの詳細については、「[Amazon EC2 インスタンスタイプ](https://aws.amazon.com/ec2/instance-types/)」を参照してください。 適切なサイジングを行うことで、不要なワークロードに対して余分な料金を支払うことなく、可能な限り最高レベルのパフォーマンスを達成できます。 **実装手順** + ワークロードの特性を把握するか、ワークロードのリソース要件を分析します。 + ワークロードを個別に評価します。AWS クラウド を使用すると、妥協することなく、各ワークロードについて個別に適切なサイジングで調整できる柔軟性と俊敏性が得られます。 + テスト環境を作成して、ワークロードに最適なコンピューティングサービスを探します。 + 継続的に新しいコンピューティングサービスを再評価して、ワークロードのニーズと照らし合わせます。 + 費用対効果の向上のために、新しいサービスを定期的に確認します。 + 定期的に Well-Architected Framework レビューを実施します。 ## リソース **関連するベストプラクティス:** + [PERF02-BP03 コンピューティング関連のメトリクスを収集する](perf_select_compute_collect_metrics.md) + [PERF02-BP06 メトリクスに基づいてコンピューティングニーズを再評価する](perf_select_compute_use_metrics.md) **関連するドキュメント:** + [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/)  + [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 foundations (CMP211-R2)](https://www.youtube.com/watch?v=kMMybKqC2Y0) (Amazon EC2 の基礎 (CMP211-R2)) + [Better, faster, cheaper compute: Cost-optimizing Amazon EC2 (CMP202-R1)](https://www.youtube.com/watch?v=_dvh4P2FVbw) (より良く、より速く、より安価なコンピューティング: Amazon EC2 でのコストの最適化 (CMP202-R1)) + [Deliver high performance ML inference with AWS Inferentia (CMP324-R1)](https://www.youtube.com/watch?v=17r1EapAxpk) (AWS Inferentia を使用して高パフォーマンスの機械学習推論を実現する (CMP324-R1)) + [Optimize performance and cost for your AWS compute (CMP323-R1)](https://www.youtube.com/watch?v=zt6jYJLK8sg) (AWS コンピューティングのパフォーマンスとコストを最適化する) + [Powering next-gen Amazon EC2: Deep dive into the Nitro system](https://www.youtube.com/watch?v=rUY-00yFlE4) (次世代 EC2 の強化: Nitro System の詳細) + [スタートアップ企業向けコンピューティングオプションの選択方法](https://aws.amazon.com/startups/start-building/how-to-choose-compute-option/) + [Optimize performance and cost for your AWS compute (CMP323-R1)](https://www.youtube.com/watch?v=zt6jYJLK8sg) (AWS コンピューティングのパフォーマンスとコストを最適化する) **関連する例:** + [Rightsizing with Compute Optimizer and Memory utilization enabled](https://www.wellarchitectedlabs.com/cost/200_labs/200_aws_resource_optimization/5_ec2_computer_opt/) (Compute Optimizer を使用したサイズ適正化とメモリ使用率の有効化) + [AWS Compute Optimizer Demo code](https://github.com/awslabs/ec2-spot-labs/tree/master/aws-compute-optimizer) (AWS Compute Optimizer デモコード) # PERF02-BP05 利用可能な伸縮性のあるリソースを使用する クラウドは、需要の変化に対応するためのさまざまなメカニズムを通じて、リソースを動的に拡張または縮小する柔軟性を提供します。この伸縮性をコンピューティング関連のメトリクスと組み合わせることによって、ワークロードは変更に自動的に対応して、必要なリソースのみを使用することができます。 **一般的なアンチパターン:** + 予想されるスパイクに対応するためにオーバープロビジョニングする。 + アラームに対応するために手動でキャパシティーを増やす。 + プロビジョニングにかかる時間を考慮に入れずにキャパシティーを増やす。 + スケーリングイベントの後、スケールダウンして元に戻すのではなく、キャパシティーを増加させたままにする。 + ワークロードの実際の要件を直接反映していないメトリクスをモニタリングする。 **このベストプラクティスを活用するメリット:** 需要は、一定である場合も、変動する場合も、あるパターンに従う場合も、スパイクが発生しやすい場合もあります。需要と供給をマッチングすることで、ワークロードのコストを最低限に抑えることができます。ワークロードの伸縮性をモニタリング、テスト、設定することで、需要の変化に応じてパフォーマンス最適化、コスト低減、信頼性の向上を実現できます。これに対して手動で対応するアプローチも可能であるとはいえ、大規模な場合は非実用的です。自動化したメトリクスベースのアプローチを採用することで、どの時点でもリソースが確実に需要を満たすようにすることができます。 **このベストプラクティスを確立しない場合のリスクレベル:** 中 ## 実装のガイダンス リソースの供給が、ワークロードが求めるリソースの需要とマッチすることを目標に、伸縮性を活用するために、メトリクスベースのオートメーションを使用する必要があります。例えば、[リソースのモニタリングに Amazon CloudWatch メトリクス](https://aws.amazon.com/startups/start-building/how-to-monitor-resources/)を使用したり、Auto Scaling グループには Amazon CloudWatch メトリクスを使用したりすることができます。 コンピューティング関連のメトリクスと組み合わせることによって、ワークロードは自動的に変化に対応し、最適な一連のリソースを利用して目標を達成できるようになります。プロビジョニングにかかる時間と予想されるリソース障害を考慮に入れて計画を策定する必要があります。 インスタンス、コンテナ、関数には、伸縮性のためのメカニズムがあり、サービスの一部として、[Application Auto Scaling](https://aws.amazon.com/autoscaling/) で、または [Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html) と組み合わせて提供されます。アーキテクチャの伸縮性を活用して、広範囲の規模の使用におけるパフォーマンス要件を満たすために十分なキャパシティーがあることを確認します。 デプロイされているワークロードのタイプに対して、伸縮自在なリソースのスケールアップまたはスケールダウンのメトリクスが検証されていることを確認します。例えば、動画トランスコーディングアプリケーションをデプロイする場合、CPU 使用率は 100% となることが想定されるため、主要なメトリクスにするべきではありません。代替手段として、インスタンスタイプのスケーリングを待機しているトランスコーディングジョブのキューの深さに対して測定することができます。 ワークロードのデプロイは、スケールアップとスケールダウンの両方のイベントに対処できる必要があります。ワークロードコンポーネントを安全にスケールダウンすることは、需要があるときにリソースをスケールアップするのと同じくらい重要です。 スケーリングイベントのテストシナリオを作成して、ワークロードが期待どおりに動作することを確認します。 **実装手順** + 履歴データを活用して、経時的なワークロードのリソース需要を分析します。以下のような具体的な事項を検討します。 + ワークロードは安定しており、経時的に既知の割合で増加しているか。 + ワークロードは、季節的な繰り返しのパターンで増減しているか。 + ワークロードはスパイクが発生しやすいか。 スパイクは予想したり予測したりできるか。 + モニタリングサービスと履歴データを可能な限り活用します。 + リソースにタグ付けすると、モニタリングに役立ちます。タグを使用する場合は、「[Tagging Best Practices](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html) (タグ付けのベストプラクティス)」を参照してください。また、[タグを使用すると、リソースの管理、特定、整理に役立ちます](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html)。 + AWS では、さまざまなアプローチで需要と供給を一致させることができます。コスト最適化の柱のベストプラクティス ([COST09-BP01～COST09-03](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/manage-demand-and-supply-resources.html)) では、以下のアプローチを採用してコストを低減する方法について説明しています。 + [COST09-BP01 ワークロードの需要に関する分析を実行する](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/cost_manage_demand_resources_cost_analysis.html) + [COST09-BP01 需要を管理するためのバッファまたはスロットルを実装する](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/cost_manage_demand_resources_buffer_throttle.html) + [COST09-BP03 リソースを動的に供給する](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/cost_manage_demand_resources_dynamic.html) + スケールダウンイベントのテストシナリオを作成して、ワークロードが期待どおりに動作することを確認します。 + 本稼働用以外のほとんどのインスタンスは、使用されていないときに停止するべきです。 + Amazon Elastic Block Store (Amazon EBS) を使用する場合のストレージのニーズについては、[ボリュームベースの伸縮性](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-modify-volume.html)を活用します。 + [Amazon Elastic Compute Cloud (Amazon EC2)](https://aws.amazon.com/ec2/) については、[Auto Scaling グループ](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-groups.html)の使用を検討してください。これにより、需要のスパイク発生時にコンピューティングインスタンスの数を自動的に増やし、需要の減少時にキャパシティーを減らして、パフォーマンスとコストを最適化できます。 ## リソース **関連するベストプラクティス:** + [PERF02-BP03 コンピューティング関連のメトリクスを収集する](perf_select_compute_collect_metrics.md) + [PERF02-BP04 適切なサイジングによって必要な設定を決定する](perf_select_compute_right_sizing.md) + [PERF02-BP06 メトリクスに基づいてコンピューティングニーズを再評価する](perf_select_compute_use_metrics.md) **関連するドキュメント:** + [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 foundations (CMP211-R2)](https://www.youtube.com/watch?v=kMMybKqC2Y0) (Amazon EC2 の基礎 (CMP211-R2)) + [Better, faster, cheaper compute: Cost-optimizing Amazon EC2 (CMP202-R1)](https://www.youtube.com/watch?v=_dvh4P2FVbw) (より良く、より速く、より安価なコンピューティング: Amazon EC2 でのコストの最適化 (CMP202-R1)) + [Deliver high performance ML inference with AWS Inferentia (CMP324-R1)](https://www.youtube.com/watch?v=17r1EapAxpk) (AWS Inferentia を使用して高パフォーマンスの機械学習推論を実現する (CMP324-R1)) + [Optimize performance and cost for your AWS compute (CMP323-R1)](https://www.youtube.com/watch?v=zt6jYJLK8sg) (AWS コンピューティングのパフォーマンスとコストを最適化する) + [Powering next-gen Amazon EC2: Deep dive into the Nitro system](https://www.youtube.com/watch?v=rUY-00yFlE4) (次世代 EC2 の強化: Nitro System の詳細) **関連する例:** + [Amazon EC2 Auto Scaling グループの例](https://github.com/aws-samples/amazon-ec2-auto-scaling-group-examples) + [Amazon EFS チュートリアル](https://github.com/aws-samples/amazon-efs-tutorial) # PERF02-BP06 メトリクスに基づいてコンピューティングニーズを再評価する データ駆動型のアプローチを採用し、ワークロードのコンピューティングリソースを再評価して、最適化します。 **期待される成果:** システムレベルのメトリクスを使用して、経時的なワークロードの動作と要件を積極的にモニタリングします。収集したデータに基づいて、使用できるリソースと比較してワークロードの需要を評価し、ワークロードのプロファイルに最適なコンピューティング環境となるように変更を加えます。例えば、時間がたつにつれて、当初指定した以上にワークロードがメモリ集約型であることが判明する場合があります。この場合、別のインスタンスファミリーやインスタンスサイズに移行すると、パフォーマンスと効率性の両方が向上する可能性があります。 **一般的なアンチパターン:** + ワークロードについてのインサイトを得るうえで、コンピューティングのニーズを再評価せずにシステムレベルのメトリクスをモニタリングしている。 + ピーク時のワークロード要件に合わせてコンピューティングニーズを設計している。 + 代替のコンピューティングソリューションに移行する際、スケーリングやパフォーマンスの要件を満たすために既存のコンピューティングソリューションのサイズを過剰に増やしてワークロードの特性により効率的に適合させている。 **このベストプラクティスを活用するメリット:** 実際のデータと、コストおよびパフォーマンスの適切なバランスに基づいて最適化されたコンピューティングリソース。 **このベストプラクティスが確立されていない場合のリスクレベル:** 低 ## 実装のガイダンス データ駆動型アプローチを採用して、観測したワークロードの動作に基づいてコンピューティングリソースを最適化します。パフォーマンスと効率性を最大限に高めるには、時間の経過に伴ってワークロードから収集したデータを使用してリソースを調整および最適化します。ワークロードの現在のリソース使用状況におけるトレンドを調べて、ワークロードのニーズにより適合させるために変更を加えることができる場所を特定します。リソースが過剰にコミットされると、システムのパフォーマンスは低下します。リソースが適切に使用されないと、システムの運用効率は低下し、コストが増大します。 パフォーマンスとリソース使用率を最適化するには、統合された運用ビュー、リアルタイムの詳細なデータ、履歴参照が必要です。自動ダッシュボードを作成してこのデータを視覚化し、運用と利用に関するインサイトを得ることができます。 **実装手順** 1. コンピューティング関連の経時的メトリクスを収集します。 1. 選択したコンピューティングソリューションで使用できるリソースとワークロードのメトリクスを比較します。 1. 既存のソリューションのサイズを適正化するか、代替のコンピューティングソリューションを評価して、設定で必要となる変更を決定します。 ## リソース **関連するベストプラクティス:** + [PERF02-BP01 使用可能なコンピューティングオプションを評価する](perf_select_compute_evaluate_options.md) + [PERF02-BP02 利用可能なコンピューティング設定オプションについて理解する](perf_select_compute_config_options.md) + [PERF02-BP03 コンピューティング関連のメトリクスを収集する](perf_select_compute_collect_metrics.md) + [PERF02-BP04 適切なサイジングによって必要な設定を決定する](perf_select_compute_right_sizing.md) **関連するドキュメント:** + [AWS を使用したクラウドコンピューティング](https://aws.amazon.com/products/compute/?ref=wellarchitected) + [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/) + [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) + [AWS Lambda 関数を使用するためのベストプラクティス](https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html#function-configuration) **関連動画:** + [Amazon EC2 foundations (CMP211-R2)](https://www.youtube.com/watch?v=kMMybKqC2Y0) (Amazon EC2 の基礎 (CMP211-R2)) + [Better, faster, cheaper compute: Cost-optimizing Amazon EC2 (CMP202-R1)](https://www.youtube.com/watch?v=_dvh4P2FVbw) (より良く、より速く、より安価なコンピューティング: Amazon EC2 でのコストの最適化 (CMP202-R1)) + [Deliver high performance ML inference with AWS Inferentia (CMP324-R1)](https://www.youtube.com/watch?v=17r1EapAxpk) (AWS Inferentia を使用して高パフォーマンスの機械学習推論を実現する (CMP324-R1)) + [Optimize performance and cost for your AWS compute (CMP323-R1)](https://www.youtube.com/watch?v=zt6jYJLK8sg) (AWS コンピューティングのパフォーマンスとコストを最適化する) + [Powering next-gen Amazon EC2: Deep dive into the Nitro system](https://www.youtube.com/watch?v=rUY-00yFlE4) (次世代 EC2 の強化: Nitro System の詳細) + [ Selecting and optimizing Amazon EC2 instances ](https://www.youtube.com/watch?v=Vz0HZ6hlpgM)(Amazon EC2 インスタンスの選択と最適化) **関連する例:** + [Rightsizing with Compute Optimizer and Memory utilization enabled](https://www.wellarchitectedlabs.com/cost/200_labs/200_aws_resource_optimization/5_ec2_computer_opt/) (Compute Optimizer を使用したサイズ適正化とメモリ使用率の有効化) + [AWS Compute Optimizer Demo code](https://github.com/awslabs/ec2-spot-labs/tree/master/aws-compute-optimizer) (AWS Compute Optimizer デモコード) # PERF 3 ストレージソリューションはどのように選択すればよいですか? システムにとって最適なストレージソリューションは、アクセス方法 (ブロック、ファイル、オブジェクト)、アクセスパターン (ランダム、シーケンシャル)、必要なスループットやアクセス頻度 (オンライン、オフライン、アーカイブ)、更新頻度 (WORM、動的)、可用性と耐久性に関する制約によって異なります。優れた設計のシステムでは、複数のストレージソリューションを使用し、さまざまな機能を有効にしてパフォーマンスとリソースの使用効率を高めています。 **Topics** + [PERF03-BP01 ストレージ特性と要件を理解する](perf_right_storage_solution_understand_char.md) + [PERF03-BP02 利用可能な設定オプションを評価する](perf_right_storage_solution_evaluated_options.md) + [PERF03-BP03 アクセスパターンとメトリクスに基づいて意思決定を行う](perf_right_storage_solution_optimize_patterns.md) # PERF03-BP01 ストレージ特性と要件を理解する ワークロードのストレージニーズを特定および文書化し、各ロケーションのストレージ特性を定義します。ストレージ特性の例としては、共有可能なアクセス、ファイルサイズ、成長率、スループット、IOPS、レイテンシー、アクセスパターン、およびデータ永続性などがあります。これらの特性を利用して、ブロック、ファイル、オブジェクト、インスタンスの各ストレージサービスが、ストレージのニーズに対して最も効率的なソリューションであるかどうかを評価します。 **期待される成果:** ストレージ要件ごとにストレージ要件を特定および文書化し、利用可能なストレージソリューションを評価します。主なストレージ特性に基づいて、チームは、選択したストレージサービスがワークロードのパフォーマンスのためにどのように役立つかを理解します。主な基準には、データアクセスパターン、成長率、スケーリングのニーズ、レイテンシー要件があります。 **一般的なアンチパターン:** + すべてのワークロードに対して、Amazon Elastic Block Store (Amazon EBS) などの 1 つのストレージタイプのみを使用する。 + すべてのワークロードのストレージアクセスパフォーマンス要件が類似していることを前提としている。 **このベストプラクティスを活用するメリット:** 特定された必要な特性に基づいてストレージソリューションを選択することは、ワークロードのパフォーマンスを向上させ、コストを削減し、ワークロードを維持するための運用にかかる労力を軽減するのに役立ちます。ストレージサービスのソリューション、設定、およびロケーションは、ワークロードのパフォーマンスにメリットをもたらします。 **このベストプラクティスを活用しない場合のリスクレベル:** 高 ## 実装のガイダンス ワークロードの最も重要なストレージパフォーマンスメトリクスを特定し、ベンチマークまたは負荷テストを使用して、データ駆動型アプローチの一環として改善を実施します。このデータを使用してストレージソリューションの制約が発生している場所を特定し、そのソリューションを改善する設定オプションを調べます。予想されるワークロードの成長率を判定し、この成長率に対応するストレージソリューションを選択します。AWS ストレージサービスを調査して、さまざまなワークロードのニーズに適したストレージソリューションを特定します。AWS でストレージソリューションをプロビジョニングすることにより、ストレージサービスをテストして、ワークロードのニーズに適しているかどうかを判断する機会が増えます。 | AWS のサービス | 主な特徴 | 一般的なユースケース | | --- | --- | --- | | Amazon S3 | 99.999999999% の耐久性、拡大無制限、どこからでもアクセス可能、アクセスと回復力に基づいた複数のコストモデル | クラウドネイティブアプリケーションデータ、データのアーカイブおよびバックアップ、分析、データレイク、静的ウェブサイトホスティング、IoT データ | | Amazon Glacier | 数秒から数時間のレイテンシー、拡大無制限、最安値のコスト、長期ストレージ | データアーカイブ、メディアアーカイブ、長期バックアップ保持 | | Amazon EBS | ストレージサイズには管理とモニタリングが必要、低レイテンシー、永続的ストレージ、99.8%～99.9% の耐久性、ほとんどのボリュームタイプは 1 つの EC2 インスタンスのみからアクセス可能 | COTS アプリケーション、I/O 集約型アプリケーション、リレーショナルデータベースおよび NoSQL データベース、バックアップとリカバリ | | EC2 インスタンスストア | 事前定義されたストレージサイズ、最も低いレイテンシー、永続化されない、1 つの EC2 インスタンスのみからアクセス可能 | COTS アプリケーション、I/O インテンシブアプリケーション、インメモリデータストア | | Amazon EFS | 99.999999999% の耐久性、拡大無制限、複数のコンピューティングサービスによるアクセス可能 | モダナイズされたアプリケーションが複数のコンピューティングサービスでファイルを共有、コンテンツ管理システムのスケーリングのためのファイルストレージ | | Amazon FSx | 4 つのファイルシステム (NetApp、OpenZFS、Windows File Server、および Amazon FSx for Lustre) をサポート、ファイルシステムごとに異なるストレージが利用可能、複数のコンピューティングサービスからのアクセス可能 | クラウドネイティブなワークロード、プライベートクラウドでのバースト、特定のファイルシステムを必要とする移行ワークロード、VMC、ERP システム、オンプレミスファイルストレージおよびバックアップ | | Snow ファミリー | ポータブルデバイス、256 ビットの暗号化、NFS エンドポイント、オンボードコンピューティング、TB 規模のストレージ | クラウド、ストレージ、および極端なオンプレミス条件下のコンピューティングへのデータの移行、ディザスタリカバリ、リモートデータ収集 | | AWS Storage Gateway | クラウド対応ストレージに低レイテンシーなオンプレミスアクセスを提供、フルマネージド型オンプレミスキャッシュ | オンプレミスデータのクラウド移行、オンプレミスソースからクラウドデータレイクへの入力、モダナイズされたファイル共有 | **実装手順:** 1. ベンチマークまたはロードテストを使用して、ストレージニーズの主な特性を収集します。主な特徴は次のとおりです。 1. 共有可能 (どのコンポーネントがこのストレージにアクセスするか) 1. 成長率 1. スループット 1. レイテンシー 1. I/O サイズ 1. 耐久性 1. アクセスパターン (読み取りまたは書き取り、頻度、急増、または一貫性) 1. ストレージ特性をサポートするストレージのタイプを特定します。 1. [Amazon S3](https://aws.amazon.com/s3/) には、無制限のスケーラビリティ、高可用性、およびアクセシビリティに関して複数のオプションがあります。Amazon S3 内外のオブジェクトの転送やアクセスには、 [Transfer Acceleration ](https://aws.amazon.com/s3/transfer-acceleration/) または [ Access Points ](https://aws.amazon.com/s3/features/access-points/) などのサービスを使用して、ロケーション、セキュリティニーズ、アクセスパターンをサポートします。この [Amazon S3 パフォーマンスガイドラインを使用して](https://docs.aws.amazon.com/AmazonS3/latest/userguide/optimizing-performance-guidelines.html) ワークロードのパフォーマンスに関するニーズを満たすために、Amazon S3 設定を最適化します。 1. [Amazon Glacier](https://aws.amazon.com/s3/storage-classes/glacier/) はデータアーカイブのために構築された Amazon S3 のストレージクラスです。ミリ秒単位のアクセスから 5～12 時間単位のアクセスまで、コストやセキュリティの異なる 3 つのアーカイブソリューションから選択できます。Amazon Glacier は、ビジネス要件とデータ特性をサポートするデータライフサイクルを実装することで、パフォーマンス要件を満たすことができます。 1. [Amazon Elastic Block Store (Amazon EBS)](https://aws.amazon.com/ebs/) は Amazon Elastic Compute Cloud (Amazon EC2) 向けに設計された、ハイパフォーマンスなブロックストレージサービスです。異なる特性を持つ [SSD または HDD ベースの](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html) ソリューションから選択できます。これらは [IOPS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/provisioned-iops.html) または [スループットを優先します](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/hdd-vols.html)。EBS ボリュームは、高性能なワークロード、ファイルシステム、データベースのプライマリストレージ、またはアタッチされたストレージシステムのみにアクセスできるアプリケーションに適しています。 1. [Amazon EC2 インスタンスストア](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html) は、Amazon EC2 インスタンスにアタッチするという点で Amazon EBS と似ています。ただし、インスタンスストアは、バッファやキャッシュなどの一時的なコンテンツとして使用するのが理想的な、一時的なストレージに過ぎません。インスタンスストアをデタッチすることはできず、インスタンスがシャットダウンするとすべてのデータが失われます。インスタンスストアは、データの永続化を必要としない、高い I/O パフォーマンスと低レイテンシーのユースケースに使用することができます。 1. [Amazon Elastic File System (Amazon EFS)](https://aws.amazon.com/efs/) は、さまざまなタイプのコンピューティングソリューションからアクセスできる、マウント可能なファイルシステムです。Amazon EFS は、ストレージを自動的に拡大/縮小し、パフォーマンスに最適化されているため、一貫した低レイテンシーを実現します。EFS には [2 つのパフォーマンス設定モード](https://docs.aws.amazon.com/efs/latest/ug/performance.html)があります。汎用と最大 I/O です。汎用は、読み出しレイテンシがミリ秒未満、書き込みレイテンシは 1 桁ミリ秒です。最大 I/O の機能により、共有ファイルシステムを必要とする何千ものコンピューティングインスタンスをサポートできます。Amazon EFS は以下をサポートしています。 [2 つのスループットモード](https://docs.aws.amazon.com/efs/latest/ug/managing-throughput.html): バーストとプロビジョンド急増するアクセスパターンを経験するワークロードには、バーストスループットモードが役立ちます。一方、常に高いパフォーマンスを発揮するワークロードには、プロビジョンドスループットモードが適しています。 1. [Amazon FSx](https://aws.amazon.com/fsx/) は最新の AWS コンピューティングソリューションをベースに構築されており、一般的に使用されている 4 つのファイルシステム (NetApp ONTAP、OpenZFS、Windows File Server、Lustre) をサポートしています。Amazon FSx [ レイテンシー、スループット、および IOPS は](https://aws.amazon.com/fsx/when-to-choose-fsx/) ファイルシステムごとに異なるため、ワークロードのニーズに合わせて適切なファイルシステムを選択する際に考慮する必要があります。 1. [AWS Snow Family](https://aws.amazon.com/snow/) は、オンラインおよびオフラインでのクラウドへのデータ移行、オンプレミスでのデータ保存やコンピューティングをサポートするストレージおよびコンピューティングデバイスです。AWS Snow デバイスは大量のオンプレミスデータの収集、データの処理、およびそれらのデータのクラウド移行をサポートします。ファイルの数、ファイルサイズ、および圧縮に関する [文書化されたパフォーマンスのベストプラクティス](https://docs.aws.amazon.com/snowball/latest/developer-guide/performance.html) があります。 1. [AWS Storage Gateway](https://aws.amazon.com/storagegateway/) は、オンプレミスアプリケーションに、クラウドベースのストレージへのアクセスを提供します。AWS Storage Gateway は、Amazon S3、Amazon Glacier、Amazon FSx、および Amazon EBS を含む、さまざまなクラウドストレージサービスをサポートしています。また、iSCSI、SMB、および NFS などの多くのプロトコルをサポートしています。アクセス頻度の高いデータをオンプレミスにキャッシュし、変更されたデータと圧縮されたデータのみを AWS に送信することで、低レイテンシーのパフォーマンスを実現します。 1. 新しいストレージソリューションで実験を行い、最適な設定を確認したら、移行を計画し、パフォーマンスメトリクスを検証します。これは継続的なプロセスであり、主な特性の変更、または利用可能なサービスやオプションに変更があった場合に再評価される必要があります。 **実装計画に必要な工数レベル: **ワークロードが 1 つのストレージソリューションから別のものに移行する場合は *中* 程度の工数が必要になる可能性があります。   ## リソース **関連ドキュメント:** + [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 FSx for NetApp ONTAP performance](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/performance.html) + [Amazon FSx for OpenZFS performance](https://docs.aws.amazon.com/fsx/latest/OpenZFSGuide/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 Snow Family](https://aws.amazon.com/snow/#Feature_comparison) + [EBS I/O の特性](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ebs-io-characteristics.html) **関連動画:** + [Deep dive on Amazon EBS (STG303-R1)](https://www.youtube.com/watch?v=wsMWANWNoqQ) + [Optimize your storage performance with Amazon S3 (STG343)](https://www.youtube.com/watch?v=54AhwfME6wI) **関連サンプル:** + [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 FSx for Lustre Container Storage Interface (CSI) ドライバー](https://github.com/kubernetes-sigs/aws-fsx-csi-driver) # PERF03-BP02 利用可能な設定オプションを評価する さまざまな特性や設定オプションとそれらがストレージにどのように関連するかを評価します。ワークロードのためのストレージ容量とパフォーマンスを最適化するために、プロビジョンド IOPS、SSD、磁気ストレージ、オブジェクトストレージ、アーカイブストレージ、またはエフェメラルストレージをどこでどのように使用するかを理解してください。 [Amazon EBS](https://aws.amazon.com/ebs) には、ワークロードに対するストレージパフォーマンスとコストを最適にできる幅広いオプションがあります。これらのオプションは、データベースおよびブートボリュームなどのトランザクションワークロード向けの SSD を基盤とするストレージ (パフォーマンスは主に IOPS に依存) と、MapReduce およびログ処理などのスループット集約型ワークロード向けの HDD を基盤とするストレージ (パフォーマンスは主に MB/秒に依存) の 2 つの主なカテゴリに分けられます。 SSD タイプのボリュームには、レイテンシーに敏感なトランザクションワークロード向けのパフォーマンスの極めて高いプロビジョンド IOPS SSD と、さまざまなトランザクションデータで使用でき、価格とパフォーマンスのバランスが取れた汎用 SSD が含まれます。 [Amazon S3 Transfer Acceleration ](https://aws.amazon.com/s3/transfer-acceleration/) を使用すると、クライアントと S3 バケットの間で、長距離にわたるファイル転送を高速で行えるようになります。Transfer Acceleration は、Amazon CloudFront のグローバルに分散したエッジロケーションを活用して、最適化されたネットワークパスでデータをルーティングします。集中的な GET リクエストがある S3 バケットのワークロードには、Amazon S3 と CloudFront を併用してください。大型のファイルをアップロードするときは、ネットワークスループットを最大化できるように、マルチパートアップロードを使用してください。 [Amazon Elastic File System (Amazon EFS)](https://aws.amazon.com/efs/) は、AWS クラウドサービスおよびオンプレミスリソースでの使用のために、シンプルでスケーラブル、かつフルマネージド型の伸縮自在な NFS ファイルシステムを提供します。Amazon EFS は、多種多様なクラウドストレージワークロードをサポートするために、汎用パフォーマンスモードと最大 I/O パフォーマンスモードの 2 つのパフォーマンスモードを提供します。また、ファイルシステム向けに選択できる、バーストスループットとプロビジョンドスループットの 2 つのスループットモードもあります。ワークロードに使用する設定を決定するには、 [Amazon EFS ユーザーガイド](https://docs.aws.amazon.com/efs/latest/ug/performance.html) を参照してください。 [Amazon FSx](https://aws.amazon.com/fsx/) には 4 つのファイルシステムがあり、エンタープライズワークロード用の [Amazon FSx for Windows File Server](https://aws.amazon.com/fsx/windows/) 、高パフォーマンスワークロード用の [Amazon FSx for Lustre](https://aws.amazon.com/fsx/lustre/) 、NetApp の ONTAP ファイルシステム用の [Amazon FSx for NetApp ONTAP](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/index.html) 、Linux ベースのファイルサーバー用の [Amazon FSx for OpenZFS](https://docs.aws.amazon.com/fsx/latest/OpenZFSGuide/what-is-fsx.html) から選ぶことができます。FSx は SSD を基盤としており、高速、予測可能、スケーラブル、かつ一貫性のあるパフォーマンスを実現するように設計されています。Amazon FSx ファイルシステムは、持続的で高速な読み取り/書き込み速度と、一貫性のある低レイテンシーデータアクセスを提供します。スループットレベルは、ワークロードのニーズに合わせて必要なものを選択することができます。 **一般的なアンチパターン:** + すべてのワークロードに対して、Amazon EBS などの 1 つのストレージタイプのみを使用する。 + すべてのストレージ層に対して実際のテストを行うことなく、すべてのワークロードにプロビジョンド IOPS を使用する。 + すべてのワークロードのストレージアクセスパフォーマンス要件が類似していることを前提としている。 **このベストプラクティスを活用するメリット:** すべてのストレージサービスオプションを評価することで、インフラストラクチャのコストとワークロードの維持に必要な労力を削減できます。これにより、新しいサービスや機能をデプロイするための市場投入までの時間を短縮できる可能性があります。 **このベストプラクティスを活用しない場合のリスクレベル:** 中 ## 実装のガイダンス ストレージ特性を特定する: ストレージソリューションを評価する場合には、必要なストレージ特性 (共有可能性、ファイルサイズ、キャッシュサイズ、レイテンシー、スループット、データの永続性など) を特定してください。その後、ニーズに最も適した AWS のサービスを見つけるために、要件と照らし合わせます。 ## リソース **関連ドキュメント:** + [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) + [EBS I/O の特性](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ebs-io-characteristics.html) **関連動画:** + [Deep dive on Amazon EBS (STG303-R1)](https://www.youtube.com/watch?v=wsMWANWNoqQ) + [Optimize your storage performance with Amazon S3 (STG343)](https://www.youtube.com/watch?v=54AhwfME6wI) **関連サンプル:** + [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) # PERF03-BP03 アクセスパターンとメトリクスに基づいて意思決定を行う ワークロードのアクセスパターンに基づいてストレージシステムを選択し、ワークロードがどのようにデータにアクセスするかを判断することによってそれらを設定します。ストレージの効率性を向上させるには、ブロックストレージではなくオブジェクトストレージを選択してください。選択したストレージオプションは、データのアクセスパターンに合わせて設定します。 データへのアクセス方法は、ストレージソリューションのパフォーマンスに影響します。アクセスパターンに最適なストレージソリューションを選択するか、パフォーマンスを最大にするためにストレージソリューションに合わせてアクセスパターンを変更することを検討してください。 RAID 0 アレイを作成することによって、単一のボリュームでプロビジョニングできるものよりも高レベルのパフォーマンスを、ファイルシステムのために実現することが可能になります。I/O パフォーマンスがフォルト トレランスよりも重要な場合は RAID 0 の使用を検討してください。例えば、データレプリケーションが既に個別にセットアップされている使用頻度が高いデータベースで使用できます。 お客様のワークロードが使用するすべてのストレージの選択肢について、ワークロードに適したストレージメトリクスを選択してください。バーストクレジットを使用するファイルシステムを利用する場合は、クレジット上限に近づいたときに通知するアラームを作成します。全体的なワークロードストレージの正常性を表示するには、ストレージダッシュボードを作成する必要があります。 Amazon EBS または Amazon FSx などの固定サイズのストレージシステムについては、使用済みのストレージの量を全体的なストレージサイズに照らしてモニタリングするようにし、可能であれば、しきい値に到達したときにストレージサイズを増加させるオートメーションを作成します。 **一般的なアンチパターン:** + 顧客からの苦情がなければ、ストレージのパフォーマンスが十分であると考えている。 + ストレージ階層を 1 つだけ使用し、すべてのワークロードがその階層に適していると考えている。 **このベストプラクティスを活用するメリット:** パフォーマンスとリソース使用率を最適化するには、統合された運用ビュー、リアルタイムの詳細なデータ、履歴参照が必要です。1 秒間隔で自動ダッシュボードとデータを作成し、データに対してメトリクスの計算を実行し、ストレージニーズに対する運用と使用状況に関する洞察を得ることができます。 **このベストプラクティスを活用しない場合のリスクレベル:** 低 ## 実装のガイダンス ストレージ使用量とアクセスパターンを最適化する: ワークロードのアクセスパターンと利用可能なストレージオプションの特性に基づいてストレージシステムを選択します。要件を満たしながら、オーバーヘッドを削減することを可能にする、最適なデータの保存場所を選択します。ストレージの特性に基づいてデータを設定および操作する際には、パフォーマンスの最適化とアクセスパターンを使用します (ボリュームのストライピング、データのパーティション化など)。 ストレージオプションに適切なメトリクスを選択する: ワークロードに適したストレージメトリクスを選択していることを確認します。各ストレージオプションには、時間の経過に伴うワークロードのパフォーマンス状況を追跡するためのさまざまなメトリクスが用意されています。ストレージバーストメトリクス (Amazon EFS のバーストクレジットのモニタリングなど) に照らして測定していることを確認します。Amazon Elastic Block Store やAmazon FSx など、固定サイズのストレージシステムの場合は、使用したストレージの量と全体的なストレージサイズをモニタリングしていることを確認します。可能な場合はオートメーションを作成し、しきい値に達したときにストレージサイズを増やします。 メトリクスをモニタリングする: Amazon CloudWatch では、アーキテクチャ内のリソース全体のメトリクスを収集できます。また、カスタムメトリクスを収集および発行して、ビジネスメトリクスまたは導出メトリクスを表面化することも可能です。CloudWatch またはサードパーティーのソリューションを使用して、しきい値を超過したことを示すアラームを設定します。 ## リソース **関連ドキュメント:** + [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/) + [EBS I/O の特性](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ebs-io-characteristics.html) + [Monitoring and understanding Amazon EBS performance using Amazon CloudWatch](https://aws.amazon.com/blogs/storage/valuable-tips-for-monitoring-and-understanding-amazon-ebs-performance-using-amazon-cloudwatch/) **関連動画:** + [Deep dive on Amazon EBS (STG303-R1)](https://www.youtube.com/watch?v=wsMWANWNoqQ) + [Optimize your storage performance with Amazon S3 (STG343)](https://www.youtube.com/watch?v=54AhwfME6wI) **関連サンプル:** + [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) # PERF 4 データベースソリューションはどのように選択すればよいですか? システムにとって最適なデータベースソリューションは、可用性、整合性、分断耐性、レイテンシー、耐久性、スケーラビリティ、クエリ機能などの要件に応じて異なります。多くのシステムでは、各種サブシステムに異なるデータベースソリューションを使用しているため、パフォーマンスを向上させるために活用する機能も異なります。システムに対して適切でないデータベースソリューションや機能を選択すると、パフォーマンス効率が低下する場合があります。 **Topics** + [PERF04-BP01 データの特性を理解する](perf_right_database_solution_understand_char.md) + [PERF04-BP02 使用可能なオプションを評価する](perf_right_database_solution_evaluate_options.md) + [PERF04-BP03 データベースのパフォーマンスメトリクスを収集して記録する](perf_right_database_solution_collect_metrics.md) + [PERF04-BP04 アクセスパターンに基づいてデータストレージを選択する](perf_right_database_solution_access_patterns.md) + [PERF04-BP05 アクセスパターンとメトリクスに基づいてデータストレージを最適化する](perf_right_database_solution_optimize_metrics.md) # PERF04-BP01 データの特性を理解する ワークロードのデータセットの特性、アクセスパターン、要件に最適なデータ管理ソリューションを選択します。データ管理ソリューションの選択および実装には、クエリ、スケーリング、ストレージの特性がワークロードのデータの要件をサポートしていることを確認する必要があります。さまざまなデータベースオプションがデータモデルにどのように適合するか、またユースケースに最適な構成オプションについて学びます。  AWS では、リレーショナル、key-value、ドキュメント、インメモリ、グラフ、時系列、台帳データベースなど多数のデータベースエンジンを提供しています。各データ管理ソリューションには、ユースケースとデータモデルをサポートするために使用できるオプションと設定があります。ワークロードでは、データの特性に応じて、いくつかの異なるデータベースソリューションを使用できる場合があります。特定の問題に最適なデータベースソリューションを選択することで、限定的な画一的アプローチのモノリシックなデータベースから脱却し、顧客のニーズに合わせたデータ管理に専念できます。 **期待される成果:** ワークロードのデータ特性が文書化され、サポートするデータベースソリューションの選択と設定を容易にし、考えられる代替手段についての洞察を得るのに十分な詳細が提供されます。 **一般的なアンチパターン:** + 大規模なデータセットを同様の特性を持つ小さなデータコレクションにセグメント化する方法を考慮していないため、データと成長の特性により適した、目的に特化したデータベースを使用する機会が失われている。 + データアクセスパターンを前もって特定せず、複雑でコストのかかる作業をやり直すことになる。 + 必要に応じて迅速にスケールしないデータストレージ戦略を使用することで成長を制限している。 + すべてのワークロードに対して 1 つのデータベースタイプとベンダーを選択する。 + 特定のタイプのデータベースソリューションに関する社内知識と経験があるため、1 つのデータベースソリューションに固執する。 + オンプレミス環境でうまく機能したことを理由にデータベースソリューションをキープする。 **このベストプラクティスを活用するメリット:** さまざまなワークロードに適したデータベースソリューションを決定できるように、すべての AWS データベースソリューションについての知識を身に付けておきます。ワークロードに適したデータベースソリューションを選択したら、各データベースサービスを簡単に試し、ワークロードのニーズを満たし続けているかどうかを判断できます。 **このベストプラクティスを活用しない場合のリスクレベル:** 高 + 実現可能なコスト削減が特定できない可能性がある。 + データを適切なレベルでセキュリティ保護できない可能性がある。 + データアクセスおよびストレージパフォーマンスが最適でない可能性がある。 ## 実装のガイダンス ワークロードのデータの特性とアクセスパターンを定義します。利用できるデータベースソリューションを確認し、どのソリューションがデータ要件をサポートするかを特定します。1 つのワークロードに対して、複数のデータベースを選択できます。各サービスまたはサービスのグループを審査し、個別に評価します。代替として利用可能なデータ管理ソリューションがデータの一部またはすべてに対して特定された場合は、コスト、セキュリティ、パフォーマンス、信頼性における利点を引き出す可能性のある代替の実装を試してみます。新しいデータ管理のアプローチを導入する場合は、既存のドキュメントを更新します。 | **タイプ** | **AWS のサービス** | **主な特徴** | **一般的なユースケース** | | --- | --- | --- | --- | | リレーショナル | Amazon RDS、Amazon Aurora | 参照整合性、ACID トランザクション、Schema-On-Write | ERP、CRM、市販のソフトウェア | | key-value | Amazon DynamoDB | 高スループット、低レイテンシー、ほぼ無限のスケーラビリティ | ショッピングカート (e コマース)、製品カタログ、チャットアプリケーション | | ドキュメント | Amazon DocumentDB | JSON ドキュメントを保存し任意の属性でクエリを実行する | コンテンツ管理 (CMS)、顧客プロファイル、モバイルアプリケーション | | インメモリ | Amazon ElastiCache、Amazon MemoryDB | ミリ秒のレイテンシー | キャッシュ、ゲームのリーダーボード | | グラフ | Amazon Neptune | データ間のリレーションに意味がある関係性の高いデータ | ソーシャルネットワーク、パーソナライゼーションエンジン、不正検出 | | 時系列 | Amazon Timestream | プライマリディメンションが時刻のデータ | DevOps、IoT、モニタリング | | ワイドカラム | Amazon Keyspaces | Cassandra ワークロード | 産業機器のメンテナンス、ルートの最適化 | | 台帳 | Amazon QLDB | 不変で暗号的に検証可能な変更の台帳 | 記録システム、医療、サプライチェーン、金融機関 | **実装手順** 1. データはどのように構造化されていますか (非構造化、key-value、半構造化、リレーショナルなど)。 1. データが構造化されていない場合は、 [Amazon S3](https://aws.amazon.com/products/storage/data-lake-storage/) などのオブジェクトストアか、 [Amazon DocumentDB などの NoSQL データベースを検討します。](https://aws.amazon.com/documentdb/) 1. key-value データの場合は、 [DynamoDB](https://aws.amazon.com/documentdb/)、 [ElastiCache for Redis](https://aws.amazon.com/elasticache/redis/) または [MemoryDB を検討します。](https://aws.amazon.com/memorydb/) 1. データがリレーショナル構造を持っている場合、どのレベルの参照整合性が必要ですか。 1. 外部キー制約の場合は、 [Amazon RDS](https://aws.amazon.com/rds/) および [Aurora](https://aws.amazon.com/rds/aurora/) などのリレーショナルデータベースがこのレベルの整合性を提供できます。 1. 通常、NoSQL データモデル内では、データをドキュメントまたはテーブルをまたいで結合するのではなく、単一のドキュメントまたはドキュメントのコレクションに非正規化して、単一のリクエストで取得します。  1. ACID (atomicity、consistency、isolation、durability) への準拠は必要ですか。 1. リレーショナルデータベースに関連付けられている ACID プロパティが必要な場合は、 [Amazon RDS](https://aws.amazon.com/rds/) および [Aurora などのリレーショナルデータベースを検討します。](https://aws.amazon.com/rds/aurora/) 1. どのような一貫性モデルが必要ですか。 1. アプリケーションが結果整合性を許容できる場合は、NoSQL の実装を検討します。他の特性を確認して、最適な [NoSQL データベース](https://aws.amazon.com/nosql/) を選びます。 1. 強整合性が必要な場合は、 [DynamoDB](https://aws.amazon.com/documentdb/) または [Amazon RDS](https://aws.amazon.com/rds/)などのリレーショナルデータベースで強力な整合性のある読み込みを使用できます。 1. どのような形式のクエリと結果をサポートする必要がありますか (SQL、CSV、Parque、Avro、JSON など)。 1. どのようなデータ型、フィールドサイズ、および全体の量が存在しますか (テキスト、数値、空間、時系列計算、バイナリまたはブロブ、ドキュメントなど)。 1. ストレージ要件は時間の経過とともにどのように変化しますか。 これにより、スケーラビリティにどのような影響がありますか。 1. サーバーレスデータベース ( [DynamoDB](https://aws.amazon.com/documentdb/) および [Amazon Quantum Ledger Database](https://aws.amazon.com/qldb/) など) は、ほぼ無制限のストレージまで動的にスケールアップします。 1. リレーショナルデータベースには、プロビジョニングされたストレージに上限があり、多くの場合、この上限に達すると、シャーディングなどのメカニズムを介して水平方向に分割する必要があります。 1. 書き込みクエリに対する読み取りクエリの割合はどのくらいですか。 キャッシングによってパフォーマンスが向上する可能性はありますか。 1. 読み取り負荷の高いワークロードでは、キャッシングレイヤーを使用することでメリットが得られます。これには、 [ElastiCache](https://aws.amazon.com/elasticache/) または [DAX](https://aws.amazon.com/dynamodb/dax/) (データベースが DynamoDB の場合) などがあります。 1. 読み取りは、 [Amazon RDS](https://aws.amazon.com/rds/)などのリレーショナルデータベースを使用して読み取りレプリカにオフロードすることもできます。 1. ストレージや変更 (OLTP - オンライントランザクション処理) または取得やレポート (OLAP - オンライン分析処理) のどちらが優先されますか。 1. 高スループットのトランザクション処理については、DynamoDB や Amazon DocumentDB などの NoSQL データベースを検討します。 1. 分析クエリの場合は、 [Amazon Redshift](https://aws.amazon.com/redshift/) などの列指向データベースを検討するか、データを Amazon S3 にエクスポートして [Athena](https://aws.amazon.com/athena/) または [QuickSight を使用して分析を実行することを検討します。](https://aws.amazon.com/quicksight/) 1. このデータの機密性はどの程度で、どのようなレベルの保護と暗号化が必要ですか。 1. すべての Amazon RDS および Aurora エンジンは、AWS KMS を使用した保管時のデータ暗号化をサポートしています。Microsoft SQL Server と Oracle では、Amazon RDS を使用する場合、ネイティブの Transparent Data Encryption (TDE) もサポートします。 1. DynamoDB の場合、 [IAM](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/access-control-overview.html) できめ細かなアクセス制御 (FGAC) を使用し、誰がどのデータにアクセスできるかをキーレベルで制御できます。 1. データにはどのレベルの耐久性が必要ですか。 1. Aurora は、リージョン内の 3 つのアベイラビリティーゾーンにわたってデータを自動的に複製します。これはつまり、データの耐久性が高く、データ損失の可能性が低くなることを意味します。 1. DynamoDB は、複数のアベイラビリティーゾーンに自動的に複製され、高可用性とデータ耐久性を提供します。 1. Amazon S3 は、99.9999999% (イレブンナイン) の耐久性を提供します。Amazon RDS や DynamoDB などの多くのデータベースサービスでは、長期的な保持とアーカイブの目的で、Amazon S3 へのデータのエクスポートをサポートしています。 1. すべきこと [目標復旧時間 (RTO) または目標復旧時点 (RPO)](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-for-disaster-recovery-dr.html) の要件はソリューションに影響しますか。 1. Amazon RDS、Aurora、DynamoDB、Amazon DocumentDB、Neptune はすべて、ポイントインタイムリカバリとオンデマンドのバックアップと復元をサポートしています。  1. 高可用性の要件については、DynamoDB テーブルを [グローバルテーブル](https://aws.amazon.com/dynamodb/global-tables/) 機能を使用してグローバルに複製でき、Aurora クラスターを Global Database 機能を使用して複数のリージョンでレプリケートできます。さらに、S3 バケットは、クロスリージョンレプリケーションを使用して AWS リージョン 間で複製できます。  1. 商用データベースエンジンやライセンスコストから離れたいという希望はありますか。 1. Amazon RDS または Aurora で PostgreSQL や MySQL などのオープンソースのエンジンを検討します。 1. 商用データベースエンジンからオープンソースへの移行を行うには、 [AWS DMS](https://aws.amazon.com/dms/) および [AWS SCT](https://aws.amazon.com/dms/schema-conversion-tool/) を利用します。 1. データベースには運用上どのようなことが期待されますか。 マネージドサービスへの移行は主な懸念事項ですか。 1. Amazon EC2 の代わりに Amazon RDS を利用し、NoSQL データベースをセルフホスティングする代わりに DynamoDB または Amazon DocumentDB を利用することで、運用上の諸経費を削減できます。 1. データベースへのアクセスは現在どのように行われていますか。 アプリケーションアクセスのみですか、それともビジネスインテリジェンス (BI) ユーザーやその他の接続された既製アプリケーションが存在しますか。 1. 外部ツールに依存している場合は、ツールがサポートするデータベースとの互換性を維持することが必要になる場合があります。Amazon RDS は Microsoft SQL Server、Oracle、MySQL、PostgreSQL など、サポートするさまざまなエンジンバージョンとの完全な互換性があります。 1. 以下は、利用可能なデータ管理サービスのリストと、その最適な使用場所です。 1. リレーショナルデータベースは、定義済みのスキーマとそれらの関係を使用してデータを格納します。これらのデータベースは、ACID (atomicity、consistency、isolation、durability) トランザクションをサポートし、参照整合性と強固なデータ整合性を維持するように設計されています。従来のアプリケーション、エンタープライズリソースプランニング (ERP)、顧客関係管理 (CRM)、e コマースの多くは、リレーショナルデータベースを使用してデータを保存します。これらのデータベースエンジンの多くは Amazon EC2 で実行することも、AWS のマネージド [データベースサービス](https://aws.amazon.com/products/databases/)( [Amazon Aurora](https://aws.amazon.com/rds/aurora)、 [Amazon RDS](https://aws.amazon.com/rds)、または [Amazon Redshift](https://aws.amazon.com/redshift)) から選ぶこともできます。 1. キー値データベースは、一般的に大量のデータを保存および取得するために、一般的なアクセスパターン用に最適化されています。これらのデータベースは、極端な量の同時リクエストでさえも、迅速な応答時間を実現します。高トラフィックのウェブアプリケーション、e コマースシステム、ゲーミングアプリケーションは、key-value データベースの典型的なユースケースです。AWS では、 [Amazon DynamoDB](https://aws.amazon.com/dynamodb/)を利用することができます。これはマルチリージョンとマルチマスターに対応し、耐久性に優れたフルマネージドデータベースで、インターネットスケールのアプリケーションに対応した、組み込みのセキュリティ、バックアップと復元の機能、インメモリキャッシュを備えています 1. インメモリデータベースは、データへのリアルタイムアクセス、最小のレイテンシー、最大のスループットが必要なアプリケーションに使用されます。これらのデータベースは、データをメモリ内に直接保存することにより、ミリ秒単位のレイテンシーでは不十分なアプリケーションにマイクロ秒単位のレイテンシーを提供します。インメモリデータベースは、アプリケーションキャッシング、セッション管理、ゲームのリーダーボード、および地理空間アプリケーションに使用できます。 [Amazon ElastiCache](https://aws.amazon.com/elasticache/) は、フルマネージド型のインメモリデータストアで、 [Redis](https://aws.amazon.com/elasticache/redis/) または [Memcached](https://aws.amazon.com/elasticache/memcached)と互換性があります。アプリケーションの耐久性要件も高い場合、超高速パフォーマンス用の耐久性のあるインメモリデータベースサービスである [Amazon MemoryDB for Redis ](https://aws.amazon.com/memorydb/) がこれを組み合わせて提供します。 1. ドキュメントデータベースは、半構造化データを JSON 型のドキュメントとしとして保存するように設計されています。これらのデータベースは、開発者がコンテンツ管理、カタログ、およびユーザープロファイルなどのアプリケーションをすばやく構築し、更新するために役立ちます。 [Amazon DocumentDB](https://aws.amazon.com/documentdb/)  は、高速で、スケーラブル、かつ高可用性の完全マネージド型ドキュメントデータベースサービスで、MongoDB ワークロードに対応しています。 1. ワイドカラムデータストアは NoSQL データベースの一種です。テーブル、行、および列を使用しますが、リレーショナルデータベースとは異なり、同じテーブル内でも列の名前と形式が行ごとに異なる場合があります。ワイドカラムデータストアは通常、設備保全、フリート管理、およびルート最適化のための大規模な産業アプリケーションでの使用が見られます。 [Amazon Keyspaces (Apache Cassandra 向け)](https://aws.amazon.com/mcs/)  は、ワイドカラムにスケールできる、可用性に優れたマネージド型の Apache Cassandra 互換データベースサービスです。 1. グラフデータベースは、関連性が高いグラフデータセット間における何百万もの関係を、大規模に、かつミリ秒単位のレイテンシーでナビゲートし、クエリする必要があるアプリケーション向けのデータベースです。多くの企業が、不正行為検出、ソーシャルネットワーキング、およびレコメンデーションエンジン向けにグラフデータベースを使用しています。 [Amazon Neptune](https://aws.amazon.com/neptune/) は、高速で信頼性に優れたフルマネージド型のグラフデータベースサービスで、関連性が高いデータセットを処理するアプリケーションの構築と実行を容易にします。 1. 時系列データベースは、時間の経過と共に変化するデータを効率的に収集、合成し、それらからインサイトを導き出します。時系列データベースは、IoT アプリケーション、DevOps、および産業用テレメトリに利用できます。 [Amazon Timestream](https://aws.amazon.com/timestream/) は、IoT および運用アプリケーション向けの高速でスケーラブルなフルマネージド型の時系列データベースサービスで、1 日あたり数兆件のイベントの保存と分析を容易にします。 1. 台帳データベースは、あらゆるアプリケーションについて、トランザクションのスケーラブルでイミュータブル、かつ暗号的な検証が可能なレコードを維持する信頼された中央機関を提供します。台帳データベースは、SoR、サプライチェーン、登録、および銀行取引にも使用されています。 [Amazon Quantum Ledger Database (Amazon QLDB)](https://aws.amazon.com/qldb/) はフルマネージド型の台帳データベースで、信頼された中央機関によって所有される、透過的でイミュータブル、かつ暗号的な検証が可能なトランザクションログを提供します。Amazon QLDB は、すべてのアプリケーションのデータ変更を追跡し、経時的な変更の完全で検証可能な履歴を維持します。 **実装計画に必要な工数レベル: **ワークロードがあるデータベースソリューションから別のデータベースソリューションに移行する場合は、アプリケーションのリファクタリングに *高* 程度の工数が必要になる可能性があります。   ## リソース **関連ドキュメント:** + [AWS でのクラウドデータベース ](https://aws.amazon.com/products/databases/?ref=wellarchitected) + [AWS Database Caching ](https://aws.amazon.com/caching/database-caching/?ref=wellarchitected) + [Amazon 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 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/UserGuide/BestPractices.html) **関連動画:** + [AWS purpose-built databases (DAT209-L) ](https://www.youtube.com/watch?v=q81TVuV5u28) + [Amazon Aurora storage demystified: How it all works (DAT309-R) ](https://www.youtube.com/watch?v=uaQEGLKtw54) + [Amazon DynamoDB deep dive: Advanced design patterns (DAT403-R1) ](https://www.youtube.com/watch?v=6yqfmXiZTlM) **関連サンプル:** + [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 (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) # PERF04-BP02 使用可能なオプションを評価する データ管理ソリューションを選択する前に、利用可能なデータベースのオプションと、それぞれがどのようにパフォーマンスを最適化するかを理解します。負荷テストを使用して、ワークロードにとって重要なデータベースメトリクスを特定します。データベースのオプションを検討する際は、パラメータグループ、ストレージオプション、メモリ、コンピューティング、リードレプリカ、結果整合性、接続プーリング、キャッシュオプションなど、さまざまな側面を考慮します。メトリクスを改善するために、こうしたさまざまな設定オプションを試します。 **期待される成果:** ワークロードでは、データ型によって、1 つまたは複数のデータベースソリューションを使用できます。データベースの機能と利点が、データの特性、アクセスパターン、ワークロードの要件に最適に合致します。データベースのパフォーマンスとコストを最適化するには、データアクセスパターンを評価して適切なデータベースオプションを決定する必要があります。許容可能なクエリ時間を評価し、選択したデータベースオプションが要件を満たすことを確認します。 **一般的なアンチパターン:** + データアクセスパターンを特定しない。 + 選択したデータ管理ソリューションの設定オプションを把握していない。 + 使用できる設定オプションを確認せずに、インスタンスサイズを増やすことのみに頼っている。 + 選んだソリューションのスケーリングに関する特性をテストしない。 **このベストプラクティスを活用するメリット:** データベースオプションを確認し、試してみることで、インフラストラクチャのコストを削減し、パフォーマンスとスケーラビリティを高め、ワークロードの維持に必要な労力を軽減できる場合があります。 **このベストプラクティスを活用しない場合のリスクレベル:** 高 + 1 つのサイズで *すべてに対応するよう* データベースを最適化する必要があると、不必要な妥協をすることになる。 + データベースソリューションがトラフィックパターンに合わせて設定されていないため、コストが高くなる。 + スケーリングの問題から運用上の問題が発生する可能性がある。 + データを適切なレベルでセキュリティ保護できない可能性がある。 ## 実装のガイダンス データベースオプションを設定できるように、ワークロードデータの特性を理解します。負荷テストを行い、主要なパフォーマンスメトリクスとボトルネックを特定します。こうした特性およびメトリクスを使用して、データベースオプションを評価し、さまざまな設定を試します。 | AWS のサービス | Amazon RDS、Amazon Aurora | Amazon DynamoDB | Amazon DocumentDB | Amazon ElastiCache | Amazon Neptune | Amazon Timestream | Amazon Keyspaces | Amazon QLDB | | --- | --- | --- | --- | --- | --- | --- | --- | --- | | コンピューティングのスケーリング | インスタンスサイズを増やす、Aurora サーバーレスインスタンスは負荷の変化に応じて自動スケーリングする | オンデマンドキャパシティモードによる自動の読み取り/書き込みスケーリング、またはプロビジョンドキャパシティモードでプロビジョニングされた読み取り/書き込みキャパシティの自動スケーリング | インスタンスサイズを増やす | インスタンスサイズを増やす、クラスターにノードを追加する | インスタンスサイズを増やす | 自動的にスケーリングしてキャパシティを調整する | オンデマンドキャパシティモードによる自動の読み取り/書き込みスケーリング、またはプロビジョンドキャパシティモードでプロビジョニングされた読み取り/書き込みキャパシティの自動スケーリング | 自動的にスケーリングしてキャパシティを調整する | | 読み取りのスケールアウト | すべてのエンジンでリードレプリカをサポート。Aurora はリードレプリカインスタンスの自動スケーリングをサポートする | プロビジョニングされた読み取りキャパシティユニットを増やす | リードレプリカ | リードレプリカ | リードレプリカ。リードレプリカインスタンスの自動スケーリングをサポート | 自動的にスケーリングする | プロビジョニングされた読み取りキャパシティユニットを増やす | 文書化された同時実行制限まで自動的にスケールアップ | | 書き込みのスケールアウト | インスタンスサイズを増やす、アプリケーション内の書き込みをバッチ処理する、またはデータベースの前にキューを追加する複数のインスタンスにまたがるアプリケーションレベルのシャーディングで水平スケーリング | プロビジョニングされた書き込みキャパシティユニットを増やす最適なパーティションキーを確保し、パーティションレベルでの書き込みのスロットリングを防ぐ | プライマリインスタンスサイズを増やす | Redis をクラスターモードで使用して書き込みを複数のシャードに分散する | インスタンスサイズを増やす | 書き込みリクエストがスケーリング中にスロットリングされる可能性がある。スロットリング例外が発生した場合は、同じ (またはそれ以上の) スループットでデータを送信し続け、自動的にスケーリングする。書き込みをバッチ処理して同時実行される書き込みリクエストを減らす | プロビジョニングされた書き込みキャパシティユニットを増やす最適なパーティションキーを確保し、パーティションレベルでの書き込みのスロットリングを防ぐ | 文書化された同時実行制限まで自動的にスケールアップ | | エンジンの設定 | パラメータグループ | 該当しない | パラメータグループ | パラメータグループ | パラメータグループ | 該当しない | 該当しない | 該当しない | | キャッシング | インメモリキャッシュ、パラメータグループを介して設定可能。ElastiCache for Redis などの専用キャッシュと組み合わせて、よくアクセスされるアイテムに対するリクエストをオフロードする | DAX (DAX) 完全マネージド型キャッシュが利用可能 | インメモリキャッシュ。必要に応じて、ElastiCache for Redis などの専用キャッシュと組み合わせて、よくアクセスされるアイテムに対するリクエストをオフロードすることも可能。 | キャッシュが主な機能 | クエリ結果キャッシュを使用して読み取り専用クエリの結果をキャッシュする | Timestream には 2 つのストレージ層があり、そのうち 1 つはハイパフォーマンスのインメモリ層 | ElastiCache for Redis などの専用キャッシュを別にデプロイし、よくアクセスされるアイテムに対するリクエストをオフロードする | 該当しない | | 高可用性 / ディザスタリカバリ | 本番ワークロードで推奨される設定は、2 つ目のアベイラビリティーゾーンでスタンバイインスタンスを実行して、リージョン内で回復力を提供すること。  リージョン間の回復力については、Aurora Global Database を使用可能 | 1 つのリージョン内で可用性が高い。テーブルは DynamoDB グローバルテーブルを使用してリージョン間で複製できる | 複数のインスタンスをアベイラビリティゾーンをまたいで作成して可用性を向上。  スナップショットはリージョンをまたいで共有でき、クラスタは DMS を使用して複製可能。これによりクロスリージョンレプリケーションやディザスタリカバリが提供される | 本番クラスタで推奨される設定は 2 つ目のアベイラビリティゾーンに少なくとも 1 つのノードを作成すること。  リージョン間でのクラスタの複製には ElastiCache Global Datastore を使用できる。 | 他のアベイラビリティゾーンのリードレプリカはフェイルオーバーターゲットとして機能する。  スナップショットはリージョンをまたいで共有でき、クラスタは Neptune ストリームを使用して複製可能。これにより、2 つの異なるリージョンの 2 つのクラスター間でデータを複製できる。 | 1 つのリージョンで可用性が高い。クロスリージョンレプリケーションには Timestream SDK を使用したカスタムアプリケーション開発が必要。 | 1 つのリージョン内で可用性が高い。  クロスリージョンレプリケーションにはカスタムアプリケーションロジックまたはサードパーティ製ツールが必要 | 1 つのリージョン内で可用性が高い。  リージョン間で複製するには、Amazon QLDB ジャーナルのコンテンツを S3 バケットにエクスポートし、クロスリージョンレプリケーション用にバケットを設定する。 | **実装手順** 1. 選択したデータベースで使用できる設定オプションは何ですか。 1. Amazon RDS および Aurora のパラメータグループを使用すると、キャッシュに割り当てられたメモリやデータベースのタイムゾーンの調整など、一般的なデータベースエンジンレベルの設定を調整できます。 1. Amazon RDS、Aurora、Neptune、Amazon DocumentDB などのプロビジョンドデータベースサービスや、Amazon EC2 にデプロイされたデータベースサービスでは、インスタンスタイプ、プロビジョニングされたストレージを変更し、リードレプリカを追加できます。 1. DynamoDB では、オンデマンドとプロビジョンドの 2 つのキャパシティモードを指定できます。さまざまなワークロードに対応するために、随時モードを切り替えて、プロビジョニングドモードで割り当てられているキャパシティを増やすことができます。 1. ワークロードでは、読み取りまたは書き込みの負荷が高くなりますか。  1. 読み取りをオフロードするためにどのようなソリューションを使用できますか (リードレプリカ、キャッシュなど)。  1. DynamoDB テーブルの場合、キャッシュに DAX を使用して読み取りをオフロードできます。 1. リレーショナルデータベースの場合、ElastiCache for Redis クラスターを作成して、最初にキャッシュから読み取り、リクエストされたアイテムが存在しない場合にデータベースにフォールバックするようにアプリケーションを設定できます。 1. Amazon RDS および Aurora などのリレーショナルデータベース、Neptune などのプロビジョンド NoSQL データベース、Amazon DocumentDB はすべて、ワークロードの読み取り部分をオフロードするためのリードレプリカの追加をサポートします。 1. DynamoDB などのサーバーレスデータベースは自動的にスケーリングします。ワークロードを処理するのに十分な読み取りキャパシティユニット (RCU) がプロビジョニングされていることを確認します。 1. 書き込みのスケーリングにはどのようなソリューションを使用できますか (パーティションキーのシャーディング、キューの導入など)。 1. リレーショナルデータベースの場合、インスタンスのサイズを増やして増加したワークロードに対応するか、プロビジョンド IOPS を増やして、基盤となるストレージへのスループットを増やせるようにします。 + また、データベースに直接書き込むのではなく、データベースの前にキューを導入することもできます。このパターンでは、データの取り込みをデータベースから切り離し、フローレートを制御することで、データベースが過負荷になるのを回避できます。  + 存続時間の短いトランザクションを大量に作成するのではなく、書き込みリクエストをバッチ処理することで、書き込み量の多いリレーショナルデータベースのスループットを向上させることができます。 1. DynamoDB のようなサーバーレスデータベースは、キャパシティモードに応じて、自動的に、またはプロビジョニングされた書き込みキャパシティユニット (WCU) を調整することにより、書き込みスループットをスケーリングできます。  + ただし、特定のパーティションキーのスループット上限に達すると、引き続き *ホット* パーティションの問題が発生する可能性があります。これは、より均等に分散されたパーティションキーを選択するか、パーティションキーを書き込みシャーディングすることで緩和できます。  1. 現在または予想される 1 秒あたりのピークトランザクション数はどのくらいですか。 このトラフィック量とこの量 \$1X% を使用してスケーリングの特性を理解します。 1. PostgreSQL 用の pg\$1bench などのネイティブツールを使用して、データベースのストレステストを行い、ボトルネックとスケーリングの特性を理解できます。 1. 合成ワークロードに加えて、実際の条件をシミュレートするために再現できるように、実稼働環境に似たトラフィックをキャプチャする必要があります。 1. サーバーレスまたは伸縮自在にスケーリングが可能なコンピューティングを使用している場合は、これをスケーリングした場合のデータベースへの影響をテストします。必要に応じて、接続管理またはプーリングを導入し、データベースへの影響を軽減します。  1. Amazon RDS および Aurora でデータベースへの接続を管理するには、RDS Proxy を使用できます。  1. DynamoDB などのサーバーレスデータベースには関連付けられている接続はありませんが、負荷の急増に対応するためにプロビジョンドキャパシティおよび自動スケーリングのポリシーを検討します。 1. 負荷は予測可能ですか。負荷の急増やアクティビティのない期間はありますか。 1. アクティビティのない期間がある場合は、こうした期間中にプロビジョンドキャパシティまたはインスタンスサイズをスケールダウンすることを検討します。Aurora Serverless V2 は、負荷に応じて自動でスケールアップおよびスケールダウンします。 1. 非本番インスタンスの場合は、業務時間外に一時停止または停止することを検討します。 1. アクセスパターンやデータの特性に応じてデータモデルをセグメント化および分割する必要がありますか。 1. データを他のサービスに移動するには、AWS DMS または AWS SCT を使用することを検討します。 ## 実装計画に必要な工数レベル:  このベストプラクティスを確立するには、現在のデータの特性とメトリクスを把握している必要があります。こうしたメトリクスを収集し、ベースラインを確立した上で、これらのメトリクスを使用して最適なデータベースの設定オプションを特定するには、 *低* ～ *中* 程度の工数が必要です。これは、負荷テストと実験によって検証するのが最善策です。 ## リソース **関連ドキュメント:** + [AWS でのクラウドデータベース ](https://aws.amazon.com/products/databases/?ref=wellarchitected) + [AWS Database Caching ](https://aws.amazon.com/caching/database-caching/?ref=wellarchitected) + [Amazon 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) **関連動画:** + [AWS purpose-built databases (DAT209-L) ](https://www.youtube.com/watch?v=q81TVuV5u28) + [Amazon Aurora storage demystified: How it all works (DAT309-R) ](https://www.youtube.com/watch?v=uaQEGLKtw54) + [Amazon DynamoDB deep dive: Advanced design patterns (DAT403-R1) ](https://www.youtube.com/watch?v=6yqfmXiZTlM) **関連サンプル:** + [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) # PERF04-BP03 データベースのパフォーマンスメトリクスを収集して記録する データ管理システムのパフォーマンスを把握するには、関連性のあるメトリクスを追跡することが重要です。このようなメトリクスは、データ管理リソースを最適化し、ワークロード要件が満たされていることを確かめ、ワークロードのパフォーマンスの概要を明確に把握するのに役立ちます。データベースのパフォーマンスに関連するパフォーマンスの測定値を記録するツール、ライブラリ、システムを使用します。 メトリクスには、データベースがホストされているシステムに関連するメトリクス (CPU、ストレージ、メモリ、IOPS など) と、データ自体にアクセスするためのメトリクス (1 秒あたりのトランザクション数、クエリレート、応答時間、エラーなど) があります。これらのメトリクスは、すべてのサポートスタッフまたは運用スタッフが簡単にアクセスできる必要があります。また、傾向、異常、ボトルネックを特定できる十分な過去の記録が必要です。 **期待される成果:** データベースのワークロードのパフォーマンスをモニタリングするには、一定期間にわたって複数のパフォーマンスメトリクスを記録する必要があります。これにより、異常を検出し、ビジネスメトリクスに照らしてパフォーマンスを測定して、ワークロードのニーズを確実に満たすことができます。 **一般的なアンチパターン:** + メトリクスの検索に手動ログファイルのみを使用している。 + チームが使用する内部ツールにのみメトリクスを発行しており、ワークロードの全体像を把握できていない。 + 一部のモニタリングソフトウェアで記録されるデフォルトのメトリクスのみを使用している。 + 問題が発生したときにだけメトリクスを確認している。 + システムレベルのメトリクスのみをモニタリングし、データアクセスや使用状況に関するメトリクスを把握していない。 **このベストプラクティスを活用するメリット:** パフォーマンスのベースラインを確立すると、ワークロードの通常の動作とワークロードの要件を理解するのに役立ちます。異常なパターンをより迅速に特定してデバッグできるため、データベースのパフォーマンスと信頼性が向上します。データベースのキャパシティは、パフォーマンスを犠牲にすることなくコストを最適化するように設定できます。 **このベストプラクティスを活用しない場合のリスクレベル:** 高 + 異常なパフォーマンスレベルと通常のパフォーマンスレベルを区別できなければ、問題の特定とそれに伴う意思決定が困難になる。 + 実現可能なコスト削減が特定できない可能性がある。 + 成長パターンが特定されないため、信頼性やパフォーマンスの低下につながる可能性がある。 ## 実装のガイダンス データベースグ関連のメトリクスを特定、収集、集計し、関連付けを行います。メトリクスは、データベースをサポートする基盤となるシステムとデータベース自体の両方のメトリクスが含まれている必要があります。基盤となるシステムのメトリクスには、CPU 使用率、メモリ、使用可能なディスク容量、ディスク I/O、ネットワークのインバウンドとアウトバウンドに関するメトリクスなどがあり、データベースのメトリクスには 1 秒あたりのトランザクション数、上位のクエリ、平均クエリレート、応答時間、インデックス使用率、テーブルロック、クエリのタイムアウトの数、開いている接続の数などがあります。このデータは、ワークロードのパフォーマンスやデータベースソリューションの使用状況を理解するために不可欠です。これらのメトリクスをデータ駆動型アプローチの一部として使用し、ワークロードのリソースを調整および最適化します。  **実装手順:** 1. 追跡するべき重要なデータベースメトリクスはどれですか。 1. [Amazon RDS のメトリクスのモニタリング](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Monitoring.html) 1. [Performance Insights を使用したモニタリング](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.html) 1. [拡張モニタリング](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 DAX のモニタリング](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/DAX.Monitoring.html) 1. [MemoryDB のモニタリング](https://docs.aws.amazon.com/memorydb/latest/devguide/monitoring-cloudwatch.html) 1. [Amazon Redshift のモニタリング](https://docs.aws.amazon.com/redshift/latest/mgmt/metrics.html) 1. [時系列のメトリクスとディメンション](https://docs.aws.amazon.com/timestream/latest/developerguide/metrics-dimensions.html) 1. [Aurora のクラスターレベルのメトリクス](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.AuroraMySQL.Monitoring.Metrics.html) 1. [Amazon Keyspaces のモニタリング](https://docs.aws.amazon.com/keyspaces/latest/devguide/monitoring.html) 1. [Amazon Neptune のモニタリング](https://docs.aws.amazon.com/neptune/latest/userguide/monitoring.html) 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. SQL の使用状況についてアプリケーションレベルの詳細が必要ですか。 1. [AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/xray-api-segmentdocuments.html#api-segmentdocuments-sql) をアプリケーションに組み込むと、洞察を得て、単一のクエリのすべてのデータポイントをカプセル化できます。 1. 現在、承認済みのロギングおよび監視ソリューションがありますか。 1. [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) では、アーキテクチャ内のリソース全体のメトリクスを収集できます。また、カスタムメトリクスを収集および発行して、ビジネスメトリクスまたは導出メトリクスを表面化することも可能です。CloudWatch またはサードパーティーのソリューションを使用して、しきい値を超過したことを示すアラームを設定します。 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 ](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) + [Amazon 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 (DAT209-L) ](https://www.youtube.com/watch?v=q81TVuV5u28) + [Amazon Aurora storage demystified: How it all works (DAT309-R) ](https://www.youtube.com/watch?v=uaQEGLKtw54) + [Amazon DynamoDB deep dive: Advanced design patterns (DAT403-R1) ](https://www.youtube.com/watch?v=6yqfmXiZTlM) **関連サンプル:** + [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) # PERF04-BP04 アクセスパターンに基づいてデータストレージを選択する ワークロードのアクセスパターンとアプリケーションの要件を使用して、使用する最適なデータサービスとテクノロジーを決定します。 **期待される成果:** 特定および文書化されたデータアクセスパターンを基にデータストレージが選択されます。このデータアクセスパターンには、最も一般的な読み取り、書き込み、削除クエリ、必要に応じた計算および集計の必要性、データの複雑性、データの独立性、必要な一貫性に関するニーズなどが含まれます。 **一般的なアンチパターン:** + 運用管理を簡素化するため、データベースエンジンを 1 社だけ選択する。 + 時間が経過してもデータアクセスパターンが変わらないと考えている。 + 複雑なトランザクション、ロールバック、一貫性ロジックをアプリケーションに実装する。 + データベースがトラフィックの急増に対応できるように設定されており、データベースリソースがほとんどアイドル状態のままになる。 + トランザクションや分析の用途に共有データベースを使用する。 **このベストプラクティスを確立するメリット:** アクセスパターンを基にデータストレージを選択および最適化すると、開発の複雑さが軽減し、パフォーマンス改善の機会が最適化します。リードレプリカ、グローバルテーブル、データのパーティショニング、キャッシュをいつ使用するべきかを理解することで、運用上の諸経費を減らし、ワークロードのニーズに応じてスケーリングできるようになります。 **このベストプラクティスを確立しない場合のリスクレベル:** 中 ## 実装のガイダンス データアクセスパターンを特定、評価し、適切なストレージ設定を選択します。各データベースソリューションには、ストレージソリューションを設定および最適化するオプションがあります。収集したメトリクスとログを使用し、オプションを試してみることで、最適な設定を特定します。下記の表で、データベースサービスごとのストレージオプションを確認できます。 | AWS Services | Amazon RDS | Amazon Aurora | Amazon DynamoDB | Amazon DocumentDB | Amazon ElastiCache | Amazon Neptune | Amazon Timestream | Amazon Keyspaces | Amazon QLDB | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | | Scaling Storage | Storage can be scaled up manually or configured to scale automatically to a maximum of 64 TiB based on engine types. Provisioned storage cannot be decreased. | Storage scales automatically up to maximum of 128 TiB and decreases when data is removed. Maximum storage size also depends upon specific Aurora MySQL or Aurora Postgres engine versions. | Storage automatically scales. Tables are unconstrained in terms of size. | Storage scales automatically up to maximum of 64 TiB. Starting Amazon DocumentDB 4.0 storage can decrease by comparable amounts for data removal through dropping a collection or index. With Amazon DocumentDB 3.6 allocated space remains same and free space is reused when data volume increases. | Storage is in-memory, tied to instance type or count. | Storage scales automatically can grow up to 128 TiB (or 64 TiB in few Regions). Upon data removal from, total allocated space remains same and is reused in the future. | Organizes your time series data to optimize query processing and reduce storage costs. Retention period can be configured through in-memory and magnetic tiers. | Scales table storage up and down automatically as your application writes, updates, and deletes data. | Storage automatically scales. Tables are unconstrained in terms of size. | **実装手順:** 1. トランザクション、原子性、一貫性、分離、耐久性 (ACID) コンプライアンス、整合性のある読み込みの要件を理解します。すべてのデータベースがこれらをサポートしているわけではなく、ほとんどの NoSQL データベースは結果整合性モデルを提供しています。 1. グローバルに分散されているアプリケーションの最適なストレージソリューションを特定するために、トラフィックパターン、レイテンシー、アクセス要件を考慮します。 1. クエリパターン、ランダムアクセスパターンおよび 1 回限りのクエリを分析します。テキストおよび自然言語の処理、時系列、グラフ向けの高度に専門化されたクエリ機能に関する条件についても考慮する必要があります。 1. 予想されるデータとトラフィックの増加を特定して文書化します。 1. Amazon RDS および Aurora は、文書化された制限までのストレージの自動スケーリングをサポートします。この制限を超える場合は、古いデータを Amazon S3 に移しアーカイブするか、過去のデータを集計し分析するか、シャーディングを使って水平にスケーリングすることを検討します。 1. DynamoDB および Amazon S3 は、ほぼ無限のストレージボリュームに自動的にスケーリングします。 1. EC2 で実行されている Amazon RDS インスタンスとデータベースは、手動でサイズ変更でき、EC2 インスタンスには追加ストレージ用に新しい EBS ボリュームを後日追加できます。  1. インスタンスタイプはアクティビティの変化に応じて変更できます。例えば、テスト中は小さいインスタンスから始め、サービスに本番のトラフィックが入ってくるようになったらインスタンスをスケーリングすることができます。Aurora Serverless V2 は負荷の変化に応じて自動でスケーリングします。  1. 通常のパフォーマンスおよびピークパフォーマンスに関する要件 (1 秒あたりのトランザクション数 TPS および 1 秒あたりのクエリ数 QPS) と一貫性に関するベースライン要件 (ACID および結果整合性)。 1. ソリューションのデプロイに関する側面と、データベースのアクセス要件 (グローバルレプリケーション、マルチ AZ、リードレプリケーション、複数の書き込みノードなど) を文書化します。 **実装計画に必要な工数レベル:** 低。データ管理ソリューションのログまたはメトリクスがない場合は、データアクセスパターンを特定して文書化する前にそれを準備する必要があります。データアクセスパターンを把握できたら、データストレージの選択および設定に必要な工数レベルは低です。 ## リソース **関連するドキュメント:** + [AWS でのクラウドデータベース](https://aws.amazon.com/products/databases/) + [Amazon RDS DB インスタンスのストレージを使用する](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PIOPS.StorageTypes.html) + [Amazon DocumentDB ストレージ](https://docs.aws.amazon.com/documentdb/latest/developerguide/how-it-works.html#how-it-works.storage) + [AWS Database Caching ](https://aws.amazon.com/caching/database-caching/) + [Amazon Timestream ストレージ](https://docs.aws.amazon.com/timestream/latest/developerguide/storage.html) + [Amazon Keyspaces のストレージ](https://docs.aws.amazon.com/keyspaces/latest/devguide/Storage.html) + [Amazon ElastiCache に関するよくある質問](https://aws.amazon.com/elasticache/faqs/) + [ Amazon Neptune ストレージ、信頼性、および可用性 ](https://docs.aws.amazon.com/neptune/latest/userguide/feature-overview-storage.html) + [Amazon Aurora ベストプラクティス](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.BestPractices.html) + [Amazon DynamoDB Accelerator ](https://aws.amazon.com/dynamodb/dax/) + [Amazon DynamoDB ベストプラクティス](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/BestPractices.html) + [Amazon RDS のストレージタイプ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html) + [Amazon RDS インスタンスクラスのハードウェア仕様](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.DBInstanceClass.html#Concepts.DBInstanceClass.Types) + [Aurora ストレージの制限](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/CHAP_Limits.html#RDS_Limits.FileSize.Aurora) **関連動画:** + [AWS purpose-built databases (DAT209-L)](https://www.youtube.com/watch?v=q81TVuV5u28) + [Amazon Aurora storage demystified: How it all works (DAT309-R) ](https://www.youtube.com/watch?v=uaQEGLKtw54) + [ Amazon DynamoDB deep dive: Advanced design patterns (DAT403-R1) ](https://www.youtube.com/watch?v=6yqfmXiZTlM) **関連する例:** + [AWS での分散負荷テスト](https://aws.amazon.com/solutions/implementations/distributed-load-testing-on-aws/) # PERF04-BP05 アクセスパターンとメトリクスに基づいてデータストレージを最適化する データの保存方法とクエリ方法を最適化して可能な限り最高のパフォーマンスを達成するパフォーマンス特性とアクセスパターンを使用します。インデックス作成、キー分散、データウェアハウス設計、またはキャッシング戦略などの最適化が、システムのパフォーマンスまたは全体的な効率性にどのように影響するかを測定してください。 **一般的なアンチパターン:** + メトリクスの検索に手動ログファイルのみを使用している。 + 内部ツールにのみメトリクスを発行している。 **このベストプラクティスを確立するメリット:** ワークロードに必要なメトリクスを確実に満たすためには、読み取りと書き込みの両方に関連するデータベースパフォーマンスメトリクスをモニタリングする必要があります。このデータを使用して、データストレージレイヤーへの読み取りと書き込みの両方の新しい最適化を追加できます。 **このベストプラクティスが確立されていない場合のリスクレベル:** 低 ## 実装のガイダンス メトリクスとパターンに基づいてデータストレージを最適化する: レポートされたメトリクスを使用して、ワークロードのパフォーマンス不足の領域を特定し、データベースコンポーネントを最適化します。データのインデックス作成方法、キャッシュ方法、複数のシステム間での分散方法など、評価するパフォーマンス関連の特性は、データデータベースシステムごとに異なります。最適化の影響を測定します。 ## リソース **関連ドキュメント:** + [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) + [Amazon 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/) + [DevOps Guru for RDS でパフォーマンスの異常を分析する](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/devops-guru-for-rds.html) + [DynamoDB の読み取り/書き込みキャパシティモード](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.ReadWriteCapacityMode.html) **関連動画:** + [AWS purpose-built databases (DAT209-L) (AWS 目的別データベース)](https://www.youtube.com/watch?v=q81TVuV5u28) + [Amazon Aurora storage demystified: How it all works (DAT309-R) (Amazon Aurora ストレージの秘密: その仕組み)](https://www.youtube.com/watch?v=uaQEGLKtw54) + [Amazon DynamoDB deep dive: Advanced design patterns (DAT403-R1)](https://www.youtube.com/watch?v=6yqfmXiZTlM) **関連サンプル:** + [Hands-on Labs for Amazon DynamoDB (Amazon DynamoDB 向けのハンズオンラボ)](https://amazon-dynamodb-labs.workshop.aws/hands-on-labs.html) # PERF 5 ネットワーキングソリューションはどのように選択すればよいですか? ワークロードに最適なネットワークソリューションは、レイテンシー、スループット要件、ジッター、および帯域幅に応じて異なります。ロケーションのオプションは、ユーザーまたはオンプレミスのリソースなどの物理的な制約に左右されます。これらの制約は、エッジロケーションまたはリソースの配置で相殺することができます。 **Topics** + [PERF05-BP01 ネットワークがパフォーマンスに与える影響を理解する](perf_select_network_understand_impact.md) + [PERF05-BP02 使用可能なネットワーク機能を評価する](perf_select_network_evaluate_features.md) + [PERF05-BP03 ハイブリッドワークロード用に適切なサイズの専用接続または VPN を選択する](perf_select_network_hybrid.md) + [PERF05-BP04 ロードバランシングと暗号化のオフロードを活用する](perf_select_network_encryption_offload.md) + [PERF05-BP05 パフォーマンスを高めるネットワークプロトコルを選択する](perf_select_network_protocols.md) + [PERF05-BP06 ネットワーク要件に基づいてワークロードのロケーションを選択する](perf_select_network_location.md) + [PERF05-BP07 メトリクスに基づいてネットワーク設定を最適化する](perf_select_network_optimize.md) # PERF05-BP01 ネットワークがパフォーマンスに与える影響を理解する ネットワーク関連の意思決定がワークロードのパフォーマンスに与える影響を分析し、理解します。ネットワークは、アプリケーションコンポーネント、クラウドサービス、エッジネットワーク、オンプレミスデータ間の接続を担っているため、ワークロードのパフォーマンスに大きな影響を与える可能性があります。ワークロードのパフォーマンスに加え、ユーザーエクスペリエンスも、ネットワークのレイテンシー、帯域幅、プロトコル、場所、ネットワークの混雑、ジッター、スループット、ルーティングルールの影響を受けます。 **期待される成果:** レイテンシー、パケットサイズ、ルーティングルール、プロトコル、サポートするトラフィックパターンなど、ワークロードのネットワーク要件をまとめて文書化します。利用可能なネットワークソリューションを確認し、ワークロードのネットワーク特性に適合するサービスを特定します。クラウドベースのネットワークは迅速に再構築できるため、パフォーマンス効率を向上させるためにもネットワーク アーキテクチャを時間とともに進化させる必要があります。 **一般的なアンチパターン:** + すべてのトラフィックが既存のデータセンターを通過する。 + 実際の使用要件を把握せずに、Direct Connect セッションをオーバービルドする。 + ワークロードの特性および暗号化にかかるコストを考慮しない。 + クラウドのネットワーク戦略にオンプレミスのコンセプトと戦略を使用する。 **このベストプラクティスを活用するメリット:** ネットワークがワークロードのパフォーマンスに与える影響を理解することで、潜在的なボトルネックの特定、ユーザーエクスペリエンスの改善、信頼性の向上を実現しながら、ワークロードの変化に伴う運用保守業務を軽減できます。 **このベストプラクティスを活用しない場合のリスクレベル:** 高 ## 実装のガイダンス ワークロードの重要なネットワークパフォーマンスメトリクスを特定し、ネットワークの特性を洗い出します。ベンチマークまたは負荷テストを使用して、データ駆動型アプローチの一部として要件を定義して文書化します。このデータを使用してネットワークソリューションの制約が発生している場所を特定し、ワークロードを改善できる設定オプションを調べます。クラウドネイティブネットワークで利用できる機能とオプションを理解し、要件に応じてワークロードのパフォーマンスにどのように影響するかを把握します。各ネットワーク機能には長所と短所があり、ワークロードの特性に適合し、ニーズに合わせてスケーリングするように設定できます。 **実装手順:** 1. ネットワークパフォーマンス要件を定義し、文書化します。 1. ネットワークのレイテンシー、帯域幅、プロトコル、場所、トラフィックパターン (急増とその頻度)、スループット、暗号化、点検、ルーティングルールなどのメトリクスを含めます。 1. 基盤となるネットワークの特性を洗い出します。 1. [VPC フローログ ](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html) 1. [AWS トランジットゲートウェイのメトリクス](https://docs.aws.amazon.com/vpc/latest/tgw/transit-gateway-cloudwatch-metrics.html) 1. [AWS PrivateLink のメトリクス](https://docs.aws.amazon.com/vpc/latest/privatelink/privatelink-cloudwatch-metrics.html) 1. アプリケーションのネットワークの特性を洗い出します。 1. [Elastic Network Adaptor](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-network-performance-ena.html) 1. [AWS App Mesh のメトリクス](https://docs.aws.amazon.com/app-mesh/latest/userguide/envoy-metrics.html) 1. [Amazon API Gateway のメトリクス](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-metrics-and-dimensions.html) 1. エッジネットワークの特性を洗い出します。 1. [Amazon CloudFront のメトリクス](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/viewing-cloudfront-metrics.html) 1. [Amazon Route 53 のメトリクス](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/monitoring-cloudwatch.html) 1. [AWS Global Accelerator のメトリクス](https://docs.aws.amazon.com/global-accelerator/latest/dg/cloudwatch-monitoring.html) 1. ハイブリッドネットワークの特性を洗い出します。 1. [Direct Connect のメトリクス](https://docs.aws.amazon.com/directconnect/latest/UserGuide/monitoring-cloudwatch.html) 1. [AWS Site-to-Site VPN のメトリクス](https://docs.aws.amazon.com/vpn/latest/s2svpn/monitoring-cloudwatch-vpn.html) 1. [AWS Client VPN のメトリクス](https://docs.aws.amazon.com/vpn/latest/clientvpn-admin/monitoring-cloudwatch.html) 1. [AWS クラウド WAN のメトリクス](https://docs.aws.amazon.com/vpc/latest/cloudwan/cloudwan-cloudwatch-metrics.html) 1. セキュリティネットワークの特性を洗い出します。 1. [AWS Shield、WAF、Network Firewall のメトリクス](https://docs.aws.amazon.com/waf/latest/developerguide/monitoring-cloudwatch.html) 1. トレーシングツールでエンドツーエンドのパフォーマンスメトリクスを洗い出します。 1. [AWS X-Ray](https://aws.amazon.com/xray/) 1. [Amazon CloudWatch RUM](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html) 1. ネットワークパフォーマンスをベンチマーキングし、テストします。 1. [ネットワークスループットをベンチマーキング](https://aws.amazon.com/premiumsupport/knowledge-center/network-throughput-benchmark-linux-ec2/) する: インスタンスが同じ VPC 内にある場合、EC2 ネットワークパフォーマンスに影響する可能性のあるいくつかの要因。同じ VPC 内で 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 (NET317-R1) ](https://www.youtube.com/watch?v=eqW6CPb58gs) + [Optimizing Network Performance for Amazon EC2 Instances (CMP308-R1) ](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/) # PERF05-BP02 使用可能なネットワーク機能を評価する パフォーマンスの向上に役立つ可能性のあるクラウドのネットワーク機能を評価します。これらの機能の影響を、テスト、メトリクス、および分析を使って測定してください。たとえば、レイテンシー、パケット損失、ジッターを低減するために利用可能なネットワークレベルの機能を活用することができます。 多くのサービスはパフォーマンスを向上させるために作成され、他のサービスはネットワークパフォーマンスを最適化するための機能を提供するのが一般的です。AWS Global Accelerator および Amazon CloudFront などのサービスは、パフォーマンスの向上のために用意されています。一方、ほとんどの他のサービスには、ネットワークトラフィックを最適化するという製品機能があります。ワークロードのパフォーマンス向上のために、EC2 インスタンスネットワーク機能、拡張ネットワーキングインスタンスタイプ、Amazon EBS 対応インスタンス、Amazon S3 Transfer Acceleration、および CloudFront などのサービス機能を確認してください。 **期待される成果:** ワークロード内のコンポーネントのインベントリを文書化し、コンポーネントごとにどのネットワーク構成がパフォーマンス要件を満たすのに役立つかを特定しました。ネットワーク機能を評価した後で、パフォーマンスメトリクスを実験および測定し、利用可能な機能をどのように使用するかを確認しました。。 **一般的なアンチパターン:** + エンドユーザーに近い AWS リージョン ではなく、本社に最も近い AWS リージョン にワークロードを配置する。 + ワークロードパフォーマンスのベンチマークや、ベンチマークに対する継続的なワークロードパローマンスの評価に失敗する。 + パフォーマンス改善オプションのサービス設定を確認しない。 **このベストプラクティスを活用するメリット:** すべてのサービス機能とオプションを評価することにより、ワークロードパローマンスを向上させ、インフラストラクチャのコストを削減し、ワークロードを維持するために必要な労力を減らし、全体的なセキュリティ体制を強化できます。グローバルな AWS のバックボーンを活用すれば、最適なネットワークエクスペリエンスをお客様に提供することができます。 **このベストプラクティスを活用しない場合のリスクレベル:** 高 ## 実装のガイダンス ネットワーク関連の設定オプションにはどのようなものがあるか、またそれらがワークロードにどのような影響を与えるかを確認します。これらのオプションがアーキテクチャとどのように相互作用し、測定されたパフォーマンスとユーザーが認識するパフォーマンスの両方に与える影響を理解することは、パフォーマンスの最適化にとって非常に重要です。 **実装手順:** 1. ワークロードコンポーネントのリストを作成します。 1. 組織のネットワークを [AWS クラウド WAN を使用して](https://aws.amazon.com/cloud-wan/)構築、管理、モニタリングします。 1. ネットワークを可視化するために [Network Manager](https://docs.aws.amazon.com/vpc/latest/tgwnm/what-is-network-manager.html) を使用します。既存の設定管理データベース (CMDB) ツール ( [AWS Config](https://aws.amazon.com/config/) など) を使用して、ワークロードや設定方法のインベントリを作成します。 1. これが既存のワークロードである場合、ボトルネックや改善すべき領域に特化して、パフォーマンスメトリクスのベンチマークを特定し、文書化します。パフォーマンスに関連するネットワークメトリクスは、ビジネス要件やワークロード特性により、ワークロードごとに異なります。最初のうちは、帯域幅、レイテンシー、パケットロス、ジッター、再送信などのメトリックスを確認することが重要かもしれません。 1. これが新しいワークロードである場合は、 [負荷テスト](https://aws.amazon.com/solutions/implementations/distributed-load-testing-on-aws/) を実施して、パフォーマンスのボトルネックを特定します。 1. 特定したパフォーマンスのボトルネックに対して、ソリューションの設定オプションを確認し、パフォーマンス改善の機会を見つけます。 1. ネットワークパスやルートが分からない場合は、 [Network Access Analyzer](https://docs.aws.amazon.com/vpc/latest/network-access-analyzer/what-is-vaa.html) を使用して特定します。 1. ネットワークプロトコルを確認して、さらにレイテンシーを減らします。 + [PERF05-BP05 パフォーマンスを高めるネットワークプロトコルを選択する](perf_select_network_protocols.md) 1. 複数のロケーションで AWS Site-to-Site VPN を使用して AWS リージョン に接続している場合は、 [高速 Site-to-Site VPN 接続](https://docs.aws.amazon.com/vpn/latest/s2svpn/accelerated-vpn.html) を確認して、ネットワークパフォーマンス向上のための機会を調べます。 1. ワークロードトラフィックが複数のアカウントにまたがっている場合は、ネットワークトポロジとサービスを評価して、レイテンシーを削減します。 + 複数のアカウントに接続する際は、 [VPC ピアリング](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html) と [AWS Transit Gateway](https://aws.amazon.com/transit-gateway/) 間の、運用とパフォーマンスに関するトレードオフを評価します。AWS Transit Gateway は、AWS Site-to-Site VPN スループットをサポートしており、マルチパスを使用することにより、単一の [最大 IPsec 制限](https://aws.amazon.com/blogs/networking-and-content-delivery/scaling-vpn-throughput-using-aws-transit-gateway/) を超えてスケーリングします。Amazon VPC と AWS Transit Gateway 間のトラフィックはプライベート AWS ネットワーク上に残り、インターネットには公開されません。AWS Transit Gateway は、数千の AWS アカウント やオンプレミスネットワークにまたがるすべての VPC を相互接続する方法を簡素化します。複数のアカウント間で AWS Transit Gateway を共有するには、 [Resource Access Manager](https://aws.amazon.com/ram/) を使用します。グローバルネットワークトラフィックを可視化するには、 [Network Manager](https://aws.amazon.com/transit-gateway/network-manager/) を使用してネットワークメトリクスを一元的に把握することができます。 1. ユーザーロケーションを確認し、ユーザーとワークロードとの間の距離を最短化します。 1. [AWS Global Accelerator](https://aws.amazon.com/global-accelerator/) は、Amazon Web Services グローバルネットワークインフラストラクチャを使用して、ユーザーのトラフィックのパフォーマンスを最大 60% まで向上するネットワークサービスです。インターネットが混雑している際には、AWS Global Accelerator は、アプリケーションへのパスを最適化して、パケット損失、ジッター、レイテンシーを一貫して低く保ちます。また、静的な IP アドレスを提供するため、DNS 設定の更新やクライアント向けアプリケーションの変更なしに、アベイラビリティゾーンや AWS リージョン 間でエンドポイントを簡単に移動させることができます。 1. [Amazon CloudFront](https://aws.amazon.com/cloudfront/) を利用することで、ワークロードのコンテンツ配信のパフォーマンスとレイテンシーをグローバルに向上させることができます。CloudFront は 410 以上のグローバルに分散したプレゼンスポイントがあり、コンテンツをキャッシュし、エンドユーザーに対してレイテンシーを減らすことができます。 1. Amazon Route 53 では、 [レイテンシーベースルーティング](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy-latency.html)、[位置情報ルーティング](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy-geo.html)、[地理的近接性ルーティング](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy-geoproximity.html)、および [IP ベースルーティング](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy-ipbased.html) のオプションを提供しており、全世界ユーザーに対するワークロードのパフォーマンスを向上することができます。ワークロードトラフィックとユーザーロケーションを確認することにより、どのルーティングオプションによってワークロードパフォーマンスが最適化されるかを特定します。 1. 追加の Amazon S3 機能を評価してストレージ IOP を改善します。 1. [Amazon S3 Transfer Acceleration](https://aws.amazon.com/s3/transfer-acceleration/) により、外部ユーザーは、Amazon S3 にデータをアップロードする際に CloudFront のネットワーク最適化機能のメリットを享受できます。これにより、AWS クラウド への専用接続がないリモートロケーションから大量のデータを転送する機能が向上します。 1. [Amazon S3 マルチリージョンアクセスポイント](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiRegionAccessPoints.html) は、1 つのアクセスポイントを提供することにより、複数のリージョンへコンテンツをレプリケートし、ワークロードを簡素化します。マルチリージョンアクセスポイントが使用されている場合、低レイテンシーバケットを特定するサービスによって、データを要求したり Amazon S3 に書き込むことができます。 1. コンピューティングリソースのネットワーク帯域幅を確認します。 1. EC2 インスタンス、コンテナ、および Lambda 機能が使用する Elastic Network Adapters (ENA) は、フロ―単位で制限されています。プレイスメントグループを見直して、 [EC2 ネットワークスループット](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-network-bandwidth.html)を最適化します。フロー単位でのボトルネックを避けるために、複数フローを使用できるようアプリケーションを設計します。コンピューティング関連のネットワークメトリクスをモニタリングおよび可視化するために、 [CloudWatch Metrics](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-instance-network-bandwidth.html) と [https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-network-performance-ena.html](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-network-performance-ena.html) を使用します。`ethtool` は ENA ドライバーに含まれており、追加のネットワーク関連のメトリクスを公開します。これらは、 [カスタムメトリクス](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) として CloudWatch に発行できます。 1. 新しい EC2 インスタンスでは、拡張ネットワーキングを利用できます。[N シリーズの EC2 インスタンス](https://aws.amazon.com/ec2/nitro/)( `M5n` と `M5dn` など) は、第 4 世代カスタム Nitro Card を活用して、最大 100 Gbps のネットワークスループットを 1 つのインスタンスに配信します。これらのインスタンスは 4 倍のネットワーク帯域幅とパケットプロセスを提供するため、ベース `M5` インスタンスと比べて、ネットワーク集約型のアプリケーションに最適です。 1. [Amazon Elastic Network Adapters](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/enhanced-networking-ena.html) (ENA) は、インスタンスに対してより良いスループットを [クラスタープレイスメントグループ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html#placement-groups-cluster%23placement-groups-limitations-cluster)内で提供することにより、さらなる最適化をもたらします。 1. [Elastic Fabric Adapter](https://aws.amazon.com/hpc/efa/) (EFA) は、高いレベルのインターノードコミュニケーションを AWS で大規模に要求するワークロードの実行を可能にする、Amazon EC2 インスタンスのネットワークインターフェイスです。EFA では、メッセージパッシングインターフェイス (MPI) を使用するハイパフォーマンスコンピューティング (HPC) アプリケーションと、NVIDIA Collective Communications Library (NCCL) を使用する機械学習 (ML) アプリケーションを、数千個に及ぶ CPU または GPU にスケールできます。 1. [Amazon EBS 最適化](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-optimized.html) インスタンスは、最適化された設定スタックを使用し、Amazon EBS I/O を増加させるために専用の追加容量を提供します。この最適化により、Amazon EBS I/O とインスタンスからのその他のトラフィック間の競合を最小限に抑えることで、EBS ボリュームで最良のパフォーマンスを実現します。 **実装計画に必要な工数レベル: ** このベストプラクティスを確立するには、ネットワークパフォーマンスに影響を与える現在のワークロードコンポーネントのオプションを把握している必要があります。コンポーネントの収集、ネットワーク改善オプションの評価、実験、実装、およびこれらの改善の文書化には、 *低* ～ *中* 程度の工数が必要です。 ## リソース **関連ドキュメント:** + [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) + [Amazon EC2 インスタンスのネットワーク帯域幅](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-network-bandwidth.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) + [クラウド CMDB の構築](https://aws.amazon.com/blogs/mt/building-a-cloud-cmdb-on-aws-for-consistent-resource-configuration-in-hybrid-environments/) + [AWS Transit Gateway を使用したVPN スループットのスケーリング](https://aws.amazon.com/blogs/networking-and-content-delivery/scaling-vpn-throughput-using-aws-transit-gateway/) **関連動画:** + [Connectivity to AWS and hybrid AWS network architectures (NET317-R1)](https://www.youtube.com/watch?v=eqW6CPb58gs) + [Optimizing Network Performance for Amazon EC2 Instances (CMP308-R1)](https://www.youtube.com/watch?v=DWiwuYtIgu0) + [AWS Global Accelerator](https://www.youtube.com/watch?v=lAOhr-5Urfk) **関連する例:** + [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/) # PERF05-BP03 ハイブリッドワークロード用に適切なサイズの専用接続または VPN を選択する AWS でオンプレミスのリソースとクラウドのリソースを接続するために一般的なネットワークが必要な場合は、パフォーマンス要件を満たす十分な帯域幅があることを確認します。ハイブリッドワークロードについては、帯域幅とレイテンシー要件を推定します。これらの数値によって、接続オプションのサイジング要件が決まります。 **期待される成果:** ハイブリッドネットワーキングを必要とするワークロードをデプロイする場合、専用接続や仮想プライベートネットワーク (VPN) などの複数の接続設定オプションがあります。各ワークロードに適切な接続タイプを選択し、ロケーションとクラウドの間に十分な帯域幅と暗号化要件への準拠を確保します。 **一般的なアンチパターン:** + ワークロードのすべての要件 (帯域幅、レイテンシー、ジッター、暗号化、トラフィックのニーズ) を理解または特定できていない。 + バックアップ接続または並列接続のオプションを評価しない。 **このベストプラクティスを活用するメリット:** 適切にサイジングされたハイブリッドネットワークソリューションを選択し、設定することで、ワークロードの信頼性を高め、パフォーマンス改善の機会を最大限に増やすことができます。ワークロード要件を特定して前もって計画し、ハイブリッドソリューションを評価することで、市場投入までの時間を短縮しながら、コストの高いネットワークの物理的変更と運用上の諸経費を最小限に抑えることができます。 **このベストプラクティスが確立されていない場合のリスクレベル:** 高 ## 実装のガイダンス 帯域幅要件に基づいてハイブリッドネットワーキングアーキテクチャを開発します。ハイブリッドアプリケーションの帯域幅とレイテンシー要件を見積もります。専用ネットワーク接続またはインターネットベースの VPN を使用する適切な接続オプションを検討します。 専用接続は、専用回線を介してネットワーク接続を確立し、一貫性あるパフォーマンスを達成しながら、高帯域幅、低レイテンシーが求められる場合に適しています。VPN 接続は、インターネット上で安全な接続を確立し、既存のインターネット接続を使用して暗号化した接続が必要となる場合に適しています。 帯域幅の要件によっては、単一の VPN 接続や専用接続では十分でない場合があります。また、複数の接続間におけるトラフィックの負荷分散を有効にするハイブリッドセットアップを設計する必要があります。 **実装手順** 1. ハイブリッドアプリケーションの帯域幅とレイテンシー要件を見積もります。 1. AWS に移行している既存のアプリケーションについては、内部ネットワークモニタリングシステムからのデータを活用します。 1. モニタリングデータがない新しいアプリケーションまたは既存のアプリケーションについては、プロダクトオーナーと相談のうえ、適切なパフォーマンスメトリクスを導き出し、優れたユーザーエクスペリエンスを提供します。 1. 接続オプションとして専用接続または VPN 接続を選択します。すべてのワークロード要件 (暗号化、帯域幅、トラフィックのニーズ) に基づいて、AWS Direct Connect か AWS Site-to-Site VPN (またはその両方) を選択できます。下の図は、適切な接続タイプの選択に役立ちます。 1. 専用接続を検討する場合は、AWS Direct Connect が必要になる場合があります。AWS Direct Connect のプライベートネットワーク接続を使用すると、パフォーマンスの予測可能性と一貫性が向上します。AWS Direct Connect は、専用接続またはホスト接続のいずれかを使用して、50 Mbps から最大 100 Gbps までの AWS 環境への専用接続を提供します。これにより、管理および制御されたレイテンシーとプロビジョニングされた帯域幅が提供され、ワークロードが効率の良い方法でその他の環境に接続できます。AWS Direct Connect パートナーを使用すると、複数の環境からエンドツーエンドの接続を確立し、一貫性あるパフォーマンスで拡張ネットワークを実現できます。AWS を使用すると、ネイティブ 100 Gbps、Link Aggregation Group (LAG)、または BGP Equal-cost multipath (ECMP) のいずれかを使用して、直接接続の帯域幅をスケーリングできます。 1. VPN 接続を検討する場合は、AWS マネージド VPNのオプションをお勧めします。AWS Site-to-Site VPN は、インターネットプロトコルセキュリティ (IPsec) をサポートするマネージド VPN サービスを提供します。VPN 接続が作成されると、高可用性に向けて 各 VPN 接続に 2 つのトンネルが含まれています。AWS Transit Gateway を使用すると、複数の VPC 間の接続を簡素化し、単一の VPN 接続で AWS Transit Gateway にアタッチされた任意の VPC に接続できます。AWS Transit Gateway を使用すると、複数の VPN トンネルでの等コストマルチパス (ECMP) ルーティングサポートを有効化して、1.25Gbps の IPsec VPN スループット制限以上の拡張もできます。 ![\[ネットワークで決定論的なパフォーマンスが必要かどうかを判断する際に考慮すべきオプションを説明するフローチャート。\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2023-04-10/framework/images/deterministic-performance-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) + [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) + [AWS Site-to-Site VPN](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html) + [Building a Scalable and Secure Multi-VPC AWS Network Infrastructure](https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/welcome.html) (スケーラブルで安全なマルチ VPC AWS ネットワークインフラストラクチャの構築) + [AWS 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 (NET317-R1) ](https://www.youtube.com/watch?v=eqW6CPb58gs)(AWS への接続性とハイブリッド AWS EC2 ネットワークアーキテクチャ (NET317-R1)) + [Optimizing Network Performance for Amazon EC2 Instances (CMP308-R1) ](https://www.youtube.com/watch?v=DWiwuYtIgu0)(Amazon EC2 インスタンスのネットワークパフォーマンス最適化 (CMP308-R1)) + [AWS Global Accelerator](https://www.youtube.com/watch?v=lAOhr-5Urfk) + [AWS Direct Connect](https://www.youtube.com/watch?v=DXFooR95BYc&t=6s) + [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 Transit Gateway とスケーラブルなセキュリティソリューション) + [AWS Networking Workshops](https://networking.workshop.aws/) (AWS ネットワーキングワークショップ) # PERF05-BP04 ロードバランシングと暗号化のオフロードを活用する ロードバランサーを使用して、ターゲットリソースの最適なパフォーマンス効率を実現し、システムの応答性を向上します。 **期待される成果:** トラフィックを処理するコンピューティングリソースの数を低減します。ターゲットにおけるリソース消費の不均衡を回避します。高度なコンピューティング集約型タスクをロードバランサーにオフロードします。クラウドの伸縮性と柔軟性を活用して、パフォーマンスを向上し、アーキテクチャを最適化します。 **一般的なアンチパターン:** + ロードバランサーの種類を選択する際にワークロードの要件を考慮していない。 + パフォーマンスの最適化のためにロードバランサー機能を活用していない。 + ロードバランサーを介さずにワークロードをインターネットに直接公開している。 **このベストプラクティスが確立されていない場合のリスクレベル:** 高 ## 実装のガイダンス ロードバランサーは、ワークロードのエントリポイントとして機能し、そこからコンピューティングインスタンスやコンテナなどのバックエンドターゲットにトラフィックを分散します。適切なロードバランサーの種類を選択することが、アーキテクチャを最適化するうえでの最初のステップとなります。 まず、プロトコル (TCP、HTTP、TLS、または WebSocket など)、ターゲットの種類 (インスタンス、コンテナ、またはサーバーレスなど)、アプリケーション要件 (長時間実行される接続、ユーザー認証、またはスティッキーなど) や配置 (リージョン、ローカルゾーン、アウトポスト、ゾーン分離など) のワークロードの特性をリストアップすることから始めます。 適切なロードバランサーを選択したら、ロードバランサーの機能を活用して、バックエンドが必要とするトラフィック処理のための労力を削減できます。 例えば、Application Load Balancer (ALB) と Network Load Balancer (NLB) の両方を使用して、SSL/TLS 暗号化オフロードを実行できます。これにより、CPU 負荷が高い TLS ハンドシェイクのターゲットによる終了を回避して、証明書管理を改善する機会が得られます。 ロードバランサーで SSL/TLS オフロードを設定すると、暗号化されていないトラフィックをバックエンドに配信すると同時に、クライアントとの間のトラフィックの暗号化の役目を果たすため、バックエンドリソースが解放され、クライアントにとっての応答時間が改善されます。 Application Load Balancer は、ターゲットでのサポートを必要とせずに HTTP2 トラフィックを処理することもできます。このようなシンプルな決断をすることで、HTTP2 は TCP 接続をより効率的に使用するようになり、アプリケーションの応答時間を改善できます。 ロードバランサーを使用すると、コンテナやサーバーレスなどのさまざまな種類のバックエンドにトラフィックを分散させて、アーキテクチャの柔軟性を向上することもできます。例えば、ヘッダー、メソッド、パターンなどのリクエストパラメータに基づいてトラフィックをさまざまなターゲットグループに転送する[リスナールール](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/listener-update-rules.html)を使用するように Application Load Balancer を設定できます。 アーキテクチャを定義する際は、ワークロードのレイテンシー要件を考慮する必要もあります。例えば、レイテンシーの影響を受けやすいアプリケーションがある場合、非常に低レイテンシーを実現する Network Load Balancer を使用するよう決定することができます。または、[AWS Local Zones](https://aws.amazon.com/about-aws/global-infrastructure/localzones/)、あるいは [AWS Outposts](https://aws.amazon.com/outposts/rack/) で Application Load Balancer を活用して、ワークロードをより顧客の近くに配置する方法を採用することもできます。 レイテンシーの影響を受けやすいワークロードに関して考慮すべきもう 1 つの点は、クロスゾーン負荷分散です。クロスゾーン負荷分散を使用すると、各ロードバランサーノードはトラフィックを有効化されたすべてのアベイラビリティーゾーン内の登録済みターゲットにトラフィックを分散します。これにより、ラウンドトリップのレイテンシーが 1 桁ミリ秒単位で増加する場合があるとはいえ、可用性が改善します。 最後に、ALB と NLB の両方により、ログやメトリクスなどのモニタリングリソースが提供されます。モニタリングを適切に設定すると、アプリケーションのパフォーマンスに関するインサイトの収集に役立ちます。例えば、ALB アクセスログを使用して、他のものより応答時間がかかるリクエストや、パフォーマンスの問題を引き起こしているバックエンドターゲットを検出できます。 **実装手順** 1. ワークロードに適したロードバランサーを選択します。 1. HTTP/HTTPS のワークロードには、Application Load Balancer を使用します。 1. TCP または UDP で実行される HTTP 以外のワークロードには、Network Load Balancer を使用します。 1. 両方の製品の機能を活用したい場合は、両方を組み合わせて ([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) に公開する場合に使用します。 1. すべてのロードバランサー製品の比較については、「[ELB の製品の比較](https://aws.amazon.com/elasticloadbalancing/features/)」を参照してください。 1. SSL/TLS オフロードを使用します。 1. [AWS Certificate Manager](https://aws.amazon.com/certificate-manager/) と統合された [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) の両方で HTTPS/TLS リスナーを設定します。 1. ワークロードによっては、コンプライアンス上の理由で、エンドツーエンドの暗号化が必要になる場合があることに注意します。この場合は、ターゲットで暗号化を有効にする必要があります。 1. セキュリティのベストプラクティスについては、「[SEC09-BP02 伝送中に暗号化を適用する](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_protect_data_transit_encrypt.html)」を参照してください。 1. 適切なルーティングアルゴリズムを選択します。 1. ルーティングアルゴリズムは、バックエンドターゲットの使用状況に変化をもたらし、パフォーマンスへの影響を左右します。例えば、ALB には、以下の[2 つのルーティングアルゴリズムのオプション](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-target-groups.html#modify-routing-algorithm)があります。 1. **最小未処理リクエスト:** アプリケーションのリクエストの複雑性が異なる場合や、ターゲットの処理能力が異なる場合に、バックエンドターゲットへのロードバランシングを改善するために使用します。 1. **ラウンドロビン:** リクエストとターゲットが同様の場合、またはリクエストをターゲット間で均等に分散する必要がある場合に使用します。 1. クロスゾーンまたはゾーン分離を検討します。 1. レイテンシーの改善とゾーンの障害ドメイン対策として、クロスゾーンをオフ (ゾーン分離) で使用します。NLB ではデフォルトでオフになっていますが、[ALB ではターゲットグループごとにオフに設定できます](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/disable-cross-zone.html)。 1. 可用性と柔軟性の向上のためには、クロスゾーンをオンにします。ALB ではデフォルトでクロスゾーンはオンになっています。[NLB ではターゲットグループごとにオフに設定できます](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/target-group-cross-zone.html)。 1. HTTP ワークロードの HTTP キープアライブをオンにします。 1. HTTP ワークロードの場合、バックエンドターゲットのウェブサーバー設定で HTTP キープアライブをオンにします。この機能にを使用すると、ロードバランサーはキープアライブタイムアウトが期限切れになるまでバックエンド接続を再利用できるため、HTTP リクエストと応答時間が改善され、バックエンドターゲットでのリソース使用率も低減します。Apache と Nginx でこれを実行する方法の詳細については、「[ELB のバックエンドサーバーとして Apache または NGINX を使用するための最適な設定を教えてください。](https://aws.amazon.com/premiumsupport/knowledge-center/apache-backend-elb/)」を参照してください。 1. コンピューティングリソースのオーケストレーションを改善するには、Elastic Load Balancing 統合を使用します。 1. ロードバランサーと統合された Auto Scaling を使用します。パフォーマンス効率に優れたシステムの重要な側面の 1 つに、バックエンドリソースのサイズの適切な設定があります。これを実現するには、バックエンドターゲットリソースのロードバランサー統合を利用できます。Auto Scaling グループと統合したロードバランサーを使用することで、受信トラフィックに対応して、必要に応じてターゲットがロードバランサーに追加されたり削除されたりします。 1. コンテナ化されたワークロードには、ロードバランサーを Amazon ECS および Amazon EKS と統合できます。 + [Auto Scaling グループ内のインスタンス全体にトラフィックを分散するには、Elastic Load Balancing を使用します](https://docs.aws.amazon.com/autoscaling/ec2/userguide/autoscaling-load-balancer.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) 1. ロードバランサーをモニタリングして、パフォーマンスのボトルネックを検出します。 1. [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) のアクセスログを有効にします。 1. ALB の場合に考慮すべき主なフィールドは以下のとおりです。 `request_processing_time`、`request_processing_time`、 `response_processing_time`. 1. NLB の場合に考慮すべき主なフィールドは以下のとおりです。 `connection_time` および `tls_handshake_time`. 1. 必要な際にログをクエリできるように準備を整えておきます。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)の両方をクエリできます。 1. [ALB の`TargetResponseTime`](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html) などのパフォーマンス関連メトリクスのアラームを作成します。 ## リソース **関連するベストプラクティス:** + [SEC09-BP02 伝送中に暗号化を適用する](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_protect_data_transit_encrypt.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)(Amazon Athena を使用したログ分析の詳しい手順) + [Application Load Balancer ログのクエリ](https://docs.aws.amazon.com/athena/latest/ug/application-load-balancer-logs.html) + [Application Load Balancer を監視する](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) **関連動画:** + [AWS re:Invent 2018: [REPEAT 1] Elastic Load Balancing: Deep Dive and Best Practices (NET404-R1) ](https://www.youtube.com/watch?v=VIgAT7vjol8)(AWS re:Invent 2018: [リピート 1] Elastic Load Balancing: ディープダイブとベストプラクティス (NET404-R1)) + [AWS re:Invent 2021 - How to choose the right load balancer for your AWS workloads ](https://www.youtube.com/watch?v=p0YZBF03r5A)(AWS re:Invent 2021 - AWS のワークロードに適切なロードバランサーを選択する方法) + [AWS re:Inforce 2022 - How to use Elastic Load Balancing to enhance your security posture at scale (NIS203) ](https://www.youtube.com/watch?v=YhNc5VSzOGQ)(AWS re:Inforce 2022 - セキュリティ体制の大規模な強化のために Elastic Load Balancing を使用する方法 (NIS203)) + [AWS re:Invent 2019: Get the most from Elastic Load Balancing for different workloads (NET407-R2) ](https://www.youtube.com/watch?v=HKh54BkaOK0)(AWS re:Invent 2019: さまざまなワークロードに Elastic Load Balancing を最大限に活用する (NET407-R2)) **関連する例:** + [ 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) (Amazon Athena を使用したログ分析の CDK とCloudFormation の例) # PERF05-BP05 パフォーマンスを高めるネットワークプロトコルを選択する ワークロードのパフォーマンス要件を評価し、ワークロードの全体的なパフォーマンスを最適化するネットワークプロトコルを選択します。 スループットの達成には、レイテンシーと帯域幅間の関係が関与します。例えば、ファイル転送で Transmission Control Protocol (TCP) を使用している場合は、高レイテンシーが全体的なスループットを低下させます。これを修正するアプローチには、TCP チューニングと最適化された転送プロトコルを使うものや、User Datagram Protocol (UDP) を使用するものもあります。 [Scalable reliable datagram (SRD)](https://ieeexplore.ieee.org/document/9167399) プロトコルは、Elastic Fabric Adapter 向けに AWS が構築したネットワークトランスポートプロトコルであり、信頼性に優れたデータグラム配信を実現します。TCP プロトコルとは異なり、SRD はパケットを並べ替えて、順不同で配信できます。SRD によるこの順不同の配信メカニズムは、代替パス経由でパケットを並行送信して、スループットを向上します。 **一般的なアンチパターン:** + パフォーマンス要件を問わず、すべてのワークロードに TCP を使用している。 **このベストプラクティスを活用するメリット:** + ワークロードコンポーネント間の通信に適切なプロトコルを選択すると、そのワークロードに対して最高のパフォーマンスを得ることができます。 + ユーザーとワークロードコンポーネント間の通信に適切なプロトコルが使用されていることを確認すると、アプリケーションのユーザーエクスペリエンスが全体的に向上します。例えば、TCP と UDP の両方を組み合わせて使用すると、VDI ワークロードは、重要なデータには TCP の信頼性、リアルタイムデータには UDP の速度を利用できます。 **このベストプラクティスが確立されていない場合のリスクレベル:**中 (適切でないネットワークプロトコルを使用すると、応答時間の遅延、高レイテンシー、貧弱なスケーラビリティなどのパフォーマンスの低下につながる可能性があります) ## 実装のガイダンス レイテンシーとスループットの要件を理解し、パフォーマンスを最適化するネットワークプロトコルを選択することが、ワークロードのパフォーマンスを向上するうえで重要となる考慮事項です。 **TCP の使用を検討するべきケース** TCP は信頼性に優れたデータ配信を提供し、データの信頼性と確実な配信が重要となるワークロードのコンポーネント間の通信に利用できます。多くのウェブベースのアプリケーションは、AWS 上のサーバーとの通信で TCP ソケットを開くうえで、HTTP や HTTPS などの TCP ベースのプロトコルを基盤としています。TCP にはデータ交換の速度とネットワークの輻輳を制御する機能があるため、E メールとファイルデータ転送も、TCP を利用する一般的なアプリケーションです。TCP で TLS を使用すると、通信に多少のオーバーヘッドが追加されるため、レイテンシーが増加し、スループットが低下する場合があります。このオーバーヘッドは主にハンドシェークプロセスの追加オーバーヘッドにより発生し、完了するまでに数回のラウンドトリップが必要になる場合があります。ハンドシェイクが完了すると、データの暗号化と復号化のオーバーヘッドは比較的少なくなります。 **UDP の使用を検討するべきケース** UDP はコネクションレス型のプロトコルであるため、ログ、モニタリング、VoIP データなどの、高速かつ効率的な転送が必要なアプリケーションに適しています。また、多数のクライアントからの小型のクエリに対応するワークロードのコンポーネントがある場合は、ワークロードの最適なパフォーマンスを確保するために UDP の使用を検討します。UDP では、Datagram Transport Layer Security (DTLS) が 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 を使用すると、暗号化と復号化の影響により、レイテンシーが増大し、ワークロードのスループットが低下する可能性があります。このようなワークロードの場合、バックエンドインスタンスではなく、ロードバランサーで SSL/TLS 暗号化および復号化プロセスの処理を行ってワークロードのパフォーマンスを向上させるために、[Elastic Load Balancing](https://aws.amazon.com/elasticloadbalancing/) での 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 インスタンス間のネットワークトラフィックでシングルフロー帯域幅を増大し (25Gbps)、テールレイテンシーを短縮して (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/) + [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 (NET317-R1)](https://www.youtube.com/watch?v=eqW6CPb58gs) (AWS ネットワークアーキテクチャとハイブリッド AWS ネットワークアーキテクチャへの接続性 (NET317-R1)) + [Optimizing Network Performance for Amazon EC2 Instances (CMP308-R1) ](https://www.youtube.com/watch?v=DWiwuYtIgu0)(Amazon EC2 インスタンスのネットワークパフォーマンス最適化 (CMP308-R1)) + [ Tuning Your Cloud: Improve Global Network Performance for Application ](https://www.youtube.com/watch?v=00ukhVcgWrs)(クラウドのチューニング: アプリケーションのグローバルネットワークパフォーマンスの向上) + [ Application Scaling with EFA and SRD ](https://pages.awscloud.com/HPC-Application-Scaling-with-Elastic-Fabric-Adapter-EFA-and-Scalable-Reliable-Datagram-SRD_2020_0004-CMP_OD.html)(EFA と SRD を使用したアプリケーションのスケーリング) **関連する例:** + [AWS Transit Gateway and Scalable Security Solutions](https://github.com/aws-samples/aws-transit-gateway-and-scalable-security-solutions) (AWS Transit Gateway とスケーラブルなセキュリティソリューション) + [AWS Networking Workshops](https://networking.workshop.aws/) (AWS ネットワーキングワークショップ) # PERF05-BP06 ネットワーク要件に基づいてワークロードのロケーションを選択する ネットワークのレイテンシー短縮、スループット向上、ページの読み込み時間とデータ転送時間の短縮による最適なユーザーエクスペリエンス提供に向けて、リソースプレイスメントのオプションを評価します。 **このベストプラクティスが確立されていない場合のリスクレベル:** ミディアム ## 実装のガイダンス 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 グローバルネットワークを介してユーザーにワークロードへの最適なパスを提供することにより、ネットワークパフォーマンス向上のために利用できます。 **実装手順** 1. 以下の主な要素に基づいて、デプロイに適切な AWS リージョン (単一または複数) を選択します。 1. **ユーザーの所在地:** ワークロードのユーザーに近いリージョンを選択して、ユーザーがワークロードを使用する際のレイテンシーを低く抑えます。 1. **データの場所:** 大量のデータを使用するアプリケーションでは、レイテンシーがデータ転送の主なボトルネックとなります。アプリケーションコードはできる限りデータに近い場所で実行してください。 1. **その他の制約:** セキュリティおよびコンプライアンスなどの制約を考慮します (例えば、データを保存する場所の要件)。 1. 特定のワークロードについて、コンポーネントが低レイテンシーを必要とする相互に依存する Amazon EC2 インスタンスのグループで構成されている場合は、ワークロードの要件を満たすうえでこのようなインスタンスの配置に影響を及ぼすために、[クラスタープレイスメントグループ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html)の使用を検討します。同じクラスタープレイスメントグループ内のインスタンスでは、TCP/IP トラフィックのフローごとのスループット制限が高くなり、ネットワークで同じ高二分帯域幅セグメントに配置されます。クラスタープレイスメントグループは、ネットワークレイテンシーが低い場合、ネットワークスループットが高い場合、またはその両方の場合にメリットがあるアプリケーションで使用することをお勧めします。 1. 低レイテンシーやデータ常駐要件など、ロケーションに依存するワークロードの場合は、[AWS Local Zones](https://aws.amazon.com/about-aws/global-infrastructure/localzones/) または [AWS Outposts](https://aws.amazon.com/outposts/) を検討します。 1. AWS Local Zones は、コンピューティング、ストレージ、データベース、およびその他の厳選された AWS サービスを人口密集地および産業の中心地の近くに配置するインフラストラクチャのデプロイタイプの 1 つです。 1. AWS Outposts は、ほぼすべてのオンプレミスまたはエッジロケーションで真に一貫性あるハイブリッドエクスペリエンスを実現する AWS インフラストラクチャとサービスを提供するフルマネージドソリューションのファミリーです。 1. 高解像度ライブビデオストリーミング、Hi-Fi 音源、拡張現実および仮想現実 (AR/VR) などのアプリケーションでは、5G デバイス向けに超低レイテンシーが必要です。このようなアプリケーションについては、[AWS Wavelength](https://aws.amazon.com/wavelength/) を検討します。AWS Wavelength は AWS のコンピューティングおよびストレージサービスを 5G ネットワーク内に組み込み、超低レイテンシーアプリケーションの開発、デプロイ、スケーリングのためのモバイルエッジコンピューティングインフラストラクチャを提供します。 1. ユーザーが地理的に分散している場合、コンテンツ配信ネットワーク (CDN) を使用して、グローバルに分散した Points of Presence (PoP) を介してデータを配信することにより、静的ウェブコンテンツおよび動的ウェブコンテンツの配信を高速化できます。CDN は通常、エッジコンピューティング機能も提供して、HTTP ヘッダーの操作や URL の書き換え、エッジにおける大規模なリダイレクトなど、レイテンシーの影響を受けやすいオペレーションを実行します。[Amazon CloudFront](https://aws.amazon.com/cloudfront/) は、静的ウェブコンテンツおよび動的ウェブコンテンツの配信を高速化するウェブサービスです。CloudFront のユースケースには、静的ウェブサイトのコンテンツ配信の高速化、ビデオオンデマンドまたはライブストリーミングビデオの提供などがあります。CloudFront を使用すると、視聴者のコンテンツとエクスペリエンスをカスタマイズして、レイテンシーを短縮することもできます。 1. アプリケーションによっては、最初のバイトのレイテンシーとジッターを低減してスループットを向上することによる、固定エントリポイントまたはより高いパフォーマンスが必要となります。このようなアプリケーションは、エニーキャスト 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 の使用を検討します。 1. アプリケーションまたはユーザーがオンプレミスにある場合は、ネットワークとクラウド間に専用のネットワーク接続を設けると、利点が得られる場合があります。専用のネットワーク接続を使用すると、輻輳が発生したり、待機時間が予期せず増大したりする可能性を低減できます。[AWS Direct Connect](https://aws.amazon.com/directconnect/) を使用すると、ネットワークを直接 AWS に接続してパブリックインターネットをバイパスすることで、アプリケーションのパフォーマンスを向上できます。新しい接続を作成する場合、AWS Direct Connect デリバリーパートナーが提供するホスト接続を選択するか、AWS から専用接続を選択して、世界中の 100 か所を超える AWS Direct Connect ロケーションにデプロイできます。また、AWS の低データ転送速度を使用してネットワークコストを削減したり、オプションでフェイルオーバーのために Site-to-Site VPN を設定したりすることもできます。 1. AWS 内でのリソースへの接続に [Site-to-Site VPN](https://aws.amazon.com/vpn/site-to-site-vpn/) を設定する場合は、オプションでアクセラレーションを有効化できます。高速 Site-to-Site VPN 接続は AWS Global Accelerator を使用して、オンプレミスネットワークからカスタマーゲートウェイデバイスに最も近い AWS エッジロケーションにトラフィックをルーティングします。 1. ワークロードのトラフィックとユーザーの所在地を確認して、ワークロードのパフォーマンスを最適化する DNS ルーティングオプションを特定します。[Amazon Route 53](https://aws.amazon.com/route53) を使用すると、[レイテンシーベースルーティング](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy-latency.html)、[位置情報ルーティング](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy-geo.html)、[地理的近接性ルーティング](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy-geoproximity.html)、[IP ベースルーティング](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy-ipbased.html)オプションを利用して、世界中の視聴者向けにワークロードのパフォーマンスを向上することができます。 1. Route 53 を利用すると、エンドユーザーのクエリレイテンシーを低く抑えることができます。Route 53 は、世界中の DNS サーバーのグローバルエニーキャストネットワークを使用して、ネットワークの状態に応じて最適なロケーションから自動的にクエリに応答する設計です。 ## リソース **関連するベストプラクティス:** + [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 Amazon の再生可能エネルギープロジェクトに近いリージョンと、グリッドの炭素強度が他の場所 (またはリージョン) よりも低く公表されているリージョンを選択する](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/)(AWS Local Zones と AWS Outpost、エッジのワークロードに適したテクノロジーの選択) + [プレイスメントグループ](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/) + [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 Local Zones 説明動画) + [AWS Outposts: Overview and How It Works ](https://www.youtube.com/watch?v=ppG2FFB0mMQ)(AWS Outposts: 概要と仕組み) + [AWS re:Invent 2021 - AWS Outposts: Bringing the AWS experience on premises ](https://www.youtube.com/watch?v=FxVF6A22498)(AWS re:Invent 2021 - AWS Outposts: AWS エクスペリエンスをオンプレミスで実現) + [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 2020: AWS Wavelength: 5G エッジで超低レイテンシーでアプリケーションを実行する) + [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 2022 - AWS Local Zones: 分散エッジ向けアプリケーションの構築) + [AWS re:Invent 2021 - Building low-latency websites with Amazon CloudFront ](https://www.youtube.com/watch?v=9npcOZ1PP_c)(AWS re:Invent 2021 - Amazon CloudFront を使用した低レイテンシーのウェブサイトの構築) + [AWS re:Invent 2022 - Improve performance and availability with AWS Global Accelerator](https://www.youtube.com/watch?v=s5sjsdDC0Lg)(AWS re:Invent 2022 - AWS Global Accelerator を使用してパフォーマンスと可用性を向上する) + [AWS re:Invent 2022 - Build your global wide area network using AWS](https://www.youtube.com/watch?v=flBieylTwvI)(AWS re:Invent 2022 - AWS を使用してグローバルなワイドエリアネットワークを構築) + [AWS re:Invent 2020: Global traffic management with Amazon Route 53 ](https://www.youtube.com/watch?v=E33dA6n9O7I)(AWS re:Invent 2020: Amazon Route 53 を使用したグローバルトラフィック管理) **関連する例:** + [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)(Edge 関数を使用した書き換えとリダイレクトの処理) # PERF05-BP07 メトリクスに基づいてネットワーク設定を最適化する ネットワーク設定が適切でないと、多くの場合、ネットワークのパフォーマンス、効率、およびコストに影響します。一般的なネットワーク環境では、早い段階でデプロイを迅速に完了することが優先され、ネットワークパフォーマンスに関する適切なネットワーク設定が十分に考慮されているとは限りません。ネットワーク設定を最適化するには、まずネットワーク環境に関する可視性とデータが必要です。 ネットワークリソースのパフォーマンスを把握するには、データの収集と分析を行い、ネットワーク設定の最適化に関する十分な情報に基づいた決定を下します。これらの変更の影響を測定して、その影響測定値を将来の意思決定に使用します。 **期待される成果:** メトリクスとネットワークモニタリングツールを使用して、ワークロードの変化に合わせてネットワーク設定を最適化します。クラウドベースのネットワークは迅速に最適化できるため、パフォーマンス効率を維持するためにもネットワークアーキテクチャを時間とともに進化させる必要があります。 **一般的なアンチパターン:** + パフォーマンス関連の問題はすべてアプリケーション関連であると想定している。 + ワークロードをデプロイしたロケーションに近いロケーションからのみ、ネットワークパフォーマンスをテストする。 + ネットワークサービスの設定はすべてデフォルトにしている。 + 十分なキャパシティを提供するためにネットワークリソースを過剰プロビジョニングしている。 **このベストプラクティスを活用するメリット:** AWS ネットワークの必要なメトリクスを収集し、ネットワークモニタリングツールを実装すると、ネットワークパフォーマンスを把握し、ネットワーク設定を最適化できます。 **このベストプラクティスを確立しない場合のリスクレベル:** 中 ## 実装のガイダンス AWS ネットワークリソースの利用方法とネットワーク設定を最適化する方法を理解するには、VPC、サブネット、またはネットワークインターフェイス間のトラフィックをモニタリングすることが重要です。以下のツールを使用すると、トラフィックの使用状況、ネットワークアクセス状況、ログに関する情報を詳細に調査できます。 **実装手順** 1. [Amazon VPC IP Address Manager](https://docs.aws.amazon.com/vpc/latest/ipam/what-it-is-ipam.html) を使用します。AWS とオンプレミスのワークロードの IP アドレスのプランニング、追跡、モニタリングには、IPAM を使用できます。これは、IP アドレスの使用と割り当てを最適化するベストプラクティスです。 1. [VPC フローログ](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html) をオンにします。VPC フローログを使用して、VPC 内のネットワークインターフェイス間で送受信される IP トラフィックに関する詳細をキャプチャします。VPC フローログを使用すると、過度に制限的なセキュリティグループルールや過度に寛容なセキュリティグループルールを診断して、ネットワークインターフェイス間のトラフィックの方向を判断できます。フローログを発行する場合、Vended Logs のデータインジェストとアーカイブ料金が適用されます。 1. [DNS クエリのログ記録](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/query-logs.html)をオンにします。Route 53 が受信するパブリックまたはプライベート DNS クエリに関する情報をログに記録するように Amazon Route 53 を設定できます。DNS ログを使用すると、要求されたドメインまたはサブドメイン、または DNS クエリに応答した Route 53 エッジロケーションを把握したうえで DNS の設定を最適化できます。 1. ネットワークの到達可能性を解析およびデバッグするには、[Reachability Analyzer](https://docs.aws.amazon.com/vpc/latest/reachability/what-is-reachability-analyzer.html) を使用します。Reachability Analyzer は、VPC 内の送信元リソースと宛先リソース間の接続テストを実行できる設定分析ツールです。このツールを使用すると、ネットワーク設定が意図した接続になっているかを確認できます。 1. リソースへのネットワークアクセスを把握するには、[Network Access Analyzer](https://docs.aws.amazon.com/vpc/latest/network-access-analyzer/what-is-network-access-analyzer.html) を使用します。Network Access Analyzer を使用すると、ネットワークのアクセス要件を指定して、指定した要件を満たさない可能性のあるネットワークパスを特定できます。対応するネットワーク設定を最適化すると、ネットワークの状態を理解して検証し、AWS のネットワークがコンプライアンス要件を満たしているかどうかを検証できます。 1. [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) を使用して、ネットワークオプションの適切なメトリクスを有効にします。ワークロードに適したネットワークメトリクスを選択していることを確認します。例えば、VPC Network Address Usage、VPC NAT Gateway、AWS Transit Gateway、VPN tunnel、AWS Network Firewall、Elastic Load Balancing、AWS Direct Connect などのメトリクスを有効にできます。メトリクスの継続的なモニタリングは、ネットワークの状態と使用状況を観測して理解する優れた方法であり、観測に基づいたネットワーク設定の最適化につながります。 **実装計画に必要な工数レベル:** 中 ## リソース **関連するドキュメント:** + [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) + [What is Reachability Analyzer?](https://docs.aws.amazon.com/vpc/latest/reachability/what-is-reachability-analyzer.html) (Reachability Analyzer とは) + [ What is Network Access Analyzer? ](https://docs.aws.amazon.com/vpc/latest/network-access-analyzer/what-is-network-access-analyzer.html)(Network Access Analyzer とは) + [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/)(Apache Parquet 形式の VPC フローログを使用して、ネットワーク分析のパフォーマンスを最適化してコストを削減する) + [Monitoring your global and core networks with Amazon Cloudwatch metrics](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 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 ネットワーキングワークショップ) + [AWS ネットワークモニタリング](https://github.com/aws-samples/monitor-vpc-network-patterns)