コンポーネント コストを最適化するための推奨事項

次の Azure Well-Architected フレームワーク コスト最適化チェックリストの推奨事項に該当します。

このガイドでは、ワークロード コンポーネントのコストを最適化するための推奨事項について説明します。 コンポーネント コストの最適化とは、ワークロード内の個々の要素のコスト効率を評価および改善するプロセスを指します。 これは、アプリケーション機能、プラットフォーム機能、リソースなど、古い、不要、または使用頻度の低いコンポーネントの継続的なレビューと潜在的な削除と改善を強調しています。 また、ディザスター リカバリー環境のコスト最適化と、最適化されていないコンポーネントの導入を回避する方法についても説明します。 この記事のガイダンスの適用対象は、設計フェーズにはない既存のワークロードです。 通常のコンポーネント最適化の軽視は、コストの増大、リソースの無駄、時間とコストの両方を浪費する非効率的なワークロードにつながる可能性があります。

定義

主要な設計戦略

ワークロード コンポーネントの最適化とは、アプリケーション機能、プラットフォーム機能、リソースなど、ワークロードのさまざまな要素を改良することです。 目標は、ワークロードがすべてのコンポーネントを効率的かつコスト効率よく使用できるようにすることです。 戦略の中には必要以上の支出を行う原因となるコンポーネントの削除、変更、回避が含まれます。 コンポーネント コストの最適化プロセスにより、最も価値の高い機能とコンポーネントにリソースを割り当て、不要な費用を防ぐことができるようになります。

アプリケーション機能を最適化する

アプリケーション機能の最適化とは、価値に基づいてアプリケーション機能の削除、再投資、収益化のいずれかを行うプロセスです。 これにより、顧客に最も大きな価値をもたらすアプリケーション機能にリソースを割り当てることができます。 アプリケーション機能の最適化によって、技術的負債をもたらす機能や、十分な投資収益率を生まない機能への投資を回避できます。

アプリケーション機能の価値を評価する

機能の価値を判断するには、それがアプリケーション全体に及ぼす影響と、顧客にもたらす価値を考慮します。 考慮するべき要素の一部を以下に示します。

• "顧客のニーズ": その機能が顧客のニーズと期待をどの程度満たしているかを評価します。 顧客からのフィードバック、アンケート、使用状況データは、知覚価値を把握する上で役に立ちます。

• "ビジネスの目標": その機能がビジネスの戦略的目標にどの程度合致しているかを評価します。 機能が収益の生成、顧客の満足、競争上の優位性にどの程度役立っているかを考慮します。

• "ユーザー エクスペリエンスへの影響": その機能がユーザー エクスペリエンスの向上とユーザビリティや生産性の改善に与える影響を明確にします。

• "差別化": その機能が市場の他のアプリケーションと比較した場合の独自のセールス ポイントや競争上の優位性をもたらしているかどうかを評価します。

アプリケーション機能のコストを評価する

効果的なリソースの割り当てと最適化のためには、各機能に関連するコストを把握することが不可欠です。 コストを評価する際には、以下のようなさまざまな側面を考慮します。

• "開発作業量": その機能や周辺機能を開発して保守するために必要となる時間、リソース、専門知識を評価します。 使用率の低い機能は多くの場合、技術的負債の主な原因となります。

• "メンテナンスとサポート": バグ修正、セキュリティ更新、トラブルシューティングなど、その機能の維持とサポートに関連する継続的なコストを考慮します。

• "インフラストラクチャとリソースの使用率": サーバー リソース、ストレージ、帯域幅など、その機能がインフラストラクチャ要件にもたらす影響を評価します。

• "統合の複雑さ": その機能を他のシステムやサード パーティのサービスと統合する際の複雑さとコストを評価します。

• "パフォーマンスに関する考慮事項": スケーラビリティ、応答時間、リソース配分状況など、その機能がアプリケーションのパフォーマンスにもたらす影響を評価します。

利害関係者と共にアプリケーション機能の価値をレビューする

製品マネージャー、ソフトウェア開発者、ビジネス アナリストなどの主要な担当者を関与させることで利害関係者とアプリケーション機能の価値をレビューし、特定の機能の事業目標に対する価値を評価します。 このコラボレーションは、メンテナンス作業に関する知見をもたらし、生産性を低下させたり新しい重要な機能の開発の邪魔となる可能性のある機能を明らかにするため、コスト最適化のためには不可欠です。 開発チームは、特定の機能を保守するために必要な作業量に関する重要な情報を与えることができます。 それが持つ価値以上の問題を引き起こす可能性がある機能について率直に話をするようチームに促します。これは、それらの機能がチームが新しい機能を作成する妨げとなっている場合に特に重要です。

機能の将来を決定する

分析と評価に基づいて、アプリケーション機能の将来を決定します。 以下のように、投資収益をもたらさないアプリケーション機能の削除、再投資、収益化を行います。

