クラウド設計パターン
アーキテクトは、プラットフォーム サービス、機能、およびコードを組み合わせてワークロードを設計し、ワークロードの機能要件と非機能要件を満たします。 ワークロードを設計するには、これらのワークロード要件を理解し、トポロジを選択し、ワークロードの制約によって提示される課題の解決にアプローチする必要があります。 多くの一般的な課題に対処するクラウド設計パターン。
システム設計は、設計パターンに大きく染み込んでいます。 インフラストラクチャ、コード、分散システムはすべて、設計パターンの組み合わせを中心に設計されています。 これらの設計パターンは、信頼性が高く、セキュリティで保護され、コストが最適化され、運用上正常で、パフォーマンスの高いアプリケーションをクラウドで構築するのに役立ちます。
これらの設計パターンは、どのテクノロジにも固有ではなく、Azure、他のクラウド プラットフォームでホストされているかどうかに関係なく、分散システムに関連しており、一部はオンプレミスワークロードやハイブリッド ワークロードにも拡張できます。
クラウド設計パターンが設計プロセスに役立つ
クラウド ワークロードでは、分散コンピューティングに関する誤解が生じやすくなります。 クラウド設計に関する誤解の例を次に示します。
- ネットワークは信頼できる
- 待機時間はゼロである
- 帯域幅は無限に存在する
- ネットワークはセキュリティで保護されている
- トポロジが変更されることはない
- 管理者が 1 人いる
- コンポーネントのバージョン管理は容易である
- 監視の実装は遅れてもよい
設計パターンを使用しても、このような誤解は払拭できませんが、誤った認識の緩和および補正を促し、適切な認識をもたらすために役立つ場合があります。 各クラウド パターンには、それぞれのトレードオフが存在します。 特定のパターンを実装する方法よりも、なぜそのパターンを選択するのかという点に注意を払う必要があります。
適切に設計されたワークロードでは、これらの業界全体の設計パターンをワークロード設計の中核となる構成要素として使用する方法が考慮されます。 すべての Azure Well-Architected の柱は、これらの設計パターンで表されます。多くの場合、設計パターンによって他の柱の目標とのトレードオフが導入されます。
パターンのカタログ
このカタログの各パターンでは、パターンが対処する問題、パターンの適用に関する考慮事項、および Microsoft Azure に基づく例について説明します。 一部のパターンには、Azure にパターンを実装する方法を示すコード サンプルまたはスニペットが含まれます。
| Pattern | まとめ | Azure Well-Architected Framework の柱 |
|---|---|---|
| Ambassador | コンシューマー サービスまたはアプリケーションの代わりにネットワーク要求を送信するヘルパー サービスを作成します。 |
|
| 破損対策レイヤー | 最新アプリケーションとレガシ システムの間にファサード、すなわちアダプター レイヤーを実装します。 |
|
| 非同期要求-応答 | フロントエンド ホストからバックエンド処理を分離します。その場合バックエンド処理を非同期にする必要がありますが、引き続きフロントエンドには明確な応答が必要です。 |
|
| フロントエンド用バックエンド | 特定のフロントエンド アプリケーションまたはインターフェイスで使用する個別のバックエンド サービスを作成します。 |
|
| Bulkhead | アプリケーションの要素をプールに分離して、障害が発生しても他の要素が引き続き機能するようにします。 |
|
| キャッシュ アサイド | データ ストアからキャッシュにオンデマンドでデータを読み込みます。 |
|
| コレオグラフィ | 中央のオーケストレーターに依存するのではなく、業務をいつどのように処理するかを各サービスで決定できます。 |
|
| Circuit Breaker | リモート サービスまたはリソースとの接続時の修正に要する時間が一定しないエラーを処理します。 |
|
| 要求チェック | 大きいメッセージを要求チェックとペイロードに分割して、メッセージ バスに過度な負荷がかかることを防ぎます。 |
|
| 補正トランザクション | 最終的に整合性がある操作を定義する一連のステップで実行された作業を元に戻します。 |
|
| 競合コンシューマー | 複数の同時実行コンシューマーが、同じメッセージング チャネルで受信したメッセージを処理できるようにします。 |
|
| コンピューティング リソース統合 | 複数のタスクまたは操作を 1 つの計算単位に統合します。 |
|
| CQRS | 個別のインターフェイスを使用して、データを更新する操作とデータを読み取る操作を分離します。 |
|
| デプロイ スタンプ | データ ストアなど、アプリケーション コンポーネントの複数の独立したコピーをデプロイします。 |
|
| エッジ ワークロードの構成 | 構成を一元化して、現場で複数のシステムとデバイスを構成する課題に対処します。 | |
| イベント ソーシング | 追加専用のストアを使用して、ドメイン内のデータに実行されるアクションを記述する一連のすべてのイベントを記録します。 |
|
| 外部構成ストア | アプリケーション展開パッケージから、一元管理される場所に構成情報を移動します。 |
|
| フェデレーション ID | 外部の ID プロバイダーに認証を委任します。 |
|
| ゲートキーパー | 専用のホスト インスタンスを使用して、アプリケーションとサービスを保護します。このホスト インスタンスは、クライアントとアプリケーションまたはサービスの間でブローカーとして機能し、要求を検証して不要部分を削除し、クライアントとアプリケーションまたはサービスの間で要求とデータを渡します。 |
|
| ゲートウェイ集約 | ゲートウェイを使用して、複数の個々の要求を 1 つの要求に集約します。 |
|
| ゲートウェイ オフロード | 共有または専用のサービス機能の負荷をゲートウェイ プロキシにオフロードします。 |
|
| ゲートウェイ ルーティング | 単一のエンドポイントを使用して複数のサービスに要求をルーティングします。 |
|
| ジオード | バックエンド サービスを一連の地理的ノードにデプロイします。各ノードが、任意のリージョンで任意のクライアント要求を処理できます。 |
|
| 正常性エンドポイント監視 | 公開されたエンドポイントを通じて外部ツールが定期的にアクセスできる機能チェックをアプリケーションに実装します。 |
|
| テーブルのインデックス作成 | クエリによって頻繁に参照されるデータ ストア内のフィールドにインデックスを作成します。 |
|
| リーダー選定 | 1 つのインスタンスを、他のインスタンスの管理を担当するリーダーとして選定することで、分散アプリケーション内で連携するタスク インスタンスのコレクションによって実行されるアクションを調整します。 |
|
| 具体化されたビュー | データの形式が必要なクエリ操作に適していない場合に、1 つ以上のデータ ストアのデータの事前設定されたビューを生成します。 |
|
| メッセージング・ブリッジ | プロトコルまたは形式のために互換性のないメッセージング システム間の通信を有効にする仲介者を構築します。 |
|
| パイプとフィルター | 複雑な処理を実行するタスクを、再利用できる一連の独立した要素に分解します。 |
|
| 優先順位キュー | サービスに送信される要求に優先順位を設定し、優先順位の高い要求から順番に受信および処理されるようにします。 |
|
| パブリッシャー/サブスクライバー | 送信側と受信側を結合せずに、アプリケーションから関心を持っている複数のコンシューマーに対して非同期的にイベントを通知できるようにします。 |
|
| 検疫 | 外部資産をワークロードで使用する権限が与えられる前に、チームが合意した品質レベルを満たしていることを確認します。 |
|
| キュー ベースの負荷平準化 | タスクとそのタスクが呼び出すサービスとの間でバッファーとして機能するキューを使用して、断続的な大きい負荷を平準化します。 |
|
| レート制限パターン | これら調整制限に関連する調整エラーを回避または最小化し、スループットをより正確に予測するのに役立つ制限パターン。 |
|
| Retry | 予測される一時的な障害をアプリケーションが処理できるようにします。アプリケーションがサービスまたはネットワーク リソースに接続しようとする際に、失敗した操作を透過的に再試行します。 |
|
| Saga | 分散トランザクションのシナリオで、マイクロサービス間のデータ整合性を管理します。 saga はトランザクションのシーケンスです。この saga によって各サービスが更新され、次のトランザクション ステップをトリガーするメッセージまたはイベントが発行されます。 |
|
| Scheduler エージェント スーパーバイザー | 分散された一連のサービスやその他のリモート リソースにわたる一連のアクションを調整します。 |
|
| シーケンシャルなコンボイ | 他のメッセージ グループの処理をブロックせずに、関連する一連のメッセージを定義された順序で処理します。 |
|
| シャーディング | データ ストアを水平方向のパーティションまたはシャードのセットに分割します。 |
|
| Sidecar | アプリケーションのコンポーネントを別のプロセスまたはコンテナーにデプロイして、分離性とカプセル化を実現します。 |
|
| 静的コンテンツ ホスティング | 静的コンテンツを、クライアントに直接配信できるクラウド ベースのストレージ サービスにデプロイします。 |
|
| ストラングラー フィグ | 機能の特定の部分を新しいアプリケーションやサービスに徐々に置き換えることで、レガシ システムを段階的に移行します。 |
|
| 調整 | アプリケーションのインスタンス、個々のテナント、またはサービス全体によって使用されるリソースの使用量を制御します。 |
|
| バレット キー | 特定のリソースまたはサービスへの限定的な直接アクセスをクライアントに提供する、トークンまたはキーを使用します。 |
|
次の手順
パターンが最適化しようとしている Azure Well-Architected Pillar の観点から設計パターンを確認します。
- 信頼性の柱 をサポートする設計パターン
- セキュリティの柱 をサポートする設計パターン
- コスト最適化の柱 をサポートする設計パターン
- オペレーショナル エクセレンスの柱をサポートする設計パターン
- パフォーマンス効率の柱をサポートする設計パターン