次の方法で共有

移行する Azure リージョンを選ぶ

  • [アーティクル]

既存の環境を Azure に移行する場合、移行するコンポーネントをホストする Azure リージョンまたはリージョンのセットを選ぶ必要があります。 領域選択には、次の大まかな手順が含まれます。

  • コア Azure リージョン選択ガイダンスを確認し、要件を満たす Azure リージョンの選択方法を理解します。
  • 環境の現状を把握し、文書化します。
  • 単一リージョン内で実行するか、複数の可用性ゾーンを使うか、複数のリージョンを使うかなど、移行に対する一般的なアプローチを実装します。
  • 必要になる可能性のあるプロセスの変更を評価します。
  • 移行プロセスを計画します。
  • プロセスの変更を最適化して促進します。

この記事では、移行ニーズを満たす Azure リージョンを選ぶ方法について、ガイダンスを提供します。 まだ行っていない場合は、複数リージョンのアプローチをサポートするためにランディング ゾーン リージョンを拡張することが必要になる場合があります。

Note

この記事では、ワークロードの移行に固有の考慮事項について説明します。 また、組織やワークロードに合わせて Azure リージョンを選ぶための一般原則も理解しておく必要があります。 詳細については、「Azure リージョンの選択」を参照してください。

シナリオの複雑さを文書化する

シナリオに文書化とプロセスの調整が必要かどうかを判断します。 次のアプローチは、潜在的な課題を評価し、一般的な行動指針の確立に役立つ可能性があります。

  • さらに堅牢な準備とガバナンスの実装を検討します。
  • 影響を受ける地域のインベントリを作成します。 影響を受ける国またはリージョンの一覧をコンパイルします。
  • ユーザー ベースの文書化。 クラウド移行は、特定された国または地域の従業員、パートナー、または顧客に影響を与えますか?
  • データセンターと資産の文書化。 移行作業には、特定された国または地域の資産が含まれていますか?
  • 地域ごとの製品バージョンの可用性とフェールオーバー要件を文書化します。
  • 可用性ゾーンが必要かどうかを判断するために、回復性の要件を文書化します。 通常、個々のリージョンではなく、シナリオ全体の回復性の要件について考慮します。
  • 主権要件とデータ所在地の要件を文書化します。 特定の主権またはデータ所在地の要件を持つワークロードは、Azure リージョンの選択に影響する可能性があります。

移行プロセス全体を通して、さまざまなシナリオとインベントリ全体で変更を調整する方法を検討します。 次の表は、さまざまなシナリオを文書化する方法の例を示しています。

リージョン 国/リージョン ローカルの従業員 ローカルの外部ユーザー ローカルのデータセンターまたは資産 データ主権要件
北米 United States はい パートナーとお客様 はい いいえ
北米 Canada いいえ 顧客 はい はい
ヨーロッパ ドイツ はい パートナーとお客様 なし - ネットワークのみ はい
アジア太平洋 韓国 はい パートナー はい いいえ

ユーザーの場所が重要になる理由

複数の国またはリージョンのユーザーをサポートする組織は、ユーザー トラフィックに対処する技術的なソリューションを開発しました。 一部のケースでは、ソリューションに資産のローカライズが伴います。 別のシナリオでは、組織がグローバル ワイド エリア ネットワーク (WAN) ソリューションを導入し、ネットワークに重点を置いたソリューションで異なるユーザー ベースに対処する方法を選ぶことも考えられます。 いずれの場合も、移行戦略は、異なるユーザーの使用プロファイルに左右される可能性があります。

たとえば、現時点でドイツにデータセンターを持っていない組織がドイツの従業員、パートナー、顧客をサポートしている場合、その組織はおそらく専用回線ソリューションを導入していると考えられます。 このタイプのソリューションは、トラフィックを他の国またはリージョンのデータセンターにルーティングします。 この既存のルーティングでは、移行したアプリケーションの認識されるパフォーマンスに重大なリスクが存在します。 確立され、チューニングされたグローバル WAN に追加のホップが挿入されると、移行後にアプリケーションのパフォーマンスの低下が認識されることがあります。 そうした問題の検出と修正によって、プロジェクトに大幅な遅延が加わる可能性があります。

次の各セクションでは、前提条件と評価、移行、最適化のプロセスにわたるこの複雑さに対処するためのガイダンスが含まれています。 各国または地域のユーザー プロファイルを理解することは、この複雑さを適切に管理するために不可欠です。

データセンターの場所が関連する理由

既存のデータセンターの場所が、移行戦略に影響を与えることがあります。 次のような要素が考えられます。