• "削除": データに基づいて、アプリケーション機能の計画された EOL を検討します。 機能の削除の理由としては、顧客の需要が少ない、メンテナンスのコストが高い、複雑性、修正するための作業量に見合わない冗長性などが考えられます。 削除のための計画を作成します。これには、コードのリファクタリング、依存関係の更新、UI の再構成が含まれる場合があります。

  リスク: 特定のユーザーやシナリオにとって不可欠な機能を誤って削除することで、アプリケーションのパフォーマンス、操作性、セキュリティに悪影響を及ぼす可能性があります。

• "再投資": 一部のアプリケーション機能は、現在の状態ではあまり価値をもたらさなくても、それらへの再投資によって価値をもたらすようになる可能性があります。 再投資とは、アプリケーション機能の手直しや強化を意味します。 その価値と実現可能性に基づいて明らかになった改善点を優先します。 変更を実装するためのロードマップとタイムラインを決定します。 開発リソース、依存関係、アプリケーションに対する影響の可能性などの要因を検討します。

• "収益化": 収益化を通じて、アプリケーション機能を収益を生み出す機会に変えます。 機能がユーザーに価値をもたらしていても、現在の投資には値しない場合があります。 これらの機能を個別の有料アドオンとして提供したり、他の会社にライセンス付与したりするなど、収益化の機会を探ります。

ワークロード リソースを最適化する

ワークロード リソースの最適化では、使用されていないリソースの削除や、ワークロードに必要な使用率の低いリソースの最適化を行います。 この作業により、支出が減り、無駄が回避され、ワークロードが価値をもたらすリソースだけを使用していることが保証されるようになります。

使用されていないワークロード リソースを削除します。 使用されていないリソースとは、ワークロードや運用プロセスが使用していないデプロイ済みサービスのことです。 これらのリソースは、長期間アイドル状態であったり、孤立していたり、忘れられていたりする場合があります。 これらは投資収益をもたらさないため、削除する必要があります。 使用されていないリソースが生じる一般的な原因は以下のとおりです。

• アラート。
• デモ ビルド。
• 環境の使用停止。
• 機能の使用停止。
• IP アドレス。
• ネットワーク ファイアウォール。
• 概念実証。
• "スナップショット"。
• ストレージ アカウント。
• 一時的なテスト環境。
• 一時的なトリアージ環境。

ワークロード内の使用されていないリソースを削除するには、以下の手順を検討してください。

1. "インベントリの取得": すべての環境のワークロード内のすべてのリソースの完全なインベントリ作成を実行します。

2. "孤立したリソースの特定": リソースは、不要になったタイミングや、親リソースが削除されたタイミングで、孤立状態になる可能性があります。 たとえば、仮想マシンを削除しても、それに関連付けられているストレージ アカウントが削除されていないという場合があります。 ワークロードを確認して、不要なリソースや孤立したリソースを特定します。

3. "アイドル状態のコンポーネントの削除": 通常、デプロイ済みのリソースには関連コストが存在します。 リソースを停止または再割り当てできたとしても、リソースの料金を支払い続けることになる場合があります。 アイドル状態のリソースを削除することを検討してください。 データが必要な場合は、それを最初にバックアップしてからリソースを削除します。 リソースをアイドル状態のままにしておくよりも、リソースを再デプロイしてデータを復元する方が賢明です。

使用率の低いリソースを最適化します。 使用率の低いリソースがあるということは、完全には利用されていないリソース容量に対して支払いを行っていることを意味するので、無駄な支出があるということになります。 これらのリソースを特定して最適化することで、コストを削減し、リソースをより効果的に割り当てます。 使用率の低いリソースのコストを評価して最適化するには、以下の手順に従います。

1. "リソースの監視": ツールを使用して、実際に使用している CPU、メモリ、ストレージの量を監視します。 この情報に基づいて、自分のニーズに合った最適なプランを選択します。

2. "使用状況の分析": データを確認して、どのリソースを使用していないのかを明らかにします。 長期間使用率が小さいリソースや、ビジーな時とスローな時の使用率に大きな違いがあるリソースに注意を払います。

3. "適切なサイズ設定": 使用されていない機能に割り当てられているリソースが多すぎないかを確認します。 そうであれば、実際に必要な量に合わせてサイズを調整します。

4. "自動スケーリング": 自動スケーリングを使用して、どれだけビジーであるかに基づいて使用するリソースを調整します。 コストが嵩み必要でもない急激なスパイクを避けるために、スケーリングの上限を設定するようにしてください。

これらの調整を行った後、すべてのものが想定どおりに動作しているままであることを確認するためのテストを行います。 リソース使用率を継続的に監視し、ワークロードの需要が時間の経過と共に変化するのに合わせてリソースの割り当てを調整します。 リソース使用率を定期的に確認して最適化し、コスト効率とパフォーマンス最適化を維持します。

