ミッション クリティカルなワークロードに関するアプリケーション プラットフォームの考慮事項

ミッション クリティカルなアーキテクチャの重要な設計領域は、アプリケーション プラットフォームです。 プラットフォームとは、アプリケーションをサポートするためにプロビジョニングする必要があるインフラストラクチャ コンポーネントと Azure サービスを指します。 以下に、包括的な推奨事項をいくつか示します。

• レイヤーでのデザイン。 適切なサービス セット、それらの構成、アプリケーション固有の依存関係の選択。 この階層化アプローチは、論理および物理セグメント化の作成に役立ちます。 ロールと機能を定義し、適切な特権とデプロイ戦略を割り当てる場合に便利です。 このアプローチにより、最終的にシステムの信頼性が向上します。

• ミッション クリティカルなアプリケーションは、信頼性が高く、データセンターや地域の障害に対する耐性を持っている必要があります。 アクティブ/アクティブ構成でゾーンとリージョンの冗長性を構築することが主な戦略です。 アプリケーションのプラットフォーム用に Azure サービスを選択するときは、複数の Azure リージョンを使用するために、Availability Zones のサポート、デプロイ、運用パターンを検討してください。

• スケール ユニット ベースのアーキテクチャを使用して、負荷の増加に対処します。 スケール ユニットを使用すると、リソースを論理的にグループ化できます。ユニットは、アーキテクチャ内の他のユニットやサービスとは無関係にスケーリングできます。 容量モデルと予想されるパフォーマンスを使用して、各ユニットの境界、数、ベースライン スケールを定義します。

このアーキテクチャでは、アプリケーション プラットフォームはグローバル、デプロイ スタンプ、リージョンのリソースで構成されます。 リージョン リソースは、デプロイ スタンプの一部としてプロビジョニングされます。 各スタンプはスケール ユニットに相当し、異常になった場合は完全に置き換えることができます。

各レイヤーのリソースには、それぞれ異なる特性があります。 詳細については、一般的なミッション クリティカルなワークロードのアーキテクチャ パターンに関する記事を参照してください。

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

グローバル リソース

このアーキテクチャの特定のリソースは、リージョンにデプロイされたリソースによって共有されます。 このアーキテクチャでは、トラフィックを複数のリージョンに分散し、アプリケーション全体の永続的状態を格納し、グローバル静的データをキャッシュするために使用されます。

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

このアーキテクチャでは、グローバル レイヤー リソースは、他のグローバル レイヤー リソースからログとメトリックを格納するための Azure Front Door、Azure Cosmos DB、Azure Container Registry、Azure Log Analytics です。

この設計には、Microsoft Entra ID や Azure DNS など、他にも基本的なリソースがあります。 簡潔にするために、この画像では省略されています。

グローバル ロード バランサー

Azure Front Door は、ユーザー トラフィックの唯一のエントリ ポイントとして使用されます。 Azure では、Azure Front Door が要求されたコンテンツを 99.99% エラーなしで配信することを保証します。 詳細については、Front Door サービスの制限に関するページを参照してください。 Front Door が使用できなくなった場合、エンド ユーザーはシステムがダウンしていることがわかります。

Front Door インスタンスから、API とフロントエンド SPA をホストするコンピューティング クラスターなど、構成されたバックエンド サービスにトラフィックが送信されます。 Front Door のバックエンドの構成ミスにより、障害が発生する可能性があります。 構成ミスによる障害を回避するには、Front Door の設定を広範囲にテストする必要があります。

もう 1 つの一般的なエラーは、TLS 証明書が正しく構成されていないか不足していることが原因で、ユーザーがフロントエンドまたは Front Door を使用してバックエンドと通信できなくなることです。 軽減策には手動による介入が必要な場合があります。 たとえば、可能であれば、前の構成にロールバックし、証明書を再発行することを選択できます。 いずれにせよ、変更が有効になる間は使用できなくなることを想定してください。 Front door によって提供されるマネージド証明書を使用して、有効期限の処理などの運用上のオーバーヘッドを軽減することをお勧めします。

