Azure でのミッション クリティカルなベースライン アーキテクチャ
このアーキテクチャでは、Azure でミッション クリティカルなワークロードを設計するためのガイダンスを提供します。 クラウドネイティブ機能を使用して、信頼性と運用効率を最大化します。 これは、 Well-Architected ミッション クリティカルなワークロード の設計手法をインターネットに接続するアプリケーションに適用します。このアプリケーションでは、ワークロードはパブリック エンドポイント経由でアクセスされ、他の会社のリソースへのプライベート ネットワーク接続は必要ありません。
重要
このガイダンスは、Azure でのミッション クリティカルなアプリケーション開発を紹介する実稼働グレードの 実装例 によって支えられています。 この実装は、実稼働に向けた最初のステップにおけるさらなるソリューション開発の基礎として使用できます。
信頼性レベル
信頼性は相対的な概念であり、ワークロードを適切に信頼性を確保するには、アプリケーションを使用できる時間の割合を把握するために、サービス レベル目標 (SLO) やサービス レベル アグリーメント (SLA) など、ワークロードを取り巻くビジネス要件を反映する必要があります。
このアーキテクチャは、99.99%の SLO を対象としています。これは、52 分 35 秒の年間許容ダウンタイムに対応します。 したがって、すべての包括的な設計上の決定は、このターゲット SLO を達成することを目的としています。
ヒント
現実的な SLO を定義するには、アーキテクチャのスコープ内のすべての Azure コンポーネントとその他の要因の信頼性の目標を理解することが重要です。 詳細については、信頼性の目標の定義に関するレコメンデーションを参照してください。 これらの個々の数値を集計して、ワークロードターゲットと一致する複合 SLO を決定する必要があります。
ミッション クリティカルなワークロードのWell-Architected: ビジネス要件の設計に関するページを参照してください。
主要な設計戦略
障害から復旧する機能、リージョンの可用性、デプロイの有効性、セキュリティなど、多くの要因がアプリケーションの信頼性に影響を与える可能性があります。 このアーキテクチャは、これらの要因に対処し、ターゲットの信頼性レベルを確実に達成することを目的とした、包括的な設計戦略のセットを適用します。
レイヤーの冗長性
アクティブ/アクティブ モデル内の複数のリージョンにデプロイします。 アプリケーションは、アクティブなユーザー トラフィックを処理する 2 つ以上の Azure リージョンに分散されます。
すべての検討対象サービス に可用性ゾーン を利用して、1 つの Azure リージョン内の可用性を最大化し、リージョン内の物理的に分離されたデータ センターにコンポーネントを分散します。
グローバル分散をサポートするリソースを選択します。
デプロイ スタンプ
需要の変化に対応するために、リソースの論理セットを個別にプロビジョニングできる スケール ユニット としてリージョン スタンプをデプロイします。 また、各スタンプは、個別にスケールインおよびスケールアウトできるフロントエンド API やバックグラウンド プロセッサなど、複数の入れ子になったスケール ユニットも適用します。
ミッション クリティカルなワークロードWell-Architected スケール ユニット アーキテクチャを参照してください。
信頼性が高く反復可能なデプロイ
Terraform などのテクノロジを使用して 、コードとしてのインフラストラクチャ (IaC) の原則 を適用して、インフラストラクチャ コンポーネントのバージョン管理と標準化された運用アプローチを提供します。
ダウンタイムゼロの青/緑のデプロイ パイプラインを実装します。 継続的な検証が適用された青/緑のデプロイを使用して、スタンプを 1 つの運用ユニットとしてデプロイするには、ビルドパイプラインとリリース パイプラインを完全に自動化する必要があります。
運用環境と運用前環境で同じデプロイ パイプライン コードを使用して、すべての検討対象環境に環境 の整合性 を適用します。 これにより、環境間のデプロイとプロセスのバリエーションに関連するリスクが排除されます。
アプリケーション コードと基になるインフラストラクチャの両方の正常性を完全に検証するために、同期された読み込みと混乱のテストを含む DevOps プロセスの一部として自動テストを統合することで、 継続的な検証 を行います。
運用上の情報
監視データ用のフェデレーション ワークスペースがある。 グローバル リソースとリージョン リソースの監視データは、個別に格納されます。 単一障害点を回避するために、一元化された監視ストアは推奨されません。 ワークスペース間のクエリは、統合されたデータ シンクと操作用の 1 つのウィンドウを実現するために使用されます。
コンテキスト化のために、アプリケーションの正常性を信号モデルにマップする 階層化された正常性 モデルを構築します。 正常性スコアは、個々のコンポーネントごとに計算され、ユーザー フロー レベルで集計され、アプリケーションの正常性を定量化するための係数として、パフォーマンスなどの主要な機能以外の要件と組み合わされます。
アーキテクチャ
*このアーキテクチャの Visio ファイル をダウンロードします。
このアーキテクチャのコンポーネントは、この方法で大まかに分類できます。 Azure サービスに関する製品ドキュメントについては、 関連リソースを参照してください。
グローバル リソース
グローバルリソースは長生きしており、システムの有効期間を共有しています。 複数リージョンデプロイ モデルのコンテキスト内でグローバルに使用できる機能があります。
コンポーネントに関する大まかな考慮事項を次に示します。 決定の詳細については、「 グローバル リソース」を参照してください。
グローバル ロード バランサー
グローバル ロード バランサーは、リージョン内のバックエンド サービスの可用性に基づいて、ある程度の保証レベルでトラフィックをリージョンデプロイに確実にルーティングするために重要です。 また、このコンポーネントには、たとえば Web アプリケーション ファイアウォールを介してイングレス トラフィックを検査する機能が必要です。
Azure Front Door は、すべての受信クライアント HTTP(S) トラフィックのグローバル エントリ ポイントとして使用され、セキュリティで保護されたレイヤー 7 イングレス トラフィックに Web アプリケーション ファイアウォール (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 ロールの割り当てでのみイメージをプルできます。
地域のリソース
リージョン リソースは、単一の Azure リージョンへの デプロイ スタンプ の一部としてプロビジョニングされます。 これらのリソースは、別のリージョンのリソースと何も共有しません。 これらは個別に削除することも、追加のリージョンにレプリケートすることもできます。 ただし、グローバル リソース は相互に共有されます。
このアーキテクチャでは、統合デプロイ パイプラインによって、これらのリソースを含むスタンプがデプロイされます。
コンポーネントに関する大まかな考慮事項を次に示します。 決定の詳細については、 地域スタンプリソースを参照してください。
フロントエンド
このアーキテクチャでは、バックエンド サービスに要求を送信するシングル ページ アプリケーション (SPA) を使用します。 利点は、Web サイトのエクスペリエンスに必要なコンピューティングが、サーバーではなくクライアントにオフロードされる点です。 SPA は、 Azure Storage アカウントで静的 Web サイトとしてホストされます。
静的コンテンツは通常、コンテンツ配信ネットワーク (CDN) を使用してクライアントの近くのストアにキャッシュされるため、バックエンド サーバーと直接通信することなくデータをすばやく処理できます。 これは、信頼性を高め、ネットワーク待機時間を短縮するためのコスト効率の高い方法です。 このアーキテクチャでは、 Azure Front Door の組み込みの CDN 機能 を使用して、エッジ ネットワークで静的な Web サイト コンテンツをキャッシュします。
コンピューティング クラスター
バックエンド コンピューティングは、3 つのマイクロサービスで構成されるアプリケーションを実行し、ステートレスです。 そのため、コンテナー化は、アプリケーションをホストするための適切な戦略です。 Azure Kubernetes Service (AKS) は、ほとんどのビジネス要件を満たし、Kubernetes は多くの業界で広く採用されているために選択されました。 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 つのスタンプに固有の情報もあります。 また、独立したリソースは単一障害点を回避します。
デプロイ パイプライン
ミッション クリティカルなアプリケーションのビルドおよびリリース パイプラインは、完全に自動化する必要があります。 そのため、手動でアクションを実行する必要はありません。 この設計では、検証済みのスタンプを毎回一貫してデプロイする完全に自動化されたパイプラインを示します。 もう 1 つの方法は、既存のスタンプにのみローリング更新プログラムをデプロイすることです。
ソース コード リポジトリ
GitHub はソース管理に使用され、アプリケーション コードとインフラストラクチャ コードでコラボレーションするための高可用性 Git ベースのプラットフォームを提供します。
継続的インテグレーション/継続的デリバリー (CI/CD) パイプライン
運用前 および運用環境での ミッション ワークロードの構築、テスト、デプロイには、自動化されたパイプラインが必要です。 Azure と他の クラウド プラットフォームをターゲットにできる豊富なツール セットが Azure Pipelines によって選択されます。
もう 1 つの選択肢は、CI/CD パイプライン用の GitHub Actions です。 追加の利点は、ソース コードとパイプラインを併置できることです。 ただし、豊富な CD 機能により、Azure Pipelines が選択されました。
エージェントのビルド
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 の分析ソースを提供します。これは、アプリケーションの正常性モデルと運用手順を最適化するために適用できます。
適切に 設計されたミッション クリティカルなワークロード(予測アクションと 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 に接続します。 クライアントの優先リージョンの一覧は、複数のリージョンで構成できます。 その場合、書き込みに失敗した場合、再試行は次の優先リージョンで行われます。
設計領域
ミッション クリティカルなアーキテクチャを定義する際の推奨事項とベスト プラクティスのガイダンスについては、これらの設計領域を確認することをお勧めします。
| デザイン領域 | 説明 |
|---|---|
| アプリケーションの設計 | スケーリングとエラー処理を可能にする設計パターン。 |
| アプリケーション プラットフォーム | 障害が発生する可能性がある場合のインフラストラクチャの選択と軽減策。 |
| データ プラットフォーム | データ ストア テクノロジの選択肢。必要な量、速度、多様性、および真実性の特性を評価して情報を得ます。 |
| ネットワークと接続 | 受信トラフィックをスタンプにルーティングするためのネットワークに関する考慮事項。 |
| 正常性モデリング | お客様の影響分析による可観測性に関する考慮事項は、アプリケーションの全体的な正常性を判断するために相関監視を行いました。 |
| 展開とテスト | 同期ロード テストや障害挿入 (混乱) テストなどの組み込みテスト シナリオを使用した CI/CD パイプラインと自動化に関する考慮事項に関する戦略。 |
| セキュリティ | 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 でのミッション クリティカルなアプリケーション開発のためのソリューション指向のアプローチを示すことを目的としたデプロイ ガイドが含まれています。
次のステップ
イングレス トラフィックとエグレス トラフィックに対するネットワーク制御を使用してベースライン アーキテクチャを拡張する場合は、このアーキテクチャを参照してください。