環境コストを最適化するための推奨事項

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

CO:08	環境コストを最適化します。 運用前、運用、オペレーション、ディザスター リカバリーの各環境の優先順位に合わせて支出を調整します。 環境ごとに、必要な可用性、ライセンス、稼働時間と条件、セキュリティを検討します。 非運用環境では、運用環境をエミュレートする必要があります。 非運用環境には戦略的トレードオフを実装します。

このガイドでは、ワークロード環境のコストを最適化するための推奨事項について説明します。 各環境は、その特定の目的に合わせて調整し、コスト効率を最適化する必要があります。 重要なコンポーネントを犠牲にすることなく、戦略的なトレードオフを行い、最も重要な場所にリソースを割り当てることが重要です。 環境を個別の方法で扱い、それに応じて最適化することで、コストの最適化と必要な目標の達成とのバランスを図ることができます。

定義

相談	定義
目標復旧時点 (RPO)	インシデント中のデータ損失の許容される最大期間。
目標復旧時間 (RTO)	インシデントの発生後にアプリケーションを使用不可状態にできる最大許容時間。
サービス レベル アグリーメント (SLA)	サービス プロバイダーとサービス顧客の間の契約合意。 この契約では、サービスレベル目標 (SLO) を定義します。 契約が満たされない場合、サービス プロバイダーに財務上の影響が生じることがあります。

主要な設計戦略

環境コストを最適化する目標は、運用、運用前、ディザスター リカバリー (DR) の環境など、各環境の価値、コスト、リスクの適切なバランスを見つけることです。 特定の用途に合わせて各環境をカスタマイズしてコストを節約し、リソースを効率的に使用します。 効率や顧客満足度など、各環境の利点を判断します。 あなたの希望は、直接利益をもたらさない場合でも、環境の投資収益率 (ROI) を評価することです。 高リスクの環境にはよりお金をかけて問題を軽減し、低リスクの環境ではお金を節約します。 各環境で価値、コスト、リスクのバランスを取ることを目指します。

環境の価値を評価する

各環境の価値を評価することは、ビジネスに与える広範な影響を理解し、ユーザーの満足度を測定し、それが組織全体の目標とどの程度一致しているかを判断することを意味します。 この評価は、リソースの割り当てに関する情報に基づいた意思決定を行い、コストを環境の優先順位に合わせて調整するのに役立ちます。 価値の本質は、環境がどれだけの収益を生み出すかということだけではありません。 環境の価値を評価するときは、ワークロードの目標に合わせて支出に優先順位を付ける必要があります。 各環境の価値を評価するには、次の要素を考慮します。

• ユーザーを考慮する: 各環境を使用するユーザーと、必要としているものを検討します。 たとえば、顧客が使用する運用環境は信頼性が高く、パフォーマンスとアップタイムに関して特定の SLA を満たしている必要があります。

  一方、開発環境は主に開発者やテスト担当者などのワークロード チーム向けです。 この環境は顧客向けの SLA を満たす必要はありませんが、チームが効率的に作業するために必要なツールとリソースを備えている必要があります。

  各環境のユーザーに固有のニーズを理解すると、リソースをより適切に割り当て、余分なコストを回避することができます。 このような回避によって、各環境が確実に機能し、コスト効率が高くなります。

• 組織の価値基準と整合させる: コスト削減の取り組みを、利益や従業員の満足度といった組織の優先事項と整合させます。 各環境について、成功がどのように定義されるかを理解し、目標達成に向けて行動を維持できるようにします。 たとえば、組織が利益の最大化や従業員の満足度に重点を置いている場合は、それらのメトリックに合わせて支出の判断を下します。

環境コストを判断する

環境コストの特定とは、各ワークロード環境におけるインフラストラクチャ、サービス、ライセンス、運用に関する費用のコストを把握することです。 コスト管理ツールは、環境全体の支出のパターンと傾向を分析する上で重要な役割を果たします。 環境コストを判断するには、次の戦略を検討します。

• コスト要因を特定する: 各環境でコストを左右する主な要因を特定します。 これらの要因には、リソース使用率、ストレージ使用量、データ保持、データ転送、特定のサービスなどがあります。

• リスクを評価する: 支出の決定に関連付けられたリスクと、それが環境や業務に及ぼす潜在的な影響を評価します。 データ セキュリティ、コンプライアンス、パフォーマンス、監査、SLA 要件などの要因を考慮します。

