レート最適化の設計

設計を変更したり、取引をやり直したり、必要な機能をあきらめることなく、効率を高めることができます。

コストを節約するために、常に再設計または再ネゴシエーションを行う必要はありません。 場合によっては、既に持っているものをよりよく利用できます。 既存のリソースと運用を最適化しない場合は、実際のメリットを見ずにお金を無駄にしている可能性があります。

シナリオの例

Contoso のビジネス インテリジェンス (BI) チームは、さまざまな部門がデータベースに直接触れることなくデータにアクセスできるように、GraphQL API のスイートをホストしています。 時間の経過とともに、バージョン管理が追加され、従量課金レベルの単一の Azure API Management ゲートウェイを介してすべてを実行するようになりました。

API Management インスタンスの背後には、次の 3 つの Azure Kubernetes Service (AKS) クラスターがあります。

• 1 つは、.NET 4.5 で記述された API 用の Windows ノード プールを実行します。

• Java Spring で記述された API 用の 1 つの Linux クラスター。

• 1 つは、Linux 上の .NET Core で記述された API 用の Windows ノード プールを実行します。 彼らは以前のチームからこのクラスターを継承しました。

これらのクラスターは API にのみ使用され、すべてのクラスターが BI チームによって管理されるようになりました。 これは最もクリーンなセットアップではありませんが、動作するため、そのままにしておきます。

BI チームはビジネスのコスト センターであるため、運用コストを削減するために料金を最適化する方法を探しています。

意味のあるインフラストラクチャを組み合わせる

リソース、ワークロード、チームなど、同じ場所で実行してみてください。 スペースを減らすのに役立つサービスを使用します。 特にセキュリティに関するトレードオフを考慮してください。

より多くのユーティリティをより少ないシステムにパックすると、使用するハードウェアが少なくなり、すべてを管理するのに費やす時間が少なくなります。 つまり、コストが削減され、複雑さが軽減されます。

"Contoso の課題"

• Contoso のチームは、Microsoft AKS ベースライン アーキテクチャに従いました。 それぞれ 3 つのシステム ノードを持つ 3 つのクラスターを実行するため、合計 9 つのノードが実行されます。

• パッチと更新プログラムは、毎月 3 回すべてのクラスターに適用されます。

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

• チームはテストを行った後、元のクラスターと同じパフォーマンスと OS 特性を実現しながら、すべての API を 3 つのユーザー ノード プールを持つ 1 つのクラスターに組み合わせることにしました。

• また、システム ノード プールの 4 つのノードに統合されるため、5 つの仮想マシンのコストを節約できます。

• パッチと更新を行うクラスターが 1 つしかないため、さらに時間を節約できます。

• 次に、2 つの Linux ノード プールを 1 つにマージして、さらに簡単にすることを検討しています。

予約やその他のインフラストラクチャ割引を活用する

時間の経過と同時に変化するとは思われず、コストと使用率が予測可能なリソースの種類に対して提供される割引を利用するために、コミットと事前購入によって最適化します。 また、ライセンス チームと協力して、将来の購入契約プログラムや更新に影響を及ぼします。

Microsoft は、特定のリソースとリソース カテゴリに対する予測可能な長期的なコミットメントに対して、割引料金を提供しています。 リソースは使用期間中のコストが低くなり、その期間にわたって償却することができます。

ライセンス チームは、リソース別の現在の投資と予測される投資を把握しておくことで、組織が契約に署名するときにコミットメントを適切に調整できるように支援できます。 場合によっては、これらの予測とコミットメントが組織の価格表に影響を与える可能性があり、それがワークロードのコストだけでなく、同じテクノロジを使う他のチームにもメリットをもたらします。

"Contoso の課題"

• チームが 1 つのクラスターに統合され、以前に吸収されていた過剰なコンピューティングと運用上の負担の一部を取り除いたので、クラスターのコストを削減するための追加の対策を見つけることに関心があります。

• BI チームは AKS プラットフォームに満足しているため、当面は AKS プラットフォームを使用し続ける予定であり、さらに使用量が増える可能性があります。

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

• AKS は Azure Virtual Machine Scale Sets 上に構築されているため、チームは Azure の予約を調びます。 彼らは、ユーザー ノードに必要な予想される SKU とスケール ユニットを知っています。

• システム ノード プールとユーザー ノード プールごとのノードの最小インスタンス数をカバーする 3 年間の予約を購入します。

• この購入により、チームは、時間の経過と共にワークロードが増大することを許容しながら、コンピューティングのニーズを最大限に満たすことができることを認識しています。

実用的な場合は固定価格の課金を使う

リソースの使用率が高く予測可能で、同等の SKU または課金オプションが使用可能な場合は、リソースの従量課金ベースの課金ではなく、固定価格の課金に切り替えます。

使用率が高く予測可能な場合、通常、固定価格モデルの方がコストが安くなり、多くの場合、より多くの機能をサポートします。 これを使うことで、ROI が向上する可能性があります。

"Contoso の課題"

• 現在、API Management インスタンスはすべて従量課金レベルの SKU としてデプロイされています。 API の使用パターンを評価した後、API がグローバルに使われ、場合によっては非常に頻繁に使われていることを把握しました。 チームは、現在の課金モデルと固定価格モデルのコストの違いを分析することにしました。

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

• コスト分析を実行した後、チームは、現在の使用パターンを考慮して、従量課金レベルから Standard レベルに移行すると、全体的に費用が少し安くなることがわかりました。 来年にかけてサービスが拡大するにつれて、コストの差がさらに顕著になる可能性があります。 固定価格モデルは要求の弾性特性を反映していませんが、場合によっては事前購入型の課金モデルが適切な選択となることがあります。

• 追加のボーナスとして、Standard レベルを使用すると、チームがワークロードの実装に熱心に取り組んでいる受信接続にプライベート エンドポイントを使用できます。

• この場合、SKU の切り替えは、使用目的と、プライベート エンドポイントの実装で可能な追加のネットワーク セグメント化の利点の両方で理にかなっています。