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

  • [アーティクル]

この Azure Well-Architected Framework のコスト最適化チェックリストの推奨事項に適用されます。

CO:07 コンポーネントのコストを最適化します。 アプリケーション機能、プラットフォーム機能、リソースなど、レガシ、不要、使用率の低いワークロード コンポーネントを定期的に削除または最適化します。

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

定義

期間 定義
アプリケーション機能 ユーザーが特定のタスクを実行したり、特定の情報にアクセスしたりできる、アプリケーション ソフトウェア内の個別の機能。
プラットフォーム機能 プラットフォームによって提供される特定の機能。 プラットフォームによって異なる場合がありますが、一般に、プラットフォーム機能は、ユーザー エクスペリエンスの向上、生産性の向上、特定のタスクやアクションの有効化を目的としています。
リソース クラウド サービス プロバイダー内で作成、構成、利用できる 1 つのエンティティまたはコンポーネント。

主要な設計戦略

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

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

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

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

機能の価値を判断するには、アプリケーション全体に対するその影響と、顧客に提供される価値を考慮します。 考慮すべきいくつかの要因は次のとおりです。

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

  • ビジネス目標: 機能がビジネスの戦略的目標とどのように一致するかを評価します。 機能が収益の生成、顧客満足度、または競争上の優位性をどのようにサポートするかを検討します。

  • ユーザー エクスペリエンスへの影響: 機能がユーザー エクスペリエンスの向上と使いやすさまたは生産性の向上に及ぼす影響を判断します。

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

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

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

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

  • メンテナンスとサポート: バグ修正、セキュリティ更新プログラム、トラブルシューティングなど、機能の保守とサポートに関連する継続的なコストを考慮してください。

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

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

  • パフォーマンスに関する考慮事項: スケーラビリティ、応答時間、リソース使用量など、アプリケーションのパフォーマンスに対する機能の影響を評価します。

利害関係者とアプリケーション機能の価値を確認する

製品マネージャー、ソフトウェア開発者、ビジネス アナリストなどの主要な担当者を関与させて、利害関係者とのアプリケーション機能の価値を確認し、ビジネス目標に関する特定の機能の価値を評価します。 このコラボレーションは、メンテナンス作業に関する分析情報を提供し、生産性を妨げたり、新しい貴重な機能の開発を妨げたりする可能性のある機能を特定するため、コストの最適化に不可欠です。 開発チームは、特定の機能を維持するために必要な作業量に関する重要な情報を提供できます。 特に、これらの機能によってチームが新しい機能を作成するのを妨げる場合は特に、価値よりも問題になる可能性がある機能について話すよう促します。

機能の将来を決定する

分析と評価に基づいて、アプリケーション機能の将来を決定します。 投資収益率を提供しないアプリケーション機能を削除、再投資、収益化します。

  • 削除: データに基づいてアプリケーション機能の計画的な終了を検討します。 機能の削除の理由には、顧客の需要が少ない、メンテナンス コストが高い、複雑さ、修正する価値がない冗長性などがあります。 削除の計画を作成します。これには、コードのリファクタリング、依存関係の更新、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 ロード バランサーは 、可用性ゾーンとリージョン間で負荷を分散できます。 これらのロード バランサーは、ディザスター リカバリーアプローチなど、アイドル状態のリソースを排除するのに役立ちます。

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

推奨事項の完全なセットを参照してください。

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