長期的な監視と最適化
 エコシステムと共にワークロードが進化するのに合わせて、適切な規模の投資を継続的に行います。 |
|---|
昨日は重要だったことでも、今日は重要ではないかもしれません。 運用環境ワークロードの評価から学んだことに応じて、アーキテクチャ、ビジネス要件、プロセス、さらにはチーム構造の変化を予想しましょう。 場合によっては、ソフトウェア開発ライフサイクル (SDLC) プラクティスの進化が必要です。 クラウド プラットフォーム、そのリソース、契約などの外部要因が変化することも考えられます。
あらゆる変化がコストに与える影響を慎重に評価する必要があります。 変化と ROI の傾向を定期的に監視し、機能要件と非機能要件を調整する必要があるかどうかを評価しましょう。
サンプル シナリオ
Contoso Air は航空会社向けに手荷物追跡ソリューションを提供しています。 ワークロードは Azure でホストし、データベースには Cosmos DB を使って AKS 上で実行し、メッセージングに Event Hubs を使っています。 ワークロードは米国西部と米国東部のリージョンにデプロイしています。
環境とサポートのコストを継続的に評価して最適化する。
コスト追跡システムを使って、リソース、データ、有料サポートのコストを継続的に評価し、最適化します。 あまり活用されておらず、廃止、交換、再構築、またはリファクタリングできるリソースはありますか?
十分に活用されていないリソースへの支払いを回避することで、コストを削減できます。 価格のメトリックを把握していると、よりコスト モデルに沿った意思決定を行うことができます。 また、不正請求を防ぐこともできます。 十分に活用されていないリソースのサイズ変更や削除、さらには SKU の変更によってコストを削減できます。
また、テクノロジ サプライヤーとのサポート契約の使用状況を評価し、契約の規模を適切に設定することで、コストの一部を節約できる場合もあります。
"Contoso の課題"
- ワークロード チームは常に予算内で作業を進めてきたため、コスト効率の最適化は優先事項ではありませんでした。
- 来年はワークロードの信頼性を高める計画を立てており、その結果、Azure のコストが増加し、ワークロードが予算を超える可能性があることを認識しています。 そこで来年度予算の増額を求めることを検討しています。
"アプローチの適用と結果"
- チームは、追加の資金を求める前に、現在の Azure とサポートのコストを評価し、節約の可能性を探ることにしました。 既存のコスト追跡システムで、リソースごと、リソース グループごと、タグごとのコストの内訳を調べ、予期しない支出があることに気付きました。
- チームは、非推奨のビルド システムに使われていて不要になった VM が環境内で実行されていること、より安価なレベルに移動できる大量の古いデータが Azure Storage にあること、利用していないコンサルティング時間を含むサポート契約料金をクラウド プロバイダーに支払っていることに気付きました。
- チームは、使われていない VM を削除し、古いデータを Archive ストレージに移動することで Azure のコストを最適化しました。 クラウド プロバイダーとより緊密に連携し、コンサルティング サービスを有効に活用するようになりました。
- チームは、繰り返し発生するタスクをバックログに追加し、将来的なワークロード コストを評価できるようにしました。
ワークロードを継続的に確認して調整する
ROI データに基づいて、アーキテクチャ設計の決定、リソース、コード、ワークフローを継続的に調整します。
メトリック、パフォーマンス データ、請求レポート、機能の使用状況を定期的に確認することで、コストを削減できる微調整につながる可能性があります。
"Contoso の課題"
- チームはこれまでは予算内に収めていたため、既存の機能に対する代替アプローチを検討していませんでした。 代わりに、計画の大部分は新機能の構築に重点を置いています。
- 初期評価で無駄を見つけた後は、現在のコンポーネントの残りの部分を調べて最適化の機会を探ることにしました。
"アプローチの適用と結果"
- チームは、低優先度のフローに必要以上のリソースを割り当てていることに気付きました。そしてパフォーマンス要件を維持しながら、割り当てられたスループットを安全にスケールバックすることができました。 具体的には、ピーク負荷を処理するためのオーバープロビジョニングを止め、代わりにキューベースの負荷平準化システムを実装することができました。
- また、コンピューティング プラットフォーム上の一部の SKU に、特定の認証コードを置き換える新機能が追加されていることもわかりました。 この機能を使うと、保守およびテストするコードが少なくなります。
デプロイ環境を最適化する
異なる SDLC 環境を異なる方法で扱い、適切な数の環境をデプロイします。 運用環境が主なコスト ドライバーになるようにします。
すべての環境で運用環境をシミュレートする必要がないことを理解することで、コストを削減できます。 非運用環境には、さまざまな機能、SKU、インスタンス数、さらにはログが含まれる場合があります。
また、運用前環境をオンデマンドで作成し、不要になったら削除することでコストを節約することもできます。
"Contoso の課題"
- ワークロード チームは、運用環境よりも運用前環境に多くのコストを費やしています。 これはシナリオによっては重要かもしれませんが、このワークロードでは過剰と考えられます。
- 運用前環境は、運用環境とほぼ同じになるように構築されています。 ワークロード チームは、運用環境との近似性が非常に高い下位環境を用意することを評価しています。なぜなら、運用環境が下位環境と同様に動作する確度が高くなるからです。
"アプローチの適用と結果"
- 慎重に評価した結果、チームは、少しの追加リスクというトレードオフを受け入れ、環境間に多少の違いがあることに伴うコスト削減を実現することにしました。
- チームは、いくつかのテスト環境を同じインフラストラクチャに併置し、使われていない環境を夜間にシャットダウンすることにしました。
- また、チームは、ローカルの開発者ワークステーション上で、インナーループの開発とテストをシフト レフトして実行できる状況を見つけました。
- 運用前環境と開発プラクティスで軽微な侵害を行う方法を見つけることで、自動化の取り組みに有効活用できる予算を確保しました。