コスト最適化の設計原則

アーキテクチャ設計は常にビジネス目標に基づいて行われ、 投資収益率 (ROI) と財務上の制約を考慮する必要があります。 考慮すべき一般的な質問は次のとおりです。

• 割り当てられた予算を使用すると、目標を達成できますか?
• アプリケーションとその操作の使用パターンは何ですか? 優先領域とは
• 使用率の向上や削減によって、リソースへの投資をどのように最大化しますか?

コスト最適化ワークロードは、必ずしも低コストのワークロードであるとは限りません。 大きなトレードオフがあります。 戦術的アプローチは事後対応型であり、短期的にのみコストを削減できます。 長期的な財務責任を達成するには、 優先順位付け、継続的監視、最適化に焦点を当てた反復可能なプロセス を含む戦略を作成する必要があります。

設計原則は、ワークロード アーキテクチャを設計して実装するときに考慮する必要がある最適化戦略を提供することを目的としています。 推奨されるアプローチから始め、 一連のビジネス要件の利点を正当化します。 戦略を設定したら、次の手順として コスト最適化チェックリスト を使用してアクションを推進します。

テクノロジのニーズに合わせてビジネス要件に優先順位を付ける際に、コストを調整できます。 ただし、 セキュリティ、スケーラビリティ、回復性、操作性など、コストを最適化する必要がある分野では、一連のトレードオフが必要です。 これらの分野の課題に対処するコストが高く、これらの原則が適切に適用されていない場合は、より安価なソリューションを優先して危険な選択を行い、最終的にorganizationのビジネス目標と評判に影響を与える可能性があります。

コスト管理規範を開発する

予算、経費、レポート、コスト追跡を認識するチーム カルチャを構築します。

コストの最適化は、organizationのさまざまなレベルで行われます。 ワークロードが組織の目標と FinOps プラクティスにどのように適合しているかを理解することが重要です。 事業単位、リソース organization、一元化された監査ポリシーを表示することで、標準化された財務システムを採用できます。

アプローチ	特長
コスト モデルを開発する。 この基本的な演習は、財務追跡システムを設定するための前提条件です。	コスト モデルは、コストをセグメント化し、インフラストラクチャ、サポート、実装を含む 総保有コストを見積もり、予測するのに役立ちます。 これにより、コスト 要因を早期に特定し、変化、成長、または収縮が予想されるビジネス モデルの全体的な支出にどのように影響するかを予測できます。
適切に割り当てられた役割と責任を持って実装された 、効果的かつ柔軟なアビリティ モデル を備えています。	アーキテクチャの進化に伴い、さまざまな役割が意思決定に関与します。 明確なアカウンタビリティは、各ロール (スコープを指定) の 機能的な期待を適用 し、明確にし、必要なレベルで透明性のあるレポートを生成するのに役立ちます。
交渉不可能なすべての機能要件と非機能要件、人員とトレーニング コスト、予想される成長を提供するプロセスをカバーする 現実的な予算 を見積もります。	財務境界を設定し、割り当てられた予算に対して支出をチェックする方法を確立できます。 また、特定のしきい値を超えると通知を受け取ります。これにより、テナント スコープ、リソース スコープ、および予算に適用されるその他のスコープで過剰な保留中が防止されます。
ガバナンスとプロセスを使用して、アビリティ モデルと予算を実装します。	それは反動なので、通知を受け取るには十分ではありません。 プロアクティブ ガバナンス は、予算を超える不要な支出につながる可能性のあるアクションを回避するのに役立ちます。 特定のアクションにより、現在の状態が改善される可能性があります。 アイテム保持ポリシーが緩和されすぎているか。 責任あるエンジニアリングを確保するには、スケーラビリティの制限が必要ですか?
経費をキャプチャして分類するシステムの機能を構築します。	さまざまな請求境界で 技術的およびビジネス上の観点を明らかにするコストを 計算できます。 また、定期的なレビューを実施し、ショーバックとチャージバックのプロセスを推進することもできます。
ワークロードが成熟するにつれてスキルを強化するために 必要なトレーニング コスト、雇用費、インフラストラクチャのコスト を計画します。	スタッフへの投資は、フルタイムまたはベンダーサポートを通じて 既存のスキルを補完 します。
アーキテクトとアプリケーション所有者からの アップストリーム通信 を奨励します。	フィードバックに基づいて行動すると、研究コストが削減されます。これは、数値データと同じくらい意味のあるものとみなされます。 従業員の入力を使用して 、現実的な設計変更 とビジネス戦略を推進することで、従業員を支援します。