Front Door には、グローバル トラフィック ルーティング以外にも多くの追加機能が用意されています。 Front Door では通過しているトラフィックを検査できるため、重要な機能は Web Application Firewall (WAF) です。 防止モードで構成すると、バックエンドに到達する前に疑わしいトラフィックがブロックされます。

Front Door の機能の詳細については、Azure Front Door に関してよく寄せられる質問を参照してください。

トラフィックのグローバル分散に関するその他の考慮事項については、適切に設計されたフレームワーク: グローバル ルーティングに関するページのミッションクリティカルガイダンスを参照してください。

Container Registry

Azure Container Registry は、Open Container Initiative (OCI) 成果物、特に Helm チャートとコンテナー イメージを格納するために使用されます。 要求フローには参加せず、定期的にのみアクセスされます。 スタンプ リソースがデプロイされる前にコンテナー レジストリが存在する必要があり、リージョン レイヤー リソースへの依存関係を持つべきではありません。

イメージへのランタイム アクセスが高速で障害に対する回復性を備えるように、レジストリのゾーン冗長性と geo レプリケーションを有効にします。 使用できない場合、インスタンスはレプリカ リージョンにフェールオーバーでき、要求は自動的に別のリージョンに再ルーティングされます。 フェールオーバーが完了するまで、イメージをプルする場合は、一時的なエラーが発生することを想定してください。

また、イメージが誤って削除された場合にもエラーが発生する可能性があります。新しいコンピューティング ノードはイメージをプルできませんが、既存のノードではキャッシュされたイメージを引き続き使用できます。 ディザスター リカバリーの主な戦略は、再デプロイです。 コンテナー レジストリ内の成果物は、パイプラインから再生成できます。 コンテナー レジストリは、すべてのデプロイをサポートするために、多数のコンカレント接続に耐えられる必要があります。

Premium SKU を使用して geo レプリケーションを有効にすることをお勧めします。 ゾーン冗長性機能により、特定のリージョン内の回復性と高可用性が確保されます。 リージョンの障害が発生した場合でも、他のリージョンのレプリカは引き続きデータ プレーン操作に使用できます。 この SKU を使用すると、プライベート エンドポイントを介したイメージへのアクセスを制限できます。

詳細については、「Azure Container Registry のベスト プラクティス」を参照してください。

データベース

すべての状態は、リージョン スタンプから分離されたデータベースにグローバルに格納することをお勧めします。 リージョン間でデータベースをデプロイして冗長性を構築します。 ミッションクリティカルなワークロードの場合、リージョン間でのデータの同期が主な関心事である必要があります。 また、障害が発生した場合でも、データベースへの書き込み要求は引き続き機能している必要があります。

アクティブ/アクティブ構成でのデータ レプリケーションを強くお勧めします。 アプリケーションは、別のリージョンとすぐに接続できる必要があります。 すべてのインスタンスは、読み取り "および" 書き込みの要求を処理できる必要があります。

詳細については、「ミッション クリティカルなワークロードのデータ プラットフォーム」を参照してください。

グローバル監視

Azure Log Analytics は、すべてのグローバル リソースからの診断ログを格納するために使用されます。 特にロード テストに使用される環境では、ストレージに対する 1 日あたりのクォータを制限することをお勧めします。 また、保持ポリシーも設定します。 これらの制限により、制限を超えて必要とされないデータを格納することによって発生する過剰使用が防止されます。

基本サービスに関する考慮事項

システムは、Azure DNS や Microsoft Entra ID など、システム全体が危険にさらされる可能性がある他の重要なプラットフォーム サービスを使う可能性があります。 Azure DNS では、有効な DNS 要求に対して 100% の可用性 SLA が保証されます。 Microsoft Entra では、99.99% 以上のアップタイムが保証されます。 それでも、障害が発生した場合の影響を認識しておく必要があります。

多くの Azure サービスは基本サービスに依存しているため、重い依存関係を取ることは避けられません。 システムが使用できない場合は、中断が予想されます。 次に例を示します。