• 支出を監視し、調整する: 支出パターン、価値の提供、リスク要因を継続的に監視し、分析します。 環境やビジネスのニーズの進化に応じて、支出の最適化戦略を定期的に見直し、調整します。

運用環境を最適化する

運用環境でコストを最適化するには、不要な費用を削減し、運用効率を高める戦略を実施する必要があります。 運用デプロイの差別化とユーザー ニーズへの対応に重点を置きます。 運用環境の最適化に関する推奨事項は以下のとおりです。

• リージョンを差別化する: サービス提供対象の顧客が少ないリージョンへの支出を減らします。 たとえば、ユーザーの 10% にサービスを提供するリージョンよりも、ユーザーの 90% にサービスを提供するリージョンにより多くの投資を行うようにします。 各リージョンとユーザー セグメントの要件を満たすようにデプロイ戦略を調整します。

• スケーリングを差別化する: 水平および垂直のスケーリング戦略を実施します。 過剰なプロビジョニングを行わずに、需要に合わせてリソースを効率的にスケーリングします。

• インフラストラクチャを差別化する: 必要なパフォーマンスとスケーラビリティを満たす、コスト効率の高いハードウェアとインフラストラクチャのソリューションを選択します。 パフォーマンス、コスト、信頼性、スケーラビリティなどの要素を考慮します。

• テナント モデルを調整する: テナント モデルに基づいて環境をカスタマイズします。 たとえば、有料テナントのサービスと機能により多くの費用を費やし、無料テナントの費用を減らします。

DR 環境を最適化する

DR 環境とは、中断を伴うイベントの発生後にワークロードが復旧するために使用するインフラストラクチャとプロセスを指します。 中断を伴うイベントには、自然災害、サイバー攻撃、ハードウェア障害などがあります。 DR 環境の維持コストと、中断を伴うイベントの潜在的な影響のバランスを取ります。 次の戦略を検討してください。

• システムとデータの重要性を評価する: システムとデータの重要性を評価し、各コンポーネントに必要な保護レベルとリソースを判断します。

• RTO と RPO を判断する: DR 環境の設計を判断するために、システムまたはアプリケーションごとに許容できるダウンタイムとデータ損失の限界を定義します。

• コールド DR 環境を最適化する: コールド DR 環境には、インフラストラクチャや実行中のサービスがほとんど、またはまったくありません。 コードとしてのインフラストラクチャ (IaC) を使用すると、中断を伴うイベントが発生したときにインフラストラクチャをすばやくデプロイできます。 バックアップとストレージのポリシーは、環境の RPO と RTO を満たす必要があります。 データ バックアップの量と頻度を必要以上に堅牢にしないようにします。

  トレードオフ: コールド DR 環境はコスト効率の高いオプションですが、復旧に時間がかかることがあります。

• ホット DR 環境を最適化する: すべてのインフラストラクチャとサービスがホット DR 環境で実行されます。 データはプライマリ サイトとリアル タイムでミラー化されます。 災害発生時にほぼ瞬時のフェールオーバーを実現し、データ損失を最小限に抑えることができます。 コストを最適化するには、アクティブ/アクティブ デプロイを検討します。

• ウォーム DR 環境を最適化する: ウォーム DR アプローチは、コールド DR 環境とホット DR 環境の中間に位置するものです。 ウォーム環境は部分的にアクティブであり、プライマリ サイトと定期的に同期されます。 コストと復旧時間のバランスが取れます。 ただし、コスト面では最も最適化されていないアプローチです。 コストを最適化するには、コールド アプローチまたはホット アプローチを検討します。

運用前環境を最適化する

運用前環境を最適化するには、不要なコストを削減しながら運用環境を厳密にシミュレートできるように、開発、テスト、ステージング領域内のリソースを戦略的に管理する必要があります。 運用前環境には、運用環境レベルのスケールと可用性は必要ありません。 特定のテストと開発のニーズに合わせてこれらの環境を調整することが最も効果的です。運用を完全に複製する必要はありません。 コスト削減の領域には、より低コストのリソースの使用、不要なサービスの停止、運用前の使用に提供される割引の適用などがあります。 運用前環境を最適化するには、次の戦略を検討します。

運用前環境を評価する

