レート最適化の設計
 機能要件または非機能要件を再設計、再交渉、または犠牲にすることなく、効率を向上させます。 |
|---|
既存のリソースと運用のユーティリティとコストを最適化する機会を活用します。 そうしないと、ROI が向上せずに不必要にお金を費やすことになります。
サンプル シナリオ
Contoso のビジネス インテリジェンス (BI) チームは、データベースへの直接アクセス権を付与せずに組織全体のデータ ストアにアクセスできるように、さまざまなビジネス ユニット向けの GraphQL API スイートをホストしています。 彼らは長年にわたってこれらを構築してきましたが、バージョン管理が重要であることが判明したため、現在は単一の従量課金レベルの API Management ゲートウェイ上でバージョン管理されたエンドポイントを介して API を公開しています。
API Management インスタンスの背後には、公開される API をホストする 3 つの AKS クラスターがあります。 1 つは .NET 4.5 で記述された API 用の Windows ノード プールの実行、1 つは Java Spring で記述された API 用の Linux クラスター、そして 1 つは、dotnet core API を実行する以前のチームから継承した Linux です。 現在、クラスターはすべて BI チームによって所有されており、これらの API にのみ使われます。 3 つのクラスターを管理するのは理想的ではありませんが、意図したとおりに機能しているため、そのまま残されています。
ビジネスのコスト センターとして、BI チームは料金を最適化して運用コストを削減する方法を模索しています。
実用的な場合はインフラストラクチャを統合する
他のリソース、ワークロード、さらにはチームとの併用で同じ場所にまとめます。 より高い密度を実現しやすいサービスを優先します。 特にセキュリティ境界における潜在的なトレードオフを考慮してください。
インフラストラクチャを統合すると、クラウド コストの最適化に役立ちます。 密度が増加すると、ワークロードの実行に必要なリソースの量が減少します。 この減少により、ユニットあたりのコストと管理コストが削減されます。
"Contoso の課題"
- ワークロード チームは、Microsoft のベースライン アーキテクチャ ガイダンスに従って AKS インフラストラクチャを設計しました。これには、クラスターごとに少なくとも 3 つのノードを実行することが推奨されています。 この構成により、チームは 3 つのクラスター全体で 9 つのシステム ノードをサポートすることになりました。
- チームは月に 3 回、クラスターにパッチと更新を適用します。
"アプローチの適用と結果"
- テスト後、チームは、元のクラスターと同じパフォーマンスと OS 特性を達成しながら、すべての API を 3 つのユーザー ノード プールを持つ単一クラスターに結合できると判断しました。
- API を 1 つのクラスターに統合すると、システム ノード プールの 4 つのノードに統合され、5 つの仮想マシンのコストが節約されます。
- また、チームは管理するクラスターが 1 つだけなので、クラスターでのパッチ適用とアップグレードのプロセスを合理化できるようになりました。
- 次のコスト削減目標は、運用オーバーヘッドをさらに削減するために 2 つの linux ノード プールを 1 つに統合することの検討です。
予約やその他のインフラストラクチャ割引を活用する
時間の経過と共に変化することが予想されず、コストと使用率が予測可能なリソースの種類に対して提供される割引を利用するために、コミットと事前購入によって最適化します。 また、ライセンス チームと協力して、将来の購入契約プログラムや更新に影響を及ぼします。
Microsoft は、特定のリソースとリソース カテゴリに対する予測可能な長期的なコミットメントに対して、割引料金を提供しています。 リソースは使用期間中のコストが低くなり、その期間にわたって償却することができます。
ライセンス チームがリソースごとの現在および予測される投資を常に認識できるようにすることで、組織が契約に署名するときに、コミットメントの規模を適切に設定できるようになります。 場合によっては、これらの予測とコミットメントが組織の価格表に影響を与える可能性があり、それがワークロードのコストだけでなく、同じテクノロジを使う他のチームにもメリットをもたらします。
"Contoso の課題"
- チームが 1 つのクラスターに統合され、以前に吸収されていた過剰なコンピューティングと運用上の負担の一部を取り除いたので、クラスターのコストを削減するための追加の対策を見つけることに関心があります。
- BI チームは AKS プラットフォームに満足しているため、当面は AKS プラットフォームを使用し続ける予定であり、さらに使用量が増える可能性があります。
"アプローチの適用と結果"
- AKS は Virtual Machine Scale Sets の上に構築されているため、チームは Azure 予約を検討しています。 彼らは、ユーザー ノードに必要な予想される SKU とスケール ユニットを知っています。
- システム ノード プールとユーザー ノード プールごとのノードの最小インスタンス数をカバーする 3 年間の予約を購入します。
- この購入により、チームは、時間の経過と共にワークロードが増大することを許容しながら、コンピューティングのニーズを最大限に満たすことができることを認識しています。
実用的な場合は固定価格の課金を使う
リソースの使用率が高く予測可能であり、同等の SKU または課金オプションが使用できる場合は、リソースの従量制の課金ではなく固定価格の課金に切り替えます。
使用率が高く予測可能な場合、通常、固定価格モデルの方がコストが安くなり、多くの場合、より多くの機能をサポートします。 これを使うことで、ROI が向上する可能性があります。
"Contoso の課題"
- 現在、API Management インスタンスはすべて従量課金レベルの SKU としてデプロイされています。 API の使用パターンを評価した後、API がグローバルに使われ、場合によっては非常に頻繁に使われていることを把握しました。 チームは、現在の課金モデルと固定価格モデルのコストの違いを分析することにしました。
"アプローチの適用と結果"
- コスト分析を実行した後、チームは、現在の使用パターンを考慮して、従量課金レベルから Standard レベルに移行すると、全体的に費用が少し安くなることがわかりました。 来年にかけてサービスが拡大するにつれて、コストの差がさらに顕著になる可能性があります。 固定価格モデルは要求の弾性特性を反映していませんが、場合によっては事前購入型の課金モデルが適切な選択となることがあります。
- 追加のボーナスとして、Standard レベルを使うと、チームがワークロードに対して実装することを熱望していた、受信接続にプライベート エンドポイントを使用できるようになります。
- この場合、SKU を切り替えることは、使用目的と、プライベート エンドポイントの実装で可能になる追加のネットワーク セグメント化の利点の、両方で意味がありました。