# トレードオフ **Topics** + [PERF 8 パフォーマンスを向上させるために、トレードオフをどのように利用すればよいですか?](w2aac19c11c11b5.md) # PERF 8 パフォーマンスを向上させるために、トレードオフをどのように利用すればよいですか? アーキテクチャの設計にあたって、最適なアプローチとなるトレードオフを特定します。多くの場合、整合性、耐久性、および時間とレイテンシーの余裕と引き換えに、パフォーマンスを向上させることができます。 **Topics** + [PERF08-BP01 パフォーマンスが最も重要な分野を理解する](perf_tradeoffs_performance_critical_areas.md) + [PERF08-BP02 設計パターンとサービスについて理解する](perf_tradeoffs_performance_design_patterns.md) + [PERF08-BP03 トレードオフが顧客と効率性にどのように影響するかを明らかにする](perf_tradeoffs_performance_understand_impact.md) + [PERF08-BP04 パフォーマンス向上の影響を測定する](perf_tradeoffs_performance_measure.md) + [PERF08-BP05 さまざまなパフォーマンス関連戦略を使用する](perf_tradeoffs_performance_implement_strategy.md) # PERF08-BP01 パフォーマンスが最も重要な分野を理解する ワークロードのパフォーマンスの向上が効率性やカスタマーエクスペリエンスにプラスの影響を与える分野を理解し、特定します。例えば、カスタマーインタラクションが多いウェブサイトは、エッジサービスを使用してコンテンツ配信をお客様に近い場所へ移動させることでメリットを得ることができます。 **期待される成果:** アーキテクチャ、トラフィックパターン、データアクセスパターンを理解し、レイテンシーと処理時間を特定することで、パフォーマンス効率を高めることができます。ワークロードが増加するにつれて、顧客エクスペリエンスに影響を及ぼす可能性のある潜在的なボトルネックを特定できます。これらの領域を特定したら、デプロイできるソリューションを調査し、パフォーマンスの懸念を取り除きます。 **一般的なアンチパターン:** + パフォーマンスの問題の計測には、 `CPU使用率やメモリ使用率などの` 標準的なコンピューティングメトリクスで十分だと考えている。 + 一部のモニタリングソフトウェアで記録されるデフォルトのメトリクスのみを使用している。 + 問題が発生したときにだけメトリクスを確認している。 **このベストプラクティスを活用するメリット:** パフォーマンスの重要な領域を理解することで、ワークロードの所有者は KPI をモニタリングし、影響の大きいパフォーマンスの改善に優先順位をつけることができます。 **このベストプラクティスが確立されていない場合のリスクレベル:** 高 ## 実装のガイダンス エンドツーエンドの追跡を構築して、トラフィックパターン、レイテンシー、重要なパフォーマンス領域を特定します。データアクセスパターンをモニタリングして、低速なクエリや不十分にフラグメント化されパーティション化されたデータを検出します。負荷テストまたはモニタリングを使用して、ワークロードのボトルネックを特定します。 ## 実装手順 1. エンドツーエンドのモニタリングを構築して、すべてのワークロードコンポーネントおよびメトリクスをキャプチャします。 + Amazon CloudWatch Real-User Monitoring (RUM) を使用して、 [実際のユーザークライアント側およびフロントエンドセッションからの](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html) アプリケーションパフォーマンスメトリクスをキャプチャします。 + AWS X-Ray を設定して、 [アプリケーションレイヤー内のトラフィックを追跡し、](https://aws.amazon.com/xray/) コンポーネントと依存関係間のレイテンシーを特定します。X-Ray サービスマップを使用して、リレーションシップとワークロードコンポーネント間のレイテンシーを確認します。 + Amazon CloudWatch Performance Insightsを使用して、 [データベースパフォーマンスメトリクスを確認し、](https://aws.amazon.com/rds/performance-insights/) パフォーマンスの改善を特定します。 + Amazon RDS 拡張モニタリングを使用して、 [データベース OS の](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html) パフォーマンスメトリクスを確認します。 + ワークロードコンポーネントおよびサービスごとの [CloudWatch メトリクスを収集し、](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) どのメトリクスがパフォーマンスの効率性に影響しているかを特定します。 + Amazon RDS を [を設定して、](https://aws.amazon.com/devops-guru/) パフォーマンスのインサイトとレコメンデーションを追加します。 1. テストを実行してメトリクスを生成し、トラフィックパターン、ボトルネック、および重要なパフォーマンス領域を特定します。 + CloudWatch Synthetic Canaries を設定して、 [cron ジョブを使用したブラウザベースのユーザーアクティビティの](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) プログラム的なシミュレーションや、 `長期にわたる一貫したメトリクスを生成するための` 表現の評価を行います。 + AWS Distributed Load Testing ソリューションを使用して、 [ピークトラフィックの生成や、](https://aws.amazon.com/solutions/implementations/distributed-load-testing-on-aws/) 予想される増加率でのワークロードのテストを行います。 1. メトリクスとテレメトリを評価して、重要なパフォーマンス領域を特定します。これらの領域をチームと一緒にレビューして、モニタリングおよびボトルネックを防ぐためのソリューションについて話し合います。 1. パフォーマンスの改善をテストし、データを使用してこれらの変更を計測します。 + CloudWatch Evidently を使用して、 [新しい改善のテストや](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Evidently.html) ワークロードパフォーマンスへの効果の確認を行います。 **実装計画に必要な工数レベル:** このベストプラクティスを確立するには、エンドツーエンドのメトリクスをレビューし、現在のワークロードパフォーマンスを把握する必要があります。エンドツーエンドのモニタリングの構築および重要なパフォーマンス領域の特定に必要な工数レベルは中程度です。 ## リソース **関連するドキュメント:** + [Amazon Builders’ Library](https://aws.amazon.com/builders-library) + [X-Ray ドキュメント](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html) + [Amazon CloudWatch RUM](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html) + [を設定して、](https://aws.amazon.com/devops-guru/) + [CloudWatch RUM および X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/xray-services-RUM.html) **関連動画:** + [Introducing The Amazon Builders’ Library (DOP328)](https://www.youtube.com/watch?v=sKRdemSirDM) + [Demo of Amazon CloudWatch Synthetics (Amazon CloudWatch Synthetics のデモ)](https://www.youtube.com/watch?v=hF3NM9j-u7I) **関連サンプル:** + [Measure page load time with Amazon CloudWatch Synthetics](https://github.com/aws-samples/amazon-cloudwatch-synthetics-page-performance) + [Amazon CloudWatch RUM Web Client](https://github.com/aws-observability/aws-rum-web) + [X-Ray SDK for Node.js](https://github.com/aws/aws-xray-sdk-node) + [X-Ray SDK for Python](https://github.com/aws/aws-xray-sdk-python) + [X-Ray SDK for Java](https://github.com/aws/aws-xray-sdk-java) + [X-Ray SDK for .Net](https://github.com/aws/aws-xray-sdk-dotnet) + [X-Ray SDK for Ruby](https://github.com/aws/aws-xray-sdk-ruby) + [X-Ray Daemon](https://github.com/aws/aws-xray-daemon) + [AWS での分散負荷テスト](https://aws.amazon.com/solutions/implementations/distributed-load-testing-on-aws/) # PERF08-BP02 設計パターンとサービスについて理解する ワークロードのパフォーマンスの向上に役立つさまざまな設計パターンとサービスについて調査し、理解します。分析の一環として、より優れたパフォーマンスを達成するために何を引き替えにすることができるかを特定します。例えば、キャッシュサービスを使用することで、データベースシステムにかかる負荷を軽減できます。しかし、キャッシュは最終的な一貫性をもたらす可能性があり、ビジネス要件と顧客の期待の範囲内で実装するためにはエンジニアリングの労力が必要です。 **期待される成果:** 設計パターンを研究することは、最高のパフォーマンスを発揮するシステムを支えるアーキテクチャ設計を選択することにつながります。どのようなパフォーマンス設定オプションが利用できるか、およびそれらがワークロードにどのように影響し得るかについて学んでください。ワークロードのパフォーマンスを最適化するには、これらのオプションがアーキテクチャとどのように相互作用し、測定されたパフォーマンスとエンドユーザーが知覚するパフォーマンスの両方に影響を与えるかを理解することに依存します。 **一般的なアンチパターン:** + 従来のすべての IT ワークロードパフォーマンス戦略がクラウドワークロードに最適であると考えている。 + マネージドサービスを使用するのではなく、キャッシュソリューションを構築および管理する。 + どのパターンがワークロードのパフォーマンスを向上させるかを評価することなく、すべてのワークロードに同じデザインパターンを使用する。 **このベストプラクティスを活用するメリット:** ワークロードに適した設計パターンとサービスを選択することで、パフォーマンスを最適化し、運用性を向上させ、信頼性を高めることができます。適切な設計パターンは、現在のワークロード特性に適合し、将来の成長や変化に応じたスケールを容易にします。 **このベストプラクティスを活用しない場合のリスクレベル:** 高 ## 実装のガイダンス どのようなパフォーマンス設定オプションが利用できるか、およびそれらがワークロードにどのように影響し得るかについて学びます。ワークロードパフォーマンスの最適化は、これらのオプションがアーキテクチャとどのように相互作用するか、および実測パフォーマンスとユーザーが認識するパフォーマンスに及ぶ影響を理解することにかかっています。 **実装手順:** 1. ワークロードのパフォーマンスを向上させるような設計パターンを評価し、検討します。 1. 最も [Amazon Builders’ Library](https://aws.amazon.com/builders-library/) では、Amazon がテクノロジーを構築し、運用する方法に関する詳しい説明を参照できます。これらの記事は Amazon のシニアエンジニアによって書かれたもので、アーキテクチャ、ソフトウェアデリバリー、および運用全般のトピックを取り上げています。 1. [AWS ソリューションライブラリ](https://aws.amazon.com/solutions/) は、サービス、コード、および設定を集めた、すぐにデプロイできるソリューションのコレクションです。これらのソリューションは、業界別またはワークロードタイプ別にまとめられた一般的なユースケースと設計パターンに基づいて、AWS と AWS パートナーによって作成されたものです。例えば、ワークロードの [分散負荷テストソリューション](https://aws.amazon.com/solutions/implementations/distributed-load-testing-on-aws/) をセットアップできます。 1. [AWS アーキテクチャセンター](https://aws.amazon.com/architecture/) には、設計パターン、コンテンツタイプ、およびテクノロジー別にまとめられた参照アーキテクチャー図があります。 1. [AWS サンプル](https://github.com/aws-samples) は、一般的なアーキテクチャパターン、ソリューション、およびサービスを試すことができる多くの実習例を含んだ GitHub リポジトリです。最新のサービスや事例など、頻繁に更新しています。 1. ワークロードを改善して、選択した設計パターンをモデル化し、サービスとサービス設定オプションを使用して、ワークロードパフォーマンスを高めます。 1. 社内チームを以下で入手可能なリソースでトレーニングしましょう [AWS Skills Guild](https://aws.amazon.com/training/teams/aws-skills-guild/). 1. このセットアップに役立てるため [AWS Partner Network](https://aws.amazon.com/partners/) を使用して、知識を迅速に提供し、改善能力を高めます。 **実装計画に必要な工数レベル:** このベストプラクティスを確立するには、ワークロードパフォーマンスの向上に役立つ設計パターンとサービスを認識する必要があります。設計パターンを評価した後、設計パターンを実装するには、 *高* 程度の工数が必要です。 ## リソース **関連するドキュメント:** + [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 Builders’ Library](https://aws.amazon.com/builders-library/) + [負荷制限を使用して過負荷を回避する](https://aws.amazon.com/builders-library/using-load-shedding-to-avoid-overload/?did=ba_card&trk=ba_card) + [Caching challenges and strategies](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/?did=ba_card&trk=ba_card) **関連動画:** + [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) # PERF08-BP03 トレードオフが顧客と効率性にどのように影響するかを明らかにする パフォーマンス関連の向上を評価する場合、どの選択肢が顧客とワークロードの効率性に影響するかを特定します。たとえば、key-value データストアの使用がシステムパフォーマンスを向上させる場合、その結果整合性の性質がお客様に与える影響を評価することが大切です。 メトリクスとモニタリングを使用して、システムのパフォーマンスが低い領域を特定します。どのように改善できるか、その改善によってどのようなトレードオフがもたらされるか、およびそれらがシステムとユーザーエクスペリエンスにどのように影響するかを判断します。例えば、データのキャッシングを実装すると、パフォーマンスが劇的に向上しますが、システムの不正な動作を防止するためにキャッシュデータをいつどのように更新または無効化するかに関する明確な戦術が必要になります。 **一般的なアンチパターン:** + 実装に結果整合性などのトレードオフがある場合でも、すべてのパフォーマンス向上が実装されるべきであると考えている。 + パフォーマンスの問題が限界に達した場合にのみ、ワークロードの変更を評価する。 **このベストプラクティスを活用するメリット:** パフォーマンス関連の改善の可能性を評価する場合は、変更のトレードオフがワークロード要件と整合的であるかどうかを判断する必要があります。場合によっては、トレードオフを補うために追加のコントロールを実装する必要があります。 **このベストプラクティスを活用しない場合のリスクレベル:** 高 ## 実装のガイダンス トレードオフを特定する: メトリクスとモニタリングを使用して、システムのパフォーマンスが低い領域を特定します。改善を行う方法と、トレードオフがシステムとユーザーエクスペリエンスに与える影響を特定します。たとえば、データキャッシングの実装はパフォーマンスを劇的に向上させるうえで役立ちますが、システムの誤動作を防止するために、キャッシュされたデータをいつどのように更新または無効化するかに関する明確な戦略が必要になります。 ## リソース **関連ドキュメント:** + [Amazon Builders’ Library](https://aws.amazon.com/builders-library) + [Quick KPI](https://docs.aws.amazon.com/quicksight/latest/user/kpi.html) + [Amazon CloudWatch RUM](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html) + [X-Ray ドキュメント](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html) **関連動画:** + [Introducing The Amazon Builders’ Library (DOP328)](https://www.youtube.com/watch?v=sKRdemSirDM) + [モニタリング計画を立てる](https://www.youtube.com/watch?v=OMmiGETJpfU&ref=wellarchitected) + [Optimize applications through Amazon CloudWatch RUM](https://www.youtube.com/watch?v=NMaeujY9A9Y) + [Amazon CloudWatch Synthetics のデモ](https://www.youtube.com/watch?v=hF3NM9j-u7I) **関連サンプル:** + [Measure page load time with Amazon CloudWatch Synthetics](https://github.com/aws-samples/amazon-cloudwatch-synthetics-page-performance) + [Amazon CloudWatch RUM Web Client](https://github.com/aws-observability/aws-rum-web) # PERF08-BP04 パフォーマンス向上の影響を測定する パフォーマンスを向上させるための変更を行うと同時に、収集されたメトリクスとデータを評価します。この情報を使用して、そのパフォーマンス向上がワークロード、ワークロードのコンポーネント、および顧客に与えた影響を判断します。この測定は、トレードオフに由来するパフォーマンス向上を理解する、および副次的な悪影響が生じたかどうかを判断するために役立ちます。 適切に設計されたシステムでは、パフォーマンス関連の戦略を組み合わせて使用します。特定のホットスポットまたはボトルネックに最も大きなプラスの影響を与える戦略を特定します。たとえば、複数のリレーショナルデータベースシステム全体でのデータシャーディングは、トランザクションに対するサポートを維持しながら、全体的なスループットを向上させることができ、各シャード内ではキャッシングが負荷の低減に役立ちます。 **一般的なアンチパターン:** + マネージドサービスとして使用できるテクノロジーを手動でデプロイおよび管理する。 + ワークロードのパフォーマンス向上に複数のコンポーネントを使用できる場合に、ネットワーキングなど、1 つのコンポーネントにのみ重点を置く。 + 顧客からのフィードバックと認識を唯一のベンチマークとして使用している。 **このベストプラクティスを活用するメリット:** パフォーマンス戦略を実装するには、複数のサービスと機能を選択する必要があります。これらを組み合わせると、パフォーマンスに関するワークロード要件を満たすことができます。 **このベストプラクティスを活用しない場合のリスクレベル:** 中 ## 実装のガイダンス 適切に設計されたシステムでは、パフォーマンス関連の戦略を組み合わせて使用します。特定のホットスポットまたはボトルネックに最も大きなプラスの影響を与える戦略を特定します。たとえば、複数のリレーショナルデータベースシステム全体でのデータシャーディングは、トランザクションに対するサポートを維持しながら、全体的なスループットを向上させることができ、各シャード内ではキャッシングが負荷の低減に役立ちます。 ## リソース **関連ドキュメント:** + [Amazon Builders’ Library](https://aws.amazon.com/builders-library) + [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](https://www.youtube.com/watch?v=NMaeujY9A9Y) + [Amazon CloudWatch Synthetics のデモ](https://www.youtube.com/watch?v=hF3NM9j-u7I) **関連サンプル:** + [Measure page load time with Amazon CloudWatch Synthetics](https://github.com/aws-samples/amazon-cloudwatch-synthetics-page-performance) + [Amazon CloudWatch RUM Web Client](https://github.com/aws-observability/aws-rum-web) + [AWS での分散負荷テスト](https://aws.amazon.com/solutions/implementations/distributed-load-testing-on-aws/) # PERF08-BP05 さまざまなパフォーマンス関連戦略を使用する 状況に応じて、複数の戦略を活用してパフォーマンスを向上させます。たとえば、過剰なネットワーク呼び出しやデータベース呼び出しを防止するためにデータキャッシングなどの戦略を使用する、データベースエンジンの読み込み速度を向上させるためにリードレプリカを使用する、データボリュームを削減するためにデータのシャーディングまたは圧縮を可能な限り使用する、ブロッキングを回避するために利用可能になった結果をバッファし、ストリーミングするなどの戦略を使用します。 ワークロードに変更を加えた後、メトリクスを収集して評価し、それらの変更の影響を判断します。システムおよびエンドユーザーに対する影響を測定して、トレードオフがワークロードにどのような影響を与えるかを理解します。負荷テストなどの体系的なアプローチを使用して、トレードオフによってパフォーマンスが向上するかどうかを調べます。 **一般的なアンチパターン:** + 顧客からの苦情がなければ、ワークロードのパフォーマンスが十分であると考えている。 + パフォーマンス関連の変更を行った後にのみ、パフォーマンスに関するデータを収集する。 **このベストプラクティスを活用するメリット:** パフォーマンスとリソース使用率を最適化するには、統合された運用ビュー、リアルタイムの詳細なデータ、履歴参照が必要です。ダッシュボードを作成し、データに関するメトリクスの計算を実行して、ワークロードが時間の経過とともに変化するのに伴い、ワークロードの運用と利用に関する洞察を得ることができます。 **このベストプラクティスを活用しない場合のリスクレベル:** 低 ## 実装のガイダンス データ駆動型のアプローチでアーキテクチャを進化させる: ワークロードに変更を加えた後、メトリクスを収集して評価し、変更の影響を判断します。システムおよびエンドユーザーに対する影響を測定して、トレードオフがワークロードにどのような影響を与えるかを理解します。負荷テストなどの体系的なアプローチを使用して、トレードオフによってパフォーマンスが向上するかどうかを調べます。 ## リソース **関連ドキュメント:** + [Amazon Builders’ Library](https://aws.amazon.com/builders-library) + [Best Practices for Implementing Amazon ElastiCache](https://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/BestPractices.html) + [AWS Database Caching ](https://aws.amazon.com/caching/database-caching/?ref=wellarchitected) + [Amazon CloudWatch RUM](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.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) + [AWS purpose-built databases (DAT209-L) ](https://www.youtube.com/watch?v=q81TVuV5u28&ref=wellarchitected) + [Optimize applications through Amazon CloudWatch RUM](https://www.youtube.com/watch?v=NMaeujY9A9Y) **関連サンプル:** + [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) + [AWS での分散負荷テスト](https://aws.amazon.com/solutions/implementations/distributed-load-testing-on-aws/)