このアーキテクチャでは、Azure でミッション クリティカルなワークロードを設計するためのガイダンスを提供します。 これは、クラウドネイティブの機能を使用して、信頼性と運用効率を最大化します。 Well-Architected なミッション クリティカル ワークロードの設計手法を、インターネットに接続するアプリケーションに適用します。この場合、ワークロードはパブリック エンドポイント経由でアクセスされ、他の会社のリソースへのプライベート ネットワーク接続を必要としません。
重要
このガイダンスは、Azure でのミッション クリティカルなアプリケーション開発を紹介する実稼働グレードの実装例によって裏付けられます。 この実装は、実稼働に向けた最初のステップにおけるさらなるソリューション開発の基礎として使用できます。
信頼性レベル
信頼性は相対的な概念であり、ワークロードの信頼性を適切に確保するには、それを取り巻くビジネス要件が反映されている必要があります。たとえば、アプリケーションが利用可能な時間の割合を取得するためのサービス レベル目標 (SLO) やサービス レベル アグリーメント (SLA) などです。
このアーキテクチャは、99.99% の SLO を目標としており、これは、52 分 35 秒の許可された年間ダウンタイムに相当します。 したがって、すべての包括的な設計上の決定は、このターゲット SLO を達成することを目的としています。
ヒント
現実的な SLO を定義するには、アーキテクチャ内のすべての Azure コンポーネントの SLA を理解することが重要です。 これらの個々の数値を集計して、ワークロード ターゲットと一致する複合 SLA を決定する必要があります。
「Well-Architected なミッション クリティカル ワークロード: ビジネス要件の設計」を参照してください。
主要な設計戦略
障害から回復する機能、リージョンの可用性、デプロイの有効性、セキュリティなど、多くの要因がアプリケーションの信頼性に影響を与える可能性があります。 このアーキテクチャでは、これらの要因に対処し、ターゲットの信頼性レベルを確実に達成することを目的とした一連の包括的な設計戦略を適用します。
レイヤーの冗長性
"アクティブ/アクティブ モデル内の複数のリージョン" にデプロイします。 アプリケーションは、アクティブなユーザー トラフィックを処理する 2 つ以上の Azure リージョンに分散されます。
すべての検討対象サービスに対して Availability Zones (AZs) を利用して、1 つの Azure リージョン内の可用性を最大化し、リージョン内の物理的に分離されたデータ センターにコンポーネントを分散させます。
"グローバル分散" をサポートするリソースを選択します。
「Well-Architected なミッション クリティカル ワークロード: グローバル分散」を参照してください。
デプロイ スタンプ
リージョンのスタンプを "スケール ユニット" としてデプロイします。ここでは、需要の変化に対応するために、リソースの論理セットを個別にプロビジョニングできます。 各スタンプでは、個別にスケールインおよびスケールアウトできるフロントエンド API やバックグラウンド プロセッサなど、入れ子になった複数のスケール ユニットも適用されます。
「Well-Architected なミッション クリティカル ワークロード: スケール ユニット アーキテクチャ」を参照してください。
信頼性が高く、反復可能なデプロイ
Terraform などのテクノロジを使用して、"コードとしてのインフラストラクチャ (IaC) の原則" を適用し、インフラストラクチャ コンポーネントのバージョン管理と標準化された運用アプローチを提供します。
"ダウンタイムなしのブルー/グリーンのデプロイ パイプライン" を実装します。 継続的な検証が適用されたブルー/グリーンのデプロイを使用して、ビルドとリリースのパイプラインを完全に自動化し、スタンプを 1 つの運用ユニットとしてデプロイする必要があります。
実稼働環境と実稼働前環境で同じデプロイ パイプライン コードを使用して、すべての検討対象環境に "環境の一貫性" を適用します。 これにより、環境間でのデプロイとプロセスのばらつきに関連するリスクが排除されます。
同期ロードやカオスのテストなど、DevOpsプロセスの一部として自動テストを統合して、"継続的な検証" を行い、アプリケーション コードと基になるインフラストラクチャの両方の正常性を完全に検証します。
「Well-Architected なミッション クリティカル ワークロード: デプロイとテスト」を参照してください。
運用の分析情報
"監視データ用のフェデレーション ワークスペース"を用意します。 グローバル リソースとリージョン リソースの監視データは、個別に格納されます。 単一障害点を回避するために、一元化された監視ストアは推奨されません。 統合されたデータ シンクと操作用の 1 つのウィンドウを実現するために、クロス ワークスペース クエリが使用されます。
コンテキスト化のためにアプリケーションの正常性を信号モデルにマップする "階層化された正常性モデル" を構築します。 正常性スコアは、個々のコンポーネントごとに計算されます。その後、ユーザー フロー レベルで集計され、アプリケーションの正常性を定量化するための係数として、パフォーマンスなどの機能以外の主要な要件と組み合わされます。
「Well-Architected なミッション クリティカル ワークロード: 正常性モデリング」を参照してください。
アーキテクチャ
*このアーキテクチャの Visio ファイルをダウンロードします。
このアーキテクチャのコンポーネントは、この方法で大まかに分類できます。 Azure サービスに関する製品ドキュメントについては、「関連リソース」を参照してください。
グローバル リソース
グローバル リソースの存続期間は長く、システムの有効期間を共有します。 これらは、マルチリージョン デプロイ モデルのコンテキスト内でグローバルに使用可能にすることができます。
コンポーネントに関する大まかな考慮事項を次に示します。 決定の詳細については、「グローバル リソース」を参照してください。
グローバル ロード バランサー
グローバル ロード バランサーは、リージョン内のバックエンド サービスの可用性に基づいた保証レベルを適用して、トラフィックをリージョンのデプロイに確実にルーティングするために重要です。 また、このコンポーネントには、たとえば Web アプリケーション ファイアウォールを使用するなど、イングレス トラフィックを検査する機能が必要になります。
Azure Front Door は、すべての受信クライアント HTTP(S) トラフィックのグローバル エントリ ポイントとして使用され、セキュリティで保護されたレイヤー 7 イングレス トラフィックに Web Application Firewall (WAF) 機能が適用されます。 これは、TCP Anycast を使用して、Microsoft バックボーン ネットワークを使用するルーティングを最適化するとともに、リージョンの正常性が低下した場合に透過的なフェールオーバーを可能にします。 ルーティングは、主要なリージョン リソースの複合的な正常性をチェックするカスタム正常性プローブに依存します。 Azure Front Door には、Web サイト コンポーネントの静的アセットをキャッシュするための組み込みのコンテンツ配信ネットワーク (CDN) も用意されています。
もう 1 つのオプションは、DNS ベースのレイヤー 4 ロード バランサーである Traffic Manager です。 ただし、DNS 伝播が発生する必要があるため、すべてのクライアントに対して障害が透過的になるわけではありません。
「Well-Architected なミッション クリティカル ワークロード: グローバル トラフィック ルーティング」を参照してください。
データベース
ワークロードに関連するすべての状態は、外部データベースである Azure Cosmos DB for NoSQL に格納されます。 このオプションは、クライアントとサーバーの両側で、パフォーマンスと信頼性のチューニングに必要な機能セットを備えているために選択されました。 アカウントでマルチマスター書き込みを有効にすることを強くお勧めします。
注意
複数リージョン書き込みの構成は信頼性のゴールド スタンダードを表しますが、コストの大きなトレードオフが伴うため、適切に検討する必要があります。
アカウントは各リージョン スタンプにレプリケートされ、ゾーン冗長も有効になっています。 また、コンテナー レベルで自動スケーリングが有効になっているため、コンテナーは、プロビジョニングされたスループットを必要に応じて自動的にスケーリングします。
詳細については、「ミッション クリティカルなワークロードのデータ プラットフォーム」を参照してください。
「Well-Architected なミッション クリティカル ワークロード: グローバルに分散されたマルチ書き込みデータストア」を参照してください。
コンテナー レジストリ
Azure Container Registry は、すべてのコンテナー イメージを格納するために使用されます。 これは geo レプリケーション機能を備えており、リソースを 1 つのレジストリとして機能させ、マルチマスター リージョン レジストリを使用して複数のリージョンにサービスを提供できます。
セキュリティ対策として、必要なエンティティへのアクセスのみを許可し、そのアクセスを認証します。 たとえば、実装では、管理者アクセスは無効になっています。 そのため、コンピューティング クラスターは、Microsoft Entra のロールの割り当てによってのみイメージをプルできます。
「Well-Architected なミッション クリティカル ワークロード: コンテナー レジストリ」を参照してください。
リージョン リソース
リージョン リソースは、単一の Azure リージョンへの "デプロイ スタンプ" の一部としてプロビジョニングされます。 これらのリソースは、別のリージョンのリソースとは何も共有しません。 これらは個別に削除することも、追加のリージョンにレプリケートすることもできます。 ただし、これらはグローバル リソースを相互に共有します。
このアーキテクチャでは、統合デプロイ パイプラインによって、これらのリソースを含むスタンプがデプロイされます。
コンポーネントに関する大まかな考慮事項を次に示します。 決定の詳細については、「リージョン スタンプ リソース」を参照してください。
フロントエンド
このアーキテクチャでは、バックエンド サービスに要求を送信するシングル ページ アプリケーション (SPA) を使用します。 利点としては、Web サイトのエクスペリエンスに必要なコンピューティングが、サーバーではなくクライアントにオフロードされることです。 SPA は、Azure Storage アカウントの静的 Web サイトとしてホストされます。
もう 1 つの選択肢は、Azure Static Web Apps です。これには、証明書の公開方法、グローバル ロード バランサーへの接続などの、追加の考慮事項が導入されています。
静的コンテンツは通常、コンテンツ配信ネットワーク (CDN) を使用してクライアントの近くのストアにキャッシュされるため、バックエンド サーバーと直接通信することなく、データをすばやく提供できます。 これは、信頼性を高め、ネットワーク待機時間を短縮するためのコスト効率の高い方法です。 このアーキテクチャでは、Azure Front Door の組み込みの CDN 機能を使用して、エッジ ネットワークに静的な Web サイト コンテンツをキャッシュします。
コンピューティング クラスター
バックエンド コンピューティングは、3 つのマイクロサービスで構成されるアプリケーションを実行し、ステートレスです。 そのため、コンテナー化が、アプリケーションをホストするための適切な方法です。 ほとんどのビジネス要件を満たし、Kubernetes が多くの業界で広く採用されているため、Azure Kubernetes Service (AKS) が選択されました。 AKS では、高度なスケーラビリティとデプロイ トポロジがサポートされています。 AKS のアップタイム SLA レベルは、Kubernetes コントロール プレーンの可用性を保証できるため、ミッション クリティカルなアプリケーションをホストする場合に強く推奨されます。
Azure は、Azure Functions、Azure App Services などの他のコンピューティング サービスを提供します。 これらのオプションにより、柔軟性と密度を犠牲にして、追加の管理責任が Azure にオフロードされます。
注意
スタンプの一時的な性質を考慮して、コンピューティング クラスターに状態を保存しないでください。 可能な限り、外部データベースに状態を保持して、スケーリングと復旧操作を軽量に保ちます。 たとえば、AKS ではポッドが頻繁に変更されます。 ポッドに状態をアタッチすると、データ整合性の負担が増えます。
「Well-Architected なミッション クリティカル ワークロード: コンテナー オーケストレーションと Kubernetes」を参照してください。
リージョン メッセージ ブローカー
ピーク負荷時にパフォーマンスを最適化し、応答性を維持するために、設計では非同期メッセージングを使用して、集中的なシステム フローを処理します。 要求がフロントエンド API ですばやく確認されるときに、その要求はメッセージ ブローカーのキューにも入れられます。 これらのメッセージはその後、バックエンド サービス (たとえば、データベースへの書き込み操作を処理するもの) によって使用されます。
このメッセージ ブローカーなどの、特定のポイントを除き、スタンプ全体はステートレスです。 データは短い時間の間、ブローカーのキューに入れられます。 メッセージ ブローカーは、少なくとも 1 回の配信を保証する必要があります。 つまり、ブローカーが使用できなくなった場合でも、サービスの復元後にメッセージはキューに入ります。 ただし、それらのメッセージがまだ処理が必要かどうかを判断するのは、コンシューマーの責任です。 メッセージが処理され、グローバル データベースに格納された後、キューはドレインされます。
この設計では、Azure Event Hubs が使用されます。 チェックポイント処理用に、追加のAzure Storage アカウントがプロビジョニングされます。 Event Hubs は、イベント ストリーミングなど、高スループットを必要とするユース ケースに推奨される選択肢です。
追加のメッセージ保証が必要なユース ケースでは、Azure Service Bus をお勧めします。 これにより、クライアント側カーソルを使用した 2 フェーズ コミットと、組み込みの配信不能キューや重複除去機能などの機能が可能になります。
詳細については、「ミッション クリティカルなワークロードのメッセージング サービス」を参照してください。
「Well-Architected なミッション クリティカル ワークロード: 疎結合のイベント ドリブン アーキテクチャ」を参照してください。
リージョンのシークレット ストア
各スタンプには、シークレットと構成を保存する独自の Azure Key Vault があります。 グローバル データベースへの接続文字列などの共通のシークレットがありますが、Event Hubs 接続文字列など、1 つのスタンプに固有の情報もあります。 また、独立したリソースにより、単一障害点が回避されます。
「Well-Architected なミッション クリティカル ワークロード: データ整合性の保護」を参照してください。
デプロイ パイプライン
ミッション クリティカルなアプリケーションのビルドとリリースのパイプラインは、完全に自動化する必要があります。 そのため、手動で実行する必要があるアクションはありません。 この設計では、検証済みのスタンプを毎回一貫してデプロイする完全に自動化されたパイプラインを示します。 もう 1 つの方法は、既存のスタンプにローリング更新のみをデプロイすることです。
ソース コード リポジトリ
GitHub はソース管理に使用され、アプリケーション コードとインフラストラクチャ コードに関するコラボレーション用に可用性の高い Git ベースのプラットフォームを提供します。
継続的インテグレーション/継続的デリバリー (CI/CD) パイプライン
実稼働前 "および" 実稼働環境での ミッション ワークロードの構築、テスト、デプロイには、自動化されたパイプラインが必要です。 Azure Pipelines が選択されています。これは、Azure やその他のクラウド プラットフォームをターゲットにできる豊富なツール セットが用意されているためです。
もう 1 つの選択肢は、CI/CD パイプライン用の GitHub Actions です。 ソース コードとパイプラインを併置できるという追加の利点があります。 しかし、CD 機能が豊富であるために、Azure Pipelines が選択されました。
「Well-Architected なミッション クリティカル ワークロード: DevOps プロセス」を参照してください。
ビルド エージェント
Microsoft でホストされるビルド エージェントが、複雑さと管理のオーバーヘッドを軽減するためにこの実装で使用されます。 セルフホステッド エージェントは、セキュリティ態勢を強化する必要があるシナリオで使用できます。
注意
セルフホステッド エージェントの使用は、「Mission Critical - Connected」参照実装で示されています。
監視リソース
効果的な運用を可能にし、信頼性を最大化するために、アプリケーションとインフラストラクチャの運用データを使用できる必要があります。 このリファレンスは、アプリケーションの包括的な監視を実現するためのベースラインを提供します。
統合データ シンク
- Azure Log Analytics は、すべてのアプリケーションとインフラストラクチャのコンポーネントのログとメトリックを保存するための統合シンクとして使用されます。
- Azure Application Insights は、アプリケーション パフォーマンス管理 (APM) ツールとして使用され、すべてのアプリケーション監視データを収集し、Log Analytics 内に直接保存します。
グローバル リソースとリージョン リソースの監視データは、個別に格納する必要があります。 単一障害点を回避するために、一元化された単一の監視ストアは推奨されません。 1 つのウィンドウを実現するために、クロス ワークスペース クエリが使用されます。
このアーキテクチャでは、リージョン内の監視リソースはスタンプ自体から独立している必要があります。スタンプを破棄した場合でも、監視を維持する必要があるためです。 リージョン スタンプには、それぞれ独自の専用の Application Insights と Log Analytics ワークスペースがあります。 リソースはリージョンごとにプロビジョニングされますが、スタンプより長く存在します。
同様に、Azure Front Door、Azure Cosmos DB、Container Registry などの共有サービスからのデータは、Log Analytics ワークスペースの専用インスタンスに保存されます。
データのアーカイブと分析
アクティブな操作に必要ない運用データは、Log Analytics から Azure Storage アカウントにエクスポートされます。この目的は、データ保持と、アプリケーションの正常性モデルと運用手順を最適化するために適用できる AIOps への分析ソースの提供の両方です。
「Well-Architected なミッション クリティカル ワークロード: 予測アクションと AI 操作」を参照してください。
要求とプロセッサのフロー
この図は、参照実装の要求とバックグラウンド プロセッサのフローを示しています。
このフローの説明は後続のセクションにあります。
Web サイト要求フロー
Web ユーザー インターフェイスに対する要求がグローバル ロード バランサーに送信されます。 このアーキテクチャでは、グローバル ロード バランサーは Azure Front Door です。
WAF 規則が評価されます。 WAF 規則は、クロスサイト スクリプティング (XSS) やSQL インジェクションなどのさまざまな攻撃から保護することで、システムの信頼性に肯定的に作用します。 WAF 規則に違反し、処理が停止した場合、Azure Front Door から要求者にエラーが返されます。 WAF 規則の違反がない場合は、Azure Front Door は処理を続行します。
Azure Front Door では、ルーティング規則を使用して、要求を転送するバックエンド プールを決定します。 ルーティング規則に対する要求の照合方法。 この参照実装では、ルーティング規則により、Azure Front Door は、UI とフロントエンド API の要求をさまざまなバックエンド リソースにルーティングできます。 この場合、パターン "/*" が UI ルーティング規則と一致します。 この規則は、シングル ページ アプリケーション (SPA) をホストする静的 Web サイトを使用するストレージ アカウントが含まれたバックエンド プールに要求をルーティングします。 Azure Front Door は、プール内のバックエンドに割り当てられた優先度と重みを使用して、要求をルーティングするバックエンドを選択します。 配信元へのトラフィック ルーティング方法。 Azure Front Door は正常性プローブを使用して、正常でないバックエンドに要求がルーティングされないようにします。 SPA は、静的 Web サイトを使用する選択したストレージ アカウントから提供されます。
注意
Azure Front Door Classic のバックエンド プールとバックエンドという用語は、Azure Front Door Standard または Premium のレベルでは配信元グループと配信元と呼ばれます。
SPA は、Azure Front Door フロントエンド ホストに対する API 呼び出しを行います。 API 要求 URL のパターンは "/api/*" です。
フロントエンド API 要求フロー
WAF 規則は、ステップ 2 と同様に評価されます。
Azure Front Door は、"/api/*" パターンによって要求を API ルーティング規則と照合します。 API ルーティング規則は、Azure Kubernetes Service (AKS) の正しいサービスに要求をルーティングする方法を認識している NGINX イングレス コントローラーのパブリック IP アドレスを含むバックエンド プールに要求をルーティングします。 前と同様に、Azure Front Door では、バックエンドに割り当てられた優先度と重みを使用して、適切な NGINX イングレス コントローラー バックエンドを選択します。
GET 要求の場合、フロントエンド API はデータベースに対して読み取り操作を実行します。 この参照実装では、データベースはグローバル Azure Cosmos DB インスタンスです。 Azure Cosmos DB は、マルチ書き込みリージョンを簡単に構成して、セカンダリ リージョンへの読み取りと書き込みの自動フェールオーバーを可能にするなど、ミッション クリティカルなワークロードに適した選択肢となる複数の機能を備えています。 API は、再試行ロジックを使用して構成されたクライアント SDK を使用して、Azure Cosmos DB と通信します。 SDK は、ApplicationRegion パラメーターに基づいて、通信するために使用可能な Azure Cosmos DB リージョンの最適な順序を決定します。
POST または PUT の要求の場合、フロントエンド API はメッセージ ブローカーへの書き込みを実行します。 参照実装では、メッセージ ブローカーは Azure Event Hubs です。 代わりに、Service Bus を選択することもできます。 ハンドラーは、後でメッセージ ブローカーからメッセージを読み取り、Azure Cosmos DB への必要な書き込みを実行します。 API は、クライアント SDK を使用して書き込みを実行します。 クライアントは再試行用に構成できます。
バックグラウンド プロセッサ フロー
バックグラウンド プロセッサは、メッセージ ブローカーからのメッセージを処理します。 バックグラウンド プロセッサは、クライアント SDK を使用して読み取りを実行します。 クライアントは再試行用に構成できます。
バックグラウンド プロセッサは、グローバルな Azure Cosmos DB インスタンスに対して適切な書き込み操作を実行します。 バックグラウンド プロセッサでは、再試行で構成されたクライアント SDK を使用して、Azure Cosmos DB に接続します。 クライアントの優先リージョン リストは、複数のリージョンで構成できます。 その場合、書き込みに失敗すると、再試行は次の優先リージョンで行われます。
設計領域
ミッション クリティカルなアーキテクチャを定義するときの推奨事項とベスト プラクティスのガイダンスについて、これらの設計領域を確認することをお勧めします。
| 設計領域 | 説明 |
|---|---|
| アプリケーションの設計 | スケーリングとエラー処理を可能にする設計パターン。 |
| アプリケーション プラットフォーム | 障害が発生する可能性がある場合のインフラストラクチャの選択と軽減策。 |
| データ プラットフォーム | データ ストア テクノロジの選択肢。必要なボリューム、速度、多様性、および正確性の特性を評価することで知ることができます。 |
| Azure ネットワークと接続性 | 受信トラフィックをスタンプにルーティングするためのネットワークに関する考慮事項。 |
| 正常性のモデリング | アプリケーションの全体的な正常性を判断するための、顧客の影響分析相関モニタリングによる監視に関する考慮事項。 |
| デプロイとテスト | CI/CD パイプラインの戦略と自動化に関する考慮事項と、同期ロード テストやエラー挿入 (カオス) テストなどの組み込みのテスト シナリオ。 |
| Security | Microsoft ゼロ トラスト モデルによる攻撃ベクトルの軽減。 |
| 操作手順 | デプロイ、キー管理、パッチの適用、更新に関連するプロセス。 |
** このアーキテクチャに固有の設計領域の考慮事項を示します。
関連リソース
このアーキテクチャで使用される Azure サービスの製品ドキュメントについては、こちらの記事を参照してください。
- Azure Front Door
- Azure Cosmos DB
- Azure Container Registry
- Azure Log Analytics
- Azure Key Vault
- Azure Service Bus
- Azure Kubernetes Service
- Azure Application Insights
- Azure Event Hubs
- Azure Blob Storage
このアーキテクチャのデプロイ
参照実装をデプロイして、ミッション クリティカルなコンテキストでの運用方法など、検討されたリソースについて完全に理解します。 これには、Azure でのミッション クリティカルなアプリケーション開発のためのソリューション指向のアプローチについて説明するためのデプロイ ガイドが含まれています。
次の手順
イングレスとエグレスのトラフィックに対するネットワーク制御を使用してベースライン アーキテクチャを拡張する場合は、このアーキテクチャを参照してください。