Azure リージョンを選択する

  • [アーティクル]

Microsoft Azure を使用するための戦略を設計する際、世界中にある多数の Azure リージョンから選ぶことができます。 リージョンの選択は、クラウド導入戦略全体の重要な要素です。 Azure リージョンにはそれぞれ固有の特性があるため、お使いの Azure リソースに最適なリージョンを選ぶことがきわめて重要です。

Azure リージョンのアーキテクチャと回復性について

Azure リージョンが異なると、特性も異なります。 Azure リージョンを多様にする要素として、可用性ゾーンと、ペアになっているリージョンの 2 つがあります。 また、一部のリージョンは、特定の国の主権実体によって運営されています。 "リージョン アーキテクチャ" とは、特定のリージョンの設計方法と、リージョンで提供される全体的なリージョン機能を指します。

Azure リージョンのしくみの詳細については、Azure リージョンと可用性ゾーンとは何かに関するページを参照してください。

可用性ゾーン

多くの Azure リージョンには、可用性ゾーンがあります。これは、リージョン内の物理的に分離された場所です。 可用性ゾーンを使用すると、デプロイ内でより高い可用性と回復性を実現できます。 可用性ゾーンの詳細と、可用性ゾーンをサポートする Azure リージョンおよびサービスの一覧については、「サービスとリージョンの可用性ゾーンのサポート」を参照してください。

ペアになっているリージョン

一部のリージョンは、別のリージョンとペアになっています。両方のリージョンは通常、同じ地政学領域内に配置されています。 リージョンのペアリングにより、リージョンで致命的な障害が発生した場合の回復性が提供されます。 リージョンのペアリングは主に geo 冗長ストレージ (GRS) に使用され、レプリケーションのために Azure Storage に依存する他の Azure サービスによって使用されます。

新しいリージョンはペアリングされません。 これらのリージョンでは、高可用性と回復性のために、代わりに可用性ゾーンが使用されます。 この記事では後ほど、これらの種類のリージョンを使用する方法について詳細に説明します。

ヒント

リージョンと可用性ゾーンを使用するワークロードを設計する方法については、「可用性ゾーンとリージョンの使用に関する推奨事項」を参照してください。

ソブリン リージョン

一部のリージョンは、特定の主権実体専用です。 すべてのリージョンは Azure リージョンですが、こうした主権リージョンは他の Azure から分離されています。 Microsoft が必ずしもこれらを管理しているわけではなく、特定の種類の顧客に限定される場合もあります。 このような主権リージョンは、Azure China 21Vianet と Azure Government - US です。 主権リージョンは、他の Azure リージョンと同じ回復性標準に基づいて構築されています。

リージョン サービスの可用性と容量を検討する

Azure には、次の 2 種類のリージョンが用意されています。

  • "推奨" リージョンは、ほとんどのワークロードに適しています。
  • "代替" リージョンは、プライマリ ワークロード用に最適化されていません。 代わりに、代替リージョンは、バックアップまたはフェールオーバー用、または定義された国または地域内に会社が存在する顧客用としてのみ使用できます。

リージョンを決定するときは、次の利点があるため、可能であれば推奨リージョンを選択することをお勧めします。

  • 通常、推奨リージョンの容量は大きくなります。 推奨リージョンは代替リージョンよりも容量が大きいため、多くの場合、長期的な成長をサポートできます。
  • コストが削減されます。 多くの推奨リージョンでは、さまざまな Azure サービスがより低コストで提供されます。 推奨リージョンを使用すると、全体的な Azure の請求額を削減できる可能性があります。
  • 最新のオファリングに早期にアクセスできます。 たとえば、AI 機能と GPU リソースは通常、推奨リージョンの方が他のリージョンよりも早く利用可能になります。 

Microsoft では、推奨するリージョンを定期的に再評価しています。 新しい推奨リージョンの利点を活用するには、マルチリージョン戦略採用することを検討してください。 この戦略は、独自のワークロードにさらに多くのリージョンを使用できるようにするのに役立ちます。