運用前環境の割り当てが不十分または不適切であると、リソースが過剰プロビジョニングまたは過小プロビジョニングになる可能性があります。 ワークロードに合わせて運用前環境を評価するには、次のガイダンスを検討します。

• 環境の種類を理解する: ワークロードに必要な開発、テスト、ステージングなどの運用前環境の種類を特定します。 リソース割り当てを効率的にするには、各環境に定義したロールと特定の機能を持たせる必要があります。

• ユーザーの要件に合わせる: 運用前環境を設定する前に、ユーザーの要件と期待を理解します。 ニーズに基づいて機能と仕様を調整し、機能やリソースの不要な費用を避けます。

• 環境を統合する: 機能を損なうことなく環境を統合できるかどうかを判断します。 重複しない機能を持つ環境を組み合わせます。 たとえば、ユーザー受け入れ環境と品質保証環境を統合できます。 これらの機能は異なり、通常、一方の環境が使用されているときは、もう一方の環境はアイドル状態になります。

  リスク: 環境を組み合わせる場合は、競合が発生したり、テストや開発のプロセスが損なわれたりしないように注意してください。

一般的な運用前環境の例を次の表に示します。

運用前環境の例	説明
開発環境	開発者はこの環境を使用してコードを作成し、テストします。 サンドボックス空間として機能するので、開発者はコードの変更を実験、構築、統合できます。
品質保証環境	この環境は品質保証アクティビティに特化しています。 運用環境にデプロイする前にバグや問題を特定して修正するためのテスト用です。
セキュリティ環境	この環境はセキュリティ テスト用です。 アプリケーションが脅威や脆弱性に対してセキュリティで保護されていることを確認するためのものです。
ユーザー受け入れテスト環境	この環境では、エンド ユーザーと関係者がアプリケーションをテストしてその機能を検証し、要件と期待を満たしていることを確認します。
ステージング環境	この環境は運用環境によく似ています。 運用環境にデプロイする前の最終的なテストと検証用です。

ガバナンスを適用する

ガバナンスの適用とは、運用前環境でのデプロイ オプションを制限して、費用を制御し、リスクを軽減することです。 運用前では、柔軟に構成を調整してリソースをデプロイすることができます。 運用前環境が運用環境からかけ離れるほど、潜在的なリスクは大きくなります。 ガバナンスを使用して運用前環境を制限します。 次のガイドラインを考慮してください。

• パフォーマンス レベルを制限する: 運用前環境のパフォーマンス要件を評価します。 コストとパフォーマンスのバランスが取れるパフォーマンス レベルを選択します。 多くの場合、サービスにはさまざまなパフォーマンス レベルがあり、このようなレベルの中にはテストに適したものもあります。 一部のサービスには、運用と同様の機能を提供するレベルがありますが、SLA は適用されません。 これらのサービスはコストを削減すると同時に、テストと開発に必要な機能を提供します。

• 運用前 SKU について理解する: 一部の SKU は開発環境向けに設計されています。 コストを最適化するには、サービスとレベルを評価します。 ワークロードにハイ パフォーマンスが必要ない場合は、低パフォーマンス レベルを選択します。

• インスタンスと CPU の数を制御する: ワークロードの需要に基づいて、運用前環境に必要なインスタンスと CPU リソースの最適な数を判断します。 コストを最小限に抑えるために、リソースの過剰なプロビジョニングを避けます。

• 保持とログを制限する: 運用前環境のログとデータの保持ポリシーを定義します。 コンプライアンス要件とコストの考慮事項に基づいて、ログとデータの保持に必要な期間を検討します。 ストレージ コストを削減するには、過剰なログと保持を避けます。

• 一貫性のある CPU アーキテクチャを使用する: 運用前と運用で同じ CPU アーキテクチャを使用します。 たとえば、x86 アプリケーションは Azure Resource Manager 上でネイティブに実行できません。また、その逆も同様です。 互換性を確保し、潜在的な問題を最小限に抑えるために、運用環境と同じ CPU アーキテクチャを使用します。

• 同じオペレーティング システムを使用する: 運用前環境では、オペレーティング システム (Windows から Linux へなど) やカーネルを変更しないでください。 多くの場合、Windows 用に構築されたソフトウェアは、互換性レイヤーがなければ Linux 上でネイティブに実行できません。また、その逆も同様です。 ファイル システムとディレクトリ構造が異なるため、アプリケーションのパッチ適用の問題が発生する可能性があります。 一貫性のある環境にすると、互換性の問題のリスクを軽減し、確実にスムーズにデプロイすることができます。

