Azure リージョンの決定ガイド

Azure への移行戦略を計画する際は、世界中のさまざまな Azure リージョンから選ぶことができます。 Azure リージョンにはそれぞれ固有の特性があり、Azure リソースに適したリージョンを選ぶことがきわめて重要です。 考慮事項には、利用可能なサービス、容量、制約、主権などがあります。

• 利用可能なサービス: 各リージョンにデプロイできる Azure サービスは、さまざまな要因によって異なります。 実際のワークロードに必要なサービスに合わせてリージョンを選択してください。 詳細については、「リージョン別の利用可能な製品」を参照してください。
• 容量: リージョンにはそれぞれ最大容量があります。 どのような種類のサブスクリプションが、どのような状況で、どのような種類のサービスをデプロイできるかは、リージョンの最大容量に左右される場合があります。 リージョンの容量は、サブスクリプションのクォータとは異なります。 大規模なデータセンターを Azure に移行する計画をしている場合は、ご自分の地域の Azure フィールド チームまたは Azure アカウント マネージャーに問い合わせて、必要な規模でデプロイできることを確認するようお勧めします。
• 制約: 特定のリージョンでのサービスのデプロイには、特定の制約が適用されます。 たとえば一部のリージョンは、バックアップまたはフェールオーバーの用途に限定されます。 注意が必要なその他の制約は、データ主権要件です。
• 主権: 特定のリージョンは、特定の主権エンティティ専用になっています。 すべてのリージョンは Azure リージョンですが、こうした主権リージョンは他の Azure から分離されています。 これらは、必ずしも Microsoft によって管理されるわけではなく、特定の種類の顧客に制約される場合もあります。 このような主権リージョンは次のとおりです。
  • Azure China 21Vianet
  • Azure Germany
    Azure Germany は非推奨とされており、ドイツ国内の標準の非主権 Azure リージョンが推奨されています。
  • Azure Government - US

複数の地理的リージョンでの運用

組織はその運用に不可欠な回復性を確保するために、複数の地理的リージョンで運用を行う場合があります。 複数の地理的リージョンで運用を行う場合、次の形で複雑さが生じる可能性があります。

• 資産の配布
• ユーザー アクセス プロファイル
• コンプライアンスの要件
• リージョンの回復性

リージョンの選択は、クラウド導入戦略全体の重要な要素です。 まず、ネットワークに関する考慮事項について説明します。

ネットワークに関する考慮事項

堅牢なクラウド デプロイには、Azure リージョンの違いを考慮して十分に練られたネットワークが必要です。 次の点を考慮する必要があります。

• Azure ペア リージョン。 リージョンに壊滅的な障害が発生した場合の回復性を確保するために、各リージョンは、同じ地政学的領域内の別のリージョンとペアになっています。 ただし Brazil South は例外です。これは、South Central US とペアになっています。

  回復性の一次的および二次的戦略として、ペア リージョンに配置することを検討してください。 考慮すべき詳細情報を次に示します。

  • Azure Storage は、geo 冗長ストレージ (GRS) をサポートしています。 Azure Storage GRS では、お客様のデータのコピーが 3 つプライマリ リージョンに格納されたうえで、さらにペア リージョンにも 3 つのコピーが格納されます。 GRS のストレージ ペアリングを変更することはできません。
  • Azure Storage GRS に依存するサービスでは、このペア リージョンの機能を利用できます。 アプリケーションとネットワークは、ペアになっているリージョンをサポートするように構成する必要があります。
  • リージョンの回復性のニーズに対応するために GRS を使用する予定がない場合は、セカンダリとしてペアになっているリージョンを使用しないでください。 リージョンの障害が発生した場合、ペア リージョンのリソースには、リソースの移行時に大きな負荷がかかります。 回復先を他のサイトとすることで、そのような負荷を回避し、復旧時の速度を向上させることができます。

  警告

  仮想マシンのバックアップまたは復旧に Azure Storage GRS を使用しないでください。 IaaS (サービスとしてのインフラストラクチャ) ワークロードの回復性をサポートするには、代わりに、Azure Backup、Azure Site Recovery、Azure マネージド ディスク を使用します。

  詳細については、「Azure のペアになっているリージョン」をご覧ください。