リージョンにデプロイできるサービスは、他の要因の中でも特にリージョンの種類によって異なります。 詳細については、次のリソースを参照してください。

一部のリージョンは、国または地域内でディザスター リカバリーを必要とするお客様のために予約されています。 これらの予約されたアクセス領域へのアクセスを要求するには、新しいサポート リクエストを作成します。

Azure は非常にスケーラブルなプラットフォームですが、各リージョンには最大容量があります。 リージョンの最大容量は、どの種類のサブスクリプションが、どのような種類のサービスを、どのような状況でデプロイできるかに影響を与える可能性があります。 リージョンの容量は、サブスクリプションのクォータとは異なります。 Azure へのデプロイまたは移行を計画している場合は、ローカルの Azure フィールド チームまたは Azure アカウント マネージャーに相談することをお勧めします。 必要な規模で導入できることを確認してください。

ディザスター リカバリーの目的でリージョンを使用する場合は、宛先リージョンで、ワークロードをサポートするために必要な容量が提供されるかどうかを検討します。 仮想マシン (VM) に基づくワークロードの場合、使用するリージョンでの容量の可用性を保証するために、容量予約の使用を検討します。

データ所在地について

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

独自のデータ所在地要件を必ず把握してください。 また、選択する Azure リージョンが、要件を満たす地理的な場所にあることも確認します。 詳細については、「Microsoft Azure リージョンでのデータ所在地とデータ保護の有効化」を参照してください。

データ所在地に関する課題に対処することは、世界規模で事業を展開する組織にとって、クラウドに移行する大きな動機となっています。 データ主権のコンプライアンスを維持するために、一部の組織は、選択した地域のクラウド プロバイダーに、重複した IT 資産をデプロイすることを選択しています。

Microsoft Cloud for Sovereignty は、主権、コンプライアンス、セキュリティ、ポリシーに関する行政固有の要件を満たしながら、行政機関がワークロードを Microsoft Cloud に展開できるようにするソリューションです。 Microsoft Cloud for Sovereignty は、ハードウェアベースの機密性と暗号化制御を使用して、政府が必要とする追加の保護を確立するために、クラウドにソフトウェア境界を作成します。 詳細については、「Microsoft Cloud for Sovereignty の機能」を参照してください。

リージョンの近接性を考慮する

Azure サービスにアクセスする必要があるユーザーまたはサービスは、世界中のさまざまな地域に存在する可能性があります。 同様に、Azure サービスは、さまざまな地域にある外部ソースからのサービスを利用することが必要な場合があります。 または、サービスをオンプレミスのシステムに接続することが必要な場合もあります。

近接性は、Azure リージョンを選択するときに考慮すべき重要な要素です。 Azure ExpressRoute を使用してオンプレミスのシステムに接続する場合、オンプレミスのシステムに近いリージョンを使用すると、ネットワーク接続を最適化し、待機時間を短縮できます。 それ以降の Azure リージョン間の接続には、高速の Microsoft グローバル ネットワークが使用されます。

Azure リージョンと他の地理的領域間の待機時間の詳細については、「Azure ネットワーク ラウンドトリップ待ち時間統計」を参照してください。

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