• Azure Front Door では、Azure DNS を使用してバックエンドやその他のグローバル サービスに到達します。
• Azure Container Registry では、Azure DNS を使用して、要求を別のリージョンにフェールオーバーします。

どちらの場合も、Azure DNS が使用できない場合、両方の Azure サービスが影響を受けます。 Front Door からのユーザー要求の名前解決は失敗します。Docker イメージはレジストリからプルされません。 外部 DNS サービスをバックアップとして使用しても、多くの Azure サービスではこのような構成が許可されておらず、内部 DNS に依存しているため、リスクは軽減されません。 完全な停止が予想されます。

同様に、Microsoft Entra ID は、新しい AKS ノードの作成、Container Registry からのイメージのプル、ポッドの起動時の Key Vault へのアクセスなどのコントロール プレーン操作に使われます。 Microsoft Entra ID を使用できない場合は、既存のコンポーネントは影響を受けないと考えられますが、全体的なパフォーマンスが低下する可能性があります。 新しいポッドまたは AKS ノードは機能しません。 そのため、この期間中にスケールアウト操作が必要な場合は、ユーザー エクスペリエンスの低下が予想されます。

リージョン デプロイ スタンプ リソース

このアーキテクチャでは、デプロイ スタンプによってワークロードがデプロイされ、ビジネス トランザクションの完了に関与するリソースがプロビジョニングされます。 スタンプは通常、Azure リージョンへのデプロイに対応します。 しかし、リージョンは複数のスタンプを持つことができません。

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

このアーキテクチャでは、スタンプ リソースは Azure Kubernetes Service、Azure Event Hubs、Azure Key Vault、Azure Blob Storage です。

スケール ユニット

スタンプはスケール ユニット (SU) と見なすこともできます。 特定のスタンプ内のすべてのコンポーネントとサービスは、特定の範囲内で要求を処理するように構成され、テストされます。 実装で使用されるスケール ユニットの例を次に示します。

各スケール ユニットは Azure リージョンにデプロイされるため、主にその特定の領域からのトラフィックを処理します (ただし、必要に応じて他のリージョンからのトラフィックを引き継ぐ可能性があります)。 この地理的な広がりにより、ロード パターンと営業時間が地域によって異なる可能性があるため、すべての SU はアイドル時にスケールインまたはスケールダウンするように設計されます。

スケーリングする新しいスタンプをデプロイできます。 スタンプ内では、個々のリソースをスケールの単位にすることもできます。

1 つのユニットで Azure サービスを選択する場合のスケーリングと可用性に関する考慮事項を次に示します。

• スケール ユニット内のすべてのリソース間の容量関係を評価します。 たとえば、100 個の受信要求を処理するには、5 つのイングレス コントローラー ポッド、3 つのカタログ サービス ポッド、Azure Cosmos DB で 1000 RU が必要です。 そのため、イングレス ポッドを自動スケールする場合は、その範囲に応じたカタログ サービスと Azure Cosmos DB RU のスケーリングを想定します。

• サービスをロード テストして、要求が処理される範囲を決定します。 結果に基づいて、最小インスタンスと最大インスタンスとターゲット メトリックを構成します。 ターゲットに到達したら、ユニット全体のスケーリングを自動化することを選択できます。

• Azure サブスクリプションのスケール制限とクォータを確認して、ビジネス要件によって設定された容量とコスト モデルをサポートします。 また、考慮に入れる個々のサービスの制限も確認してください。 ユニットは一緒にデプロイされるのが一般的であるため、カナリア デプロイに必要なサブスクリプション リソースの制限を考慮します。 詳細については、Azure サービスの制限に関するページを参照してください。

• 可用性ゾーンをサポートするサービスを選択して、冗長性を構築します。 これにより、テクノロジの選択肢が制限される可能性があります。 詳細については、Availability Zones に関するページを参照してください。

ユニットのサイズとリソースの組み合わせに関するその他の考慮事項については、適切に設計されたフレームワーク: スケール ユニット アーキテクチャに関するページのミッションクリティカル ガイダンスを参照してください。

