ハイブリッドおよびマルチクラウド シナリオ用に環境を準備する
クラウド導入フレームワークの準備方法では、環境をクラウド導入のために準備する方法をお客様に説明します。 この方法には、任意の Azure クラウド導入環境の構成要素である、Azure ランディング ゾーンなどの技術アクセラレータが含まれています。
このガイドは、組織に展開する適切なランディング ゾーンを選択するのに役立ちます。
ランディング ゾーンでのハイブリッドおよびマルチクラウド
Azure ランディング ゾーンとは、次から成るマルチサブスクリプション Azure 環境の出力です。
- スケール
- セキュリティ ガバナンス
- ネットワーク
- ID
- コスト管理
- 監視
ハイブリッドおよびマルチクラウド デプロイの準備を行う場合、環境に関する考慮事項が若干異なることがあります。 ハイブリッドおよびマルチクラウド デプロイの一貫性のある環境では、次の点を考慮する必要があります。
- ネットワーク トポロジと接続
- 運用、ガバナンス、セキュリティ、コンプライアンスのための統合された運用プロセス制御
- 異種環境全体で統合され、一貫性のある自動化規範、開発エクスペリエンス、DevOps プラクティス
Azure Arc によってハイブリッドとマルチクラウドのアーキテクチャを実現し、一連のテクノロジがそこに含まれています。 実現される各アーキテクチャには、デプロイを成功させるために作成する必要がある不可欠なすべての設計領域と考慮事項が含まれています。
クラウドの組み合わせを評価する
ハイブリッドおよびマルチクラウド環境を選択するには、1 つのバイナリ決定ではなく、さまざまな決定が必要です。 Azure 環境を構成する前に、クラウド ホスティングに関する特定の選択の組み合わせがクラウド環境でどのようにサポートされるか特定します。 次の図には、一般的なクラウドの組み合わせの例がいくつか含まれています。
この図では、濃い青色の点はそれぞれワークロードであり、薄い青色の円はそれぞれ個別の環境でサポートされているビジネス プロセスです。
クラウドのすべての組み合わせに、異なる Azure 環境構成が必要です。 これは、次の参考用のお客様 3 社で確認できます。
ハイブリッドファーストのお客様: ほとんどのワークロードがオンプレミスにとどまっており、多くの場合、従来型、ハイブリッド型、移植可能型のアセットホスティング モデルが混在しています。 いくつかの特定のワークロードが、エッジ、Azure、その他のクラウド プロバイダーにデプロイされています。
- Fabrikam は、古いデータセンターに多大な投資を行っている "ハイブリッド ファースト" のお客様です。 最優先事項はコストとガバナンスです。 レガシ IT の優先順位と古いテクノロジ インフラストラクチャが Fabrikam のイノベーションの妨げとなっていたことが、クラウドの早期導入を促進しました。
Azure ファーストのお客様: ほとんどのワークロードが Azure に移行されますが、一部のワークロードはオンプレミスにとどまっています。 戦略上の決定により、いくつかのワークロードがエッジまたはマルチクラウド環境に存在しています。
- Contoso は "Azure ファースト"のお客様です。 Fabrikam と同様に、デジタル変革の第一波を終えています。数社を買収し、規制対象業界の顧客が加わりました。 最優先事項は引き続きイノベーションですが、マルチクラウド環境では運用管理に重点を置いています。 買収戦略を継続するには、効率的でスケーラブルな運用が必要です。
マルチクラウド ファーストのお客様: ほとんどのワークロードは、Google Cloud Platform (GCP) や Amazon Web Services (AWS) などの別のパブリック クラウドでホストされています。 戦略上の決定により、いくつかのワークロードが Azure またはエッジに存在しています。 お客様は多くの場合、クラウド戦略の成熟とともに、ハイブリッド ファーストの組み合わせから Azure ファーストの組み合わせに移行しますが、ハイブリッドまたはマルチクラウドの組み合わせを優先することに決めたお客様もサポートされます。 Azure では、それぞれの種類の組み合わせで役割を果たします。
- Tailwind Traders は "マルチクラウド ファースト" のお客様です。 Contoso と同様に、クラウドに移行しましたが、これを行うために Azure を使用しませんでした。 いくつかのローカル データセンターアセットとエッジ デバイスがあります。 Tailwind Traders は、初期のスタートアップ フェーズにおいて他のクラウドの早期導入者であり、最重要な優先事項は成長です。 顧客の小売要件と、効率的なスケーリングを可能にする改善された運用の必要性により、ハイブリッドとマルチクラウドの成長が促進されます。
いくつかの考慮事項は、ハイブリッドおよびマルチクラウド用のクラウド環境を準備するために重要となります。 アプリケーションとデータに関するハイブリッドおよびマルチクラウド戦略により、次の質問に対する回答が導き出されます。 どのようなクラウドの組み合わせが必要か明確に特定し、環境に最適な構成を検討します。
- 現在サポートされているハイブリッド、エッジ、マルチクラウド環境の組み合わせはどのようなものか。
- 将来の戦略に最適な組み合わせはどれか。
- 各プラットフォームの運用を個別に、または統合運用と 1 つのウィンドウ アプローチを使用して行うか。
Azure Arc の概要
オンプレミス、エッジ、マルチクラウドにまたがる複雑で分散された環境を簡素化することができます。 Azure Arc を使用すると、場所を問わず Azure サービスをデプロイでき、Azure の管理が任意のインフラストラクチャに拡張されます。
環境全体の整理とガバナンス: オンプレミス、エッジ、マルチクラウドの環境にまたがるデータベース、Kubernetes クラスター、サーバーの整理およびガバナンスを 1 つの場所から集中的に行うことで、制御します。
Kubernetes アプリケーションを大規模に管理: DevOps 手法を使用して Kubernetes アプリケーションを複数の環境でデプロイおよび管理します。 ソース管理からアプリケーションを一貫してデプロイおよび構成するようにします。
どこでも Azure サービスを実行: データアセットの自動修正、アップグレード、セキュリティ、スケーリングをオンプレミス、エッジ、マルチクラウドの環境をまたいでオンデマンドで行えます。
仮想マシンへのセルフサービス アクセスの有効化: Azure ロールベース アクセス制御 (RBAC) を使用して、Azure 経由で VMware vSphere および System Center Virtual Machine Manager リソースにセルフサービス機能を許可します。 Azure portal からすべての VM ライフサイクルおよび電源サイクル操作を実行し、Azure テンプレート、API、SDK を通じて操作を自動化します。
Azure Arc のお客様の簡単な説明
前述の 3 社の参考用のお客様はすべて、異なるハードウェアでワークロードを実行しています。 また、オンプレミスのデータセンターと複数のパブリック クラウド プロバイダーにまたがってワークロードを実行し、エッジにデプロイされた IoT ワークロードをサポートしています。 これらのワークロードはさまざまなサービスを含み、ベアメタル サーバー、仮想マシン、マネージドのサービスとしてのプラットフォーム (PaaS) サービス、クラウド ネイティブのコンテナー ベース アプリケーションに基づいています。
3 社のお客様はいずれも、ビジネスの成功を実現するには、ハイブリッドとマルチクラウドの確立されたプラクティスを持つ必要があることに気付いています。 最新化されたワークロードの必要性が、3 社すべてのお客様のそれぞれの分野における関連性に非常に重要になっています。
ハイブリッドおよびマルチクラウドのコントロール プレーンとして Azure Arc を使用すると、これらのお客様は既存の IT 投資と現在の運用プラクティスを非分配方式で利用できます。 お客様は次のリソースをオンボードすることで、現在のプラクティスを引き続き使用できます。
- Azure Arc 対応サーバー、Azure Arc 対応 VMware vSphere、または Azure Arc 対応 System Center Virtual Machine Manager
- SQL Server
- Kubernetes クラスター
Azure Arc 対応のデータ サービス、アプリケーション サービス、機械学習サービスを使用して、引き続きデータ主権の要件を確実に満たしつつ、ワークロードを最新化します。
Azure Arc では Azure Resource Manager (ARM) API を拡張しているので、すべてのワークロードを Azure における第一級オブジェクトとして表現できます。 この拡張機能によって、統合された運用、管理、コンプライアンス、セキュリティ、ガバナンスを大規模に実装するための基盤が提供されます。 これは以下を使用して実装します。
- 集中型の監視
- ログ記録
- テレメトリ
- ポリシー
- 更新プログラムの管理
- 変更の追跡
- 在庫管理
- 脅威の検出
- セキュリティ脆弱性の管理と監査
最初の Azure 環境を構成する
クラウドの組み合わせごとに、クラウド リソースのサポート、ガバナンス、管理を行うための Azure 環境が必要になります。 クラウド導入フレームワークの準備手法には、環境の準備に役立ついくつかの手順が用意されています。
「Azure ランディング ゾーンとは」を参照します
個々の Azure ランディング ゾーンの設計領域を検討し、技術面の要件を適切に評価します。
要件を Azure ランディング ゾーンの実装オプションと比較し、構成に最適なテンプレートを見つけて実装します。
ランディング ゾーン アクセラレータとしての Azure Arc
Azure Arc リソースは、どのアプリケーションにも含めることができます。 以下に例を示します。
- Azure Arc 対応サーバー、Azure Arc 対応 VMware vSphere、Azure Arc 対応 System Center Virtual Machine Manager。これらは、Azure の外部にデプロイされた IT 資産を表します。 Azure Arc 対応 VMware vSphere や Azure Arc 対応 System Center Virtual Machine Manager など、専用の Azure Arc サービスでは、vCenter および System Center Virtual Machine Manager で管理されるオンプレミス データセンターにデプロイされた IT 資産を Azure に投影します。
- マルチクラウド環境内のカスタマー マネージド Kubernetes クラスター。
- エッジで動作する Azure Arc 対応のデータ、アプリケーション、機械学習の各サービス。
アプリケーション ランディング ゾーンのサブスクリプションには、Azure Arc リソースと通常の Azure リソースの両方も含めることができます。
Azure Arc リソースは Azure の外部に配置されるため、Azure でのそれらの表現方法では、それらは "メタデータ リソース" と見なすことができます。 Azure Arc リソースは、ランディング ゾーンに含めることができる他の Azure リソースのように扱います。 それがプラットフォームかアプリケーションかに関係なく、サブスクリプションの民主化およびアプリケーション中心でアーキタイプに依存しないという設計原則に従います。
Azure ランディング ゾーンでの Azure Arc リソースの一般的な例
次の例では、Azure ランディング ゾーンで Azure Arc リソースをメタデータ リソースとして投影する方法を示します。
例 1: Azure の外部にドメイン コントローラーを投影する
多くのお客様は、その環境内に Active Directory Domain Services (AD DS) のデプロイを行っています。 ドメイン コントローラーは、AD DS とお客様の全体的なアーキテクチャの重要なコンポーネントです。
Azure ランディング ゾーンの概念アーキテクチャ内には、ID ベースのリソースをホストするように設計された専用の ID ランディング ゾーン サブスクリプションが存在します。 このサブスクリプションは、AD DS ドメイン コントローラー (DC) 仮想マシン (VM) を使用して、Azure でホストできます。 また、他の場所から Azure Arc 対応サーバーを介して Azure に投影することもできます。
例 2: オンプレミスのデータセンターを Azure に投影する
ほとんどのお客様の環境内には引き続き、オンプレミスのデータセンターが存在しています。 これらのデータセンターの占有領域は、単一サーバーから大規模な仮想化環境まで異なることがあります。
お客様は、これらのオンプレミスのデータセンターを通常のランディング ゾーンとして扱い、必要に応じて新規または既存のランディング ゾーンに配置できます。 一般的なアプローチをいくつか次に示します。
- プロジェクト リソースを、オンプレミスのデータセンター リソースの専用ランディング ゾーン サブスクリプションに移動する。
- 世界中に複数のデータセンターがある大規模な環境では、地理的リージョンごとに 1 つのランディング ゾーンがある場合があります。 これらのランディング ゾーンにはそのリージョンのリソースも含まれていて、オンプレミスのデータセンターを Azure に論理的に分離します。
- このアプローチは、さまざまなオンプレミスのデータセンターのセキュリティ、ガバナンス、コンプライアンスの要件にも役立つ可能性があります。
- 同じアプリケーションまたはサービスをサポートする他の Azure リソースに基づいて、プロジェクト リソースを別々のランディング ゾーン サブスクリプションに移動する。
例 3: リモート アプリケーション リソースを Azure に投影する
お客様が、待機時間の影響を受けやすいアプリケーションや、データ主権の要件を持つアプリケーションを開発する場合があります。 これらのアプリケーションでは、Azure の外部にあるアプリケーションに含まれるリソースをホストすることが必要になる場合があります。 お客様は中心となる場所から、アプリケーションを構築するすべてのリソースの制御、ガバナンス、保護、運用を引き続き行いたいと考えています。 Azure Arc を使用することで、お客様はこの目標を達成できます。
このシナリオでは、お客様は、アプリケーションの Azure Arc リソースを、Azure リソースのデプロイ先と同じアプリケーション ランディング ゾーン サブスクリプションに投影する必要があります。 その後お客様は、リソースの場所に関係なく、1 つのコントロール プレーンからすべてのリソースに 1 つのコントロール セットを適用できます。
例 4: サポート終了に達したオンプレミス サーバーを Azure に投影して、Azure Arc 経由で配信される拡張セキュリティ更新プログラムを使用する
サポート終了に近づく Windows Server バージョンを使用しているお客様で、サポート終了期限に間に合わせることができないが、それでもオンプレミスを維持する必要があるお客様は多いです。 このシナリオでは、Azure Arc で利用できる拡張セキュリティ更新プログラムの購入を検討します。
お客様が Azure ランディング ゾーンをデプロイする途中である場合、または既にデプロイされているものがある場合、お客様は、オンプレミスのデータセンターを通常のランディング ゾーンとして扱い、必要に応じて新規または既存のランディング ゾーンに配置できます。 一般的なアプローチをいくつか次に示します。
プロジェクト リソースを、オンプレミスのデータセンター リソースの専用ランディング ゾーン サブスクリプションに移動する。
世界中に複数のデータセンターがある大規模な環境では、地理的リージョンごとに 1 つのランディング ゾーンがある場合があります。 これらのランディング ゾーンにはそのリージョンのリソースも含まれていて、オンプレミスのデータセンターを Azure に論理的に分離します。
このアプローチは、さまざまなオンプレミスのデータセンターのセキュリティ、ガバナンス、コンプライアンスの要件にも役立つ可能性があります。
同じアプリケーションまたはサービスをサポートする他の Azure リソースに基づいて、プロジェクト リソースを別々のランディング ゾーン サブスクリプションに移動する。
お客様は、Azure Arc 対応サーバー ランディング ゾーン アクセラレータのガイダンスを確認して、重要な設計領域全体にわたる設計上の考慮事項と推奨事項を確認する必要があります。
現時点で、お客様が Azure ランディング ゾーンを持っていないか、デプロイする予定がない場合:
- お客様は、Azure Arc 対応サーバー ランディング ゾーン アクセラレータのガイダンスを確認して、重要な設計領域全体にわたる設計上の考慮事項と推奨事項を確認する必要があります。
次のステップ
ハイブリッドとマルチクラウドのクラウド導入過程の詳細については、次の記事を参照してください。