プロセスと文化

コードとしてのインフラストラクチャ: AWS CloudFormation テンプレートなどのアプローチを使用してインフラストラクチャをコードとして定義します。テンプレートを使用すると、アプリケーションコードと設定のほか、インフラストラクチャをソースコントロールに配置できます。これは、ソフトウェアの開発に使用するものと同じ慣行をインフラストラクチャに適用することを可能にし、イテレーションを迅速に行えるようになります。

デプロイパイプライン: 継続的統合/継続的デプロイ (CI/CD) パイプライン (ソースコードのリポジトリ、ビルドシステム、デプロイ、自動化のテストなど) を使用して、インフラストラクチャをデプロイします。これにより、イテレーションの度に、反復可能で、一貫性があり、低コストな方法でデプロイできるようになります。

明確に定義されたメトリクス: メトリクスをセットアップしてモニタリングすることで主要業績評価指標 (KPI) をキャプチャします。技術メトリクスとビジネスメトリクスの両方を使用することをお勧めします。ウェブサイトまたはモバイルアプリの主なメトリクスは、最初の 1 バイトを受信するまでの時間、または最初のレンダリングまでの時間のキャプチャです。一般的に適用されるその他のメトリクスには、スレッド数、ガベージコレクション率、および待機状態などがあります。リクエストあたりの総累積コストなどのビジネスメトリクスでは、コストを削減する方法をアラートできます。メトリクスを解釈する方法を十分に検討してください。たとえば、平均ではなく最大または 99 パーセンタイルを選択できます。

パフォーマンステストの自動化: デプロイプロセスの一環として、簡単な実行テストが正常に終了した後に、パフォーマンステストを自動的に開始します。自動化により新しい環境が作成され、テストデータなどの初期条件が設定された後に、一連のベンチマークとロードテストが実行されます。これらのテストの結果は、時間の経過に伴うパフォーマンスの変化を追跡できるようにビルドに関連付けてください。テストが長時間実行される場合、パイプラインのこの部分を、他のビルドと同期しないようにできます。または、Amazon EC2 スポットインスタンスを使用して夜間にパフォーマンステストを実行できます。

ロードの生成: 合成ユーザージャーニーや事前に記録されたユーザージャーニーをレプリケートする一連のテストスクリプトを作成してください。これらは結合スクリプトではなく、べき等スクリプトにしてください。有効な結果を得るために、プレウォーミングスクリプトを含める必要がある場合もあります。テストスクリプトは、可能な限り本番での使用状況を再現する必要があります。ソフトウェアまたは SaaS (Software-as-a-Service) ソリューションを使用してロードを生成できます。AWS Marketplace ソリューションとスポットインスタンスの使用を検討してください。これらを利用することで、コスト効率に優れた方法で負荷を生成できます。

パフォーマンスの可視性: 主要なメトリクス、特に各ビルドバージョンに対するメトリクスはチームが確認できるようにする必要があります。これにより、時間の経過に伴う大量の肯定的または否定的な傾向の評価を参照できるようになります。また、エラーや例外でもメトリクスを表示し、確実に作動するシステムをテストするようにしてください。

可視化: 可視化テクニックを使用して、パフォーマンスの問題、ホットスポット、待機状態、または使用率が低い状態が発生する場所を明確にします。アーキテクチャ図にパフォーマンスメトリクスを重ね合わせます。コールグラフ、または符号も問題をすばやく特定するために役立ちます。

定期的なレビュープロセス: 低パフォーマンスのアーキテクチャは通常、パフォーマンスレビュープロセスが存在しないか、または破綻していることに起因します。アーキテクチャのパフォーマンスレベルが低い場合は、パフォーマンスレビュープロセスを導入することで、反復的な改善を促すことができます。

継続的な最適化: クラウドワークロードのパフォーマンス効率を継続的に最適化する文化を取り入れます。