• Azure Backup と Azure Site Recovery は、IaaS およびデータ バックアップのニーズに応じてネットワーク設計と連携して機能し、リージョンの回復性を高めます。 データ転送を Microsoft のバックボーンにとどめ、可能な場合は仮想ネットワーク ピアリングを使用するように、ネットワークが最適化されていることを確認します。 グローバルにデプロイしている大規模な組織では、リージョン間のトラフィックをルーティングして、リージョンのエグレス料金を節約するために Azure ExpressRoute Premium を使用する場合があります。

• Azure リソース グループは、Azure リージョンに固有です。 ただし、リソース グループ内の "リソース" は、多くの場合、複数のリージョンにまたがります。 リージョンの障害が発生した場合、その影響下にあるリージョンのリソース グループに対するコントロール プレーン操作は失敗しますが、そのリソース グループ内のリソースは他のリージョンで引き続き機能します。 ネットワークとリソース グループの設計方法は、リージョンごとのリソース グループの回復性に左右される場合があります。

• Azure 内の多くの PaaS (サービスとしてのプラットフォーム) サービスは、サービス エンドポイントや Azure Private Link をサポートしています。 どちらのソリューションも、リージョンの回復性、移行、ガバナンスを考慮する際に、ネットワークの設計方法に大きく影響する可能性があります。

• 多くの PaaS サービスは、独自のリージョンの回復性ソリューションに依存しています。 たとえば、Azure SQL Database と Azure Cosmos DB のデプロイでは、レプリケート先のリージョンを簡単に増やすことができます。 Azure DNS などの一部の Azure サービスには、リージョンの依存関係がありません。 クラウド導入プロセスで使用するサービスを検討する際には、使用する各 Azure サービスで必要となる可能性があるフェールオーバー機能と復旧手順を明確に理解しておいてください。

• ディザスター リカバリーをサポートするために複数のリージョンにデプロイするだけでなく、多くの組織では、フェールオーバーへの依存を避けるためにアクティブ/アクティブ パターンでデプロイすることを選択しています。 アクティブ/アクティブ パターンを使用する利点には、グローバル負荷分散、フォールト トレランスの向上、ネットワーク パフォーマンスの向上などがあります。 このパターンを利用するには、アプリケーションによって、複数のリージョンでアクティブ/アクティブの実行がサポートされている必要があります。

警告

Azure リージョンは高可用性のコンストラクトです。 特定のリージョンで実行されているサービスには、Azure サービス レベルアグリーメントが適用されます。 決してミッション クリティカルなアプリケーションを 1 つのリージョンに依存させないでください。 常にリージョンの障害に備えて計画し、復旧と軽減策の手順を練習してください。

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

ネットワーク トポロジを検討した後、ドキュメントとプロセスのさらなる整合が必要かどうかを判断します。 次のアプローチは、潜在的な課題を評価し、一般的な行動指針の確立に役立つ可能性があります。

• さらに堅牢な準備とガバナンスの実装を検討します。
• 影響を受ける地域のインベントリを作成します。 影響を受ける国/リージョンの一覧を作成します。
• データ主権要件の文書化。 特定された国/リージョンには、データ主権を管理するコンプライアンス要件がありますか?
• ユーザー ベースの文書化。 特定された国/リージョンの従業員、パートナー、または顧客は、クラウド移行の影響を受けますか?
• データセンターと資産の文書化。 特定された国/リージョンに、移行作業に含まれる可能性のある資産がありますか。
• リージョンの SKU の可用性とフェールオーバーの要件を文書化します。

移行プロセス全体の変更点をすり合わせて、初期インベントリに取り組みます。 次の表は、調査結果を文書化するのに役立つシナリオの例を示しています。

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

データ主権要件を把握する

