次の方法で共有

パフォーマンス効率をサポートするアーキテクチャ設計パターン

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

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

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

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

次のステップ

他の Azure Well-Architected Framework の柱をサポートするアーキテクチャ設計パターンを確認します。