Azure ランディング ゾーンの設計原則
Azure ランディング ゾーンの概念アーキテクチャは、ランディング ゾーンのあらゆるプロセスまたは実装に普遍的に適用されます。 アーキテクチャの基礎には、重要な技術領域全体にわたる後続の設計決定の羅針盤として機能する一連のコア設計原則があります。
この原則は、ターゲット アーキテクチャの最適な設計への取り組みに役立ちます。 Azure ランディング ゾーン アクセラレータまたはエンタープライズ規模のランディング ゾーン コード ベースのいずれかのバージョンをデプロイすることを選ぶ場合は、ここで説明する設計原則を適用してアーキテクチャを構築してください。
これらの原則を実装の一部として使うと、クラウド テクノロジの利点を実現するための有用なガイドとして役立ちます。 このクラウド指向の視点は、"クラウド ネイティブ" と呼ばれることもよくあり、組織にとって、レガシ テクノロジのアプローチでは通常実現できない作業方法とテクノロジ オプションを表しています。
設計偏差の影響
Tailwind Traders の場合のように、原則から偏差する正当な理由が存在する場合もあります。 組織の要件によって、Azure 環境の設計に関する特定の結果やアプローチが規定されることがあります。 このような場合、その偏差が設計と将来の運用に与える影響を理解することが重要です。 各原則で説明されているトレードオフを慎重に検討してください。
一般的なルールとして、要件と機能のバランスを取るようにしてください。 概念アーキテクチャに至る取り組みは、要件が変化したり、実装から学んだりするのに伴い、時間をかけて進化します。 たとえば、プレビュー サービスを使用し、サービス ロードマップに依存すると、導入時に技術的な障害が解消される可能性があります。
サブスクリプションの民主化
サブスクリプションを管理とスケールのユニットとして利用して、アプリケーションの移行と新しいアプリケーション開発を加速します。 サブスクリプションをビジネス ニーズと優先順位に合わせ、ビジネス エリアとポートフォリオ所有者をサポートします。 新しいワークロードの設計、開発、テストと、既存のワークロードの移行を支援するために、サブスクリプションを事業部門に提供します。
組織が大規模な運用を効果的に実行できるように、適切な管理グループ階層でサブスクリプションをサポートします。 このサポートにより、サブスクリプションを効率的に管理および整理できます。
偏差の影響
この原則を実装するためのアプローチの 1 つは、複数の事業部門とワークロード チームに移行する分散運用です。 このアプローチにより、ワークロード所有者は、プラットフォーム基盤によって確立されたガードレール内で、ワークロードの制御と自律性をさらに制御することができます。
集中運用を必要とし、運用環境の制御をワークロード チームや事業部門に委任したくないお客様の場合、この原則から偏差するには、リソースの編成の設計に変更を加えなければならない場合があります。
Azure ランディング ゾーンの概念アーキテクチャの設計では、すべての運用管理サブスクリプションで特定の管理グループとサブスクリプション階層が想定されています。 この前提は、運用モデルと合致しない可能性があります。
この偏差があると、組織の成長と進化に伴って、運用モデルが変更される可能性があります。 この変更により、リソースが別のサブスクリプションに再び移行され、その後に複雑な技術的な移行が発生する可能性があります。 アプローチにコミットする前に、調整に関するガイダンスを確認してください。
ポリシー主導のガバナンス
ガードレールを提供し、組織のプラットフォームとそこにデプロイされたアプリケーションの継続的なコンプライアンスを確保するために、Azure Policy を使用します。 Azure Policy は、独立性と、クラウドに対するセキュリティで保護されたパスも、アプリケーションの所有者に提供します。
偏差の影響
環境内のガードレール作成に Azure Policy を利用しないと、コンプライアンスを維持するための操作と管理のオーバーヘッドが増加します。 Azure Policy を使用すると、環境内での必要なコンプライアンスの状態を制限したり、自動化したりするのに役立ちます。
設計上の考慮事項の一環として、ランディング ゾーン実装で Azure Policy を使用する方法について確認してください。
単一のコントロールおよび管理プレーン
お客様が開発したポータルやツールなどの抽象化レイヤーに依存しないようにします。 集中運用とワークロード運用の両方で一貫したエクスペリエンスを提供することを強くお勧めします。
Azure には、ロールベースのアクセスおよびポリシー主導の制御の対象となる、統一された一貫性のあるコントロール プレーンが用意されています。 これは、すべての Azure リソースとプロビジョニング チャネルに適用されます。 Azure を使用して、エンタープライズ資産全体を管理するための、標準化された一連のポリシーと制御を確立できます。
逸脱の影響
コントロールおよび管理プレーンの運用にマルチベンダーのアプローチを選択すると、統合と機能のサポートが複雑になるおそれがあります。 "最適な組み合わせ" 設計を実現するために個々のコンポーネントをマルチベンダーの操作ツールに置き換えると、固有の依存関係のために制限が生じ、意図しないエラーが発生するおそれがあります。
運用、セキュリティ、またはガバナンスに既存のツール投資を持ち込んでいるお客様には、Azure サービスとその依存関係を確認することをお勧めします。
アプリケーション中心のサービス モデル
純粋なインフラストラクチャのリフトアンドシフト移行 (仮想マシンの移動など) ではなく、アプリケーション中心の移行と開発に重点を置きます。 設計の選択肢として、古いアプリケーションと新しいアプリケーション、サービスとしてのインフラストラクチャ (IaaS) アプリケーション、またはサービスとしてのプラットフォーム (PaaS) を区別する必要はありません。
サービス モデルとは関係なく、Azure プラットフォームにデプロイされるすべてのアプリケーションに安全な環境を実現するように努めます。
逸脱の影響
管理グループ階層の実装オプションとは異なる方法でワークロードをセグメント化すると、環境を管理するポリシーとアクセスの制御の構造が複雑になる可能性があります。 たとえば、組織階層構造や Azure サービスによるグループ化からの偏差です。 このトレードオフにより、意図しないポリシー重複のリスクと例外が生じ、運用と管理のオーバーヘッドが増加します。
顧客が検討するもう 1 つの一般的なアプローチは、開発、テスト、運用のワークロードにランディング ゾーンを使用することです。 詳細については、FAQ の質問「エンタープライズ規模のアーキテクチャで "開発/テスト/運用" ワークロード ランディング ゾーンを処理するにはどうすればよいですか?」を参照してください。
Azure ネイティブの設計とロードマップへの調整
Azure ネイティブのプラットフォーム サービスと機能を、可能な限り使用してください。 環境内で新しい機能を確実に使用できるように、このアプローチを Azure プラットフォームのロードマップと合致させます。 Azure プラットフォームのロードマップは、移行戦略と Azure ランディング ゾーンの概念の軌道を通知するために役立ちます。
逸脱の影響
Azure 環境にサードパーティー製ソリューションを導入すると、機能サポートや Azure のサービスとの統合を提供するにあたって、そのソリューションへの依存関係が生じる可能性があります。
場合によっては、既存のサードパーティー製ソリューションへの投資を環境に取り込む必要があります。 この原則とそのトレードオフは、お客様の要件に合わせて慎重に検討してください。
推奨事項
初日にすべてが必要になる可能性は低いため、機能をトレードオフする準備を整えます。 技術的な障壁を取り除くために、プレビュー サービスを使用し、サービス ロードマップを利用します。
このアプローチを使用する場合、希望する運用モデルのすべての側面が一般提供されているとは限りません。