コスト効率の考え方を使用した設計

完了
投資に対する利益を最大にするために必要なものだけに費やします。

アーキテクチャに関するすべての決定は、財務に対して直接的および間接的な影響を与えます。 構築するか購入するか、テクノロジの選択、課金モデルとライセンス、トレーニング、運用などに関連するコストについて理解します。

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

サンプル シナリオ

Contoso Manufacturing (CM) は、南アメリカにある 4 つの倉庫を処理するための倉庫管理システム (WMS) を社内で構築して稼働させており、ソリューションを更新してクラウドに移行する時期であると判断しました。 現在のソリューションのリフトアンドシフトによる移行、または最新のクラウド ツールを使用したグリーン フィールド構築を検討しています。 CM の上級リーダーはコストを管理しようと考えており、コスト効率の維持を目標として移行に取り組む方法を、ワークロード チームのリーダーに求めています。

WMS ソリューションは、IIS 上で稼働する .NET アプリケーションであり、データベースとして SQL Server を使っています。

ワークロード設計の総コストを測定する

投資収益率 (ROI) への影響を考慮して、テクノロジと自動化の選択によって発生する総コストを測定します。 設計は、機能と機能以外に関するすべての要件について、許容される境界内で動作する必要があります。 また、設計は、予想される進化に柔軟に対応できる必要もあります。 取得、トレーニング、変更管理のコストを考慮します。

ROI を考慮してバランスの取れたアプローチを実装すると、コストが増加する可能性があるオーバーエンジニアリングが防がれます。

"Contoso の課題"

  • ワークロード エンジニアリング チームは、このワークロードをクラウドに移行し、既にクラウドネイティブ開発を行っている他の CM チームに参加することを楽しみにしています。
  • チームは、アプリケーションの技術的負債を認識しており、多くのコンポーネントについて、大量のアプリケーション コードを書き換え、新しいクラウドネイティブ ソリューションに移行することで、それに対処することを予期しています。
  • エンジニアリング チームは、この機会を利用して、システムをマイクロサービスとして完全に再設計し、チームにとって新しいけれども楽しみなテクノロジである AKS でホストしようと考えています。

"アプローチの適用と結果"

  • ワークロード チームは、クラウド移行の一環として大規模なリファクタリングを行いたいことははっきりしていますが、ワークロードの ROI を維持する必要があることを認識しています。 ワークロードの ROI を維持するとなると、チームは、エンジニアリング チームに対して広範に新しいトレーニングを行う必要のないソリューションを使うことになる可能性が高く、移行の一環としてワークロードを大幅に作り直すことはできません。
  • ワークロード チームは、コスト効率が維持され、予想されるパラメーター内で動作し、オーバーエンジニアリングにならない、現実的なアプローチでシステムを設計することにします。 チームは、ROI を維持し、移行を効率的に実行するには、クラウドでも Azure App Service のような同様のソリューションを使うのが最善のアプローチであると判断しました。
  • 移行の間に、Azure 上で実現するとプラットフォームをさらに進化させることができる技術的負債を選んで対応し、選択プロセスの一部として ROI を考慮します。

設計を洗練させる

全体的なコストを削減できるサービス、追加投資の必要がないサービス、機能に大きな影響を与えないサービスを優先させて、設計を微調整します。 優先順位を決めるときは、ROI が高くなるビジネス モデルとテクノロジを選ぶようにする必要があります。

リソースの柔軟性や動的スケーリングを実現できる可能性がある安価なオプションを調べることができ、既存の投資の使用が正当化されることもあります。 優先順位を決めるときのパラメーターでは、重要なワークロード、ランタイム、運用に必要なコストや、チームの作業効率を高めるのに役立つその他のコストが考慮される場合があります。

"Contoso の課題"

  • 既存のワークロードはハイパーコンバージド (HCI) アプライアンスでホストされており、チームのコスト センターはコンピューティング、ネットワーク、ストレージのコストに対してチャージバックされます。
  • ワークロードでは、Windows 仮想マシンに運用前環境と運用環境が展開されています。
  • GitHub Actions とセルフホステッド ランナーが、GitHub Actions ジョブの実行に使われています。

"アプローチの適用と結果"

  • いくつかのクラウドネイティブ オプションを評価した後、チームは、Web コンポーネントを Azure App Service に移動すると、大幅な変更なしで Windows IIS アプリケーションの互換性が提供され、大がかりなトレーニングが必要ないと判断します。
  • チームは、GitHub Actions とセルフホステッド ランナーを引き続き使うことにしますが、使われていないときはノードをゼロにスケーリングできる機能を備えた仮想マシン スケール セットに移行します。

コストのガードレールをサポートするようにアーキテクチャを設計する

プラットフォーム ソリューション、ポリシー、インフラストラクチャとアプリケーションの設計パターン、または自動化を通じてコスト ガードレールを実装し、クラウド環境のコストが予算内に収まるようにします。

ガバナンス ポリシーまたは組み込みのアプリケーション設計パターンによって適用すると、偶然または未承認の料金を防ぐことができます。

"Contoso の課題"

  • 既存のシステムにはコスト ガードレールはありませんが、ほとんど変更されないため、そのようなガードレールを構築するきっかけはほとんどありませんでした。
  • HCI 環境の所有者が、このワークロードに適用されるリソース制限を設定して、ワークロードによるコンピューティング リソースとストレージ リソースの過剰な消費を効果的に防いでいます。
  • チームは、クラウドへの移行によって予期しないコストが発生するリスクを懸念しており、そのリスクを最小限に抑える方法がわかりません。

"アプローチの適用と結果"

  • チームは、Microsoft Cost Management ソリューションについて学習します。
  • チームは、Azure App Service プランにスケール制限を設定することを計画しています。
  • チームは、一部の高価格の仮想マシン SKU に対して拒否ポリシーを設定して、それらの SKU のデプロイを禁止する予定です。
  • チームは、ストレージのコストの制御に役立つ自動化を実装する予定です。 特定のデータの種類は、最終アクセス日などの条件に基づいて、ホット ストレージからコールド ストレージまたはアーカイブ ストレージに自動的に移動します。 この種類の自動化は、HCI 環境では不可能です。

自分の知識をチェックする

1.

次のうち、ワークロードの総コストを測定するときに考慮する必要がある要因の 1 つであるのはどれですか?

2.

コストのためのワークロードの設計を微調整するとき、優先する必要があるのは次のうちどれですか?

3.

ワークロード チームがワークロードの Azure コストを確実に制御したい場合、次のうちどれを行う必要がありますか?