オペレーショナル エクセレンスをサポートするクラウド設計パターン

  • [アーティクル]

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

多くの設計パターンは、1 つ以上のアーキテクチャの柱を直接サポートしています。 オペレーショナル エクセレンスの柱をサポートする設計パターンでは、安全なデプロイ プラクティスのための強固な基盤を提供し、時間、移行シナリオ、および可観測性の経過に伴うアーキテクチャの進化を促進するトポロジを使用します。

オペレーショナル エクセレンスのための設計パターン

次の表は、オペレーショナル エクセレンスの目標をサポートするクラウド設計パターンをまとめたものです。

Pattern まとめ
破損対策レイヤー レガシ コンポーネントと新しいコンポーネント間のプロキシ操作にメディエーター レイヤーを追加することで、レガシ システムの動作または実装の選択肢から新しいシステム コンポーネントを保護します。 このパターンは、これらのレガシ システムと統合するときに、異なるデータ モデルやビジネス ルールを持つ可能性があるレガシ実装によって、新しいコンポーネント設計が引き続き非フラッシュ状態に保たれるようにするのに役立ちます。 このパターンは、システムの段階的な移行に特に役立ちます。 既存のコンポーネントをサポートしながら、新しいコンポーネントの技術的負債を削減します。
コレオグラフィ 分散化されたイベントドリブン通信を使用して、ワークロード内の自律分散コンポーネントの動作を調整します。 このパターンは、ワークロードのライフサイクル中に頻繁にサービスを更新または置換する場合に役立ちます。 分散コンポーネントは自律的であるため、システムに対する全体的な変更を少なくしてワークロードを変更できます。
コンピューティング リソース統合 密度を高めることで、コンピューティング リソースを最適化および統合します。 このパターンは、共有インフラストラクチャ上のワークロードの複数のアプリケーションまたはコンポーネントを組み合わせたものです。 統合により、より均質なコンピューティング プラットフォームが実現します。これにより、管理と可観測性を簡素化し、運用タスクに対するさまざまなアプローチを減らし、必要なツールの量を減らすことができます。
デプロイ スタンプ 同じバージョンまたは異なるバージョンが同時にデプロイされるという前提に基づいて、特定のバージョンのアプリケーションとそのインフラストラクチャを展開の制御された単位として解放するためのアプローチを提供します。 このパターンは、不変のインフラストラクチャの目標に合わせ、高度なデプロイ モデルをサポートし、安全なデプロイ プラクティスを容易にすることができます。
外部構成ストア コードの変更やアプリケーションの再デプロイを必要とせずに、構成値の動的更新をサポートするために、アプリケーションに外部化されたサービスに構成を抽出します。 このアプリケーション構成とアプリケーション コードの分離により、環境固有の構成がサポートされ、構成値にバージョン管理が適用されます。 外部構成ストアは、安全な展開方法を可能にするために機能フラグを管理するための一般的な場所でもあります。
ゲートウェイ集約 1 つの要求で複数のバックエンド サービスへの呼び出しを集計することで、ワークロードとのクライアントの対話を簡略化します。 このトポロジを使用すると、バックエンド ロジックをクライアントとは独立して進化させることができます。これにより、クライアントのタッチポイントを変更することなく、チェーンされたサービスの実装、さらにはデータ ソースを変更できます。
ゲートウェイ オフロード 要求をバックエンド ノードに転送する前と後に、ゲートウェイ デバイスに要求処理をオフロードします。 オフロード ゲートウェイを要求プロセスに追加すると、複数のノードから管理するのではなく、1 つのポイントからオフロードされた機能の構成と維持を管理できます。
ゲートウェイ ルーティング 要求の意図、ビジネス ロジック、バックエンドの可用性に基づいて、受信ネットワーク要求をさまざまなバックエンド システムにルーティングします。 ゲートウェイ ルーティングを使用すると、バックエンドから要求を切り離し、バックエンドで高度なデプロイ モデル、プラットフォームの移行、および転送中のドメイン名解決と暗号化の単一管理ポイントをサポートできるようになります。
正常性エンドポイント監視 その目的のために特別に設計されたエンドポイントを公開することで、システムの正常性または状態を監視する方法を提供します。 ワークロード全体で公開する正常性エンドポイントと結果の分析レベルを標準化すると、問題をトリアージするのに役立ちます。
メッセージング ブリッジ プロトコルまたは形式のために互換性のないメッセージング システム間の通信を可能にする中継手段を提供します。 この分離により、ワークロード内でメッセージングとイベント テクノロジを移行する場合や、外部の依存関係から異種要件がある場合に柔軟性が得られます。
パブリッシャー/サブスクライバー クライアント間通信またはクライアント間通信を中間メッセージ ブローカーまたはイベント バス経由の通信に置き換えることによって、アーキテクチャのコンポーネントを分離します。 この間接参照レイヤーを使用すると、両方のコンポーネントへの変更を調整しなくても、パブリッシャー側またはサブスクライバー側で実装を安全に変更できます。
検疫 外部資産をワークロードで使用する承認を受ける前に、チームが合意した品質レベルを満たしていることを確認します。 これらのチェックの自動化と一貫性は、ワークロードのソフトウェア開発ライフサイクルと安全なデプロイ プラクティス (SDP) の一部です。
Sidecar メイン アプリケーションと共に存在するコンパニオン プロセスに非特権タスクまたはクロスカット タスクをカプセル化することで、アプリケーションの機能を拡張します。 このパターンは、アプリケーションが直接実装の依存関係を取る必要なく、アプリケーションの可観測性を向上させる可能性がある、ツール統合の柔軟性を実装するためのアプローチを提供します。 これにより、サイドカー機能は独立して進化し、アプリケーションのライフサイクルとは無関係に維持されます。
ストラングラー フィグ 実行中のシステムのコンポーネントを、多くの場合、システムの移行または最新化中に新しいコンポーネントに体系的に置き換えるアプローチを提供します。 このパターンは継続的な改善アプローチを提供します。このアプローチでは、実装するリスクの高い大規模な全身変更ではなく、時間の経過に伴う小さな変更による増分置換が推奨されます。

次の手順

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