コスト効率の考え方を使用して設計する

投資に対する最高のリターンを達成するために必要なものだけに費やします。

すべてのアーキテクチャ上の決定には、直接的および間接的な財務上の影響があります。 ビルドと購入オプションに関連するコスト、テクノロジの選択、課金モデルとライセンス、トレーニング、運用などを理解します。

一連の要件を考慮して、ワークロードの横断的な懸念に効果的に対処するコストに関連して、トレードオフの決定を最適化して行います。

アプローチ	特長
ROI への影響を考慮して、テクノロジと自動化の選択によって発生する総コストを測定します。 設計は、すべての機能要件と非機能要件に対して許容できる境界内で動作する必要があります。 また、予測される進化に対応するために、設計は柔軟である必要があります。 取得、トレーニング、変更管理のコストを考慮します。	ROI を考慮したバランスの取れたアプローチを実装 すると、オーバーエンジニアリングが防止され、コストが増加する可能性があります。 コストが高く、ビジネス上の正当な理由がない代替手段を破棄すると、他の分野で使用できる予算のバッファーが提供されます。 計画的な成長を超えて設計することはお勧めしません。これは、短期的な設計の選択とトレードオフの報酬に割り当てられる投資を迂回する可能性があるためです。
要件を満たすのに最適な課金モデルを使用して、初期コストを確立します。	コスト見積もりを絞り込むには、コストと予算の比較を予測し、メインコストの要因を特定するのに役立ちます。 コスト ドライバーはビジネス要件を満たすのに役立ちますか? 選択内容を再調整し、その他のコスト効率の高いオプションを評価するには、初期コストを把握しておく必要があります。 設計が純粋な仮定の状態であった場合に検出されない可能性がある隠されたコストを明らかにします。
全体的なコストを削減したり、追加の投資を必要としたり、機能に大きな影響を与えたりしないサービスに優先順位を付けることで、設計を微調整します。 優先度設定は、高い ROI をもたらすビジネス モデルとテクノロジの選択を考慮する必要があります。	リソースの柔軟性や動的スケーリングを可能にする、または既存の投資の使用を正当化する可能性がある、より安価なオプションを調べることができます。 優先度設定パラメーターでは、重要なワークロード、ランタイム、運用に必要なコストや、チームの作業効率を高めるのに役立つその他のコストが考慮される場合があります。
コスト ガードレールをサポートするようにアーキテクチャを設計します。	ガバナンス ポリシーまたは組み込みのアプリケーション設計パターンを使用して適用すると、偶発的または未承認の料金を防ぐことができます。
サービス レベル アグリーメント (SLA) によってサポートされるワークロードの場合は、ペナルティの 予算を予約する場合と実装に使用することの長所と短所を比較検討します。 実装が健全な場合は、ペナルティを回避できます。	設計が意図した機能を果たし、コミットメントを満たしていることを確認することは、責任の最終的なリスクを軽減するプロアクティブなアプローチです。 現実的なコストコミットメントを交渉したり、製品所有者と協力して専用の違反予算を作成したりすると、これらの目標をより達成しやすくなります。

使用の最適化を設計する

リソースと操作の使用を最大化します。 これらを、ソリューションのネゴシエートされた機能要件と非機能要件に適用します。

