# 具体的な改善点を評価する
<a name="evaluate-specific-improvements"></a>

 ワークロードによってプロビジョニングされる、作業の単位を完了するために必要なリソースを理解します。潜在的な改善点を評価して、潜在的な影響、実装のコスト、関連付けられたリスクを見積もります。

 経時的な改善点を測定するには、AWS でプロビジョニングした内容と、それらのリソースがどのように消費されるかをまず理解します。

 AWS の使用状況の全体的な概要を把握してから、AWS コストと使用状況レポートを使って、ホットスポットを特定します。この[AWS サンプルコード](https://github.com/aws-samples/aws-usage-queries)は、Amazon Athena の助けを借りてレポートを確認および分析するのに役立ちます。

## プロキシメトリクス
<a name="proxy-metrics"></a>

 特定の変更を評価する際、その変更が関連リソースに及ぼす影響を最も定量的に把握できるのはどのメトリクスなのかを評価する必要もあります。これらのメトリクスはプロキシメトリクスと呼ばれます。評価する改善点のタイプ、および改善の対象となるリソースに最も当てはまるプロキシメトリクスを選択します。これらのメトリクスは経時的に進化します。

 ワークロードをサポートするためにプロビジョニングされたリソースには、コンピューティング、ストレージ、およびネットワークリソースが含まれます。プロキシメトリクスを使ってプロビジョニングされたリソースを評価して、それらのリソースがどのように消費されるかを確認します。

 プロキシメトリクスを使って、ビジネス成果を達成するためにプロビジョニングされたリソースを測定します。


|  **リソース**  |  **プロキシメトリクスの例**  |  **改善目標**  | 
| --- | --- | --- | 
|  コンピューティング  |  vCPU 分  |  プロビジョニングされたリソースの使用率を最大化する  | 
|  ストレージ  |  プロビジョニングされた GB  |  プロビジョニング合計を減らす  | 
|  ネットワーク  |  転送された GB または転送されたパケット数  |  転送合計および転送距離を減らす  | 

## ビジネスメトリクス
<a name="business-metrics"></a>

 ビジネス成果の達成を定量化するビジネスメトリクスを選択します。ビジネスメトリクスは、ワークロードが提供する価値、例えば、同時アクティブユーザー数、提供された API コール数、完了したトランザクション数などを反映するものである必要があります。これらのメトリクスは経時的に進化する可能性があります。財務ベースのビジネスメトリクスを評価する際は注意してください。トランザクションの価値に一貫性がないと比較が無効になります。

## 重要業績評価指標
<a name="key-performance-indicators"></a>

 以下の式を用いて、プロビジョニングされたリソースを達成したビジネス成果で割ることで、単位作業あたりのプロビジョニングされたリソースを決定します。

![\[この式に表示された図: 作業単位あたりのプロビジョニングされたリソース = プロビジョニングされたリソースのプロキシメトリクス/成果のビジネスメトリクス\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/sustainability-pillar/images/key-performance-indicators-formula.png)


 作業単位あたりのリソースを KPI として使用します。比較の基準としてプロビジョニングされたリソースに基づいてベースラインを確立します。


|  **リソース**  |  **KPI 例**  |  **改善目標**  | 
| --- | --- | --- | 
|  コンピューティング  |  トランザクションあたりの vCPU 分数  |  プロビジョニングされたリソースの使用率を最大化する  | 
|  ストレージ  |  トランザクションあたりの GB  |  プロビジョニング合計を減らす  | 
|  ネットワーク  |  トランザクションあたりの転送 GB またはトランザクションあたりの転送パケット数  |  転送合計および転送距離を減らす  | 

## 改善を推定する
<a name="estimate-improvement"></a>

 改善は、プロビジョニングされたリソースの量的削減 (プロキシメトリクスによって示される) と、作業単位あたりプロビジョニングされたリソースの基準値からの変化の割合の両方で見積もられます。


|  **リソース**  |  **KPI 例**  |  **改善目標**  | 
| --- | --- | --- | 
|  コンピューティング  |  トランザクションあたりの vCPU 分の削減 %  |  使用率を最大化する  | 
|  ストレージ  |  トランザクションあたりの GB の削減 %  |  プロビジョニング合計を減らす  | 
|  ネットワーク  |  トランザクションあたりの転送 GB またはトランザクションあたりの転送パケット数の削減 %  |  転送合計および転送距離を減らす  | 

## 改善点を評価する
<a name="evaluate-improvements"></a>

 予想される実質的な利益に対する潜在的な改善点を評価します。実装と維持の時間、コスト、工数レベル、そして想定外の影響などのビジネスリスクを評価します。

 目標とする改善は、多くの場合、消費するリソースのタイプとのトレードオフを示します。例えば、コンピューティングの消費を抑えるために、結果を保存したり、転送されるデータを制限するために、結果をクライアントに送る前にデータを処理したりすることができます。これらの[トレードオフ](sustainability-as-a-non-functional-requirement.md)は後にさらに説明します。

 ワークロードのリスクを評価する際には、セキュリティ、信頼性、パフォーマンス効率、コストの最適化、改善によるワークロードの運用能力への影響など、非機能的要件も含めます。

 このステップを [シナリオの例](improvement-process.md#example-scenario) に適用することで、目標改善点を次のように評価しました。


|  **ベストプラクティス**  |  **目標とする改善点**  |  **潜在的な**  |  **コスト**  |  **リスク**  | 
| --- | --- | --- | --- | --- | 
|  ニーズに合わせて最小限のハードウェアを使用する  |  予測スケーリングを実装して、使用率が低い期間を減らす  |  中程度  |  低  |  低  | 
|  データアクセスとストレージパターンを万全にサポートするテクノロジーを使用する  |  より効果的な圧縮メカニズムを実装して、合計ストレージと達成までの時間を減らす  |  高い  |  低  |  低  | 

 予測スケジューリングを導入することにより、使用率の低いインスタンスや未使用のインスタンスが消費する vCPU 時間を削減し、既存のスケーリングメカニズムと比較して、消費するリソースを約 11% 削減する中程度の効果が得られました。関与するコストは低く、クラウドリソースの設定と Amazon EC2 Auto Scaling の予測スケーリングのオペレーションが含まれます。リスクは、予測を超える需要に対して反応的にスケールアウトを行うと、パフォーマンスが制約されることです。

 より効果的な圧縮を導入することで、オリジナル画像と加工したすべての画像でファイルサイズを大幅に削減し、制作に必要なストレージ容量を約 25% 削減できます。新しいアルゴリズムを実装することは、リスクが少なく労力の少ない代替案です。