ディザスター リカバリー リソースを最適化します。 ディザスター リカバリー環境の最適化とは、ディザスター リカバリー用に割り当てられたリソースが効率的に使用されていることを確認することです。 ウォーム (アクティブ/パッシブ) ディザスター リカバリー戦略は、低使用率の一般的な原因です。 ウォーム ディザスター リカバリー戦略では、1 つの環境がすべての負荷を受け持ち、もう 1 つの環境は障害シナリオが発生するまでアイドル状態になります。 ディザスター リカバリー環境を最適化するには、ホット (アクティブ/アクティブ)、コールド (アクティブ/オフ)、またはアクティブ/再デプロイのアプローチが使用率の低いリソースを回避するのにどのように役に立つのかを検討してください。 これら 3 つのディザスター リカバリー アプローチの概要を以下に示します。

• "ホット プラン": プライマリ環境とセカンダリ環境の両方がトラフィックを同時に処理します。 ワークロードは、これらの環境間で負荷のバランスを取り、リアルタイムで需要に対応できます。 2 つのアクティブな環境に負荷を分散することで、より安価なリソースを使用し、単一ポイント ボトルネックを減らし、容量を最大限に活用することが可能になります。 リソースの浪費やアイドリングの観点から、これはコストの削減につながる可能性があります。 ホット アプローチでは、同期と 2 つの環境間のパリティの維持に、より多くの投資が必要になる場合があります。

• "コールド プラン": コールド ディザスター リカバリー モデルには、障害によってフェールオーバーの必要性が生じるまで休止状態のままのスタンバイ環境が含まれます。 スタンバイ環境はアクティブに実行されていないため、コンピューティング、ストレージ、ネットワークの操作に関連するコストが最小限に抑えられます。 費用は、バックアップ、仮想マシン (VM) イメージ、テンプレートの保存が中心となります。 コールド モデルでのフェールオーバーには時間がかかる可能性があります。これはリソースを起動してデータを復元する必要があるからです。 このアプローチに取り組む前に、復旧時間がビジネスの目標復旧時間 (RTO) に収まることを確認します。

• "アクティブ/再デプロイ": この戦略はコードとしてのインフラストラクチャを使用します。 フェールオーバー イベントが発生した際に、事前定義されたテンプレートとスクリプトを使用してセカンダリ環境をデプロイします。 ディザスター リカバリー環境に事前デプロイされたコンピューティング リソースが存在しないため、アイドル状態のリソースの維持に関連するコストを節約できます。 コストが発生するのは、フェールオーバー シナリオで実際のデプロイが発生する場合だけです。 コールド アプローチと同様に、このモデルで必要となる復旧時間は長く、特にインフラストラクチャの複雑性が高い場合にそれが顕著になります。 復旧時間をテストして測定し、それが目標復旧時間に収まることを確認する必要があります。

プラットフォーム機能を最適化する

プラットフォーム機能の最適化には、コストを最適化するためのパフォーマンス レベルや構成設定などのプラットフォーム機能の排除や更新が含まれます。 これは、支出をワークロードの要件に合ったものにし、不要な機能に対する不要な費用を防ぐのに役立ちます。 プラットフォーム機能のコストを最適化するためのヒントをいくつか以下に示します。

• "購入したものの機能を把握する": 最適化を行うには、すべてのクラウド プラットフォームにわたるサービスとその機能の明確なインベントリが必要です。 ワークロード内のプラットフォームまたはサービスの機能と動作を理解します。 自分が選択した特定のレベルと、各レベルが提供する機能を把握します。 たとえば、自動スケーリングや高度なネットワークを必要としない場合は、下位レベルのプランで十分な場合があります。

• "使用されていない機能の無効化": 費用がかかるプラットフォーム機能を特定して無効にします。 不要なストレージ スナップショット、使用していないディスク、冗長なセキュリティ機能、使用率の低いネットワーク機能が存在する可能性があります。

• "適切なバージョンの使用": サービスのより新しいバージョンは、同じ価格で同様のパフォーマンスを提供している可能性があります。 たとえば、新しいハードウェアを搭載した仮想マシンは、同じパフォーマンスをより低い費用で提供していることがよくあります。

• "適切な構成の使用": 必要以上の可用性やパフォーマンスに対する支払いを行っている場合があります。 ワークロードに必要のない可用性またはパフォーマンスの保証を排除します。

• "不要な自動化の排除": 自動化プロセスを評価し、余分なコストを発生させる可能性がある未使用の自動化を排除します。