• スケーリングを制限する: コストを最適化するために、自動化を制限して自動化の暴走を抑えることができます。 たとえば、開発環境では最大スケーリング制限を 3 に設定し、運用環境では 10 に設定します。 スケーリングを制限して、リソースの使用量と自動化コストを制御します。

• 不要なリソースをオフにする: 業務時間外や週末など、リソースがアクティブに使用されていないときはリソースをオフにします。 自動化ツールまたはスクリプトを使用して、リソースのシャットダウンと起動をスケジュールできます。 一部のベンダーは、プログラムでリソースを停止および開始できる API を提供しています。 IaC を使用して、必要がなくなった時点で削除できる一時的な環境を作成することを検討します。

• 使用できるリージョンを制限する: Azure リソースが安く済む可能性があるさまざまなリージョンで運用前環境を実行することの利点の可能性を検討します。 運用前デプロイをこのようなリージョンに制限することで、これらの環境のコストを最適化します。

運用との類似性のバランスを取る

多くの場合、運用前環境で運用環境を正確にミラー化することは不必要であり、コストがかかります。 目標は、各運用前環境を運用とは適宜異なるものにして、不要なコストを避けることです。 ただし、運用前と運用が異なる場合、運用にバグがデプロイされるリスクがあります。 これらの環境が異なるほど、リスクは高まります。 ニーズに合わせて運用前環境を調整することで、コストを最適化しながらリスクを管理できます。 運用との類似性のバランスを取るには、次の推奨事項を検討します。

• 正確なレプリカを避ける: 運用前環境を運用の正確なコピーにすることは避けます。 コストが不必要に増加する可能性があります。 コスト効率が高く、デプロイ前に潜在的なリスクを検出して対処できる運用前環境を作成します。

• 極端にかけ離れないようにする: 異なるサービスの使用など、運用から過度にかけ離れないようにします。 サービスによっては、実際のリスクを正確にシミュレートできない場合があります。 リスクのしきい値を決定し、コスト節約だけを理由にしきい値を超えないようにします。

• ランタイムを短縮する: コストを節約するために、運用前ステージのプロセスのランタイムを短縮することを検討します。 検出されないメモリ リークなど、新たに発生する可能性のある脆弱性に注意してください。

• ライセンスを確認する: セキュリティ ツールのライセンス プランを確認します。 運用と運用前のセットアップでノード数が大幅に異なる場合は、セキュリティを損なうことなくコストを微調整するニーズを再評価します。

開発環境を最適化する

開発環境は、開発、テスト、デバッグを目的として設計されています。 ライフサイクルは短く、多くの場合は必要に応じて作成されるので、存在するのは短期間です。 開発環境は、通常、信頼性、容量、セキュリティに関する要件が他の運用前や運用の環境よりも低くなります。 機能数は少ない可能性があり、低いリソース使用率を許容できます。 開発環境を最適化するには:

• ツールの評価: 統合開発環境 (IDE)、ライセンス、関連ツールなど、現在のツール セットアップのコスト効率を定期的に評価します。 品質を損なうことなく同様の機能を提供する、無料またはオープンソースの代替品を検討します。 開発環境の進化に合わせて、これらのツールの必要性と効率性を継続的に再評価します。

• ハードウェアを検討する: 現在のハードウェア セットアップのコストとパフォーマンスを評価します。 より優れた、より効率的なハードウェアに投資すると、生産性が向上し、長期的なコストが削減されます。 ハードウェアを頻繁に交換するのではなく、既存のシステムをアップグレードして寿命を延ばし、パフォーマンスを向上させることを検討します。

• 環境の数を最適化する: 個別の開発環境と共有環境の長所と短所を分析します。 個々の環境で運用セットアップを模倣し、開発者間の干渉を防ぎ、カスタマイズされたセットアップを提供できます。 ただし、開発者数が増えると、スケーリングのコストが高くなります。 共有環境はコストを節約できますが、問題が開発チーム全体に同時に影響を与える場合、信頼性の懸念が生じる可能性があります。 コスト、リスク軽減、効率性、開発者の満足度に基づいて適切なバランスを見つけてください。