複数の地理的リージョンで運用するのは、組織にとって一般的なことです。 組織は、複数の Azure リージョンを使用すると、次の利点を得ることができます。

  • 異なるリージョンで異なるワークロードを実行する。 この理由は、特定の顧客ベースまたはビジネス パートナーに近いリージョンで運用したい場合に当てはまります。 これは、特定の Azure リージョンで利用できない Azure サービスを使用する場合にも関係します。
  • 地理的に分散しているユーザー ベースをサポートする。 複数の国で事業を展開している場合、または顧客が複数の国からサービスを使用している場合、それぞれの場所に Azure リソースを配置することは理にかなっています。 または、単一のリージョンを使用し、Azure Front Door を使用して、そのリージョンへのグローバル トラフィックを高速化することも検討できます。
  • データ主権要件に準拠する。 組織では、特定のデータを格納できる地理的領域に制限が課される場合があります。
  • 高い回復性を実現する (特にビジネス クリティカルなワークロードの場合)。 ビジネス クリティカルなワークロードには、高可用性や、リージョン全体の停止や災害からの保護など、可用性ゾーンによって提供されるベネフィットが必要です。
  • ネットワークの接続性とパフォーマンスを向上する。 ハイブリッドまたはマルチクラウドのシナリオでは、複数の Azure リージョンを使用すると、ネットワーク パフォーマンスの向上に役立ちます。 トラフィックは、オンプレミスのシステムまたは別のクラウド プロバイダーの場所に近い場所で、Microsoft の高速バックボーン ネットワークに出入りできます。 マルチクラウド ソリューションの詳細については、「他のクラウド プロバイダーへの接続」を参照してください。
  • コストの最適化。 Azure リソースの種類が異なると、リージョンによって価格が異なる場合があります。 料金計算ツールや Azure サービスの価格情報などのツールを使用する場合は、正確な価格情報を表示するために必ず適切なリージョンを選択してください。 開発環境とテスト環境を別のリージョンにデプロイすると、コストを削減できる場合があります。 ただし、運用リージョンで使用する機能とサービスがそのリージョンで提供されていることを確認する必要があります。
  • リソース クォータを超えてスケーリングする。 一部の Azure リソースには、各サブスクリプションに基づいて各リージョンに作成できるリソースのインスタンス数を制限するクォータと制限があります。 これらの制限を超えてスケーリングするには、追加のサブスクリプションまたは複数のリージョンを使用することが必要な場合があります。
  • 容量の制限は避けてください。 リージョンに容量制限が適用される場合があります。 複数のリージョンを使用する場合は、デプロイするサービスをサポートするリージョンを見つけて使用する方がおそらく簡単でしょう。 1 つのリージョンを使用していて、容量制限を回避するためだけに 2 つ目のリージョンに拡張する必要がある場合は、リソースの準備とデプロイにさらに時間がかかる可能性があります。
  • マルチクラウド デプロイと比較して複雑さが軽減します。 マルチリージョン デプロイの管理の複雑さは通常、マルチクラウド デプロイよりも少なく、多くの場合、同様の可用性と回復性の利点を得ることができます。 ただし、2 つの方法のどちらを選択するかは、組織の具体的な目標によって異なります。

複数の地理的リージョンにまたがるクラウド環境を運用している場合は、次の要素を考慮してください。

  • 操作の複雑さ。 異なるリージョンに複数のリソースがある場合、追加の運用上のオーバーヘッドが発生する可能性があります。 リージョン間でリソースを複製する場合は、追加のコストを支払う必要がある場合もあります。
  • データの同期。 リージョン間でデータを同期またはレプリケートする必要があるかどうかを判断します。 その必要があれば、非同期または同期のどちらで行うかを判断します。 複数リージョンのデータ ストレージ層の構成は複雑になる場合があります。 回復性、パフォーマンス、コストのトレードオフを考慮する必要があります。
  • グローバル ネットワーク トポロジ。 Azure には、さまざまなネットワーク サービスが用意されています。 また、Azure では、さまざまな要件を満たし、さまざまなトレードオフを提供するために、さまざまなグローバル ネットワーク トポロジの実装もサポートされています。 たとえば、Azure Virtual WAN を使用して Azure ネットワークを複数のリージョンに拡張できます。また、多少手を加えて従来のハブアンドスポーク モデルを使用することもできます。
  • ユーザー アクセス プロファイル。 1 人のユーザーが複数のリージョンのコンポーネントを使用する場合、その ID とアクセスのプロファイルをリージョン間で管理する方法を把握します。
  • コンプライアンス要件。 各リージョンで、データ主権の要件を含むコンプライアンス要件が満たされていることを確認します。
  • リージョンの回復性。 複数リージョン アーキテクチャの使用は回復性の向上に役立ちますが、各リージョン内で高可用性を実現するようにソリューションを設計する必要もあります。 可能な限り可用性ゾーンを使用し、各リージョン内で高い回復性を実現する方法を必ず検討してください。
  • フェールオーバーする。 回復性を目的として複数のリージョンを使用する場合、アクティブ/パッシブ アプローチを使用するようにソリューションを設計できます。 このアプローチでは、リージョンの停止を検出し、リージョン間のトラフィックをフェールオーバーする必要があります。 フェールオーバー プロセスで停止が検出され、トラフィック ルーティングが完了するまでに時間がかかる場合があり、その結果、サービスのダウンタイムが発生する可能性があります。 一部の組織では、フェールオーバーに依存するのを避け、アクティブ/アクティブ パターンでのデプロイを選択しています。 アクティブ/アクティブ パターンを使用する利点には、グローバル負荷分散、フォールト トレランスの向上、ネットワーク パフォーマンスの向上などがあります。 このパターンを利用するには、アプリケーションで、複数のリージョンでの同時実行をサポートする必要があります。

