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

[アーティクル]
04/20/2023

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

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

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

重要

この記事は、 Azure Well-Architected ミッションクリティカルなワークロードシリーズの一部です。このシリーズに慣れていない場合は、ミッションクリティカルなワークロードの概要から始めてお勧めします。

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

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

グローバルリソース

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

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

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

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

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

リージョンリソース

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

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

ミッションクリティカルなワークロードのベースラインアーキテクチャ

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

「適切に設計されたミッションクリティカルなワークロード: コンテナー化」を参照してください。

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

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

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

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

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

設計領域

提供されている設計ガイダンスを使用して、設計上の主要な決定事項をナビゲートして最適なソリューションに到達することをお勧めします。詳細については、「主要な設計領域とは」を参照してください。

次のステップ

ミッションクリティカルなアプリケーションシナリオを設計するためのベストプラクティスを確認します。

アプリケーションの設計

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