この参照アーキテクチャは、一元化された共有サービスを使用し、オンプレミス接続を必要とし、企業の他のワークロードと統合するミッション クリティカルなワークロードをデプロイするためのガイダンスを提供します。 このガイダンスは、組織内のアプリケーション チームの一員であるワークロード所有者を対象にしています。
組織から、企業管理グループを継承する "Azure アプリケーション ランディング ゾーン" にワークロードをデプロイすることを求められているときに、この状況になる場合があります。 一元化されたチームによって管理される "Azure プラットフォーム ランディング ゾーン" に事前にプロビジョニングされている共有リソースとワークロードを統合することが期待されます。
重要
Azure ランディング ゾーンとは アプリケーション ランディング ゾーンは、ワークロードが実行される Azure サブスクリプションです。 これは、組織の共有リソースに接続されています。 その接続を通じて、ネットワーク、ID アクセス管理、ポリシー、監視などの、ワークロードを実行するために必要な基本的なインフラストラクチャにアクセスできます。 プラットフォーム ランディング ゾーンは、それぞれ特定の機能を持つさまざまなサブスクリプションのコレクションです。 たとえば、接続サブスクリプションでは、一元化された DNS 解決、オンプレミス接続、およびアプリケーション チームが使用できるネットワーク仮想アプライアンス (NVA) が提供されます。
ワークロード所有者は、共有リソースの管理を中央チームにオフロードし、ワークロード開発作業に集中できるというメリットが得られます。 組織は、複数のワークロードに一貫したガバナンスと償却コストを適用するというメリットが得られます。
Azure ランディング ゾーンの概念を理解することを強くお勧めします。
このアプローチでは、最大限の信頼性の実現は、お客様とプラットフォーム チームの間の共同責任です。 ミッション クリティカルなワークロードが想定どおりに動作するには、一元管理されたコンポーネントの信頼性が高い必要があります。 ワークロードに影響を与える一元化されたサービスの利用不可の問題がプラットフォーム レベルで軽減されるように、プラットフォーム チームと信頼できる関係を築いておく必要があります。 ただし、お客様のチームには、目標を達成するためにプラットフォーム チームとともに要件を推進する責任があります。
このアーキテクチャは、ネットワーク制御を使用したミッション クリティカルなベースライン アーキテクチャに基づいています。 この記事を読み進める前に、このベースライン アーキテクチャについての理解を深めておくことをお勧めします。
注意
このガイダンスは、Azure でのミッション クリティカルなアプリケーション開発を紹介する運用グレードの実装例によって裏付けられています。 この実装は、運用に向けた以降のソリューション開発のための最初のステップでの基礎として使用できます。
主要な設計戦略
ミッション クリティカルなベースライン上に次の戦略を適用します。
クリティカル パス
アーキテクチャのすべてのコンポーネントが同等に信頼性を持つ必要があるわけではありません。 クリティカル パスには、ワークロードでダウンタイムやパフォーマンスの低下が発生しないように、機能を維持する必要があるコンポーネントが含まれます。 そのパスをリーンに保つことで、障害点を最小限に抑えることができます。
コンポーネントのライフサイクル
重要なコンポーネントのライフサイクルを検討してください。これは、ダウンタイムをほぼゼロにするという達成目標に影響を与えるためです。 コンポーネントには、必要に応じて作成および破棄できるエフェメラル、つまり寿命の短いリソースと、システムまたはリージョンと有効期間を共有する非エフェメラル、つまり寿命の長いリソースがあります。
外部依存関係
障害点をもたらす可能性がある、コンポーネントとプロセスへの外部依存関係を最小限に抑えます。 このアーキテクチャには、お客様のチーム外のさまざまなチームが所有するリソースがあります。 これらのコンポーネント (重要な場合) は、このアーキテクチャの対象です。
サブスクリプションのトポロジ
Azure ランディング ゾーンは、単一のサブスクリプション トポロジを意味するものではありません。 すべての環境にわたってワークロードの信頼性の要件に対応するために、プラットフォーム チームとともにサブスクリプション フットプリントを事前に計画します。
クリティカル パスへの自律的な監視
チームがデータ コレクション (特にクリティカル パス) にすばやくクエリを実行し、修復に対処できるようにする専用の監視リソースを用意します。
Architecture
このアーキテクチャの Visio ファイルをダウンロードします。
このアーキテクチャのコンポーネントは、ネットワーク制御を使用したミッション クリティカルなベースライン アーキテクチャと同じです。 説明は簡潔にするために短くしています。 詳細については、リンク先の記事を参照してください。 Azure サービスに関する製品ドキュメントについては、「関連リソース」を参照してください。
グローバル リソース
これらのリソースは、アプリケーション ランディング ゾーン サブスクリプションに存在します。 グローバル リソースは非エフェメラルで、システムの有効期間を共有します。 Azure サービスとその構成は、ベースラインのグローバル リソースと同じままです。
リージョン ネットワーク リソース
これらのリソースは、プラットフォーム ランディング ゾーン サブスクリプションとアプリケーション ランディング ゾーン サブスクリプションにまたがって存在します。 ベースライン アーキテクチャでは、自分が所有するすべてのリソースがデプロイされます。 しかし、このアーキテクチャでは、ネットワーク リソースは接続サブスクリプションを通じて提供され、プラットフォーム ランディング ゾーンの一部としてプロビジョニングされます。
この記事の、「リージョン ハブ仮想ネットワーク」セクションを参照してください。
リージョン スタンプ リソース
これらのリソースは、アプリケーション ランディング ゾーン サブスクリプションに存在します。 これらのリソースは、グローバル リソースを除く他のリソースと何も共有しません。
プラットフォーム チームによって事前にプロビジョニングされているネットワーク リソースを除き、ほとんどの Azure サービスとその構成はベースラインのスタンプ アーキテクチャと同じままです。
この記事の、「リージョン スポーク仮想ネットワーク」セクションを参照してください。
外部リソース
ワークロードは、オンプレミスのリソースと対話します。 その一部は、オンプレミス データベースなど、ワークロードのクリティカル パスにあります。 これらのリソースとそれらのリソースとの通信は、ワークロードの全体的な複合サービス レベル アグリーメント (SLA) に組み込まれます。 すべての通信は、接続サブスクリプションを通じて行われます。 ワークロードが到達する可能性がある外部リソースは他にもありますが、重要とは見なされていません。
デプロイ パイプラインのリソース
検証済みのスタンプが一貫した方法でデプロイされるようにするには、ミッション クリティカルなアプリケーションのビルドとリリースのパイプラインを完全に自動化する必要があります。 これらのリソースは、ベースラインのデプロイ パイプラインと同じままです。
リージョン監視リソース
これらのリソースは、アプリケーション ランディング ゾーン サブスクリプションに存在します。 グローバル リソースとリージョン リソースの監視データは、個別に格納されます。 Azure サービスとその構成は、ベースラインの監視リソースと同じままです。
この記事の、「監視に関する考慮事項」セクションを参照してください。
管理リソース
プライベート コンピューティング クラスターやその他のリソースにアクセスするために、このアーキテクチャではプライベート ビルド エージェントとジャンプ ボックス仮想マシン インスタンスが使用されます。 Azure Bastion は、ジャンプ ボックスへの安全なアクセスを提供します。 スタンプ内のリソースは、ベースラインの管理リソースと同じままです。
ネットワークに関する考慮事項
この設計では、ワークロードはアプリケーション ランディング ゾーンにデプロイされ、プラットフォーム ランディング ゾーン内のフェデレーション リソースへの接続を必要とします。 その目的は、オンプレミスのリソースへのアクセス、エグレス トラフィックの制御などです。
ネットワーク トポロジ
プラットフォーム チームが、組織全体のネットワーク トポロジを決定します。 このアーキテクチャでは、ハブスポーク トポロジが想定されています。 代替案は、Azure Virtual WAN です。
リージョン ハブ仮想ネットワーク
接続サブスクリプションには、組織全体で共有されるリソースを持つハブ仮想ネットワークが含まれます。 これらのリソースは、プラットフォーム チームによって所有および保守されています。
ミッション クリティカルの視点からは、このネットワークは非エフェメラルであり、これらのリソースはクリティカル パスにあります。
| Azure リソース | 目的 |
|---|---|
| Azure ExpressRoute | オンプレミスから Azure インフラストラクチャへのプライベート接続を提供します。 |
| Azure Firewall | エグレス トラフィックを検査および制限する NVA として機能します。 |
| Azure DNS | クロスプレミスの名前解決を提供します。 |
| VPN Gateway | パブリック インターネット経由でリモート組織のブランチを Azure インフラストラクチャに接続します。 回復性を向上させるためのバックアップ接続代替手段としても機能します。 |
リソースは各リージョンにプロビジョニングされ、スポーク仮想ネットワーク (次に説明します) にピアリングされます。 NVA、ファイアウォール規則、ルーティング規則、ExpressRoute の VPN Gateway へのフェールオーバー、DNS インフラストラクチャなどの更新を理解して、同意するようにしてください。
注意
フェデレーション ハブを使用する主なメリットは、組織が管理するネットワーク ハブを走査することで、Azure またはクロスプレミスの他のワークロードとワークロードを統合できることです。 この変更により、責任の一部がプラットフォーム チームに移行されるため、運用コストも削減されます。
リージョン スポーク仮想ネットワーク
アプリケーション ランディング ゾーンには、リージョンごとに少なくとも 2 つの事前プロビジョニングされた Azure Virtual Networks があり、リージョン スタンプによって参照されます。 これらのネットワークは非エフェメラルです。 1 つは運用トラフィックを提供し、もう 1 つは vNext デプロイを対象としています。 この方法により、信頼性の高い安全なデプロイ プラクティスを実行できます。
運用仮想ネットワーク
運用トラフィックは、別の仮想ネットワークに分離されています。 この仮想ネットワークは非エフェメラルであり、このネットワークを所有しています。 このアーキテクチャは、ネットワーク制御を使用したベースライン アーキテクチャと同じ設計を維持します。
運用ネットワークとスポーク ネットワークの間にピアリングはありません。 すべての通信はプライベート リンク経由で行われます。
共同責任
アーキテクチャの設計要素ごとにどのチームが責任を負うのかを明確に理解してください。 以降に重要な分野を示します。
IP アドレス計画
ワークロードの実行に必要なサイズを見積もったら、プラットフォーム チームと協力して、ネットワークを適切にプロビジョニングできるようにします。
プラットフォーム チーム
ピアリングに参加する仮想ネットワークに個別のアドレスを指定します。 オンプレミスやワークロード ネットワークなどのアドレスが重複すると、中断が発生し、停止の原因になる可能性があります。
ランタイムとデプロイのリソースを格納し、フェールオーバーを処理し、スケーラビリティをサポートするのに十分な大きさの IP アドレス空間を割り当てます。
事前にプロビジョニングされた仮想ネットワークとピアリングが、ワークロードの予想される増加に対応できることが必要です。 その増加をプラットフォーム チームと定期的に評価する必要があります。 詳細については、「Azure への接続性」を参照してください。
リージョン スポーク ネットワークのサブネット作成
リージョン仮想ネットワークへのサブネットの割り当ては、お客様が行う必要があります。 サブネットとその中のリソースはエフェメラルです。 アドレス空間は、潜在的な増加に対応するのに十分な大きさである必要があります。
プライベート エンドポイント サブネット トラフィックが仮想ネットワークに到達すると、ネットワーク内の PaaS サービスとの通信は、ネットワーク制御を使用したベースライン アーキテクチャと同様に、プライベート エンドポイントの使用に限定されます。 これらのエンドポイントは、専用サブネットに配置されます。 プライベート エンドポイントへのプライベート IP アドレスは、そのサブネットから割り当てます。
クラスター サブネット ワークロードのスケーラビリティ要件は、サブネットに割り当てる必要があるアドレス空間の量に影響します。 AKS ノードとポッドがスケールアウトされると、このサブネットから IP アドレスが割り当てられます。
ネットワークのセグメント化
承認されていないアクセスによってワークロードの信頼性が侵害されないように、適切なセグメント化を維持します。
このアーキテクチャでは、ネットワーク セキュリティ グループ (NSG) を使用して、サブネットと接続サブスクリプション間のトラフィックを制限します。 NSG は、サポートされているサービスに ServiceTags を使用します。
プラットフォーム チーム
Azure Network Manager ポリシー経由で NSG の使用を適用します。
ワークロードの設計に注意してください。 スタンプ間に直接のトラフィックはありません。 リージョン間フローもありません。 これらのパスが必要な場合は、トラフィックが接続サブスクリプションを通過する必要があります。
他のワークロードからミッション クリティカルなワークロードに送信される不要なハブ トラフィックを防止します。
リージョン スタンプからのエグレス トラフィック
各リージョン スポーク ネットワークからの送信トラフィックはすべて、リージョン ハブ ネットワーク内の一元化された Azure Firewall 経由でルーティングされます。 これは、トラフィックを検査して許可または拒否するネクスト ホップとして機能します。
プラットフォーム チーム
そのカスタム ルートに対して UDR を作成します。
アプリケーション チームが新しいルート テーブルを持たないサブネットを作成しないようにブロックする Azure ポリシーを割り当てます。
ワークロードの要件に基づいてルートを拡張できるように、適切なロールベースのアクセス制御 (RBAC) アクセス許可をアプリケーション チームに付与します。
複数リージョンの冗長性
リージョンの停止に耐えられるように、ミッション クリティカルなワークロードを複数のリージョンにデプロイする必要があります。 プラットフォーム チームと協力して、インフラストラクチャの信頼性を確認します。
プラットフォーム チーム
リージョンごとに一元化されたネットワーク リソースをデプロイします。 ミッション クリティカルな設計手法には、リージョンの分離が必要です。
アプリケーション チームと協力して、リージョンの隠し依存関係を明らかにすることで、あるリージョンでのプラットフォーム リソースの低下が、別のリージョンのワークロードに影響を与えないようにします。
DNS の解決
接続サブスクリプションは、プライベート DNS ゾーンを提供します。 ただし、その一元化されたアプローチでは、お客様のユース ケースに特化した DNS ニーズが考慮されない場合があります。 独自の DNS ゾーンをプロビジョニングし、リージョン スタンプにリンクしてください。 アプリケーション チームが DNS を所有していない場合、Azure Cosmos DB などのグローバル リソースではプライベート リンクの管理が困難になります。
プラットフォーム チーム
Azure プライベート DNS ゾーンをアプリケーション チームに委任して、そのユース ケースに対応します。
リージョン ハブ ネットワークの場合は、アプリケーション チームによって管理されるプライベート DNS ゾーンをサポートするために、DNS サーバーの値を既定値 (Azure 提供) に設定します。
環境の設計に関する考慮事項
運用、運用前、開発の別個の環境にワークロードを配置するのが一般的な方法です。 いくつかの主要な考慮事項を次に示します。
分離をどのように維持するか
運用環境は、他の環境から分離する "必要があります"。 下位の環境でも、一定の分離レベルを維持する必要があります。 環境間でのアプリケーション所有のリソースの共有を避けます。
アプリケーション チームが所有するグローバル、リージョン、スタンプのリソースに、1 つの運用環境が必要です。 可能な限り運用環境をシミュレートする環境でアプリケーションがテストされるようにするために、ステージングや統合などの運用前環境が必要です。 開発環境は、運用環境のスケールダウン バージョンである必要があります。
予想されるライフサイクルはどのくらいか
運用前環境は、検証テストが完了した後に破棄できます。 開発環境は機能と有効期間を共有し、開発が完了したときに破棄することをお勧めします。 これらのアクションは、継続的インテグレーション/継続的デプロイ (CI/CD) の自動化によって実行されます。
どのようなトレードオフがありますか?
環境の分離、管理の複雑さ、コストの最適化のトレードオフを検討します。
ヒント
すべての環境は、プラットフォーム リソースを含む外部リソースの運用インスタンスに依存すると考えられます。 たとえば、接続サブスクリプション内の運用リージョン ハブなどです。 運用前と運用の環境の間の差分を最小限に抑えることができます。
ワークロード インフラストラクチャのサブスクリプション トポロジ
サブスクリプションは、プラットフォーム チームによって提供されます。 環境の数によっては、1 つのみのワークロードに複数のサブスクリプションを要求します。 環境の種類によっては、専用サブスクリプションが必要な環境もあれば、1 つのサブスクリプションに統合される環境もあります。
いずれの場合も、プラットフォーム チームと協力して、ワークロードの全体的な信頼性目標を満たすトポロジを設計してください。 プラットフォームが提供するリソースを同じサブスクリプション内の環境間で共有するとメリットが得られます。これは運用環境を反映するためです。
注意
複数のサブスクリプションを使用して環境を格納すると、必要なレベルの分離を実現できます。 ランディング ゾーン サブスクリプションは、同じ管理グループから継承されます。 そのため、テストと検証で、運用との一貫性が確保されます。
運用サブスクリプション
お客様のサブスクリプションにリソース制限が設定されている可能性があります。 これらのリソースをすべて 1 つのサブスクリプションに併置すると、その制限に達する可能性があります。 スケール ユニットと予想されるスケールに基づいて、より分散したモデルを検討してください。 たとえば、次のように入力します。
Azure DevOps ビルド エージェントとグローバル リソースの両方を含む 1 つのサブスクリプション。
リージョンごとに 1 つのサブスクリプション。 これには、リージョン リソース、スタンプ リソース、およびリージョン スタンプのジャンプ ボックスが含まれます。
このアーキテクチャで使用されるサブスクリプション トポロジの例を次に示します。
運用前サブスクリプション
少なくとも 1 つのサブスクリプションが必要です。 多くの独立した環境を実行できますが、複数の環境を専用サブスクリプションで使用することをお勧めします。 このサブスクリプションも、前述の運用サブスクリプションと同様のリソース制限の対象になる場合があります。
開発サブスクリプション
少なくとも 1 つのサブスクリプションが必要です。 このサブスクリプションは、すべて独立した環境を実行する場合、リソース制限の対象になることがあります。 そのため、複数のサブスクリプションを要求してもかまいません。 個々の環境を専用サブスクリプションに用意することをお勧めします。
可能な限り運用トポロジと一致させてください。
デプロイに関する考慮事項
アプリケーションの停止でよくある原因は、失敗したデプロイまたは誤ったリリースです。 アプリケーションのライフサイクルの一環として、アプリケーション (および新機能) を徹底的にテストしてください。 ランディング ゾーンにワークロードをデプロイするときは、プラットフォームが提供するリソースとガバナンスに設計を統合する必要があります。
Well-Architected なミッション クリティカル ワークロード: デプロイとテストに関する記事を参照してください。
インフラストラクチャのデプロイ
ビルド エージェントとそのネットワークなどのデプロイ インフラストラクチャの信頼性は、多くの場合、ワークロードのランタイム リソースと同程度に重要です。
このアーキテクチャでは、プライベート ビルド エージェントを使用して、アプリケーションの可用性に影響を与える可能性がある未承認のアクセスを防止します。
デプロイ リソース間の分離を維持することを強くお勧めします。 デプロイ インフラストラクチャは、その環境のワークロード サブスクリプションにバインドする必要があります。 運用前サブスクリプションで複数の環境を使用している場合は、それらの個々の環境のみにアクセスを制限して、分離を強化します。 デプロイ インフラストラクチャの信頼性を高めるために、リージョンごとのデプロイ リソースを検討することも考えられます。
ダウンタイムなしのデプロイ
アプリケーションを更新すると、停止が発生する可能性があります。 一貫性のあるデプロイを適用することで、信頼性が向上します。 次の方法をお勧めします。
- 全自動のデプロイ パイプラインを用意する。
- クリーン スタンプ上の運用前環境に更新プログラムをデプロイする。
詳細については、ミッション クリティカルなデプロイとテストのガイドラインに関する記事を参照してください。
ベースライン アーキテクチャでは、これらの方法はプロビジョニングを解除し、更新ごとにスタンプを破棄することで実現されます。 この設計では、プラットフォーム チームが一部のリソースを所有しているため、完全なプロビジョニング解除は不可能です。 そのため、デプロイ モデルが変更されました。
デプロイメント モデル
ベースライン アーキテクチャでは、ブルーグリーン モデルを使用してアプリケーションの更新プログラムをデプロイします。 変更が適用された新しいスタンプは、既存のスタンプに並行してデプロイされます。 トラフィックが新しいスタンプに移動されると、既存のスタンプが破棄されます。
この場合、指定のピアリングされた仮想ネットワークは非エフェメラルです。 スタンプで、仮想ネットワークを作成したり、リージョン ハブにピアリングしたりすることはできません。 これらのリソースは、各デプロイで再利用する必要があります。
カナリア モデルでは、ロールバックするオプションを使用して安全なデプロイを実現できます。 まず、コードを変更した新しいスタンプをデプロイします。 デプロイ パイプラインは、事前にプロビジョニングされた仮想ネットワークを参照し、サブネットを割り当て、リソースをデプロイし、プライベート エンドポイントを追加します。 次に、この事前プロビジョニングされた仮想ネットワーク内のこれらのサブネットにトラフィックが移行されます。
既存のスタンプが不要になると、プラットフォーム所有のリソースを除き、すべてのスタンプ リソースがパイプラインによって削除されます。 仮想ネットワーク、診断設定、ピアリング、IP アドレス空間、DNS 構成、ロールベースのアクセス制御 (RBAC) は維持されます。 この時点で、スタンプはクリーンな状態になり、次の新しいデプロイの準備が整います。
DINE (deploy-if-not-exists) Azure ポリシー
Azure アプリケーション ランディング ゾーンには、DINE (deploy-if-not-exists) Azure ポリシーが含まれている場合があります。 このチェックにより、デプロイされたリソースがアプリケーション チームによって所有されているときでも、アプリケーション ランディング ゾーンの企業標準を満たしていることが確認されます。 デプロイと最終的なリソース構成の間に不一致がある可能性があります。
リソースに適用されるすべての DINE ポリシーの影響を把握してください。 リソース構成に変更がある場合は、ワークロードの開発サイクルの早い段階で、宣言型デプロイにポリシーの意図を組み込みます。 そうしないと、目的の状態とデプロイされた状態の間に差異が生じる誤差が発生する可能性があります。
デプロイ サブスクリプションのアクセス管理
影響範囲を限定するために、サブスクリプションの境界をセキュリティ境界として扱います。 脅威はワークロードの信頼性に影響を与える可能性があります。
プラットフォーム チーム
- アクセス許可の範囲をアプリケーション ランディング ゾーン サブスクリプションにして、アプリケーション チームに操作を認可します。
1 つのサブスクリプション内で複数のデプロイを実行している場合、侵害は両方のデプロイに影響します。 専用サブスクリプションでデプロイを実行することをお勧めします。 論理的な分離を維持するために、環境ごとにサービス プリンシパルを作成します。
サービス プリンシパルにより、ワークロード リソースに対する自律性がもたらされるようにする必要があります。 サブスクリプション内のプラットフォーム リソースの過剰な操作を防ぐ制限を設けることも必要です。
監視に関する考慮事項
Azure ランディング ゾーン プラットフォームは、管理サブスクリプションの一部として共有監視リソースを提供します。 一元化された運用チームは、アプリケーション チームにフェデレーション モデルの使用を促します。 ただし、ミッション クリティカルなワークロードの場合、単一障害点になる可能性があるため、一元化された監視ストアは推奨されません。 ミッション クリティカルなワークロードでは、一元化された運用チームには適用できないか、実行不可能なテレメトリも生成されます。
そのため、監視のための自律的なアプローチを強くお勧めします。 最終的には、ワークロード オペレーターが監視に対する責任を負うため、全体的な正常性を表すすべてのデータにアクセスできる必要があります。
ベースライン アーキテクチャはそのアプローチに従い、この参照アーキテクチャで引き続き使用されます。 Azure Log Analytics と Azure Application Insights は、これらのスコープ内のリソースを監視するために、リージョンとグローバルにデプロイされます。 ログの集計、ダッシュボードの作成、アラートの作成は、お客様のチームの担当範囲です。 メトリックとログをさまざまなシンクに送信する Azure Diagnostics 機能を利用して、ログとメトリックの収集に対するプラットフォーム要件をサポートします。
正常性モデル
ミッション クリティカルな設計手法には、システムの正常性モデルが必要です。 全体的な正常性スコアを定義するときに、アプリケーションが依存するスコープ内プラットフォーム ランディング ゾーン フローを含めます。 ワークスペースにまたがる監視を実行するためのログ、正常性、アラートのクエリを作成します。
プラットフォーム チーム
ミッション クリティカルなアプリケーションのクリティカル パスで使用される関連プラットフォーム リソースに対して、ロールベースのアクセス制御 (RBAC) のクエリとログ シンクの読み取りを許可します。
運用を行うのに十分なアクセス許可をアプリケーション チームに付与することで、ミッション クリティカルなワークロードに対する信頼性の組織目標をサポートします。
このアーキテクチャでは、正常性モデルには、接続サブスクリプションでプロビジョニングされたリソース由来のログとメトリックが含まれています。 データベースなどのオンプレミス リソースに到達するようにこの設計を拡張する場合、正常性モデルには、Azure "と" オンプレミスのネットワーク仮想アプライアンスなどのセキュリティ境界をはじめとする、そのリソースへのネットワーク接続を含める必要があります。 この情報は、根本原因をすばやく特定し、信頼性への影響を修復するために重要です。 たとえば、エラーが発生したのは、データベースにルーティングしようとしたときなのか、データベースに問題があったのかなどです。
Well-Architected なミッション クリティカル ワークロード: 正常性モデリングに関する記事を参照してください。
プラットフォームが提供するポリシーとルールとの統合
アプリケーション ランディング ゾーン サブスクリプションは、その管理グループから Azure ポリシー、Azure Network Manager ルール、およびその他のコントロールを継承します。 プラットフォーム チームが、これらのガードレールを提供します。
デプロイについては、次の理由から、プラットフォームが提供するポリシーのみに依存しないでください。
- これらは、個々のワークロードのニーズに対応するようには設計されていません。
- ポリシーとルールは、チームの外部で更新または削除される可能性があるため、信頼性に影響を与える可能性があります。
デプロイ内で Azure ポリシーを作成して割り当てることを強くお勧めします。 この作業によって重複が発生する可能性がありますが、これは、システムの信頼性への潜在的な影響を考慮すると、許容されます。 プラットフォーム ポリシーに変更がある場合でも、ワークロード ポリシーはローカルでは引き続き有効です。
プラットフォーム チーム
- アプリケーション チームに、ポリシーの進展に応じた変更管理プロセスに参加してもらいます。
- アプリケーション チームによって使用されるポリシーに注意してください。 管理グループに追加する必要があるかどうかを評価します。
このアーキテクチャのデプロイ
このアーキテクチャのネットワーク面は、ミッション クリティカル Connected 実装で実装されます。
Note
Connected 実装は、組織のリソースに依存し、他のワークロードと統合され、共有サービスを使用する、ミッション クリティカルなワークロードを示すことを目的としています。 この実装では、接続サブスクリプションが既に存在することを想定しています。
次のステップ
Azure Well-Architected フレームワークのネットワークと接続の設計領域を確認します。
関連リソース
ベースライン アーキテクチャで使用される Azure サービスに加えて、次のサービスがこのアーキテクチャにとって重要です。