統合されたハイブリッドおよびマルチクラウド操作

ハイブリッド クラウドとは、オンプレミス/プライベート インフラストラクチャとパブリック クラウド サービスの組み合わせを指し、マルチクラウドは複数のクラウド プロバイダーを同時に使用することを意味します。 現在、多くの企業では、チーム、分散サイト、システムがオンプレミスのデータセンターやさまざまなクラウドに分散しています。 課題は、クラウドからエッジへの最新化を可能にする、安全で適切に管理された方法でこれらの環境を統合することです。 このガイダンスでは、ハイブリッド環境とマルチクラウド環境を中央コントロール プレーンとして Azure と統合および管理するための規範的なエンドツーエンドフレームワークを提供します。

クイック スタート: Azure ハイブリッドサービスとマルチクラウド サービス

Azure Arc、Azure Monitor、Azure Kubernetes Service、Microsoft Fabric、Azure IoT、Azure Local などの Azure ソリューションが、すべての環境で IT の統合と最新化にどのように役立つかについて説明します。 目標は、サイロを分解し、あらゆる場所で一貫したプラクティスを提供する標準的な運用モデルを確立することです。 クラウドからエッジまでリソースをセキュリティで保護、管理、最新化する方法について詳しく説明し、以前に分離されたチームとシステムを 1 つの Azure 主導の戦略で統合します。

最初のステップは、ビジネス目標に合わせ、統一を強調するハイブリッドおよびマルチクラウドの明確な戦略を確立することです。 この連携により、ビジネス価値 (機敏性、回復性、コストの最適化、イノベーション) が、アドホックな決定ではなく、クラウド導入を促進します。 このフェーズの主なアクティビティには、ドライバーとビジョンの定義、基本原則の設定、クラウド の組み合わせの決定、Azure サービスの目標へのマッピングなどがあります。

1. ハイブリッドおよびマルチクラウドのビジネス ドライバーを定義する

まず、組織がハイブリッドおよびマルチクラウドを採用している理由を特定します。 ビジネス ドライバーはフォーカスを提供し、このアプローチが測定可能な価値を提供することを保証します。 これらの要因は、意思決定を導き、断片化されたテクノロジの選択を防ぐために、具体的なビジネス成果または主要業績評価指標 (KPI) にリンクする必要があります。 一般的なドライバーは次のとおりです。

• ベンダーの柔軟性: 1 つのプロバイダーへの依存を減らしてロックインを軽減し、コストの最適化と最適なサービスの使用を可能にします。 たとえば、別の方法でコストを節約したり、独自の機能を提供したりする場合は、1 つのクラウドの機能のみに依存しないようにします。
• 部署の多様性: さまざまなプラットフォームを使用するさまざまなチーム、買収、または子会社に対応します。 統一された戦略により、運用サイロを防ぎ、既存の投資を尊重しながら、すべての環境で中央ガバナンスを確立します。
• コンプライアンスとデータ所在地: データ主権または特定のセキュリティ制御に関する規制の義務を満たします。 オンプレミスのままにする必要があるワークロードには、Azure Stack HCI が現在の一部となっている Azure Local を使用します。 他のデータとアプリケーションの Azure クラウド サービスに接続します。
• 回復性とディザスター リカバリー: ワークロードを分散し、マルチ環境フェールオーバーを確立することで可用性を向上させます。 回復性は、ローカライズされた障害中に操作を維持します。ディザスター リカバリーは、より広範なインシデントの後に通常の操作を復元します。 最小限のダウンタイムを確保するために、統合されたプロセスを使用して Azure とセカンダリ環境 (他のクラウドまたはオンプレミス) の間の復旧を設計します。
• パフォーマンスの最適化: 待機時間を短縮するために、ワークロードをユーザーまたはデータ ソースの近くに配置します。 たとえば、Azure クラウド サービスを通じて一元的な調整を維持しながら、リアルタイム処理のために Azure Local インスタンスを工場の場所にデプロイします。
• 最新化とイノベーション: 特殊なクラウド サービスを使用して変革を推進します。 たとえば、必要に応じて他のクラウド間でデータとアプリを統合しながら、Azure の AI サービスと Microsoft Fabric 分析を使用します。
• サイロの統合: インフラストラクチャ、クラウド、およびアプリケーション チーム間の内部サイロを排除します。 リソース管理用の Azure Arc、監視用の Azure Monitor などの一般的なツールとプロセスを確立して、以前に分離されたグループ間で共有の可視性とコラボレーションを作成します。

