Azure でのミッションクリティカルなワークロードのアーキテクチャパターン

2025-05-07

この記事では、Azure 上のミッションクリティカルなアーキテクチャの主要なパターンについて説明します。設計プロセスを開始し、ビジネス要件に最も適したコンポーネントを選択するときに、このパターンを適用します。この記事では、北星の設計アプローチを推奨し、一般的なテクノロジコンポーネントを含むその他の例を示します。

主要な設計領域を評価し、基になるコンポーネントを使用する重要なユーザーとシステムフローを定義し、次の特性に留意しながら、Azure リソースとその構成のマトリックスを開発することをお勧めします。

特徴	考慮事項
有効期間	ソリューション内の他のリソースと比較して、リソースの予想される有効期間は何ですか? リソースの有効期間をシステムまたはリージョン全体よりも長くするか、共有する必要はありますか。または一時的にする必要がありますか?
状態	このレイヤーでの永続化状態が信頼性または管理容易性にどのような影響を与えますか?
リーチ	リソースはグローバルに分散する必要がありますか? リソースは、グローバルまたはそのリージョン内にある他のリソースと通信できますか?
依存関係	他のリソースへの依存関係は何ですか?
スケールの制限	そのリソースで予想されるスループットは何ですか? その需要に合わせてリソースによって提供されるスケールはどのくらいですか?
可用性とディザスターリカバリー	このレイヤーでの障害による可用性への影響は何ですか? システム障害が発生するか、ローカライズされた容量または可用性の問題のみを引き起こすか。

上記の特性に基づいて、ミッションクリティカルなリソースを分類して識別します。このアクティビティは、リソース使用率と関連するコストを追跡するのに役立ち、最適化作業に最も重要な場所に集中できます。 ビジネスにとって重要と見なされるリソースのグループにタグを付けすることをお勧めします。これらのリソースの一部は、複数のワークロード間で共有される場合があることに注意してください。

Microsoft が推奨するタグの詳細については、「ミッションクリティカルなワークロードにラベルを付ける」を参照してください。

コアアーキテクチャパターン

ミッションクリティカルなアプリケーションの汎用パターンを示す図。

グローバルリソース

特定のリソースは、各リージョン内にデプロイされたリソースによってグローバルに共有されます。一般的な例としては、複数のリージョンにトラフィックを分散し、アプリケーション全体の永続的な状態を格納し、それらのリソースを監視するために使用されるリソースがあります。

特徴	考慮事項
有効期間	これらのリソースは、長生きすることが予想されます (一時的ではありません)。その有効期間は、システムの有効期間以上に及びます。ダウンタイムなしの更新操作がサポートされていると仮定すると、多くの場合、リソースはインプレースデータとコントロールプレーンの更新で管理されます。
状態	これらのリソースは少なくともシステムの有効期間中に存在するため、このレイヤーは多くの場合、グローバルな geo レプリケート状態を格納する役割を担います。
リーチ	リソースはグローバルに分散し、それらのリソースをホストするリージョンにレプリケートする必要があります。これらのリソースは、待機時間が短く、必要な一貫性を持つリージョンまたは他のリソースと通信することをお勧めします。
依存関係	リソースを使用できない状態がグローバルな障害の原因になる可能性があるため、リソースはリージョンリソースへの依存関係を回避する必要があります。たとえば、1 つのコンテナーに保持されている証明書やシークレットは、コンテナーが配置されているリージョンで障害が発生した場合、グローバルに影響を与える可能性があります。
スケールの制限	多くの場合、これらのリソースはシステム内のシングルトンインスタンスであり、システム全体のスループットを処理できるようにスケーリングできる必要があります。
可用性とディザスターリカバリー	リージョンリソースとスタンプリソースでは、グローバルリソースを使用できます。グローバルリソースは、システム全体の正常性に合わせて高可用性とディザスターリカバリーを使用して構成することが重要です。

リージョンスタンプリソース

