# COST 10. どのように新しいサービスを評価するのですか? AWS では新しいサービスと機能がリリースされるため、既存のアーキテクチャの決定をレビューし、現在でもコスト効率が最も優れているかどうかを確認することがベストプラクティスです。 **Topics** + [COST10-BP01 ワークロードレビュープロセスを開発する](cost_evaluate_new_services_review_process.md) + [COST10-BP02 このワークロードを定期的に見直し、分析する](cost_evaluate_new_services_review_workload.md) # COST10-BP01 ワークロードレビュープロセスを開発する ワークロードレビューの基準とプロセスを定義するプロセスを開発します。レビューを行う際には、潜在的利益を織り込む必要があります。例えば、コアワークロードや、請求の 10% 超に値するワークロードは四半期または 6 か月ごとにレビューし、10% 以下のワークロードは年に 1 回レビューするなどです。 **このベストプラクティスを活用しない場合のリスクレベル:** 高 ## 実装のガイダンス ワークロードの費用対効果を最大にするには、ワークロードを定期的にレビューし、新しいサービス、機能、コンポーネントを実装する機会があるかどうかを把握する必要があります。全体的なコスト削減を達成するには、潜在的なコスト削減量に比例したプロセスを行う必要があります。例えば、支出全体の 50% を占めるワークロードは、支出全体の 5% を占めるワークロードよりも定期的かつ徹底的にレビューする必要があります。外部要因または変動性を考慮します。ワークロードにより特定の地域、特定の市場セグメントにサービスが提供されていて、その領域での変化が予測される場合、レビュー頻度を高くすることでコスト削減につながる可能性があります。レビューで考慮すべきもう 1 つの要因は、変更を運用する労力です。変更のテストおよび検証に多大なコストがかかる場合は、レビューの頻度を下げる必要があります。 古くなったレガシーコンポーネントやリソースには維持するための長期的なコストがかかることや、新しい機能を実装できないことを考慮します。テストと検証にかかる現在のコストが、提案されている利益を上回っている場合があります。しかし、ワークロードと現在のテクノロジーとのギャップが時間の経過とともに大きくなるにつれて、変更にかかるコストが増加し、結果として巨額のコストになることがあります。例えば、新しいプログラミング言語に移行するときの費用対効果は現時点で低いとします。しかし、5 年後には、その言語に精通した人材のコストが増加する可能性があります。ワークロードが増加すると、さらに大規模なシステムを新しい言語に移行することになり、結果的にこれまでよりもさらに多大な労力を要します。 ワークロードをコンポーネントに分割し、コンポーネントのコストを割り当て (コストの見積りで可)、各コンポーネントの横に要因 (労力や外部市場など) を一覧表示します。この指標を使用して、各ワークロードのレビュー頻度を決定します。例えば、ウェブサーバーが高コストで、変更の労力が低く、外部要因が高い場合は、レビュー頻度が高くなります。中央データベースが中程度のコストで、変更の労力が高く、外部要因が低い場合は、レビューの頻度は中程度になります。 新しいサービス、設計パターン、リソースの種類、設定が利用できるようになった時点で、これらを評価するプロセスを定義し、ワークロードコストを最適化します。[パフォーマンスの柱のレビュー](https://docs.aws.amazon.com/wellarchitected/latest/framework/perf-06.html)と[信頼性の柱のレビュー](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_monitor_aws_resources_review_monitoring.html)プロセスと同様に、最適化および改善のアクティビティを特定、検証、優先順位付けし、これをバックログに組み込みます。 **実装手順** + **レビュー頻度を定義する:** ワークロードとそのコンポーネントを確認する頻度を定義します。継続的な改善とレビューの周期のための時間とリソースを割り当て、ワークロードの効率性と最適化を向上させます。これは要因の組み合わせであり、組織内のワークロード、またワークロード内のコンポーネントによって、異なる場合があります。一般的な要因には、収益またはブランドの観点から評価された組織にとっての重要性、ワークロードの実行にかかる総コスト (運用コストとリソースコストを含む)、ワークロードの複雑さ、変更の実装の容易性、ソフトウェアライセンス契約、ある変更がライセンス違反によるライセンス費用の重大な増加を生じさせるかどうかなどが含まれます。コンポーネントは、ウェブサーバーやデータベース、コンピューティングリソースやストレージリソースなど、機能的または技術的に定義できます。それに応じて要因のバランスをとり、ワークロードとそのコンポーネントのための期間を設定します。例えば、ワークロード全体は 18 か月ごとに、ウェブサーバーは 6 か月ごとに、データベースは 12 か月ごとに、コンピューティングおよび短期ストレージは 6 か月ごとに、長期ストレージは 12 か月ごとに、それぞれ確認することができます。 + **レビューの十分性を定義する:** ワークロードまたはワークロードコンポーネントのレビューに費やされる労力を定義します。レビュー頻度と同様に、これは複数の要因のバランスです。最も大きな利益をもたらす取り組みに集中できるように、改善の機会を定期的に評価し、優先順位を設定します。同時に、それらの活動に必要な作業量を見積もります。予想される結果が目標に達しておらず、作業コストがさらにかかる場合は、代わりの一連のアクションを使用して作業を繰り返します。レビュープロセスには、漸進的な継続的改善を可能にする時間とリソースを含める必要があります。例えば、データベースコンポーネントの分析に 1 週間、コンピューティングリソースの分析に 1 週間、ストレージのレビューに 4 時間を、それぞれ費やすように決めます。 ## リソース **関連ドキュメント:** + [AWS ニュースブログ](https://aws.amazon.com/blogs/aws/) + [クラウドコンピューティングのタイプ](https://aws.amazon.com/types-of-cloud-computing/) + [AWS の最新情報](https://aws.amazon.com/new/) **関連する例:** + [AWS サポートのプロアクティブサービス](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/) + [SAP ワークロードの定期的なレビューを計画する](https://docs.aws.amazon.com/wellarchitected/latest/sap-lens/best-practice-4-4.html) # COST10-BP02 このワークロードを定期的に見直し、分析する 既存のワークロードは、それぞれ定義されたプロレスに基づいて定期的に見直され、新しいサービスを導入できるか、既存のサービスを置き換えることができるか、またはワークロードをリアーキテクトできるかを確認します。 **このベストプラクティスを活用しない場合のリスクレベル:** 中 ## 実装のガイダンス AWS は定期的に新しい機能を追加しているため、最新のテクノロジーを利用して、より迅速に実験やイノベーションできます。「[AWS の最新情報](https://aws.amazon.com/new/)」では、AWS の新機能について詳しく説明し、リリースされた AWS サービス、機能、リージョン拡大に関して概説します。発表されたリリースの詳細を確認して、既存のワークロードの見直しや分析にそれらを使用できます。新しい AWS のサービスと機能の利点を得るには、ワークロードでレビューを行い、必要に応じて新しいサービスや機能を実装する必要があります。つまり、場合によっては、ワークロードに使用している既存のサービスを置き換えたり、ワークロードをモダナイズして新しい AWS のサービスを導入したりする必要があるということです。例えば、ワークロードを見直して、メッセージングコンポーネントを Amazon Simple Email Service に置き換えることができます。これにより、すべての機能を低コストで提供しながら、インスタンスのフリートの運用と維持にかかるコストを削減できます。 ワークロードを分析して潜在的な機会を見出すには、新しいサービスだけではなく、ソリューション構築における新しい方法も考慮する必要があります。他のお客様のアーキテクチャ設計、課題、ソリューションについては、AWS の「[This is My Architecture](https://aws.amazon.com/architecture/this-is-my-architecture)」ビデオをご覧ください。「[All-In series](https://aws.amazon.com/architecture/all-in-series/)」で、実際の AWS サービスとカスタマーストーリーをご覧ください。また、基本的なクラウドアーキテクチャパターンのベストプラクティスを説明、調査、および分類する「[Back to Basics](https://aws.amazon.com/architecture/back-to-basics/)」ビデオシリーズを視聴することもできます。もう 1 つのソースは、「[How to Build This](https://aws.amazon.com/architecture/how-to-build-this/)」動画です。この動画は、AWS サービスを使用して実用最小限の製品 (MVP) を実現する方法について、大きな構想を持つユーザーを支援するように設計されています。確固たるアイデアを持った世界中の構築者が、経験豊富な AWS のソリューションアーキテクトからのアーキテクチャに関するガイダンスを得ることができます。最後に、「[入門ガイド](https://aws.amazon.com/getting-started/)」の資料を参照できます。ステップバイステップのチュートリアルが含まれています。 レビュープロセスを開始する前に、合意されたレビュープロセスに従いながら、ワークロードにおけるビジネスの要件、特定のサービスまたはリージョンを使用するためのセキュリティおよびデータのプライバシー要件、パフォーマンス要件に従います。 **実装手順** + ** ワークロードを定期的に見直す:** 定義したプロセスを使用して、指定した頻度でレビューを実行します。各コンポーネントに適正な労力を費やしていることを確認します。このプロセスは、コスト最適化のためにサービスを選択した最初の設計プロセスに似ています。サービスとこのサービスがもたらすメリットを分析します。今回は、長期的なメリットだけでなく、変更を行うコストも考慮します。 + ** 新しいサービスを実装する:** 分析の結果、変更を実施する場合は、まずワークロードのベースラインを実行し、各アウトプットの現在のコストを把握します。変更を実施し、分析を実行して、各アウトプットの新しいコストを確認します。 ## リソース **関連ドキュメント:** + [AWS ニュースブログ](https://aws.amazon.com/blogs/aws/) + [AWS の最新情報](https://aws.amazon.com/new/) + [AWS ドキュメント ](https://docs.aws.amazon.com/) + [AWS 使用開始 ](https://aws.amazon.com/getting-started/) + [AWS 一般的なリソース ](https://docs.aws.amazon.com/#general_resources) **関連動画:** + [AWS - This is My Architecture](https://aws.amazon.com/architecture/this-is-my-architecture) + [AWS - Back to Basics](https://aws.amazon.com/architecture/back-to-basics/) + [AWS - All-In シリーズ](https://aws.amazon.com/architecture/all-in-series/) + [構築する方法](https://aws.amazon.com/architecture/how-to-build-this/)