コストの最適化をサポートするクラウド設計パターン

  • [アーティクル]

ワークロード アーキテクチャを設計するときは、一般的な課題に対処する業界パターンを使用する必要があります。 パターンは、ワークロード内で意図的なトレードオフを行い、目的の結果に合わせて最適化するのに役立ちます。 また、信頼性、セキュリティ、パフォーマンス、運用に影響を与える可能性がある特定の問題に起因するリスクを軽減するのにも役立ちます。 軽減されていない場合、リスクは最終的にコストを増加させます。 これらのパターンは、実際のエクスペリエンスによって支えられ、クラウドスケールと運用モデル向けに設計されており、本質的にベンダーに依存しません。 ワークロード設計を標準化する方法として既知のパターンを使用することは、オペレーショナル エクセレンスの構成要素です。

多くの設計パターンは、1 つ以上のアーキテクチャの柱を直接サポートします。 コスト最適化の柱をサポートする設計パターンは、有利な課金モデルの実装、オーバープロビジョニングの削減、スケーリング ディメンションの変更、移行中の価値の最大化に合わせて調整されます。

コスト最適化のための設計パターン

次の表は、コスト最適化の目標をサポートするクラウド設計パターンをまとめたものです。

Pattern まとめ
要求チェック メッセージ フローからデータを分離し、メッセージに関連するデータを個別に取得する方法を提供します。 メッセージング システムでは多くの場合、メッセージ サイズに制限が課され、サイズ制限の増加は多くの場合、Premium 機能です。 メッセージ本文のサイズを小さくすると、より安価なメッセージング ソリューションを使用できる場合があります。
競合コンシューマー 分散処理と同時処理を適用して、キュー内の項目を効率的に処理します。 このパターンは、キューが空の場合に、キューの深さに基づくスケーリングを 0 に減らし、コストを最適化するのに役立ちます。 同時コンシューマー インスタンスの最大数を制限することで、コストを最適化することもできます。
コンピューティング リソース統合 密度を高めることで、コンピューティング リソースを最適化および統合します。 このパターンは、共有インフラストラクチャ上のワークロードの複数のアプリケーションまたはコンポーネントを結合します。 これにより、コンポーネントの集計、またはプールされたインフラストラクチャ上のワークロード全体を使用して未使用のプロビジョニング容量を回避することで、コンピューティング リソースの使用率が最大化されます。 コンテナー オーケストレーターは一般的な例です。
ゲートウェイ オフロード 要求をバックエンド ノードに転送する前と後に、要求処理をゲートウェイ デバイスにオフロードします。 オフロード ゲートウェイを要求プロセスに追加すると、ノードごとに費やされるリソースからゲートウェイの実装にコストをリダイレクトできます。 一元化された処理モデルのコストは、分散モデルのコストよりも多くの場合低くなります。
メッセージング ブリッジ プロトコルまたは形式が原因で互換性のないメッセージング システム間の通信を可能にする中継手段を提供します。 この仲介によって、既存のシステムの寿命が長くなる一方で、別のメッセージングまたはイベント テクノロジを使用するシステムとの相互運用性が可能になります。
パブリッシャー/サブスクライバー 中間メッセージ ブローカーまたはイベント バスを使用して、直接のクライアント間通信またはクライアント間通信を通信に置き換えることで、アーキテクチャのコンポーネントを分離します。 この設計では、過剰プロビジョニングを回避するために、消費ベースの課金と組み合わせて、アーキテクチャでイベント駆動型のアプローチを実現できます。
キュー ベースの負荷平準化 受信要求またはタスクのレベルを制御するには、キューにバッファーし、キュー プロセッサが制御されたペースで処理できるようにします。 負荷処理は要求またはタスクの取り込みから切り離されているため、このアプローチを使用して、ピーク時の負荷を処理するためにリソースを過剰プロビジョニングする必要性を減らすことができます。
シャーディング 特定の要求を処理する特定の論理宛先に読み込みを指示し、最適化のためにコロケーションを有効にします。 シャードを実装するシステムでは、多くの場合、1 つのよりコストの高いリソースではなく、コストの低いコンピューティング リソースまたはストレージ リソースの複数のインスタンスを使用する利点があります。 多くの場合、この構成ではコストを節約できます。
静的コンテンツ ホスティング その目的のために設計されたホスティング プラットフォームを使用して、ワークロード クライアントへの静的コンテンツの配信を最適化します。 動的アプリケーション ホストは、通常、コード化されたビジネス ロジックを実行できるため、静的ホストよりもコストが高くなります。 アプリケーション プラットフォームを使用して静的コンテンツを配信することは、コスト効率が高くはありません。
ストラングラー フィグ 実行中のシステムのコンポーネントを新しいコンポーネントに体系的に置き換えるアプローチを提供します。多くの場合、システムの移行または最新化中に行われます。 このアプローチの目的は、段階的に最新化しながら、現在実行中のシステムでの既存の投資の使用を最大化することです。 これにより、ROI が低い置換の前に高 ROI の置換を実行できます。
調整 リソースまたはコンポーネントへの受信要求のレートまたはスループットに制限を課します。 この制限により、コスト モデリングが通知され、アプリケーションのビジネス モデルに直接関連付けることもできます。 また、使用率に明確な上限を設定します。これは、リソースのサイズ設定に組み込むことができます。
バレット キー 中間リソースを使用してアクセスをプロキシすることなく、リソースへのセキュリティ制限付きアクセスを許可します。 この設計では、すべてのクライアント要求を直接処理するコンポーネントを追加せずに、クライアントとリソースの間の排他的な関係として処理をオフロードします。 この利点は、クライアントの要求が頻繁に行われるか、重要なプロキシ リソースを必要とするのに十分な大きさである場合に最も大きくなります。

次の手順

他の Azure Well-Architected Framework の柱をサポートするクラウド設計パターンを確認します。