アーキテクチャの決定: 移行戦略設計における最初の手順の 1 つは、ターゲット リージョンを決定することです。 多くの場合、この決定には、既存の資産がある場所が影響します。 また、クラウド サービスの可用性とそれらのサービスの単価は、リージョンによって異なる場合があります。 主権要件を含むデータ所在地の要件も、アーキテクチャの決定に影響を与える可能性があります。 現在および将来の資産の配置場所を理解することは、アーキテクチャの決定に影響するだけでなく、予算の見積もりにも影響する可能性があります。

データセンターの依存関係: 「シナリオの複雑さを文書化する」セクションの表にあるサンプル シナリオは、さまざまなグローバル データセンター間の依存関係を計画する必要があることを示しています。 この規模で運営している組織は、これらの依存関係を文書化していないか、または十分に理解していない可能性があります。 ユーザー プロファイルの評価に対する組織のアプローチは、組織内のこれらの依存関係をある程度特定するのに役立ちます。 また、依存関係から生じるリスクや複雑さを軽減しうる追加の評価手順をチームで調査する必要があります。

一般的なアプローチを導入する

次のアプローチでは、グローバルな移行の複雑さに対処するためのデータドリブン モデルを使用します。 移行の範囲に複数のリージョンが含まれる場合、クラウド導入チームは、次の準備に関する考慮事項を評価する必要があります。

  • ビジネス要件を満たすことができるかどうかを判断する: 複数の可用性ゾーンを使用して、高可用性、復元力、パフォーマンス、コストの要件を判断します。 これらの要件が満たされていない場合は、複数リージョンのアプローチが必要かどうかを検討してください。

  • データ主権を評価する: データ主権によって、一部の資産のローカライズが必要な場合がありますが、多くの資産はそうしたコンプライアンスの制約に制御されない可能性があります。 ログ、レポート、ネットワーク ルーティング、ID、その他の中央 IT サービスといったサービスは、複数のサブスクリプション、またはリージョンにまたがって共有サービスとしてホストされるのがふさわしいと考えられます。 これらのサービスに共有サービス モデルを使ってデータ主権を評価します。 このアプローチの概要については、共有サービスを使ったハブスポーク トポロジの参照アーキテクチャに関する記事を参照してください。

  • 環境がスケーリングされていることを確認する: 類似した環境の複数のインスタンスをデプロイする場合は、環境の移行専用チームを確立して、一貫性の作成、ガバナンスの向上、デプロイの高速化を支援できます。 複雑な企業向けのガバナンス ガイドでは、複数のリージョンにわたる規模の環境を作成するアプローチを確立しています。

データドリブンの前提条件

チームがベースライン アプローチに慣れ、準備が整ったら、これらのデータドリブンの前提条件について考慮します。

  • 大まかな調査結果をまとめる: 複雑さの文書化のセクションで取り上げた表を完成させて、実際のクラウド導入戦略の複雑さを評価します。

  • 影響を受ける各国またはリージョンのユーザー プロファイルを分析する: 移行プロセスの早い段階で、一般的なユーザー ルーティングを理解することが重要です。 グローバル専用回線を変更し、Azure ExpressRoute のような接続をクラウド データセンターに追加すると、数か月のネットワークの遅延が生じる可能性があります。 ユーザー ルーティングには、できる限りプロセスの早い段階で対処してください。

  • 初期デジタル資産の合理化を遂行する: 移行戦略に複雑さを導入する場合は、初期デジタル資産の合理化を完了してください。 詳細については、「デジタル資産とは」を参照してください。

  • タグ付けを使用してデジタル資産の要件を把握する: データ主権要件の影響を受けるすべてのワークロードを識別するためのタグ付けポリシーを確立します。 必要なタグは、デジタル資産の合理化で始まり、移行済みの資産まで確実に運ばれるようにします。

  • ハブスポーク モデルを評価する: 分散システムは多くの場合に、共通の依存関係を共有しています。 共通の依存関係は、多くの場合、ハブスポーク モデルを導入することで対処できます。 ハブスポーク モデルの導入は、移行プロセスの範囲を超えますが、今後の準備プロセスの繰り返しで考慮されるためにフラグ付けしておく必要があります。

  • 移行バックログの優先順位付け: 複数のリージョンをサポートするワークロードの実稼働デプロイをサポートするためにネットワークの変更が必要な場合、クラウド戦略チームは、それらのネットワークの変更から生じるエスカレーションを追跡し、管理する必要があります。 戦略チームがバックログの優先順位を自由に変更できるようにして変化を加速させると共に、ネットワークの変更によってグローバル ワークロードがブロックされないようにする上で、このより高いレベルの経営幹部のサポートが役立ちます。 グローバルなワークロードには、ネットワークの変更が完了したときに初めて優先順位を付けることになります。