政府機関がデータの主権性とプライバシーに関する規制を確立する動きが世界中で始まっています。 この種のコンプライアンス要件では、多くの場合、その場所の市民を保護するために、特定の国/地域でのローカリゼーションが必要です。 顧客、従業員、またはパートナーに属するデータを、ユーザーと同じリージョン内のクラウド プラットフォームに格納しなければならないケースも中にはあります。

この課題への対応が、世界的規模で事業を展開する組織にとっての、クラウド移行への重要な動機付けになっています。 データ主権へのコンプライアンスを維持するために、重複した IT 資産をリージョン内のクラウド プロバイダーにデプロイすることを選んだ組織もあります。 上の表では、ドイツのシナリオが良い例です。 このシナリオには、顧客、パートナー、従業員は含まれていますが、ドイツの現在の IT 資産は含まれていません。 この組織は、データ主権規制領域内のデータセンターに、たとえばドイツの Azure データセンターを使用して一部の資産をデプロイすることが考えられます。 地域のデータ主権規制の影響下にあるデータを把握することは、クラウド導入チームが、その組織にとって最良の移行アプローチを見極めるための手立てとなります。

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

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

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

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

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

既存のデータセンターの場所が、移行戦略に影響を与えることがあります。 次の要因について検討します。

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

データセンターの依存関係: 複雑さの文書化に関するセクションの表のサンプル シナリオを見ると、さまざまなグローバル データセンター間の依存関係についての検討が必要であることがわかるでしょう。 この規模で事業を展開している多くの組織では、そのような依存関係は文書化されていないか、十分に理解されていない場合があります。 ユーザー プロファイルの評価に対する組織のアプローチは、組織内のこれらの依存関係をある程度特定するのに役立ちます。 また、依存関係から生じるリスクや複雑さを軽減しうる追加の評価手順をチームで調査する必要があります。

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

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

• データ主権によって、一部の資産のローカライズが必要な場合がありますが、多くの資産はそうしたコンプライアンスの制約の影響を受けない可能性があります。 ログ、レポート、ネットワーク ルーティング、ID、その他の中央 IT サービスは、複数のサブスクリプション、または複数のリージョンにまたがって共有サービスとしてホストされるのがふさわしいと考えられます。 クラウド導入チームは、共有サービスを含むハブスポーク トポロジの参照アーキテクチャの説明に従って、これらのサービスの共有サービス モデルを使用してデータ主権を評価する必要があります。
• 類似した環境の複数のインスタンスをデプロイする場合、環境ファクトリを使用することで整合性を与え、ガバナンスを改善して、デプロイを加速させることができます。 複雑な企業向けのガバナンス ガイドでは、複数のリージョンにわたる規模の環境を作成するアプローチを確立しています。

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

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

• 大まかな調査結果をまとめる: 複雑さの文書化のセクションで取り上げた表を完成させて、実際のクラウド導入戦略の複雑さを評価します。
• 影響を受ける各国/リージョンのユーザー プロファイルを分析する: 移行プロセスの早い段階で、一般的なユーザー ルーティングを理解することが重要です。 グローバル専用回線を変更し、ExpressRoute のような接続をクラウド データセンターに追加することは、数か月のネットワークの遅延が必要になることがあります。 ユーザー ルーティングには、できる限りプロセスの早い段階で対処してください。
• 初期デジタル資産の合理化を遂行する: 移行戦略が複雑になったときは、常に初期デジタル資産の合理化を遂行する必要があります。 詳細については、「デジタル資産とは」を参照してください。
• タグ付けを使用してデジタル資産の要件を把握する: データ主権要件の影響を受けるすべてのワークロードを識別するためのタグ付けポリシーを確立します。 必要なタグは、デジタル資産の合理化で始まり、移行済みの資産まで運ばれる必要があります。
• ハブスポーク モデルを評価する: 分散システムは多くの場合に、共通の依存関係を共有しています。 共通の依存関係は、多くの場合、ハブスポーク モデルを導入することで対処できます。 ハブスポーク モデルの導入は、移行プロセスの範囲を超えますが、今後の準備プロセスの繰り返しで考慮されるためにフラグ付けしておく必要があります。
• 移行バックログの優先順位付け: 複数のリージョンをサポートするワークロードの実稼働デプロイをサポートするためにネットワークの変更が必要な場合、クラウド戦略チームは、それらのネットワークの変更から生じるエスカレーションを追跡し、管理する必要があります。 戦略チームがバックログの優先順位を自由に変更できるようにして変化を加速させるとともに、グローバルなワークロードがネットワークの変更によってブロックされないようにするうえで、より高いレベルの経営幹部のサポートが役立ちます。 グローバルなワークロードには、ネットワークの変更が完了したときに初めて優先順位を付けることになります。

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