サービスとオファリングは、さまざまな機能と価格レベルを提供します。 一連の機能を購入した後は、それらを十分に活用しないでください。 レベルへの投資を最大化する方法を見つけます。 同様に、課金モデルを継続的に評価して、現在の運用環境のワークロードに基づいて、使用量に合ったモデルを見つけます。

アプローチ	特長
選択した リソース SKU が 、パフォーマンス、セキュリティ、信頼性、または運用目標を満たすのに役立つ追加機能を提供するかどうかを評価します。	設計用に選択した SKU によって提供される機能を利用することで、支払った分を最大限に活用し、 未使用の機能に対する支払いを回避できます。
実用的な場合は、従量課金制の価格を使用します。	使用した分を正確に支払います。 このオプションは、完全に利用されたプリペイド オプションよりもコストが高くなる可能性があります。 ただし、 事前購入済みのコンピューティングを完全に利用する予定がない場合は、消費課金の方が適している可能性があります。
ポリシーを適用 して、設計と設計の上限と下限に準拠します。	ガバナンスにより、許可されているリージョンとサービスとその予算数量のみがプロビジョニングされます。 このガバナンス により、リソースの無駄と過剰なプロビジョニングが削減されます。
リソースに対して既に支払っている場合は、復旧計画の一環として、アクティブ/アクティブ モデルまたはアクティブ/パッシブ モデルよりもアクティブ/アクティブのみのデプロイに優先順位を付けます。	設計が既定でアクティブ/パッシブ モデルを使用している場合は、それ以外の場合に使用できる アイドル 状態のリソース が存在する可能性があります。 アクティブ/アクティブに変換すると、負荷平準化とスケーリングバーストの要件を満たすことができます。オーバーペンディングは不要です。 アクティブのみのモデルで復旧ターゲットを満たすことができる場合は、それらのリソースのコストを完全に削除できます。
未使用のリソースとデータ のデプロイを 定期的かつ厳格に確認し、使用を停止します。	未使用のリソースをシャットダウンし、不要になったときにデータを削除すると、無駄が減り 、資金が解放され、他の場所に投資できるようになります。
割引された長期プランで コミットしたリソース の追加の用途を見つけます。	事前購入されたリソース、既存のライセンス、および未使用のコミットメント ベースの割引リソースを検討してください。 これらのリソースを使用すると、コストを節約できます。 これらのリソースは、テスト、追加環境、または機能要件と非機能要件に対処するために使用できます。 同様に、ワークロードが使用しているリソースにコミットされたプランを利用する機会を見つけることで、ワークロードは事前コミットを介してそれらのリソース コストを最適化できます。
サポート プランへの投資を活用します。	サポート プランを使用して 運用の問題を処理したり、プロアクティブなレビュー を行ったりすると、お金の価値を得るのに役立ちます。 Microsoft サポート モデルに完全に関与します。

レート最適化の設計

機能要件または非機能要件を再設計、再ネゴシエーション、または犠牲にすることなく、効率を向上させます。

既存のリソースと運用のユーティリティとコストを最適化する機会を活用します。 そうでない場合は、ROI を追加せずに不必要にお金を費やします。

