

# プロセスと文化
<a name="process-and-culture"></a>

 ワークロードを設計する際には、効率的で高性能なクラウドワークロードをより良く実行するための原則と慣行があります。この重点分野では、クラウドワークロードのパフォーマンス効率を高める文化を醸成するのに役立つベストプラクティスを紹介します。

 この文化を醸成するために、以下の基本方針を考慮してください。
+  **コードとしてのインフラストラクチャ:** AWS CloudFormation テンプレートなどのアプローチを使用してインフラストラクチャをコードとして定義します。テンプレートを使用すると、アプリケーションコードと設定のほか、インフラストラクチャをソースコントロールに配置できます。これは、ソフトウェアの開発に使用するものと同じ慣行をインフラストラクチャに適用することを可能にし、イテレーションを迅速に行えるようになります。
+  **デプロイメントパイプライン:** 継続的インテグレーション/継続的デプロイメント (CI/CD) パイプライン (ソースコードリポジトリ、ビルドシステム、デプロイメント、およびテストのオートメーションなど) を使用してインフラストラクチャをデプロイします。これにより、イテレーションのたびに、反復可能で、一貫性があり、低コストな方法でデプロイできるようになります。
+  **明確に定義されたメトリクス:** メトリクスをセットアップおよびモニタリングして主要業績評価指標 (KPI) をキャプチャします。メトリクスについては、技術とビジネス両方のメトリクスの使用をお勧めします。ウェブサイトまたはモバイルアプリの主なメトリクスは、最初の 1 バイトを受信するまでの時間、または最初のレンダリングまでの時間のキャプチャです。一般的に適用されるその他のメトリクスには、スレッド数、ガベージコレクション率、および待機状態などがあります。リクエストあたりの総累積コストなどのビジネスメトリクスでは、コストを削減する方法をアラートできます。メトリクスを解釈する方法を十分に検討してください。例えば、平均値ではなく、最大値または 99 パーセンタイル値を選択できます。
+  **パフォーマンステストのオートメーション:** デプロイメントプロセスの一環として、より簡単に実行できるテストが正常に終了した後で、パフォーマンステストを自動的に開始します。自動化により新しい環境が作成され、テストデータなどの初期条件が設定された後に、一連のベンチマークとロードテストが実行されます。これらのテストの結果は、時間の経過に伴うパフォーマンスの変化を追跡できるようにビルドに関連付けてください。テストが長時間実行される場合、パイプラインのこの部分を、他のビルドと同期しないようにできます。または、Amazon EC2 スポットインスタンスを使用して夜間にパフォーマンステストを実行できます。
+  **ロードの生成:** 合成ユーザージャーニーや事前に記録されたユーザージャーニーをレプリケートする一連のテストスクリプトを作成します。これらは結合スクリプトではなく、べき等性スクリプトにしてください。有効な結果を得るために、「プレウォーミング」スクリプトを含める必要がある場合もあります。テストスクリプトは、可能な限り本番での使用状況を再現する必要があります。負荷の生成には、ソフトウェアまたは Software as a Service (SaaS) ソリューションを使用できます。[AWS Marketplace](https://aws.amazon.com/marketplace/) ソリューションおよび[スポットインスタンス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances.html)の使用を検討してください。これらを利用することで、コスト効率に優れた方法で負荷を生成できます。
+  **パフォーマンスの可視性:** 主要なメトリクス、特に各ビルドバージョンに対するメトリクスはチームが確認できるようにする必要があります。これにより、時間の経過に伴う大量の肯定的または否定的な傾向の評価を参照できるようになります。また、エラーや例外の数に関するメトリクスも表示して、動作中のシステムをテストしていることを確認するようにしてください。
+ **可視化:** パフォーマンス問題、ホットスポット、待機状態、または低使用率が発生している箇所を明らかにする可視化手法を使用します。アーキテクチャ図にパフォーマンスメトリクスを重ね合わせます。コールグラフ、またはコードも問題をすばやく特定するために役立ちます。
+  **定期的なレビュープロセス:** 低パフォーマンスのアーキテクチャは通常、パフォーマンスレビュープロセスが存在しないか、または破綻していることに起因します。アーキテクチャのパフォーマンスレベルが低い場合は、パフォーマンスレビュープロセスを導入することで、反復的な改善を促すことができます。
+  **継続的な最適化:** クラウドワークロードのパフォーマンス効率を継続的に最適化する文化を取り入れましょう。

**Topics**
+ [PERF05-BP01 ワークロードの状態とパフォーマンスを測定するための主要業績評価指標 (KPI) を設定する](perf_process_culture_establish_key_performance_indicators.md)
+ [PERF05-BP02 モニタリングソリューションを活用して、パフォーマンスが最も重要な分野について把握する](perf_process_culture_use_monitoring_solutions.md)
+ [PERF05-BP03 ワークロードのパフォーマンス向上プロセスを定める](perf_process_culture_workload_performance.md)
+ [PERF05-BP04 ワークロードの負荷テストを実施する](perf_process_culture_load_test.md)
+ [PERF05-BP05 自動化でパフォーマンス関連の問題をプロアクティブに修正する](perf_process_culture_automation_remediate_issues.md)
+ [PERF05-BP06 ワークロードとサービスを最新の状態に保つ](perf_process_culture_keep_workload_and_services_up_to_date.md)
+ [PERF05-BP07 メトリクスを定期的に見直す](perf_process_culture_review_metrics.md)