スタンプには、ビジネストランザクションの完了に参加するアプリケーションとリソースが含まれます。スタンプは通常、Azure リージョンへのデプロイに対応します。しかし、リージョンは複数のスタンプを持つことができません。

特徴	考慮事項
有効期間	スタンプ外のリージョンリソースが引き続き保持されている間、リソースの追加と削除を動的に行うことができるようにすることを意図して、リソースは短い存続期間 (一時的) が予想されます。一時的な性質は、ユーザーにより多くの回復性、スケール、近接性を提供するために必要です。
状態	スタンプはエフェメラルであり、各デプロイで破棄されるため、スタンプはできるだけステートレスにする必要があります。
リーチ	リージョンおよびグローバルリソースと通信できます。ただし、他のリージョンや他のスタンプとの通信は避ける必要があります。
依存関係	スタンプリソースは独立している必要があります。これらはリージョン内およびグローバルな依存関係を持つことが想定されていますが、同じリージョンまたは他のリージョンにある他のスタンプのコンポーネントに依存しないでください。
スケールの制限	スループットはテストによって確立されます。スタンプ全体のスループットは、最もパフォーマンスの低いリソースに制限されます。スタンプの処理能力は、別のスタンプへのフェールオーバーによって需要が高まる状況を見積もる必要があります。
可用性とディザスターリカバリー	スタンプの一時的な性質のため、ディザスターリカバリーはスタンプを再デプロイすることによって行われます。リソースが異常な状態にある場合は、スタンプ全体を破棄して再デプロイできます。

リージョンリソース

システムは、リージョンにデプロイされているが、スタンプリソースよりも長く存在するリソースを持つことができます。たとえば、スタンプを含め、リージョンレベルでリソースを監視する可観測性リソースなどです。

特徴	考慮事項
有効期間	リソースはリージョンの有効期間を共有し、スタンプリソースをライブで公開します。
状態	リージョンに格納された状態は、そのリージョンの存続期間を超えて存在することはできません。リージョン間で状態を共有する必要がある場合は、グローバルデータストアの使用を検討してください。
リーチ	リソースをグローバルに分散する必要はありません。他のリージョンとの直接通信は、必ず回避する必要があります。
依存関係	スタンプは有効期間が短いため、リソースはグローバルリソースに依存できますが、スタンプリソースには依存しません。
スケールの制限	リージョン内のすべてのスタンプを組み合わせて、リージョンリソースのスケール制限を決定します。

ミションに必須なワークロードの基礎アーキテクチャ

これらのベースラインの例は、ミッションクリティカルなアプリケーションに推奨される北星アーキテクチャとして機能します。ベースラインでは、コンテナー化と、アプリケーションプラットフォーム用のコンテナーオーケストレーターの使用を強くお勧めします。ベースラインでは、Azure Kubernetes Service (AKS) が使用されます。

Well-Architected ミッションクリティカルなワークロード: コンテナー化について参照してください。

ベースラインアーキテクチャ

ミッションクリティカルな体験を始めたばかりの場合は、このアーキテクチャを参考にしてください。ワークロードはパブリックエンドポイント経由でアクセスされ、他の会社のリソースへのプライベートネットワーク接続は必要ありません。
ネットワーク制御を使用したベースライン

このアーキテクチャは、ベースラインアーキテクチャに基づいています。この設計は、インターネットからワークロードリソースへの未承認のパブリックアクセスを防ぐための厳密なネットワーク制御を提供するように拡張されています。
Azure ランディングゾーンのベースライン

このアーキテクチャは、より広範な組織内での統合が必要なエンタープライズセットアップでワークロードをデプロイする場合に適しています。ワークロードでは、一元化された共有サービスが使用され、オンプレミスの接続が必要であり、企業内の他のワークロードと統合されます。これは、Corp. 管理グループを継承する Azure ランディングゾーンのサブスクリプションにデプロイされます。
App Services によるベースライン

このアーキテクチャは、App Services を主要なアプリケーションホスティングテクノロジと見なすことでベースライン参照を拡張し、コンテナーのデプロイに使いやすい環境を提供します。