次の方法で共有

パフォーマンス効率をサポートするクラウド設計パターン

  • [アーティクル]

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

多くの設計パターンは、1 つ以上のアーキテクチャの柱を直接サポートします。 パフォーマンス効率の柱をサポートする設計パターンは、スケーラビリティ、パフォーマンス チューニング、タスクの優先順位付け、ボトルネックの除去に対処します。

パフォーマンス効率のための設計パターン

次の表は、パフォーマンス効率の目標をサポートするクラウド設計パターンをまとめたものです。

Pattern まとめ
非同期要求-応答 即時の回答を必要としないプロセスの対話の要求フェーズと応答フェーズを切り離すことで、システムの応答性とスケーラビリティを向上させます。 非同期パターンを使用すると、サーバー側でコンカレンシーを最大化できます。 このパターンを使用して、容量に応じて作業を完了するようにスケジュールできます。
フロントエンド用バックエンド 特定のフロントエンド インターフェイス専用の個別のサービスを作成することで、ワークロードのサービス レイヤーを個別化します。 この分離により、共有サービス レイヤーでは不可能な方法で最適化できます。 個々のクライアントを異なる方法で処理する場合は、特定のクライアントの制約と機能のパフォーマンスを最適化できます。
Bulkhead コンポーネント間のセグメント化を導入して、誤動作の爆発半径を分離します。 この設計により、各バルクヘッドを個別にスケーラブルにして、バルクヘッドにカプセル化されたタスクのニーズを満たすことができます。
キャッシュ アサイド 必要に応じて設定されるキャッシュを導入することで、頻繁に読み取るデータへのアクセスを最適化します。 その後、同じデータに対する後続の要求でキャッシュが使用されます。 このパターンは、頻繁に変更されない読み取り負荷の高いデータで特に役立ち、一定量の失効を許容できます。 この実装の目的は、データ ストアからデータをソーシングするのではなく、この種類のデータをキャッシュにオフロードすることで、システム全体のパフォーマンスを向上することです。
コレオグラフィ 分散化されたイベントドリブン通信を使用して、ワークロード内の自律分散コンポーネントの動作を調整します。 このパターンは、一元化されたオーケストレーション トポロジでパフォーマンスのボトルネックが発生した場合に代替手段を提供できます。
Circuit Breaker 誤動作または使用できない依存関係に対する継続的な要求を防ぎます。 再試行オンエラーアプローチでは、依存関係の回復中にリソースの過剰な使用率が発生する可能性があり、回復を試みようとしている依存関係のパフォーマンスが過負荷になる可能性もあります。
要求チェック メッセージ フローからデータを分離し、メッセージに関連するデータを個別に取得する方法を提供します。 このパターンにより、システムが大きなデータ ペイロードを処理するときに、メッセージパブリッシャー、サブスクライバー、およびメッセージ バス自体の効率とパフォーマンスが向上します。 これは、メッセージのサイズを小さくし、コンシューマーが必要な場合にのみ、および適切なタイミングでペイロード データを取得できるようにすることで機能します。
競合コンシューマー 分散処理と同時処理を適用して、キュー内の項目を効率的に処理します。 このモデルでは、すべてのコンシューマー ノードに負荷を分散し、キューの深さに基づく動的スケーリングをサポートします。
コンピューティング リソース統合 密度を高めることで、コンピューティング リソースを最適化および統合します。 このパターンは、共有インフラストラクチャ上のワークロードの複数のアプリケーションまたはコンポーネントを結合します。 この統合により、予備ノード容量を使用して過剰プロビジョニングを減らすことで、コンピューティング リソースの使用率が最大化されます。 コンテナー オーケストレーターは一般的な例です。 大規模 (垂直方向にスケーリングされた) コンピューティング インスタンスは、多くの場合、これらのインフラストラクチャのリソース プールで使用されます。
コマンド クエリ責務分離 (CQRS) アプリケーションのデータ モデルの読み取り操作と書き込み操作を分離します。 この分離により、各操作の特定の目的に合わせて、対象を絞ったパフォーマンスとスケーリングの最適化が可能になります。 この設計は、読み取り/書き込み比率が高いアプリケーションで最も役立ちます。
デプロイ スタンプ 同じバージョンまたは異なるバージョンが同時にデプロイされるという前提に基づいて、特定のバージョンのアプリケーションとそのインフラストラクチャを制御された展開単位としてリリースするアプローチを提供します。 このパターンは、多くの場合、ワークロードで定義されているスケール ユニットに合わせて調整されます。1 つのスケール ユニットが提供する容量を超える追加の容量が必要な場合は、スケールアウトのために追加のデプロイ スタンプがデプロイされます。
イベント ソーシング 状態変更を一連のイベントとして扱い、変更できない追加専用ログにキャプチャします。 ワークロードに応じて、このパターンは通常、CQRS、適切なドメイン設計、戦略的スナップショット作成と組み合わせることで、パフォーマンスを向上させることができます。 パフォーマンスの向上は、アトミックな追加専用操作と、書き込みと読み取りのデータベース ロックの回避が原因です。
フェデレーション ID ユーザーを管理し、アプリケーションの認証を提供するために、ワークロードの外部にある ID プロバイダーに信頼を委任します。 ユーザー管理と認証をオフロードすると、アプリケーション リソースを他の優先順位に充当できます。
ゲートキーパー バックエンド ノードに要求を転送する前と後に、セキュリティとアクセス制御の適用専用の要求処理をオフロードします。 このパターンは、多くの場合、ノード レベルでレート チェックを実装するのではなく、ゲートウェイ レベルで調整を実装するために使用されます。 すべてのノード間でレート状態を調整することは、本質的にパフォーマンスが高いわけではありません。
ゲートウェイ集約 1 つの要求で複数のバックエンド サービスへの呼び出しを集計することで、ワークロードとのクライアント操作を簡略化します。 この設計では、クライアントが複数の接続を確立する設計よりも短い待機時間が発生する可能性があります。 キャッシュは、バックエンド システムへの呼び出しを最小限に抑えるため、集計の実装でも一般的です。
ゲートウェイ オフロード 要求をバックエンド ノードに転送する前と後に、要求処理をゲートウェイ デバイスにオフロードします。 オフロード ゲートウェイを要求プロセスに追加すると、ゲートウェイで機能が一元化されるため、ノードごとに使用するリソースを少なくできます。 オフロードされた機能の実装は、アプリケーション コードとは別に最適化できます。 オフロードされたプラットフォーム提供の機能は、既にパフォーマンスが高い可能性があります。
ゲートウェイ ルーティング 要求の意図、ビジネス ロジック、バックエンドの可用性に基づいて、受信ネットワーク要求をさまざまなバックエンド システムにルーティングします。 ゲートウェイ ルーティングを使用すると、システム内のノード間でトラフィックを分散して負荷を分散できます。
ジオード 複数の地域でアクティブ/アクティブ可用性モードで動作するシステムをデプロイします。 このパターンでは、データ レプリケーションを使用して、任意のクライアントが任意の地理的インスタンスに接続できる理想的な機能をサポートします。 これを使用して、分散ユーザー ベースに最も近いリージョンからアプリケーションを提供できます。 これにより、長距離トラフィックを排除し、同じ geode を現在使用しているユーザー間でのみインフラストラクチャを共有するため、待機時間が短縮されます。
正常性エンドポイント監視 その目的のために特別に設計されたエンドポイントを公開することで、システムの正常性または状態を監視する方法を提供します。 これらのエンドポイントを使用すると、トラフィックを正常として検証されたノードのみにルーティングすることで、負荷分散を改善できます。 追加の構成では、使用可能なノード容量に関するメトリックを取得することもできます。
テーブルのインデックス作成 クライアントがメタデータを検索してデータを直接取得できるようにすることで、分散データ ストアでのデータ取得を最適化し、完全なデータ ストア スキャンを行う必要がなくなります。 クライアントはシャード、パーティション、またはエンドポイントを指します。これにより、パフォーマンスの最適化のために動的データ パーティション分割を有効にすることができます。
具体化されたビュー データの事前計算済みビューを使用して、データ取得を最適化します。 具体化されたビューには、データベース エンジンまたはクライアントが要求ごとに再計算する必要なしに、複雑な計算またはクエリの結果が格納されます。 この設計により、全体的なリソース消費量が削減されます。
優先順位キュー 優先度の高い項目が処理され、優先度の低い項目の前に完了します。 ビジネスの優先順位に基づいて項目を分離すると、最も時間の影響を受けやすい作業にパフォーマンスの取り組みを集中できます。
パブリッシャー/サブスクライバー クライアント間またはクライアント間の直接通信を中間メッセージ ブローカーまたはイベント バス経由の通信に置き換えることで、アーキテクチャのコンポーネントを分離します。 発行元をコンシューマーから切り離すことで、コンシューマーが特定のメッセージに対して実行する必要があるタスク専用のコンピューティングとコードを最適化できます。
キュー ベースの負荷平準化 受信要求またはタスクのレベルを制御するには、キューにバッファーし、キュー プロセッサが制御されたペースで処理できるようにします。 この方法では、要求の取り込みによって処理される速度に関連付ける必要がないため、スループット パフォーマンスに関する意図的な設計が可能になります。
Scheduler エージェント スーパーバイザー システム内で監視可能な要因に基づいて、タスクをシステム全体に効率的に分散および再配布します。 このパターンでは、パフォーマンスと容量のメトリックを使用して現在の使用率を検出し、容量を持つエージェントにタスクをルーティングします。 これを使用して、優先度の高い作業の実行に優先順位を付け、優先順位の低い作業よりも優先することもできます。
シャーディング 特定の要求を処理する特定の論理宛先に読み込みを指示し、最適化のためにコロケーションを有効にします。 スケーリング戦略でシャーディングを使用すると、データまたは処理はシャードに分離されるため、そのシャードに送信される他の要求とだけリソースが競合します。 シャーディングを使用して、地理に基づいて最適化することもできます。
Sidecar メイン アプリケーションと共に存在するコンパニオン プロセスで非プライマリ タスクまたはクロスカット タスクをカプセル化することで、アプリケーションの機能を拡張します。 クロスカット タスクは、メイン プロセスの複数のインスタンス間でスケーリングできる 1 つのプロセスに移動できるため、アプリケーションの各インスタンスに重複する機能をデプロイする必要がなくなります。
静的コンテンツ ホスティング その目的のために設計されたホスティング プラットフォームを使用して、ワークロード クライアントへの静的コンテンツの配信を最適化します。 外部化されたホストへの責任のオフロードは、輻輳を軽減するのに役立ち、アプリケーション プラットフォームを使用してビジネス ロジックを提供することのみを可能にします。
調整 リソースまたはコンポーネントへの受信要求のレートまたはスループットに制限を課します。 システムの需要が高い場合、このパターンは、パフォーマンスのボトルネックにつながる可能性がある輻輳を軽減するのに役立ちます。 また、これを使用して、うるさい隣人のシナリオを事前に回避することもできます。
バレット キー 中間リソースを使用してアクセスをプロキシすることなく、リソースへのセキュリティ制限付きアクセスを許可します。 これにより、すべてのクライアント要求をパフォーマンスの高い方法で処理する必要があるアンバサダー コンポーネントを必要とせずに、クライアントとリソースの間の排他的な関係として処理がオフロードされます。 このパターンを使用する利点は、プロキシがトランザクションに価値を追加しない場合に最も重要です。

次の手順

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