これらの前提条件は、移行戦略の実行中に複雑さに対処できるプロセスを確立するのに役立ちます。

プロセス変更の評価

移行シナリオにグローバルな資産とユーザー ベースの複雑さが含まれる場合は、移行候補者を評価するための主要なアクティビティを追加します。 これらのアクティビティは、グローバルなユーザーや資産に関する障害と結果を明確にするためのデータを生成するのに役立ちます。

評価プロセス中に推奨されるアクション

データセンターにまたがる依存関係の評価:Azure Migrate の依存関係分析ツールは、依存関係の特定を支援できます。 移行を開始する前に、これらのツールを使用してください。 シナリオにグローバルな複雑さが伴う場合、依存関係の評価は評価プロセスで必要な手順です。 依存関係のグループ化を使用すると、依存関係を視覚化し、ワークロードのサポートに必要な資産の IP アドレスとポートを識別できます。

重要

  • 資産の配置と IP アドレス スキーマを理解している該当分野の専門家 (SME) が、セカンダリ データセンターに存在している資産を識別する必要があります。
  • 視覚化された下流方向の依存関係とクライアントを評価して、双方向の依存関係を理解します。

グローバル ユーザーへの影響の特定: 前提条件のユーザー プロファイル分析の結果から、グローバル ユーザー プロファイルに影響を受けるすべてのワークロードを特定する必要があります。 影響を受けるワークロードの一覧に移行候補が含まれる場合、移行担当アーキテクトは、ネットワークおよび運用の SME に問い合わせる必要があります。 これらの専門家は、ネットワーク ルーティングとパフォーマンスの予想を検証する点で助けになります。 少なくとも、アーキテクチャには、最も近いネットワーク運用センターと Azure との間の ExpressRoute 接続を含める必要があります。 ExpressRoute 接続の参照アーキテクチャは、必要なネットワーク接続の構成に役立ちます。

コンプライアンスのための設計: 前提条件のユーザー プロファイル分析の結果から、データ主権要件の影響を受けるすべてのワークロードを特定する必要もあります。 評価プロセスのアーキテクチャ アクティビティ中に、担当のアーキテクトは、コンプライアンスの SME に問い合わせる必要があります。 専門家の力を借りながら、アーキテクトは複数のリージョン間で移行とデプロイを実行するための要件を把握することができます。 このような要件は、設計戦略に大きく影響します。 設計に役立つ参照アーキテクチャを次に示します。

警告

ExpressRoute の参照アーキテクチャまたはアプリケーションの参照アーキテクチャを使用する場合は、データ主権の要件を満たすために、レプリケーション プロセスから特定のデータ要素を除外することが必要になる場合があります。 特定のデータ要素を除外するというタスクによって、昇格プロセスの手順が 1 つ増えることになります。

移行プロセスの変更

複数のリージョンにデプロイする必要があるアプリケーションを移行する場合、クラウド導入チームはいくつかの考慮事項を検討する必要があります。 Azure Site Recovery コンテナーと、構成およびプロセス サーバーの設計は、このような考慮事項のうちの 2 つです。 他の 2 つは、ネットワーク帯域幅の設計とデータ同期です。

移行プロセス中に推奨されるアクション

Site Recovery コンテナーの設計: Site Recovery は、デジタル資産の Azure へのクラウドネイティブのレプリケーションと同期に推奨されるツールです。 サイトの回復は、各資産に関するデータをサイトの回復コンテナーにレプリケートします。 このコンテナーは、特定のリージョンと Azure データセンター内の特定のサブスクリプションにバインドされます。 アセットを 2 つ目のリージョンにレプリケートするときに、2 つ目のサイトの回復コンテナーも必要になる場合があります。

構成およびプロセス サーバーの設計: Site Recovery は、単一の Site Recovery コンテナーにバインドされている、構成およびプロセス サーバーのローカル インスタンスで動作します。 この構成を使う場合、必要に応じて、レプリケーションを容易にするために、これらのサーバーの 2 つ目のインスタンスをソース データセンターにインストールします。

ネットワーク帯域幅の設計: レプリケーションおよび継続的な同期時に、管理者は、ソース データセンターからターゲット Azure データセンター内の Site Recovery コンテナーに、バイナリ データをネットワーク経由で移動します。 レプリケーションと同期は帯域幅のプロセスを消費します。 2 つ目のリージョンへのワークロードの複製により、消費される帯域幅の量が 2 倍になります。

