# 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/)