コスト効率の考え方を使用した設計
- 12 分
|
|
|---|
アーキテクチャに関するすべての決定は、構築または購入、使用するツール、ライセンスとトレーニングの方法など、予算に影響します。 これらのオプションを検討し、アプリのニーズを満たすトレードオフを過大な支出なしに行うことが重要です。
サンプル シナリオ
Contoso Manufacturing では、南アメリカ全体で 4 つの倉庫を処理するカスタム構築の倉庫管理システム (WMS) を実行しています。 WMS を更新してクラウドに移動したいと考えています。 現在のソリューションのリフト アンド シフト移動と、最新のクラウド ツールを使用したグリーン フィールド ビルドのどちらを決定しているかが決まります。 リーダーシップはコストを管理し続けたいので、チームにはコスト効率を維持する計画が必要です。
WMS ソリューションは、インターネット インフォメーション サービス (IIS) 上で実行され、データベースに SQL Server を使用する .NET アプリケーションです。
設計の完全なコストを理解する
投資収益率 (ROI) への影響を考慮して、テクノロジと自動化の選択によって発生する総コストを測定します。 設計は、機能と機能以外に関するすべての要件について、許容される境界内で動作する必要があります。 また、設計は、予想される進化に柔軟に対応できる必要もあります。 取得、トレーニング、変更管理のコストを考慮します。
ROI を考慮してバランスの取れたアプローチを実装すると、コストが増加する可能性があるオーバーエンジニアリングが防がれます。
"Contoso の課題"
Contoso のエンジニアリング チームは、他のチームと同様に、倉庫システムをクラウドに移行することに興奮しています。
現在のアプリには技術的な負債があることを知っているので、アプリケーション コードの多くを書き直し、新しいクラウドネイティブ ツールに切り替える予定です。
エンジニアリング チームは、すべてをマイクロサービスに再設計し、Azure Kubernetes Service (AKS) で実行したいと考えています。これは、新しくエキサイティングなプラットフォームです。
"アプローチの適用と結果"
チームは、クラウド移行中に大幅な再設計を行うことに興奮していますが、ワークロードの ROI を維持する必要があることを理解しています。 そのため、既に知っているツールを使用し、エンジニアリング チームの追加トレーニングを必要とする大規模な書き換えを回避する必要があります。
ワークロード チームは、システムの設計に実用的なアプローチを取ります。 コスト効率が高く、期待に応え、複雑すぎないようにしたいと考えています。 ROI をチェックし、移行をスムーズにするために、Azure App Service などのクラウドで同等のソリューションを使用することにしました。
インフラストラクチャ、ライセンス、運用コストを考慮したコスト ベースラインと、新しいプラットフォームのトレーニング、レガシ コードの書き換え、チーム間での変更の管理など、あまり明白ではない要因を確立します。 予算内で実現可能な内容をより明確に把握し、より身近でリスクの低いパスとしての App Service の決定を確認します。
移行中、チームは現在取り組むのに理にかなっている技術的負債の一部をクリーンアップする予定です。 そうすることで、すべてが Azure で実行された後も、これらの選択を行うときに ROI を念頭に置きながら、プラットフォームを改善し続けるより良い場所になります。
設計を洗練させる
全体的なコストを削減できるサービス、追加投資の必要がないサービス、機能に大きな影響を与えないサービスを優先させて、設計を微調整します。 優先順位を決めるときは、ROI が高くなるビジネス モデルとテクノロジを選ぶようにする必要があります。
リソースの柔軟性や動的スケーリングを可能にする可能性のある安価なオプションを調べるか、既存の投資の使用を正当化することができます。 優先順位を決めるときのパラメーターでは、重要なワークロード、ランタイム、運用に必要なコストや、チームの作業効率を高めるのに役立つその他のコストが考慮される場合があります。
"Contoso の課題"
既存のワークロードはハイパーコンバージド (HCI) アプライアンスでホストされており、チームのコスト センターはコンピューティング、ネットワーク、ストレージのコストに対してチャージバックされます。
ワークロードによって、運用前環境と運用環境が Windows 仮想マシンにデプロイされました。
セルフホステッド ランナーを含む GitHub Actions は、GitHub Actions ジョブの実行に使用されます。
"アプローチの適用と結果"
複数のクラウドネイティブ オプションを評価した後、チームは、Web コンポーネントを App Service に移動することで、Windows IIS アプリケーションの互換性を大幅に変更することなく提供し、重要なトレーニングを必要としないことを決定しました。
チームは、GitHub Actions とセルフホステッド ランナーを引き続き使うことにしますが、使われていないときはノードをゼロにスケーリングできる機能を備えた仮想マシン スケール セットに移行します。
コストのガードレールをサポートするようにアーキテクチャを設計する
アーキテクチャでコスト制限を設定して、支出を安全な範囲内に保ち、クラウド環境のコストがこれらの制限の下で維持されるようにします。
制限を適用すると、驚きの料金を回避し、実際に予算を使うだけになるようにすることができます。
"Contoso の課題"
現在のシステムにはコスト ガードレールはありませんが、ほとんど変更されないため、誰も追加をプッシュしません。
HCI 環境の所有者はリソースの上限を設定しているため、ワークロードで使用できるコンピューティングまたはストレージが許可されているよりも多くすることはできません。
チームは、クラウドへの移行が予期しないコストにつながる可能性があることを心配しており、その回避方法が不明です。
"アプローチの適用と結果"
チームは、Microsoft Cost Management ソリューションの使用方法について説明します。
App Service プランのスケール制限を設定する予定です。
一部の高価な仮想マシン SKU の使用をブロックする拒否ポリシーを設定する予定です。
ストレージに保存する自動化を追加する予定です。 古いデータまたは使用頻度の低いデータは、コールドやアーカイブなどの低コストのストレージ層に自動的に移動します。 この種の自動化は、古い HCI 環境では不可能でした。
自分の知識をチェックする
フィードバック
このページはお役に立ちましたか?
いいえ
このトピックについてサポートが必要ですか?
このトピックの意図を把握したり、理解を深めたりするために Ask Learn を使ってみませんか?