シナリオによっては、帯域幅が制限されています。 また、ワークロードに大幅な構成やデータ ドリフトが含まれる場合もあります。 このような場合、2 つ目のリージョンにデータをレプリケートすると、移行の完了にかかる時間が長くなる可能性があります。 さらに重要なことに、これらの制限は、それまでソース データセンターで利用できていた帯域幅に引き続き依存するユーザーやアプリケーションのエクスペリエンスに影響する可能性があります。

データ同期: 最大帯域幅の浪費が、データ プラットフォームの同期に由来する場合がよくあります。 複数の可用性ゾーンにデプロイする場合、複数の可用性ゾーン間でデータを自動的に同期するゾーン冗長データ サービスを使用できる可能性があります。 複数のリージョンにまたがったデプロイでは、多くの場合、アプリケーションの整合性を保つためにデータの同期が必要になります。 このアプローチはマルチリージョン Web アプリケーションとマルチリージョン n 層アプリケーションの参照アーキテクチャで定義されています。

アプリケーションを同期させておくことが、そのアプリケーションの望ましい運用状態である場合、各クラウド プラットフォームに対してソース データ プラットフォームを同期させることをお勧めします。 この同期は、アプリケーションと中間層の資産を移行する前に行います。

Azure から Azure へのディザスター リカバリー: 代替オプションにより、複雑さをさらに軽減できる場合があります。 2 段階のデプロイを使ってタイムラインとデータ同期のニーズを満たす場合、Azure から Azure へのディザスター リカバリーが許容可能な解決策になると考えられます。 このシナリオでは、単一の Site Recovery コンテナーと、構成およびプロセス サーバー設計を使用して、ワークロードを最初の Azure データセンターに移行します。 ワークロードをテストしたら、移行済みの資産から 2 つ目の Azure データセンターにそのワークロードを回復できます。

この方法により、ソース データセンター内のリソースへの影響が軽減されます。 Azure 間のディザスター リカバリーでは、Azure データセンター間の高速転送速度と高帯域幅制限も利用されます。

Note

Azure から Azure へのディザスター リカバリーアプローチでは、エグレス帯域幅の料金が高くなることで、短期的な移行コストが増加する可能性があります。

リリース プロセスの変更

最適化と昇格時のグローバルな複雑さに対処する際に、デプロイ先のリージョンごとに同等の作業が必要になる場合があります。 単一リージョンを使う場合、ビジネス テストとビジネス変更プランの複製が必要になる場合があります。

リリース プロセス中におすすめの操作

事前テストの最適化: 初期オートメーション テストでは、すべての移行作業の場合と同様に、潜在的な最適化の機会を特定できます。 グローバル ワークロードの場合は、各リージョンで個別にワークロードをテストします。 ネットワークまたは選択した Azure データセンターの小さな構成変更が、パフォーマンスに影響を及ぼす可能性があります。

ビジネス変更プラン: 複雑な移行シナリオに対応するビジネス変更計画を作成します。 ビジネス変更計画により、ビジネス プロセスとユーザー エクスペリエンスの変更について明確なコミュニケーションを確保できます。 また、プランは変更を統合するために必要な取り組みのタイミングについて、明確なコミュニケーションを確保するのにも役立ちます。 グローバルな移行作業の場合、このプランには、影響を受ける各地域のエンドユーザーに関する考慮事項を含める必要があります。

ビジネス テスト: 各リージョンでビジネス テストが必要になる場合もあります。 ビジネス テストを行うことにより、十分なパフォーマンスを確保すると共に、変更されたネットワーク ルーティング パターンの準拠を徹底することができます。

昇格フライト: 多くの場合、昇格は単一のアクティビティとして行われ、実稼働トラフィックは移行済みのワークロードに対して直ちに再ルーティングされます。 グローバルなリリース作業の場合、昇格をフライト (事前に定義された一連のユーザー) 単位で提供する必要があります。 昇格フライトにより、クラウド戦略チームとクラウド導入チームは、パフォーマンスを監視しやすくなり、各リージョン内のユーザーのサポートを強化できます。 プロモーション フライトは、ネットワーク レベルで制御できます。 具体的には、ソース ワークロード資産から新しく移行された資産への特定の IP 範囲の移行を変更できます。 指定したユーザーのコレクションを移行した後、次のグループを再ルーティングできます。

フライトの最適化: 昇格フライトを使用する 1 つの利点は、より踏み込んだ監視が可能となり、デプロイされた資産を最適化する機会が得られることです。 最初のフライトで短期間、運用環境の使用に成功した後、IT 運用手順でサポートされるようになった時点で、移行済みの資産を改善することができます。