信頼性をサポートするクラウド設計パターン
ワークロード アーキテクチャを設計するときは、一般的な課題に対処する業界パターンを使用する必要があります。 パターンは、ワークロード内で意図的なトレードオフを行い、目的の結果に合わせて最適化するのに役立ちます。 また、セキュリティ、パフォーマンス、コスト、運用に影響を与える可能性がある特定の問題に起因するリスクを軽減するのにも役立ちます。 軽減されていない場合、これらのリスクは最終的に信頼性の問題を引き起こします。 これらのパターンは、実際のエクスペリエンスによって支えられ、クラウドスケールと運用モデル向けに設計されており、本質的にベンダーに依存しません。 ワークロード設計を標準化する方法として既知のパターンを使用することは、オペレーショナル エクセレンスの構成要素です。
多くの設計パターンは、1 つ以上のアーキテクチャの柱を直接サポートしています。 信頼性の柱をサポートする設計パターンは、ワークロードの可用性、自己保持、回復、データと処理の整合性、および誤動作の封じ込めについて優先順位を付けます。
信頼性のための設計パターン
次の表は、信頼性の目標をサポートするクラウド設計パターンをまとめたものです。
| Pattern | まとめ |
|---|---|
| Ambassador | ネットワーク通信に関連する横断的なタスクをオフロードすることで、ネットワーク通信をカプセル化および管理します。 結果として得られるヘルパー サービスは、クライアントの代わりに通信を開始します。 このメディエーション・ポイントは、再試行やバッファリングなど、ネットワーク通信に信頼性パターンを追加する機会を提供します。 |
| フロントエンド用バックエンド | 特定のフロントエンド インターフェイス専用の個別のサービスを作成して、ワークロードのサービス レイヤーを個別化します。 この分離により、あるクライアントをサポートするサービス層の誤動作が、別のクライアントのアクセスの可用性に影響しない可能性があります。 さまざまなクライアントを異なる方法で扱う場合は、予想されるクライアント アクセス パターンに基づいて信頼性の取り組みに優先順位を付けることができます。 |
| Bulkhead | コンポーネント間で意図的かつ完全なセグメント化を導入し、誤動作の爆発半径を分離します。 この障害分離戦略では、問題が発生しているバルクヘッドのみに障害を含め、他のバルクヘッドへの影響を防ぎます。 |
| キャッシュ アサイド | 必要に応じて設定されるキャッシュを導入することで、頻繁に読み取られたデータへのアクセスを最適化します。 その後、同じデータに対する後続の要求でキャッシュが使用されます。 キャッシュによってデータ レプリケーションが作成され、配信元データ ストアが一時的に使用できない場合に、頻繁にアクセスされるデータの可用性を維持するために、限られた方法で使用できます。 さらに、キャッシュに誤動作が発生した場合、ワークロードは配信元データ ストアにフォールバックする可能性があります。 |
| Circuit Breaker | 正常に動作しない、または使用できない依存関係に対する継続的な要求を防ぎます。 これにより、このパターンにより、障害のある依存関係のオーバーロードが防止されます。 このパターンを使用して、ワークロードの正常な低下をトリガーすることもできます。 サーキット ブレーカーは、多くの場合、自動復旧と組み合わせて、自己保存と自己復旧の両方を提供します。 |
| 要求チェック | メッセージング フローからデータを分離し、メッセージに関連するデータを個別に取得する方法を提供します。 メッセージ バスでは、専用のデータ ストアに存在することが多い信頼性とディザスター リカバリーは提供されないため、メッセージからデータを分離すると、基になるデータの信頼性が向上する可能性があります。 この分離により、障害発生後のメッセージ キュー回復アプローチも可能になります。 |
| 補正トランザクション | 以前に適用されたアクションの影響を元に戻すことによって、障害から回復するメカニズムを提供します。 このパターンでは、補正アクションを使用して、重要なワークロード パスの誤動作に対処します。これには、データ変更を直接ロールバックしたり、トランザクション ロックを解除したり、ネイティブ システムの動作を実行して効果を反転させるなどのプロセスが含まれる場合があります。 |
| 競合コンシューマー | 分散処理と同時処理を適用して、キュー内の項目を効率的に処理します。 このモデルでは、コンシューマーをレプリカとして扱うことでキュー処理の冗長性が構築されるため、インスタンスの障害によって他のコンシューマーがキュー メッセージを処理できなくなります。 |
| イベント ソーシング | 状態変更を一連のイベントとして扱い、変更できない追加専用ログにキャプチャします。 このパターンは、複雑なビジネス プロセスで信頼性の高い変更履歴が重要な場合に使用できます。 また、状態ストアを回復する必要がある場合は、状態の再構築も容易になります。 |
| フェデレーション ID | ユーザーを管理し、アプリケーションの認証を提供するために、ワークロードの外部にある ID プロバイダーに信頼を委任します。 ユーザー管理と認証をオフロードすると、これらのコンポーネントの信頼性が ID プロバイダーに移行されます。これは通常、SLA が高くなります。 さらに、ワークロードのディザスター リカバリー中に、認証コンポーネントをワークロード回復計画の一部として対処する必要がない可能性があります。 |
| ゲートウェイ集約 | 1 つの要求で複数のバックエンド サービスへの呼び出しを集計することで、ワークロードとのクライアントの対話を簡略化します。 このトポロジを使用すると、一時的な障害処理をクライアント間の分散実装から一元化された実装に移行できます。 |
| ゲートウェイ オフロード | 要求をバックエンド ノードに転送する前と後に、ゲートウェイ デバイスに要求処理をオフロードします。 この責任をゲートウェイにオフロードすると、バックエンド ノードでのアプリケーション コードの複雑さが軽減されます。 場合によっては、オフロードによって機能が信頼性の高いプラットフォーム提供の機能に完全に置き換わる場合があります。 |
| ゲートウェイ ルーティング | 要求の意図、ビジネス ロジック、バックエンドの可用性に基づいて、受信ネットワーク要求をさまざまなバックエンド システムにルーティングします。 ゲートウェイ ルーティングを使用すると、システム内の正常なノードにのみトラフィックをルーティングできます。 |
| ジオード | 複数の地域でアクティブ/アクティブ可用性モードで動作するシステムをデプロイします。 このパターンでは、データ レプリケーションを使用して、任意のクライアントが任意の地理的インスタンスに接続できる理想的な機能をサポートします。 これは、ワークロードが 1 つ以上のリージョンの停止に耐えるのに役立ちます。 |
| 正常性エンドポイント監視 | その目的のために特別に設計されたエンドポイントを公開することで、システムの正常性または状態を監視する方法を提供します。 このエンドポイントを使用して、ワークロードの正常性を管理し、アラートとダッシュボードを作成できます。 また、自己修復修復のシグナルとして使用することもできます。 |
| テーブルのインデックス作成 | クライアントがメタデータを検索してデータを直接取得できるようにすることで、分散データ ストア内のデータ取得を最適化し、完全なデータ ストア スキャンを実行する必要がなくなります。 クライアントは参照プロセスを通じてシャード、パーティション、またはエンドポイントを指しているため、このパターンを使用して、データ アクセスのフェールオーバー アプローチを容易にすることができます。 |
| リーダー選定 | 分散アプリケーションのインスタンスの リーダー を確立します。 リーダーは、目標の達成に関連する責任を調整します。 このパターンは、作業を確実にリダイレクトすることで、ノードの誤動作の影響を軽減します。 また、リーダーが誤動作した場合のコンセンサス アルゴリズムによるフェールオーバーも実装します。 |
| パイプとフィルター | 複雑なデータ処理を一連の独立したステージに分割して、特定の結果を実現します。 各ステージの単一の責任により、集中した注意が払われ、混同されたデータ処理の気が散るのを回避できます。 |
| 優先順位キュー | 優先度の高い項目が処理され、優先度の低い項目の前に完了していることを確認します。 ビジネスの優先順位に基づいて項目を分離することで、最も重要な作業に信頼性の取り組みを集中できます。 |
| パブリッシャー/サブスクライバー | クライアント間通信またはクライアント間通信を中間メッセージ ブローカーまたはイベント バス経由の通信に置き換えることによって、アーキテクチャのコンポーネントを分離します。 |
| キュー ベースの負荷平準化 | 受信要求またはタスクのレベルを制御するには、キューにバッファーを設定し、キュー プロセッサが制御されたペースで処理できるようにします。 このアプローチでは、タスクの到着を処理から切り離すことで、需要の急激な急増に対する回復性を提供できます。 また、キュー処理の誤動作を分離して、取り込み量に影響を与えないようにすることもできます。 |
| レート制限 | クライアント要求のレートを制御して、調整エラーを減らし、無制限の再試行オンエラー シナリオを回避します。 この戦術は、サービスが指定された制限に達しないように設計されている場合に、サービスとの通信に関する制限とコストを認めることで、クライアントを保護します。 これは、特定の期間にサービスに送信される操作の数やサイズを制御することによって機能します。 |
| Retry | 特定の操作を制御された方法で再試行することで、一時的または断続的な障害に対処します。 分散システムでの一時的な障害の軽減は、ワークロードの回復性を向上させる重要な手法です。 |
| saga 分散トランザクション | 作業を小規模で独立したトランザクションのシーケンスに分解することで、実行時間の長いトランザクションと複雑なトランザクションを調整します。 各トランザクションには、実行中のエラーを元に戻し、整合性を維持するための補正アクションも必要です。 通常、複数の分散システムにまたがるモノリシック トランザクションは不可能であるため、このパターンでは原子性と補正を実装することで一貫性と信頼性が提供されます。 |
| Scheduler エージェント スーパーバイザー | システム内で観測可能な要因に基づいて、タスクをシステム全体に効率的に分散および再配布します。 このパターンでは、正常性メトリックを使用してエラーを検出し、正常なエージェントにタスクを再ルーティングして、誤動作の影響を軽減します。 |
| シーケンシャルなコンボイ | 同時メッセージングイングレスを維持しながら、定義された順序で処理をサポートします。 このパターンを使用すると、トラブルシューティングが困難な競合状態、問題のあるメッセージ処理、または誤った順序のメッセージに対処するためのその他の回避策が排除され、誤動作につながる可能性があります。 |
| シャーディング | 特定の要求を処理するために特定の論理宛先に読み込みを送信し、最適化のためにコロケーションを有効にします。 データまたは処理はシャードに分離されているため、1 つのシャードの誤動作は、そのシャードに分離されたままです。 |
| ストラングラー フィグ | 実行中のシステムのコンポーネントを、多くの場合、システムの移行または最新化中に新しいコンポーネントに体系的に置き換えるアプローチを提供します。 このパターンの増分アプローチは、移行中のリスクを軽減するのに役立ちます。 |
| 調整 | リソースまたはコンポーネントへの受信要求のレートまたはスループットに制限を課します。 この制限を設計して、誤動作につながる可能性のあるリソースの枯渇を防ぐことができます。 このパターンは、正常な劣化計画の制御メカニズムとして使用することもできます。 |
次の手順
他の Azure Well-Architected Framework の柱をサポートするクラウド設計パターンを確認します。