• 定期的にクリーンアップする: 孤立したリソース、使用されていないデータ、概念実証実験が蓄積されないように、開発環境を定期的にクリーンアップして最適化します。 クリーンアップ プロセスまたは自動ツールを実装し、使用されていないリソースを特定して削除します。 必須かつ有効なコンポーネントのみを保持します。 定期的なクリーンアップにより、ストレージ コストを削減し、リソースを効率的に使用することができます。

• サンプリングによるスケーリングを実装する: すべてのコンポーネントを最大容量までスケーリングするのではなく、重要なコンポーネントを選択してスケーリングするサンプリング アプローチを検討します。 このアプローチは、リスクを最小限に抑えながらコスト効率を高めることができます。 特定の要素をスケーリングしない場合のリスクと利益の比率を評価し、環境への潜在的な影響を考慮します。

• データ管理を最適化する: 開発環境では、データ保持とバックアップの頻度の必要性が低い可能性があります。

エンドポイント エミュレーションを検討する

特に GPU などのコストが高いリソースについては、エンドポイント エミュレーションやモック エンドポイントを使用することで、運用前環境のコストを最適化できます。 運用前環境で最もコストがかかる、またはリソースを大量に消費するコンポーネントまたはサービスを特定します。 モック エンドポイントを使用して、このような高コストのコンポーネントを呼び出すことなく、その応答をシミュレートします。 API 応答をシミュレートするには、商用またはオープン ソースの API モック サーバー、あるいはカスタム実装を使用できます。

エミュレーションとモック エンドポイントはコストの節約に役立ちますが、テストに十分な程度まで運用環境を再現していることを確認する必要があります。 正確性とコストのバランスを取り、将来的に運用で問題が発生しないようにします。 たとえば、GPU が主要なコスト要因である場合、運用前ステージで実際の GPU 処理能力を必要としないタスクには GPU エミュレーションを検討します。 エミュレーションは実際の GPU のパフォーマンスや特性を完全には再現していない可能性があるため、運用前テストで GPU の正確な動作が重要ではない場合に使用してください。

Azure ファシリテーション

環境コストを判断して最適化する: Microsoft Cost Management は、組織が Microsoft Cloud ワークロードのコストの監視、割り当て、最適化を行うのに役立つ一連のツールです。 Cost Management は、課金スコープまたはリソース管理スコープにアクセスできるすべてのユーザーが利用できます。

Azure Advisor は、最適化が必要な仮想マシンの使用領域の特定など、コストの最適化に関する推奨事項を提供するツールです。 Advisor を使用すると、情報に基づいて意思決定を行い、Azure 環境のコストを最適化できます。 Azure には、支出の優先順位付けに役立つコスト管理ツールと機能が用意されています。 これらのツールを使用すると、環境全体のコストを追跡して分析し、予算を設定し、コスト最適化の推奨事項を受け取ることができます。

ガバナンスの適用: Azure Policy を使用して、Azure 環境にデプロイできるリソースの種類に制限を適用するポリシー ルールを定義することで、リソースの種類、SKU、インスタンスを制限できます。 プロビジョニングされたリソースの制御を維持し、組織のポリシーとベスト プラクティスに確実に準拠できます。

Azure Policy を使用してリソースの種類を制限するには、許可するリソースの種類を指定するポリシー規則を定義します。 これらの規則を該当する Azure サブスクリプションまたはリソース グループに適用します。 Azure Policy により、許可されていないリソースをユーザーがデプロイできなくなります。

Azure Resource Manager を使用して、宣言的な方法でリソースを定義および管理します。 各環境に割り当てられるリソースは、それぞれの要件に基づいて調整できます。 テンプレートを使用し、リソース構成をパラメーター化してコストを最適化します。

運用前環境の最適化: Azure には、非運用環境に割引料金を適用する Dev/Test 価格オプションが用意されています。 より多くのリソースと予算を重要な運用環境に割り当て、非運用環境のコストを最適化できます。 Azure ライセンス プランである Azure ハイブリッド特典を使用することもできます。

API のモック作成には Azure API Management を使用できます。 API Management はバックエンド サービスのファサードとして機能します。これにより、API プロバイダーは API コンシューマーに影響を与えることなく API の実装を抽象化し、バックエンド アーキテクチャを進化させることができます。

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

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

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