ビジネス ドライバーごとに、特定のビジネス成果または KPI にリンクします。 たとえば、ドライバーが "ダウンタイムを回避する" 場合、結果は 99.99% 可用性を達成している可能性があります。 "グローバル展開のサポート" がドライバーの場合、1 年以内に一部の新しい地域で結果が開始される可能性があります。 サイロの統合が目標である場合、IT プロセスを統合することで運用オーバーヘッドが 20% 削減される可能性があります。 結果の推進要因を基にすることで、測定可能な価値の提供に重点を置く戦略が保証されます。 これらの要因と期待される成果を明確に記録してください。それらは今後のすべての意思決定を方向づけます。

2. ハイブリッドおよびマルチクラウドの明確なビジョンステートメントを作成する

ハイブリッド/マルチクラウド環境のターゲット状態と成功の様子を説明する簡潔なビジョン ステートメントを作成します。 このビジョンステートメントは、すべての利害関係者が最終的な目標を理解するのに役立つ方向性を提供します。 ビジョンは、統合アプローチが組織にどのように利益をもたらすかを明確にする必要があります。 例えば次が挙げられます。

• "すべてのインフラストラクチャとチームを統合するアダプティブ クラウド プラットフォームを構築し、ビジネス ニーズに最も適した場所で任意のアプリを実行できるようにします。"(柔軟性と統一性を重視します。
• "マルチクラウドの回復性を通じて、100% アップタイムで一貫したカスタマー エクスペリエンスを実現します。"(信頼性と継続性に重点を置いています。
• "クラウドとオンプレミス全体で DevOps を標準化することで、デプロイの頻度を 50% 増やします。"(機敏性とプロセスの改善に重点を置いています。
• 「オンプレミスのフットプリントを 2 年間で 50% 削減し、コストを削減しながら、クラウド管理を残りのすべてのオンプレミス資産に拡張します。"(効率性とクラウド優先の運用を重視します。

3. ハイブリッドおよびマルチクラウドの成功メトリックを確立する

ビジョンに沿って、進行状況を測定するための 2 ~ 5 個の主要な成功メトリック (KPI) を定義します。 前のステップの主要な各ドライバーは、少なくとも1つのKPIに対応付ける必要があります。 可能な場合は、それらを具体的かつ期限付きにします。 たとえば、機敏性がドライバーの場合、KPI はインフラストラクチャのプロビジョニング時間を 12 か月以内にすべての環境で数週間から数時間に短縮する可能性があります。 コストの最適化がドライバーである場合、KPI は、クラウドバーストと統合によってインフラストラクチャの使用率を 30% 向上させる可能性があります。 バーストを導入する前に、データエグレスと同期のコストを評価します。 セキュリティまたはコンプライアンスのメトリックも含めます。 たとえば、100% のオンボードリソースとスコープ内リソースが、Azure Policy と Defender for Cloud を使用して測定されたベースライン セキュリティ ポリシーに準拠している必要があることを目標に設定します。

メトリックを設定することで、成功の共有定義を作成します。 チームを調整し、時間の経過と共にハイブリッド/マルチクラウド イニシアチブの利点を追跡する方法を提供します。

4. ハイブリッドおよびマルチクラウドの原則を設定する

さまざまなワークロードに使用するクラウドまたは環境を決定するための基本原則を確立します。 明確な原則は、複雑さを増す可能性のあるランダムまたは優先優先の選択を防ぎます。 また、移植性に対する要望と、クラウド固有のサービスの利点とのバランスを取ります。 次のようなガイドラインを作成します。

1. クラウドに依存しない使用量とクラウド固有の使用状況を判断します。 クラウドに依存しないソリューションを構築する場所と、クラウドネイティブ サービスを使用する場所を決定します。 ワークロードごとに、移植性が重要かどうかを判断します。 たとえば、記録のコア システムでは、任意の場所で実行される Azure Kubernetes Service、コンテナー、データベースなどのテクノロジを使用して、中立性に優先順位を付ける場合があります。 これに対し、顧客向けプロジェクトやイノベーション プロジェクトでは、Azure Functions などのクラウド固有の PaaS サービスを使用して開発を高速化できます。

2. 可能な場合は、統合レイヤーとして Azure を使用します。 Azure をすべての環境の中央管理および統合レイヤーにします。 各クラウドの並列ツールセットを維持するのではなく、Azure を使用して他のクラウドを管理することを計画します。 たとえば、AWS で一部の VM を実行する場合は、Arc を使用して Azure にオンボードし、Azure Policy を使用してポリシーを適用して、Azure リソースと同じように管理できるようにします。 この統合により、各クラウドのネイティブ管理ツールを使用する必要はありません。 Azure は、IT 資産全体で一貫したオーバーレイになります。

3. マルチクラウドの複雑さを正当化する。 マルチクラウド アプローチでは、複数のスキル セット、アーキテクチャの変化、クラウド間のデータ エグレス料金などのコストの増加など、複雑さが生じる可能性があります。 別のクラウドを使用するには明確な正当な理由が必要であるという原則を設定します。 一意の機能またはビジネス要件で特に義務付けられている場合を除き、新しいデプロイでは既定で Azure に設定されます。 セカンダリ クラウドを使用する場合は、Azure を介して統合し、その必要性を定期的に見直します。 この意図的な姿勢により、異なるプラットフォーム上で非管理対象のサイロ化されたデプロイが拡散されるのを回避できます。 開発者が別のデータ分析テクノロジを使用することを提案する場合は、強力な理由を持ち、統合を計画する必要があります。 それ以外の場合は、Microsoft Fabric などの Azure の分析オファリングを使用する必要があります。

これらの原則は、アーキテクトとエンジニアに意思決定フレームワークを提供します。 たとえば、データベース サービスを選択する場合、ガイドラインでは、戦略に合わない Azure 以外のサービスを自動的に選択するのではなく、機能のために Azure の PaaS データベースに誘導する場合があります。 全体的な目的は、バックボーンとしての Azure の使用を奨励し、断片化を最小限に抑え、必要に応じてマルチクラウド要素のみを受け入れることです。

5. ハイブリッドとマルチクラウドのクラウド ミックスを選択する

オンプレミスを含むクラウド プラットフォームを戦略の一部として決定し、最初から中央管理ハブとして Azure を確立します。

1. 要件に基づいてクラウド ポートフォリオを選択します。 ビジネスと技術のニーズを評価して、クラウド プラットフォームの組み合わせを決定します。 多くの企業では、さまざまなニーズや従来の投資を満たすために複数のパブリック クラウドを使用しています。 使用するプラットフォームとその理由を文書化します。 また、オンプレミスインフラストラクチャが今後どのような役割を果たすかを決定します。 たとえば、ほとんどのワークロードに Azure を使用し、Azure Local を使用して特定のファクトリ コントロール システムのオンプレミス システムを維持できます。 具体的であれ。 オンプレミスに残る必要がある重要なワークロードを特定し、Azure Local でホストし、Azure Arc 経由で管理をオンボードし、他のクラウドの例外的なケースを使用して最新化を計画します。 この計画的な組み合わせが、回復性や特殊な機能にセカンダリ クラウドを使用するなど、ドライバーに結び付けられるようにします。

2. Azure をすべての環境のプライマリ コントロール プレーンにします。 Azure は、すべてのクラウドとオンプレミスのリソースを管理するためのメイン ハブとして機能する必要があることを明確に示します。 Azure は Azure Arc と関連サービスを介して強力なハイブリッド管理を提供するため、この決定は戦略的です。 管理のために AWS、Google Cloud、オンプレミスのリソースを Azure に投影することで、専門知識とツールを一元化できます。 実際には、これは、AWS のツールから Azure リソースを管理するのではなく、Arc を使用して Azure から AWS リソースを管理する必要があることを意味します。 Azure のクロスクラウド サービス (Arc、Microsoft Defender for Cloud、Azure Monitor) は、このハブ ロールに適しており、統合と一貫性を提供します。

3. 統合運用モデルを設計します。 このハイブリッド/マルチクラウド セットアップで IT 運用がどのように機能するかを想定します。 すべての環境で機能するプロセスを定義します。 たとえば、ポリシーは、すべてのサーバー (Azure VM、オンプレミス サーバー、AWS EC2) をインベントリする必要があります。 また、Azure Arc を使用して構成し、Azure および Arc 対応リソースの Azure Policy によって管理する必要があります。 AWS または Google Cloud の場合は、Defender for Cloud マルチクラウド コネクタを使用してコンプライアンス ポスチャーを可視化します。これは、Azure Policy の割り当てを直接行うのではなく、マルチクラウド コネクタを介して行われます。 GitHub Actions/Azure DevOps で CI/CD パイプラインを使用して、承認されたテンプレートを使用して任意のターゲット環境にアプリケーションをデプロイする必要があります。 ネットワーク操作では、Azure を他のサイト/クラウドをリンクするハブとして扱う必要があり、セキュリティ チームは Microsoft Sentinel を使用してすべてを監視する必要があります。 このターゲット運用モデルを記述することで、クラウドごとに個別の運用チームのように、統合運用でサイロを置き換える必要があることを期待できます。 日常業務の変更に備えて組織を準備し、一貫性を実現する方法を明らかにします。

4. クロスプラットフォーム運用をサポートする統合チームを確立します。 テクノロジと共に、人間の側面を計画します。 プラットフォームチームとワークロードチームのトレーニングとサポートを可能にするチームを確立します。 従来の IT チーム、クラウド チーム、セキュリティのメンバーを含めます。 Azure のツールを使用して任意の環境でリソースを管理できるように、オンプレミスの IT スタッフを Azure とクラウドのスキルでトレーニングします。 このアプローチは、コラボレーションとクロストレーニングが必要であることを示しています。 場合によっては、再構成を意味する場合があります。 別のクラウド チームをマージしたり、すべてのビジネス ユニットにサービスを提供する一元化されたプラットフォームを用意したりする可能性があります。 この戦略の一部にすることで、組織構造が運用モデルをサポートすることが保証されます。

クラウド ミックスを意図的に選択し、アンカーとして Azure を選択することで、統合管理の強力な基盤を設定します。 誰もが、運用する必要がある環境と、Azure がそれらを結び付ける方法を理解する必要があります。 この理解は、プラットフォームの制御されていない拡散を防ぎ、以前の原則を強化します。

6. Azure ハイブリッドおよびマルチクラウド サービスを目標にマップする

戦略を完了したら、特定の目標を達成するのに役立つ Azure サービスとテクノロジを特定します。 この識別により、高度な戦略から実用的な実装へのブリッジが作成されます。 技術スタックのすべての重要な領域を検討し、それらを Azure ソリューションにマップします。

このマッピングを文書化することで、戦略に具体的な Azure 中心のテクノロジ ゲーム プランが含まれていることが保証されます。 また、スキルのギャップとツールのニーズを早期に特定するのにも役立ちます。 たとえば、分析に Microsoft Fabric を使用する予定の場合は、データ統合スキルと Power BI の専門知識が必要であることがわかります。 Azure Arc が中心である場合は、Arc で運用チームのトレーニングを計画します。この手順により、戦略的な意図が、それを実現する実用的な Azure サービスに変換されます。

戦略の結果

このフェーズの最後には、上記のすべての要素をキャプチャするハイブリッド/マルチクラウド戦略が必要です。 これまでの決定を要約する必要があります。

• ビジネス ドライバーとスコープ: IT 運用、マルチクラウドのアップタイム要件、エッジ要件を統合します。
• ビジョン ステートメント: Azure は主要なプラットフォームとコントロール プレーンであり、他のクラウドとオンプレミス システムを統合して、統一されたアジャイルなデジタル インフラストラクチャを提供します。
• 成功メトリック: 可用性、デプロイ速度、コスト削減、コンプライアンスに関する特定のターゲット。
• 基本原則: ロックインを回避する方針、既定でAzureを使用すること、必要に応じてクラウドに依存しない設計を活用すること。
• クラウド ミックス: 使用される環境 (Azure、Azure ローカル経由のオンプレミス、その他のクラウド) とその理由。
• 主要なテクノロジ: 戦略を実行することを決定した Azure および Azure 以外のサービス。

説明するために、戦略をまとめる方法の抜粋例を次に示します。

• 戦略の概要の例: 組織は、ニーズごとに最適なクラウド機能を使用しながら、IT 運用を統合するためのアダプティブ ハイブリッド/マルチクラウド アプローチを追求しています。
• ドライバー: ダウンタイムを回避します (目標 < 1 時間/年)。 EU のデータ所在地に関する法律を満たす。 運用サイロを分解して効率を向上させる (目標 20% OPEX 削減)。
• ビジョン: Azure は、他のすべての環境を統合する主要なクラウドおよびコントロール プレーンです。 オンプレミスのニーズに合わせて、Azure と 1 つのセカンダリ クラウドと Azure Local を使用してグローバル カバレッジを向上させる必要があります。
• クラウドの原則: 差別化と高速化のために Azure ネイティブ サービスを採用します。 特別な理由がない限り、新しいデプロイは既定で Azure にします。
• クラウド ミックス: 現在、最大 50% オンプレミスが Azure Local、40% Azure、10% AWS で最新化され、特定のユース ケースに対応しています。 長期的な目標: 70% Azure。残りのオンプレミスは Azure Local 経由で実行され、他のクラウドのニッチな使用のみが実行されます。
• 主要な Azure テクノロジ: リソース管理を統合するための Azure Arc。 エンド ツー エンドの可視性とセキュリティのための Azure Monitor と Defender。 クラウドをオンプレミスに拡張するための Azure Local。 コンテナー用の AKS。 データ分析を統合するための Microsoft Fabric。 エッジ デバイス用の Azure IoT。 統合されたアイデンティティのためのEntra ID。 すべてのデプロイ用に標準化された Azure Pipelines。 すべてのプラットフォームで厳格なセキュリティ コンプライアンスを維持しながら、アップタイムとデプロイ頻度の目標を満たす能力によって成功を測定する必要があります。

この戦略的な簡単な情報を利害関係者によって承認することで、次に進む前に全員が一致することが保証されます。 これで、Azure に重点を置いた確実なゲーム プランを手に入れた詳細な計画に進むことができます。

次のステップ