コンピューティング クラスター

ワークロードをコンテナー化するには、各スタンプでコンピューティング クラスターを実行する必要があります。 このアーキテクチャでは、Kubernetes が最新のコンテナー化されたアプリケーションで最も一般的なコンピューティング プラットフォームであるため、Azure Kubernetes Service (AKS) が選択されています。

AKS クラスターの有効期間は、スタンプの一時的な性質にバインドされます。 クラスターはステートレスであり、永続ボリュームがありません。 マネージド ディスクの代わりにエフェメラル OS ディスクが使用されます。これは、アプリケーションまたはシステム レベルのメンテナンスを受けることが想定されていないためです。

信頼性を高めるために、クラスターは、特定のリージョンの 3 つの可用性ゾーンをすべて使用するように構成されています。 これにより、AKS コントロール プレーンの 99.95% の SLA 可用性を保証する AKS アップタイム SLA をクラスターで使用できるようになります。

スケール制限、コンピューティング容量、サブスクリプション クォータなどのその他の要因も、信頼性に影響を与える可能性があります。 十分な容量がない場合、または制限に達した場合、スケールアウト操作とスケールアップ操作は失敗しますが、既存のコンピューティングが機能することが期待されます。

クラスターでは自動スケールが有効になっており、必要に応じてノード プールが自動的にスケールアウトされるため、信頼性が向上します。 複数のノード プールを使用する場合は、すべてのノード プールを自動スケールする必要があります。

ポッド レベルでは、ポッドの水平オートスケーラー (HPA) によって、構成された CPU、メモリ、またはカスタム メトリックに基づいてポッドがスケーリングされます。 ワークロードのコンポーネントをロード テストして、自動スケーラーと HPA 値のベースラインを確立します。

また、クラスターは、ノード イメージの自動アップグレードと、それらのアップグレード中に適切にスケーリングするように構成されます。 このスケーリングにより、アップグレードの実行中にダウンタイムをゼロにできます。 アップグレード中に 1 つのスタンプ内のクラスターが失敗した場合、他のスタンプ内の他のクラスターは影響を受けませんが、可用性を維持するために、スタンプ間のアップグレードは異なる時点で行われる必要があります。 また、クラスターのアップグレードは、同時に使用できないように、ノード間で自動的にロールされます。

cert-manager や ingress-nginx などの一部のコンポーネントでは、外部コンテナー レジストリからのコンテナー イメージが必要です。 これらのリポジトリまたはイメージが使用できない場合は、新しいノード (イメージがキャッシュされていない) 上の新しいインスタンスを開始できない可能性があります。 これらのイメージを環境の Azure Container Registry にインポートすることで、このリスクを軽減できます。

スタンプは一時的であるため、このアーキテクチャでは可観測性が重要です。 診断設定は、すべてのログとメトリック データをリージョンの Log Analytics ワークスペースに格納するように構成されます。 また、AKS Container Insights は、クラスター内 OMS エージェントを介して有効になります。 このエージェントを使用すると、クラスターから Log Analytics ワークスペースに監視データを送信できます。

コンピューティング クラスターに関するその他の考慮事項については、適切に設計されたフレームワーク: コンテナー オーケストレーションと Kubernetes に関するページのミッションクリティカルのガイダンスを参照してください。

Key Vault

Azure Key Vault は、データベースへの接続文字列や Event Hubs 接続文字列などのスタンプ シークレットといったグローバル シークレットを格納するために使用されます。

このアーキテクチャでは、コンピューティング クラスター内のシークレット ストア CSI ドライバーを使用して、Key Vault からシークレットを取得します。 シークレットは、新しいポッドが生成されるときに必要です。 Key Vault が使用できない場合は、新しいポッドが開始されない可能性があります。 その結果、中断が発生する可能性があります。スケールアウト操作が影響を受け、更新が失敗すし、新しいデプロイを実行することができない可能性があります。

