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

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

CO:08	環境コストを最適化します。 運用前、運用、運用、ディザスター リカバリー環境に優先順位を付けるために支出を調整します。 環境ごとに、必要な可用性、ライセンス、営業時間と条件、セキュリティを考慮してください。 非運用環境では、運用環境をエミュレートする必要があります。 非運用環境に戦略的トレードオフを実装する。

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

定義

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

主要な設計戦略

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

環境の価値を評価する

各環境の価値を評価することは、ビジネスに対するより広範な影響を理解し、ユーザーの満足度を測定し、組織の目標を包括的に調整する方法を決定することを意味します。 この評価は、リソースの割り当てに関する情報に基づいた意思決定を行い、コストを環境の優先順位に合わせて調整するのに役立ちます。 価値の本質は、環境によって生み出される収益を超えています。 環境の価値を評価する場合は、ワークロードの目標に共感する方法で支出に優先順位を付ける必要があります。 各環境の価値を評価するには、次の要因を考慮してください。

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

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

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

• 組織の価値の尺度に合わせる: コスト削減の取り組みを、利益や従業員の満足度など、organizationの優先事項に合わせます。 環境ごとに、成功がどのように定義されているかを理解して、ターゲットに対してアクションを維持できるようにします。 たとえば、organizationが利益の最大化や従業員の満足度に重点を置いている場合は、支出の決定をそれらのメトリックに合わせます。

環境コストを決定する

環境コストの決定は、各ワークロード環境におけるインフラストラクチャ、サービス、ライセンス、運用コストのコストを把握することです。 コスト管理ツールは、環境全体の支出パターンと傾向に関する分析情報を得るための鍵です。 環境コストを決定するには、次の戦略を検討します。

• コスト ドライバーの特定: 各環境でコストを促進する主な要因を特定します。 これらの要因には、リソース使用率、ストレージ使用量、データ保持、データ転送、および特定のサービスが含まれます。

• リスクの評価: 支出の決定に関連するリスクと、環境とビジネス運用に対する潜在的な影響を評価します。 データ セキュリティ、コンプライアンス、パフォーマンス、監査、SLA 要件などの要因を考慮してください。

• 支出の監視と調整: 支出パターン、価値の提供、リスク要因を継続的に監視および分析します。 環境とビジネスのニーズが進化するにつれて、支出の最適化戦略を定期的に確認して調整します。

運用環境を最適化する

運用環境でのコストの最適化には、不要なコストを削減し、運用効率を向上させる戦略を実装する必要があります。 運用環境のデプロイを区別し、ユーザーのニーズを満たすことに重点を置きます。 運用環境を最適化するための推奨事項を次に示します。

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

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

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

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

DR 環境を最適化する

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

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

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

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

  トレードオフ: コールド 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 リソースが安価になる可能性があるさまざまなリージョンで運用前環境を実行する場合の潜在的な利点を検討してください。 これらの環境のコストを最適化するために、運用前のデプロイをこれらのリージョンに制限します。

生産との類似性のバランスを取る

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

• 正確なレプリカを避ける: 実稼働前環境を運用環境の正確なコピーにしないでください。 不必要にコストが増加する可能性があります。 Createコスト効率は高いが、デプロイ前に潜在的なリスクを明らかにして対処できる実稼働前環境です。

• 極端な逸脱を避ける: 異なるサービスの使用など、運用環境からの過度の逸脱を避けます。 異なるサービスでは、実際のリスクを正確にシミュレートできない場合があります。 リスクのしきい値を決定し、コストを節約するためだけにしきい値を超えないでください。

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

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

開発環境を最適化する

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

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

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

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

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

• サンプリングスケーリングを実装する: すべてのコンポーネントを最大容量にスケーリングする代わりに、重要なコンポーネントを選択的にスケーリングするサンプリングされたアプローチを検討してください。 このアプローチは、リスクを最小限に抑えながら、コスト効率が高い場合があります。 特定の要素をスケーリングしないというリスクとベネフィットの比率を評価し、環境に対する潜在的な影響を考慮します。

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

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

エンドポイント エミュレーションまたはモック エンドポイント (特に GPU などの高価なリソース) を使用して、実稼働前環境でコストを最適化できます。 最もコストが高い、またはリソースを集中的に消費する運用前環境のコンポーネントまたはサービスを特定します。 モック エンドポイントを使用して、これらのコストのかかるコンポーネントの応答を呼び出さずにシミュレートします。 API 応答をシミュレートするには、WireMock、Postman のモック サーバー、カスタム実装などのツールを使用できます。

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

Azure ファシリテーション

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

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

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

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

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

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

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

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

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

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