リージョン間で再配置する

場合によっては、リソースまたはワークロードをある Azure リージョンから別のリージョンに再配置することが必要な場合があります。 ビジネス要件の変更、企業買収、データ所在地に関する法律などの要因が、再配置が必要になる理由です。

ヒント

リージョン間でのリソースの再配置は複雑になる可能性があります。 可能であれば、最初からリソースを適切なリージョンにデプロイすることを目指します。

Azure では、いくつかのツールとさまざまな再配置機能が用意されていますが、詳細は Azure サービスごとに異なります。 一部のリソースの種類はリージョン間で直接移動できますが、その他の種類は、Azure Resource Mover を使用すると移動することができます。 移動できないリソースの種類もあり、その場合は再デプロイする必要があります。

リージョン間での再配置の詳細については、「クラウド ワークロードを再配置する」を参照してください。

リージョン間での高可用性とディザスター リカバリー

Azure リージョンは高可用性です。 Azure サービス レベル アグリーメントは、特定のリージョンで実行されるサービスに適用されます。 このセクションでは、回復性を向上するために複数のリージョンにデプロイすることを選択した場合に適用されるいくつかの考慮事項について説明します。

警告

ビジネス クリティカルなワークロードを設計する場合、必ずリージョンの障害を考慮して計画し、1 つのリージョンだけにデプロイしないようにしてください。 また、復旧と軽減の手順を練習する必要もあります。 詳細については、「ミッションクリティカルなワークロード」を参照してください。

Azure サービスの回復性機能について

多くのサービスとしてのプラットフォーム (PaaS) サービスは、独自のリージョン回復性ソリューションに依存しています。 たとえば、Azure SQL Database と Azure Cosmos DB をデプロイすると、データをより多くのリージョンに簡単にレプリケートできます。 他のサービスは単一のリージョンにデプロイされるため、それらを他のリージョンに手動でデプロイする必要があります。 また、Azure DNS や Azure Front Door などの一部の Azure サービスはグローバルにデプロイされており、リージョンの依存関係はありません。

クラウド導入プロセスで検討する Azure サービスごとに、必要なフェールオーバー機能と復旧手順を把握します。

Azure リソース グループのデプロイを計画する

最も信頼性の高いシナリオとしては、リージョンの停止の影響を最小限に抑えるためにも、リソース グループと同じリージョンにリソースを配置することをお勧めします。 詳細については、「リソース グループの場所の配置」を参照してください。

同じリソース グループ内の異なるリージョンにリソースがある場合は、リソースを新しいリソース グループまたはサブスクリプションに移動することを検討してください。

リソースが別のリソース グループへの移行をサポートしているかどうかを判断するには、リソースを相互参照して一覧を作成します。 適切な前提条件を満たしていることを確認してください。

ヒント

可能な限り、複数の可用性ゾーンがあるリージョンにリソース グループをデプロイします。 可用性ゾーンは、リージョンの停止により、リソースの可用性が低下し、管理操作も使用できなくなるリスクを最小限に抑えるのに役立ちます。

