コスト最適化をサポートするクラウド設計パターン
ワークロード アーキテクチャを設計するときは、一般的な課題に対処する業界パターンを使用する必要があります。 パターンは、ワークロード内で意図的なトレードオフを行い、目的の結果に向けて最適化するのに役立ちます。 また、信頼性、セキュリティ、パフォーマンス、運用に影響を与える可能性のある特定の問題に起因するリスクを軽減するのにも役立ちます。 リスクが軽減されなければ、最終的にはコストが増加します。 これらのパターンは実際の経験に裏付けられ、クラウドの規模と運用モデルに合わせて設計されており、本質的にベンダーに依存しません。 ワークロード設計を標準化する方法として既知のパターンを使用することは、オペレーショナル エクセレンスの構成要素です。
多くの設計パターンは、1 つ以上のアーキテクチャの柱を直接サポートします。 コスト最適化の柱をサポートする設計パターンは、有利な課金モデルの実装、オーバープロビジョニングの削減、スケーリング ディメンションの変更、移行中の価値の最大化とつながっています。
コスト最適化のための設計パターン
次の表は、コスト最適化の目標をサポートするクラウド設計パターンをまとめたものです。
| Pattern | まとめ |
|---|---|
| 要求チェック | データをメッセージング フローから分離し、メッセージに関連するデータを個別に取得する方法を提供します。 メッセージングシステムはメッセージ サイズに制限を課すことが多く、サイズ制限の増加がプレミアム機能であることが多いです。 メッセージ本文のサイズを小さくすると、より安価なメッセージングソリューションを使用できる場合があります。 |
| 競合コンシューマー | 分散処理と同時処理を適用して、キュー内の項目を効率的に処理します。 このパターンを使用すると、キューが空のときにキューの深さに基づいてゼロまで拡張できるため、コストを最適化できます。 また、同時に発生するコンシューマインスタンスの最大数を制限することで、コストを最適化することも可能です。 |
| コンピューティング リソース統合 | 密度を高めることでコンピューティング リソースを最適化および統合します。 このパターンは、共有インフラストラクチャ上でワークロードの複数のアプリケーションまたはコンポーネントを組み合わせます。 そうすることで、プールされたインフラストラクチャ上のコンポーネントまたはワークロード全体を集約して、使用されていないプロビジョニングされた容量を回避し、コンピューティング リソースの利用率を最大限に高めます。 コンテナー オーケストレーターが一般的な例です。 |
| ゲートウェイ オフロード | 要求をバックエンド ノードに転送する前後に、要求の処理をゲートウェイ デバイスにオフロードします。 オフロード ゲートウェイを要求プロセスに追加すると、ノードごとに費やされるコストをリソースからゲートウェイ実装にリダイレクトできます。 集中処理モデルのコストは、分散モデルのコストよりも低いことがよくあります。 |
| メッセージング ブリッジ | プロトコルまたは形式が原因で互換性のないメッセージング システム間の通信を可能にする仲介機能を提供します。 この仲介機能により、異なるメッセージングまたはイベント テクノロジを使用するシステムとの相互運用性を維持しながら、既存のシステムの寿命を延ばすことができます。 |
| パブリッシャー/サブスクライバー | クライアントからサービス、またはクライアントからサービスへの直接通信を中間メッセージ ブローカーまたはイベント バスを使用した通信に置き換えることにより、アーキテクチャのコンポーネントを分離します。 この設計により、アーキテクチャ内でイベントドリブンのアプローチが可能になり、従量課金ベースの課金とうまく組み合わせてオーバープロビジョニングを回避できます。 |
| キュー ベースの負荷平準化 | 受信要求またはタスクのレベルを制御するために、それらをキューにバッファリングし、キュー プロセッサに制御されたペースで処理を行わせます。 要求やタスクの取り込みと負荷処理が分離されているため、このアプローチを使用すると、ピーク時の負荷を処理するためのリソースをオーバープロビジョニングする必要を軽減できます。 |
| シャーディング | 特定の要求を処理するために読み込みを特定の論理宛先に指示し、最適化のためのコロケーションを可能にします。 シャードを実装するシステムでは、多くの場合、コストの高い単一のリソースを使用するのではなく、よりコストの低いコンピューティング リソースやストレージ リソースの複数のインスタンスを使用することができます。 多くの場合、この構成によってコストを節約できます。 |
| 静的コンテンツ ホスティング | その目的のために設計されたホスティング プラットフォームを使用して、ワークロード クライアントへの静的コンテンツの配信を最適化します。 動的アプリケーション ホストは、通常、コード化されたビジネス ロジックを実行できるため、静的ホストよりもコストが高くなります。 静的コンテンツの配信にアプリケーション プラットフォームを使用することは、コスト効率が良くありません。 |
| ストラングラー フィグ | 実行中のシステムのコンポーネントを、多くの場合、システムの移行または最新化中に、新しいコンポーネントに体系的に置き換えるアプローチを提供します。 このアプローチの目標は、段階的に最新化しながら、現在実行中のシステムへの既存の投資を最大限に活用することです。 これにより、ROI の低い置換の前に、ROI の高い置換を実行できます。 |
| 調整 | リソースまたはコンポーネントへの受信要求のレートまたはスループットに制限を課します。 制限はコスト モデリングに影響を与えることがあり、アプリケーションのビジネス モデルに直接結び付く可能性があります。 また、使用率に明確な上限が設けられるため、それを考慮に入れてリソースのサイズを設定できます。 |
| バレット キー | アクセスをプロキシする中間リソースを使用せずに、リソースへのセキュリティ制限付きアクセス権を付与します。 この設計では、すべてのクライアント要求を直接処理するコンポーネントは追加せず、処理をクライアントとリソースの間の排他的な関係としてオフロードします。 この利点が最も顕著になるのは、クライアントの要求が頻繁であるか、大量のプロキシ リソースを必要とするほど大きい場合、またはプロキシが要求の一部としての値を付加しない場合です。 |
次のステップ
Azure Well-Architected フレームワークの他の柱をサポートするクラウド設計パターンを確認します。