アプローチ	特長
コミットと事前購入によって最適化し、時間の経過と同時に変化することが予想されない、コストと使用率が予測可能なリソースの種類に対して提供される 割引を利用 します。 また、ライセンス チームと協力して、将来の購入契約プログラムと更新に影響を与えます。	Microsoft では、特定のリソースとリソース カテゴリに対する予測可能で長期的なコミットメントの料金を削減します。 リソースは、使用期間中にコストが削減され、期間中に償却できます。 ライセンス チームは、リソース別の現在および予測される投資を把握しておくことで、organizationが契約に署名したときに適切なサイズのコミットメントを支援できます。 場合によっては、これらの予測とコミットメントがorganizationの価格シートに影響を与える可能性があり、ワークロードのコストと同じテクノロジを使用する他のチームにもメリットがあります。
追加のライセンスを 必要としない代替手段を評価することで、ライセンス コストを削減する方法を見つけます。 ハイブリッド使用や運用前サブスクリプションの価格などのオプションを検討してください。	サービス、オペレーティング システム、ツールの ライセンス コストを削減 するには、同じテクノロジまたは同等のテクノロジに対する使用権を低コストで付与するオプションを利用します。
リソースの使用率が高く予測可能で、同等の SKU または課金オプションが使用可能な場合は、リソースの従量課金ではなく固定価格の課金に切り替えます。	使用率が高く予測可能な場合、固定価格モデルは通常、コストが低く、多くの場合、より多くの機能をサポートします。 これを使用すると、ROI が向上する可能性があります。
organizationによって提供される一元化されたリソースを使用し、他のチームとコストを共有します。	共有リソースは、多くの場合、複数のワークロードをサポートする容量が高く、 コストはチーム間で分散されます。 共有リソースに依存すると、ワークロードの機能が損なわれていない限り、コストを節約できます。 ショーバックとチャージバックは、他の潜在的な利点です。
コストの低いリージョンにデプロイします。	一部の地域では、より安い価格でサービスを提供しています。 機能要件と非機能要件を引き続き満たすことができる場合は、これらのリージョンの使用を検討する必要があります。 さらにメリットを得られるのは、運用環境でできない場合でも、環境ごとのリージョンの選択を評価し、運用前環境に有利な価格を使用する可能性があります。
他のリソース、ワークロード、さらにはチームと一緒に使用状況を検索します。 より高い密度を実現しやすくするサービスを優先します。 潜在的なトレードオフ (特にセキュリティの境界) を考慮してください。	ハードウェア使用率を最適化することで、コストを節約できます。 密度が高くなるにつれて、ワークロードを実行するために必要なリソースの量が減少します。 これにより、ユニットあたりのコストと管理コストが削減されます。

時間の経過に伴う監視と最適化

ワークロードがエコシステムと共に進化するにつれて、継続的に適切なサイズの投資を行います。

昨日の重要なことは、今日は重要ではないかもしれません。 運用ワークロードの評価を通じて学習するにつれて、 アーキテクチャ、ビジネス要件、プロセス、さらにはチーム構造の変化を期待できます。 ソフトウェア開発ライフサイクル (SDLC) プラクティスを進化させる必要がある場合があります。 クラウド プラットフォーム、そのリソース、契約など、外部要因も変わる可能性があります。

すべての変更がコストに与える影響を慎重に評価する必要があります。 変化と ROI の傾向を定期的に監視し、機能要件と非機能要件を調整する必要があるかどうかを評価します。

アプローチ	特長
コスト追跡システムを使用して、リソース、データ、有料サポートのコストを継続的に評価して最適化します。 廃止、置換、再構築、またはリファクタリングできる使用率の低いリソースはありますか?	十分に利用されていないリソースに対する支払いを回避することで、コストを削減できます。 価格メトリックを理解すると、コスト モデルに合った意思決定を行うのに役立ちます。 また、不当な課金を防ぐことができます。 使用率の低いリソースのサイズを変更または削除したり、SKU を変更したりすることで、コストを削減できます。 また、サポート 契約の使用を評価し、適切なサイズ設定を行うことで、コストを節約できる場合もあります。
ROI データに基づいてアーキテクチャ設計の決定、リソース、コード、ワークフローを継続的に調整します。	メトリック、パフォーマンス データ、課金レポート、機能の使用状況を定期的に確認すると、 コストを削減できる微調整につながる可能性があります。
異なる SDLC 環境を異なる方法で扱い、適切な数の環境をデプロイします。 運用環境は、メインコスト ドライバーである必要があります。	すべての環境で運用環境をシミュレートする必要はないことを理解することで、コストを節約できます。 非運用環境では、さまざまな機能、SKU、インスタンス数、さらにはログ記録を使用できます。 また、オンデマンドで実稼働前環境を作成し、不要になったらそれらを削除することで、コストを節約することもできます。

次の手順

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