場合によっては、リソース グループ内のリソースは複数のリージョンに渡ります。 リージョン全体が利用できない場合、利用できないリージョンのリソース グループ内にあるリソースに関係するすべての管理操作は失敗する可能性があります。 ただし、別のリージョンにデプロイされているリソースは、それらを管理できない場合でも使用できる可能性があります。 一部のシナリオでは、リソースが常に使用可能になるように、リソース グループを複数のリージョンに配置する場合があります。 この方法には制限がありますが、一時的な障害が起こっても、リソースの可用性が維持されます。

ペアになっているリージョンで GRS を使用する

関連付けられたペアのリージョンがあるリージョンにデプロイする場合、そのペアになっているリージョンを複数リージョンの回復性戦略の一部として使用できます。 ペアのリージョンを使用すると、プライマリ リージョンとセカンダリ リージョンを使用できます。

Azure Storage では GRS がサポートされています。 Storage の GRS では、データの 3 つのコピーがプライマリ リージョンに格納され、さらに 3 つのコピーが、ペアになっているリージョンに格納されます。 GRS のストレージ ペアリングを変更することはできません。 Storage に依存する他の Azure サービスでは、多くの場合、このペア リージョンの機能を利用できます。 アプリケーションとネットワークを、ペアになっているリージョンをサポートし、GRS ストレージを適宜使用するように構成する必要があります。

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

ヒント

複数リージョンのソリューションでは、Storage GRS を使用する必要はありません。 代わりに、次のような他のオプションを使用できます。

これらのシナリオでは、セカンダリ リージョンを選択する際、ペアになっているリージョン以外のリージョンの使用を検討します。 プライマリ リージョンでリージョン障害が発生した場合、リソースが移行され、リージョン間のフェールオーバーが発生すると、ペアになっているリージョンのリソースに大きな負荷がかかります。 代替リージョンに回復すると、その負荷を回避できます。つまり、復旧時の速度が向上します。

ペアのないリージョンにデプロイする

新しい Azure リージョンには、リージョン ペアがありません。 これらのリージョンでは、可用性ゾーンを使用して高可用性を実現します。 このようなリージョンでは、リージョンにデータを格納するオプションを提供するデータ回復性ガイドラインに従います。

これらのリージョンを使用する場合、ローカル冗長ストレージ (LRS) またはゾーン冗長ストレージ (ZRS) を使用できます。 ペアのないリージョンでは、GRS はサポートされません。 Storage に依存する Backup などのサービスでは、ZRS または LRS ストレージの使用も必要になる場合があります。 可能な場合、リージョン内の回復性を向上するために、ZRS を使用することをお勧めします。

Azure リージョン全体が使用できなくなるというまれなイベントに備えるには、リージョン間のディザスター リカバリーを計画する必要があります。 少なくとも、自動化アプローチを使用してインフラストラクチャをデプロイし、リージョン間でデータをバックアップすることをお勧めします。 リージョン全体の停止が発生した場合、リソースを手動で再デプロイし、バックアップを復元できます。 一部のシナリオについては、復旧時間とデータ損失の可能性を低減するための他の代替手段を検討することが必要な場合があります。 詳細については、「サービスとリージョンの可用性ゾーンのサポート」および「Azure の回復性 - 事業継続とディザスター リカバリー」を参照してください。

データの回復性のニーズについて検討します。 データがある場所に関係なく、世界中のどの場所からでもデータを移動、コピー、またはアクセスできます。

一部の Azure サービスでは、リージョンをペアにすることなく複数のリージョンにデータを格納またはレプリケートする方法が提供されます。 次に例を示します。

次のステップ

既存のワークロードをオンプレミスのデータセンターから Azure に移行する場合、リージョンの選択について留意する必要がある考慮事項が他にもいくつかあります。 詳細については、「移行する Azure リージョンを選ぶ」を参照してください。