Key Vault では、操作の数に制限があります。 シークレットの自動更新により、ポッドが多数ある場合は制限に達する可能性があります。 この状況を回避するために、更新の頻度を減らすことができます。

シークレット管理に関するその他の考慮事項については、適切に設計されたフレームワーク: データ整合性保護に関するページのミッションクリティカルのガイダンスを参照してください。

Event Hubs

スタンプ内の唯一のステートフル サービスは、短期間要求を格納するメッセージ ブローカー (Azure Event Hubs) です。 ブローカーは、バッファリングと信頼性の高いメッセージングの必要性に対応します。 処理された要求はグローバル データベースに保持されます。

このアーキテクチャでは、Standard SKU が使用され、高可用性のためにゾーン冗長性が有効になっています。

Event Hubs の正常性は、コンピューティング クラスターで実行されている HealthService コンポーネントによって検証されます。 さまざまなリソースに対して定期的なチェックを実行します。 これは、異常な状態を検出する場合に役立ちます。 たとえば、メッセージをイベント ハブに送信できない場合、スタンプはどの書き込み操作でも使用できなくなります。 HealthService は、この状態を自動的に検出し、異常な状態を Front Door に報告する必要があります。これにより、スタンプがローテーションから除外されます。

スケーラビリティのためには、自動インフレを有効にすることをお勧めします。

詳細については、「ミッション クリティカルなワークロードのメッセージング サービス」を参照してください。

メッセージングに関するその他の考慮事項については、適切に設計されたフレームワーク: 非同期メッセージングに関するページのミッションクリティカルのガイダンスを参照してください。

ストレージ アカウント

このアーキテクチャでは、2 つのストレージ アカウントがプロビジョニングされます。 どちらのアカウントもゾーン冗長モード (ZRS) でデプロイされます。

Event Hubs のチェックポイント処理に、1 つのアカウントが使用されます。 このアカウントが応答しない場合、スタンプは Event Hubs からのメッセージを処理できず、スタンプ内の他のサービスにも影響を与える可能性があります。 この条件は、コンピューティング クラスターで実行されているアプリケーション コンポーネントの 1 つである HealthService によって定期的にチェックされます。

もう 1 つは、UI シングルページ アプリケーションをホストするために使用されます。 静的 Web サイトのサービスに問題がある場合、Front Door は問題を検出し、このストレージ アカウントにトラフィックが送信されません。 この間、Front Door ではキャッシュされたコンテンツを使用できます。

復旧の詳細については、「ディザスター リカバリーとストレージ アカウントのフェールオーバー」を参照してください。

リージョン リソース

システムは、リージョンにデプロイされているが、スタンプ リソースよりも長く存在するリソースを持つことができます。 このアーキテクチャでは、スタンプ リソースの可観測データがリージョンのデータ ストアに格納されます。

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

スタンプ リソースのデータの監視

監視リソースのデプロイは、リージョン リソースの一般的な例です。 このアーキテクチャでは、各リージョンには、スタンプ リソースから出力されたすべてのログとメトリック データを格納するように個別の Log Analytics ワークスペースが構成されています。 リージョン リソースはスタンプ リソースよりも長く存続するため、スタンプが削除された場合でもデータを使用できます。

Azure Log Analytics と Azure Application Insights は、プラットフォームからのログとメトリックを格納するために使用されます。 特にロード テストに使用される環境では、ストレージに対する 1 日あたりのクォータを制限することをお勧めします。 また、すべてのデータを格納するアイテム保持ポリシーを設定します。 これらの制限により、制限を超えて必要とされないデータを格納することによって発生する過剰使用が防止されます。

同様に、Application Insights も、すべてのアプリケーション監視データを収集するリージョン リソースとしてデプロイされます。

監視に関する設計上の推奨事項については、適切に設計されたフレームワーク: 正常性モデリングに関するページのミッションクリティカルのガイダンスを参照してください。

次のステップ

参照実装をデプロイして、このアーキテクチャで使用されているリソースとその構成を完全に理解します。

実装: Mission-Critical Online