PERF 1: どのように最良パフォーマンスのアーキテクチャを選択するのですか?
多くの場合、ワークロード全体での最適なパフォーマンスのためには、複数のアプローチが必要になります。Well-Architected なシステムでは、パフォーマンスを向上させるために複数のソリューションと機能が使用されています。
リソース
Introducing The Amazon Builders’ Library (DOP328)
ベストプラクティス:
-
利用可能なサービスやリソースを理解する:
クラウドで利用できる幅広いサービスやリソースに関する情報を取得し、その内容を理解します。ワークロードに関連するサービスと設定のオプションを特定し、最適なパフォーマンスを実現する方法を理解してください。
-
アーキテクチャにかかわる選択プロセスを決める:
クラウドにおける社内の経験と知識、または公開されたユースケース、関連ドキュメント、ホワイトペーパーなどの外部リソースを利用して、リソースとサービスの選定プロセスを決定します。ワークロードで使用できると考えられるサービスの実験とベンチマークを促進するプロセスを定義するようにしてください。
-
意思決定においてコスト要件を考慮する :
ワークロードには、多くの場合、運用のコスト要件があります。社内のコスト管理を使用し、予測されたリソースニーズに基づいて、リソースのタイプとサイズを選択してください。
-
ポリシーやリファレンスアーキテクチャを使用する:
内部ポリシーと既存のリファレンスアーキテクチャを評価し、独自の分析を使用してワークロードのサービスと設定を選択することによって、パフォーマンスと効率性を最大化します。
-
クラウドプロバイダー、または適切なパートナーからのガイダンスを利用する:
判断の指針とするために、ソリューションアーキテクト、プロフェッショナルサービス、または適切なパートナーなどのクラウド企業のリソースを利用します。これらのリソースは、アーキテクチャを確認して改善し、最適なパフォーマンスを実現するのに役立ちます。
-
既存のワークロードのベンチマークを実施する:
既存のワークロードのパフォーマンスにベンチマーク結果を参考に、クラウドでの実行状況を把握します。ベンチマークから収集されたデータを使用して、アーキテクチャ面での判断を導き出します。
-
ワークロードの負荷テストを実施する:
異なるリソースタイプとサイズを使用して、最新のワークロードアーキテクチャをクラウドにデプロイします。デプロイメントをモニタリングして、ボトルネック、または過剰なキャパシティーを特定するパフォーマンスメトリクスを取得してください。このパフォーマンス情報を使用して、アーキテクチャとリソースを設計、またはそれらをより良く選択します。
改善計画
利用可能なサービスやリソースを理解する
関連サービスのワークロードソフトウェアとアーキテクチャを棚卸しする: ワークロードのインベントリを収集し、詳細を確認する製品のカテゴリを決定します。パフォーマンスを向上させ、運用の複雑さを軽減するために、マネージドサービスに置き換えることができるワークロードコンポーネントを特定します。
アーキテクチャにかかわる選択プロセスを決める
アーキテクチャのアプローチを選択する: パフォーマンス要件を満たすアーキテクチャの種類を特定します。配信用のメディア (デスクトップ、ウェブ、モバイル、IoT)、従来の要件、統合などの制約を特定します。リファクタリングなどの再利用の機会を把握します。他のチーム、アーキテクチャ図、および AWS ソリューションアーキテクト、AWS リファレンスアーキテクチャ、APN
パートナーなどのリソースを参考にすると、アーキテクチャを選ぶ際に役立ちます。
パフォーマンス要件を定義する: カスタマーエクスペリエンスを使用して、最も重要なメトリクスを特定します。メトリクスごとに、ターゲット、測定アプローチ、および優先順位を特定します。カスタマーエクスペリエンスを定義します。顧客に必要なパフォーマンスのエクスペリエンスと、顧客がワークロードのパフォーマンスをどのように評価するかを文書化します。重要なユーザーストーリーのエクスペリエンスの懸念事項について優先順位を付けます。要件に対してこのストーリーがどのように実行されるかを知ることができるように、パフォーマンス要件を含め、スクリプト化されたユーザージャーニーを実装します。
意思決定においてコスト要件を考慮する
ワークロードコンポーネントを最適化してコストを削減する: ワークロードコンポーネントを適切なサイズにし、伸縮性を実現することで、コストを削減し、コンポーネントの効率を最大化します。マネージドデータベース、インメモリキャッシュ、リバースプロキシなど、必要に応じてマネージドサービスに置き換えることができるワークロードコンポーネントを判断します。
ポリシーやリファレンスアーキテクチャを使用する
既存のポリシーまたはリファレンスアーキテクチャを使用してワークロードをデプロイする: サービスをクラウドデプロイに統合し、パフォーマンステストを使用して、引き続きパフォーマンス要件を満たせるようにします。
クラウドプロバイダー、または適切なパートナーからのガイダンスを利用する
AWS リソースにサポートを依頼する: AWS ソリューションアーキテクトとプロフェッショナルサービスは、ソリューションの実装に対するガイダンスを提供します。APN パートナーは、ビジネスの俊敏性とイノベーションを解き放つために役立つ AWS の専門知識を提供します。
既存のワークロードのベンチマークを実施する
開発中にパフォーマンスをモニタリングする: ワークロードの進化に合わせて、パフォーマンスを目で見て確認できるプロセスを実装します。
配信パイプラインに統合する: 配信パイプラインで負荷テストを自動的に実行します。テスト結果を事前定義された主要業績評価指標 (KPI) やしきい値と比較して、引き続きパフォーマンス要件を満たせるようにします。
ユーザージャーニーをテストする: 負荷テストには、合成またはサニタイズされたバージョンの本番データを使用します (機密情報や身元がわかる情報は削除してください)。アプリケーション全体で再生またはプログラミング済みのユーザージャーニーを大規模に使用して、アーキテクチャ全体を練習として動かします。
ワークロードの負荷テストを実施する
負荷テストによってアプローチを検証する: パフォーマンス要件を満たすかどうかを調べるには、概念実証の負荷テストを行います。AWS のサービスを使用して、本番規模の環境を実行し、アーキテクチャをテストすることができます。料金はテスト環境が必要となる場合にのみ発生することから、オンプレミス環境を使用する場合に比べてわずかなコストで本格的なテストを実施できます。Amazon
EC2 テストポリシー
メトリクスをモニタリングする: Amazon CloudWatch では、アーキテクチャのリソース全体のメトリクスを収集できます。また、カスタムメトリクスを収集および発行して、ビジネスメトリクスまたは導出メトリクスを表面化することも可能です。CloudWatch
またはサードパーティーのソリューションを使用して、しきい値を超過したことを示すアラームを設定します。
大規模にテストする: 負荷テストは実際のワークロードを使用するため、ソリューションが本番環境でどのように機能するかを確認できます。AWS のサービスを使用して、本番規模の環境を実行し、アーキテクチャをテストすることができます。テスト環境に対する支払いはテスト環境が必要なときにのみ発生するため、オンプレミスの環境を使用する場合より低いコストで大規模なテストを実行できます。スケールできない場所や非線形の方法でスケールされるかどうかを確認するには、AWS
クラウドを活用してワークロードをテストしてください。例えば、低コストで負荷を生成し、本番前にボトルネックを発見するには、スポットインスタンスを使用します。