プロセス変更の評価

移行シナリオでグローバルな資産とユーザー ベースの複雑さに対処する必要が生じる場合、移行候補の評価にいくつかの重要なアクティビティを追加する必要があります。 これらのアクティビティは、グローバルなユーザーや資産に関する障害と結果を明確にするためのデータを生成します。

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

データセンターにまたがる依存関係の評価:Azure Migrate の依存関係視覚化ツールは、依存関係の特定を支援できます。 これらのツールは、移行を開始する前に使用することをお勧めします。 グローバルな複雑さが伴う場合、これは評価プロセスで必要な手順になります。 依存関係のグループ化による視覚化は、ワークロードをサポートするために必要な資産の IP アドレスとポートを特定する効果的な手段となります。

重要

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

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

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

警告

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

移行プロセスの変更

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

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

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

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

ネットワーク帯域幅の設計: レプリケーションおよび継続的な同期時に、管理者は、ソース データセンターからターゲット Azure データセンター内の Site Recovery コンテナーに、バイナリ データをネットワーク経由で移動します。 レプリケーションと同期のプロセスは帯域幅を消費します。 2 つ目のリージョンへのワークロードの複製により、消費される帯域幅の量が 2 倍になります。 帯域幅が制限されていたり、ワークロードに大量の構成またはデータ ドリフトが含まれていたりすると、2 つ目のリージョンへのデータの複製が、移行の所要時間に支障をきたす可能性があります。 さらに重要なことに、これらの制限は、それまでソース データセンターで利用できていた帯域幅に引き続き依存するユーザーやアプリケーションのエクスペリエンスに影響する可能性があります。

データの同期: 最大帯域幅の浪費が、データ プラットフォームの同期に由来する場合がよくあります。 マルチリージョン Web アプリケーションとマルチリージョン n 層アプリケーションの参照アーキテクチャで定義されているように、多くの場合にアプリケーションを一致させるために、データの同期が必要になります。 アプリケーションを同期させておくことが、そのアプリケーションの望ましい運用状態である場合、各クラウド プラットフォームに対してソース データ プラットフォームを同期させることをお勧めします。 これは、アプリケーションと中間層の資産を移行する前に行う必要があります。

Azure から Azure へのディザスター リカバリー: 代替オプションにより、複雑さをさらに軽減できる場合があります。 タイムラインとデータ同期によって 2 段階のデプロイが必要になりそうな場合、Azure から Azure へのディザスター リカバリーが許容可能な解決策になると考えられます。 このシナリオでは、単一の Site Recovery コンテナーと、構成またはプロセス サーバー設計を使用して、ワークロードを最初の Azure データセンターに移行します。 ワークロードをテストしたら、移行済みの資産から 2 つ目の Azure データセンターにそのワークロードを回復できます。 このアプローチでは、ソース データセンター内のリソースに対する影響が減り、Azure データセンター間で高速の転送速度と高い帯域幅制限を利用します。

Note

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

最適化および昇格プロセスの変更

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

最適化および昇格プロセス中に推奨されるアクション

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

ビジネス変更プラン: 複雑な移行シナリオの場合は常に、ビジネス変更プランを作成します。 ビジネス変更プランを使用することにより、変更を統合するのに必要とされるビジネス プロセス、ユーザー エクスペリエンス、および作業タイミングへの変更を明確に伝えることができます。 グローバルな移行作業の場合、このプランには、影響を受ける各地域のエンドユーザーに関する考慮事項を含める必要があります。

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

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

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