• "ツールの冗長性の排除": 不要なツールや、同じ機能を提供するツールを取り除きます。 ソフトウェアのビルド、コードの記述、セキュリティ、監視に使用するツールの潜在的な冗長性を評価します。 たとえば、GitHub Actions を使用してソフトウェアをビルドする場合、ソフトウェアをビルドする別のツールを購入する必要はありません。 機能またはツールを購入する前に、そのジョブを実行できるツールがワークロード内に既に存在していないかを確認します。 ツールの冗長性を排除して無駄な費用を防ぎ、既に持っているものを最大限に活用します。

最適化されていないコンポーネントを防止する

最適化されていないコンポーネントの防止とは、追加や変更の前に、コンポーネントが不可欠で最適化されていることをあらかじめ確認することです。 無駄を取り除く最適な方法は、初めから無駄を回避することです。 根本にある非効率性に対処することで不要な費用を防ぐ戦略を使用し、ワークロードが最初からコスト効率の高い方法で実行されていることを確認します。 無駄を防ぐために、以下の戦略を検討します。

• "ソリューションの変更前に根本原因を特定する": 問題を修正する前に、実際には何がその問題を引き起こしているのかを理解するようにします。 たとえば、自分の Web サイトが遅い場合に、すぐに新しいシステムに切り替えることはしないでください。 まずは、それが遅い理由を特定します。 実際の問題は、不適切なデータベース クエリなど、他に存在することがわかるかもしれません。 実際の問題を修正することで時間とお金を節約します。

• "メタデータの適用": メタデータを適用してリソースを整理して追跡します。 メタデータを使用することでリソースを分類してグループ化し、孤立したリソースの追跡、削除、防止を簡単に行うことができます。 すべてのリソースにわたって一貫したメタデータ戦略を策定します。 所有者、予想されるリソース期間 (たとえば sunset-30d)、またはその他のタグの追加を検討します。

• "標準的ではない変更の文書化": 想定外のコストを削減するために、ワークロードの通常の制御プロセス外で実行されたインフラストラクチャまたは構成に対する変更をすべて文書化します。 たとえば、短期的な需要を満やしたり問題をトリアージしたりするためにリソースのスケーリング容量を増やしたまま (スケールアップまたはスケールアウト)、それをスケールダウンすることを忘れることがあるかもしれません。 標準的でない変更の一覧を作成し、それらが不要になったときに変更を元に戻すためのリマインダーとしてその一覧を使用します。

• "物事をシンプルにする": インフラストラクチャを簡素化し、複雑さを最小限に抑えてコストを削減します。 要件を満たす必要なリソースとサービスのみを使用します。

Azure ファシリテーション

アプリケーション機能の最適化: Azure Monitor と Application Insights を使用することで、アプリケーションの使用状況を監視し、使用されている領域と使用されていない領域を特定することができます。 収集された分析情報に基づいて、使用されていない機能や使用率の低い機能を削除または最適化するための情報に基づいた意思決定を行うことができます。

ワークロード リソースとプラットフォーム機能の最適化: Azure Advisor のコストに関する推奨事項は、使用されていないリソースを特定して排除するための推奨事項を提供します。 Advisor を使用してリソースの使用状況を分析し、削除またはスケールダウンするべきリソースに関する提案を受け取ることができます。 Azure Advisor 内のコスト最適化ブックは、使用率と効率の目標を達成するのに役立つ最も一般的に使用されるいくつかのツールの一元化されたハブとして機能します。 これによって、Azure Advisor のコストに関する推奨事項を含め、さまざまな推奨事項が提供されます。 また、これはアイドル状態のリソースを特定し、不適切に割り当て解除された仮想マシンを管理するのにも役立ちます。

Azure Monitor はブックをサポートしています。 Azure Monitor ブックを使用すると、定義されたスコープで孤立したリソースを見つけて報告するブックを検索または作成できます。 Azure Automation を使用すると、仮想マシンをアイドル時間中にシャットダウンできます。 リソースのシャットダウンは、アイドル状態のリソースの使用を最小限に抑えることによるコストの削減につながります。

Azure 内の自動スケーリング機能を使用することで、事前定義された条件に基づいてアプリケーションを自動的にスケーリングできるため、容量を過剰プロビジョニングする恐れがなくなります。 自動スケーリングは、リソースを効率的かつコスト効率よく割り当てるのに役立ちます。

設計の観点から、Azure ロード バランサーは、複数の可用性ゾーンとリージョンにわたって負荷を分散することができます。 これらのロード バランサーは、たとえばディザスター リカバリーのアプローチにおいて、アイドル状態のリソースを排除するのに役立ちます。

関連リンク

• 継続的なパフォーマンス最適化のための推奨事項
• 信頼性目標を定義するための推奨事項
• 可用性の高いマルチリージョン設計のための推奨事項
• スケーリングとパーティション分割を最適化するための推奨事項
• 支出ガードレールを設定するための推奨事項

コスト最適化チェックリスト

レコメンデーションの完全なセットを参照してください。