# 継続的最適化
<a name="a-optimize-over-time"></a>

**Topics**
+ [COST 10 新しいサービスをどのように評価すればよいですか？](w2aac19c13c13b5.md)

# COST 10 新しいサービスをどのように評価すればよいですか？
<a name="w2aac19c13c13b5"></a>

AWS では新しいサービスと機能がリリースされるため、既存のアーキテクチャの決定をレビューし、現在でもコスト効率が最も優れているかどうかを確認することがベストプラクティスです。

**Topics**
+ [COST10-BP01 ワークロードレビュープロセスを開発する](cost_evaluate_new_services_review_process.md)
+ [COST10-BP02 このワークロードを定期的に見直し、分析する](cost_evaluate_new_services_review_workload.md)

# COST10-BP01 ワークロードレビュープロセスを開発する
<a name="cost_evaluate_new_services_review_process"></a>

 ワークロードレビューの基準とプロセスを定義するプロセスを開発します。レビューを行う際には、潜在的利益を織り込む必要があります。例えば、請求の 10% 以上の価値を持つコアワークロードは四半期ごとにレビューし、10% 未満のワークロードは年に 1 回レビューするなどです。 

 **このベストプラクティスを活用しない場合のリスクレベル:** 高 

## 実装のガイダンス
<a name="implementation-guidance"></a>

ワークロードの費用対効果が常に最大になるようにするには、ワークロードを定期的にレビューし、新しいサービス、機能、コンポーネントを実装する機会があるかどうかを把握する必要があります。全体的なコスト削減を達成するには、潜在的なコスト削減量に比例したプロセスを行う必要があります。たとえば、支出全体の 50% を占めるワークロードは、支出全体の 5% を占めるワークロードよりも定期的かつ徹底的にレビューする必要があります。外部要因または変動性を考慮します。ワークロードにより特定の地域、特定の市場セグメントにサービスが提供されていて、その領域での変化が予測される場合、レビュー頻度を高くすることでコスト削減につながる可能性があります。レビューで考慮すべきもう 1 つの要因は、変更を運用する労力です。変更のテストおよび検証に多大なコストがかかる場合は、レビューの頻度を下げる必要があります。

古くなったレガシーコンポーネントやリソースには維持するための長期的なコストがかかることや、新しい機能を実装できないことを考慮します。テストと検証にかかる現在のコストが、提案されている利益を上回っている場合があります。しかし、ワークロードと現在のテクノロジーとのギャップが時間の経過とともに大きくなるにつれて、変更にかかるコストが増加し、結果として巨額のコストになることがあります。たとえば、新しいプログラミング言語に移行するときの費用対効果は現時点で低いとします。しかし、5 年後には、その言語に精通した人材のコストが増加する可能性があります。ワークロードが増加すると、さらに大規模なシステムを新しい言語に移行することになり、結果的にこれまでよりもさらに多大な労力を要します。

ワークロードをコンポーネントに分割し、コンポーネントのコストを割り当て (コストの見積りで可)、各コンポーネントの横に要因 (労力や外部市場など) を一覧表示します。この指標を使用して、各ワークロードのレビュー頻度を決定します。たとえば、ウェブサーバーが高コストで、変更の労力が低く、外部要因が高い場合は、レビュー頻度が高くなります。中央データベースが中程度のコストで、変更の労力が高く、外部要因が低い場合は、レビューの頻度は中程度になります。

**実装手順**
+  **レビュー頻度を定義する: **ワークロードとそのコンポーネントを確認する頻度を定義します。これは要因の組み合わせであり、組織内のワークロードによって異なる場合があります。また、ワークロード内のコンポーネントによって異なる場合もあります。一般的な要因には、収益またはブランドの観点から評価された組織にとっての重要性、ワークロードの実行にかかる総コスト (運用コストとリソースコストを含む)、ワークロードの複雑さ、変更の実装の容易性、ソフトウェアライセンス契約、ある変更がライセンス違反によるライセンス費用の重大な増加を生じさせるかどうかなどが含まれます。コンポーネントは、ウェブサーバーやデータベース、コンピューティングリソースやストレージリソースなど、機能的または技術的に定義できます。それに応じて要因のバランスをとり、ワークロードとそのコンポーネントのための期間を設定します。例えば、ワークロード全体は 18 か月ごとに、ウェブサーバーは 6 か月ごとに、データベースは 12 か月ごとに、コンピューティングおよび短期ストレージは 6 か月ごとに、長期ストレージは 12 か月ごとに、それぞれレビューすることとできます。
+ ** レビューの十分性を定義する: **ワークロードまたはワークロードコンポーネントのレビューに費やされる労力を定義します。レビュー頻度と同様に、これは複数の要因のバランスです。例えば、データベースコンポーネントの分析に 1 週間を、ストレージのレビューに 4 時間を、それぞれ費やすようにすることができます。

## リソース
<a name="resources"></a>

 **関連するドキュメント:** 
+  [AWS ニュースブログ](https://aws.amazon.com/blogs/aws/) 
+  [クラウドコンピューティングのタイプ](https://aws.amazon.com/types-of-cloud-computing/) 
+  [AWS の最新情報](https://aws.amazon.com/new/) 

# COST10-BP02 このワークロードを定期的に見直し、分析する
<a name="cost_evaluate_new_services_review_workload"></a>

 既存のワークロードは、定義されたプロセスごとに定期的に見直されます。 

 **このベストプラクティスが確立されていない場合のリスクレベル:** 低 

## 実装のガイダンス
<a name="implementation-guidance"></a>

新しい AWS のサービスと機能の利点を得るには、ワークロードでレビュープロセスを実行し、必要に応じて新しいサービスや機能を実装する必要があります。例えば、ワークロードを見直して、メッセージングコンポーネントを Amazon Simple Email Service (Amazon SES) に置き換えることができます。これにより、すべての機能を低コストで提供しながら、インスタンスのフリートの運用と維持にかかるコストを削減できます。

**実装手順**
+ ** ワークロードを定期的に見直す: **定義したプロセスを使用して、指定した頻度でレビューを実行します。各コンポーネントに適正な労力を費やしていることを確認します。このプロセスは、コスト最適化のためにサービスを選択した最初の設計プロセスに似ています。サービスとこのサービスがもたらすメリットを分析します。今回は、長期的なメリットだけでなく、変更を行うコストも考慮します。
+ ** 新しいサービスを実装する:** 分析の結果、変更を実施する場合は、まずワークロードのベースラインを実行し、各アウトプットの現在のコストを把握します。変更を実施し、分析を実行して、各アウトプットの新しいコストを確認します。

## リソース
<a name="resources"></a>

 **関連するドキュメント:** 
+  [AWS ニュースブログ](https://aws.amazon.com/blogs/aws/) 
+  [クラウドコンピューティングのタイプ](https://aws.amazon.com/types-of-cloud-computing/) 
+  [AWS の最新情報](https://aws.amazon.com/new/)