"このコンテンツは古いものです。現在、このバージョンの Well-Architected Framework は、次の場所にあります。 https://docs.aws.amazon.com/ja_jp/wellarchitected/2022-03-31/framework/performance-efficiency.html

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 クラウドを活用してワークロードをテストしてください。例えば、低コストで負荷を生成し、本番前にボトルネックを発見するには、スポットインスタンスを使用します。