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