複数の Azure リージョンに Azure API Management サービス インスタンスをデプロイする方法

適用対象: Premium

Azure API Management では、複数リージョンの展開がサポートされています。これにより、API パブリッシャーは、サポートされている 1 つ以上の Azure リージョン内の既存の API Management インスタンスにリージョン API ゲートウェイを追加できます。 複数リージョンの展開により、地理的に分散した API コンシューマーによって認識される要求待ち時間が短くなり、1 つのリージョンがオフラインになった場合でもサービスの可用性を向上できます。

リージョンを追加するときは、次の要素を構成します。

• リージョンがホストするスケール ユニットの数。

• オプションの Availability Zones (そのリージョンでサポートされている場合)。

• 既存のリージョンまたはリージョンでネットワークが構成されている場合は、追加されたリージョンの仮想ネットワーク設定。

複数リージョン デプロイについて

• API Management インスタンスのゲートウェイ コンポーネントのみが複数のリージョンにレプリケートされます。 インスタンスの管理プレーンと開発者ポータルは、最初にサービスをデプロイしたリージョンであるプライマリ リージョンのみでホストされたままになります。

• 仮想ネットワークにデプロイ (挿入) されたときに API Management インスタンスのセカンダリの場所を構成する場合、VNet とサブネットリージョンは、構成しているセカンダリの場所と一致する必要があります。 プライマリ リージョンで可用性ゾーンを追加、削除、有効化する場合、またはプライマリ リージョンのサブネットを変更する場合は、API Management インスタンス の VIP が変更されます。 詳細については、Azure API Management サービスの IP アドレスに関するページを参照してください。 ただし、セカンダリ リージョンを追加する場合、すべてのリージョンには独自のプライベート VIP があるため、プライマリ リージョンの VIP は変更されません。

• API やポリシー定義などのゲートウェイ構成は、プライマリ リージョンと、追加するセカンダリ リージョンとの間で定期的に同期されます。 リージョン ゲートウェイへの更新の反映には通常、10 秒未満かかります。 複数リージョンのデプロイでは、複数のリージョンで API ゲートウェイを利用でき、1 つのリージョンがオフラインになった場合にサービスの可用性を提供できます。

• API Management がトラフィック マネージャー エンドポイントへのパブリック HTTP 要求 (外部 VNet および API Management のネットワークに接続されていないモードを要求) を受信すると、最も短い待機時間に基づいてリージョン ゲートウェイにトラフィックがルーティングされるため、地理的に分散された API コンシューマーで発生する待機時間が短縮されます。 内部 VNet モードでは、お客様は独自のソリューションを構成して、複数のリージョン ゲートウェイにわたってトラフィックをルーティングし、負荷分散する必要があります。 詳細については、「ネットワークに関する考慮事項」を参照してください。

• 各リージョン (プライマリ リージョンを含む) のゲートウェイには、https://<service-name>-<region>-01.regional.azure-api.net の URL パターンに従うリージョン DNS 名があります (例: https://contoso-westus2-01.regional.azure-api.net)。

• リージョンがオフラインになった場合、API 要求は、障害が発生したリージョンを迂回して、次に最も近いゲートウェイに自動的にルーティングされます。

• プライマリ リージョンがオフラインになると、API Management 管理プレーンと開発者ポータルは使用できなくなりますが、セカンダリ リージョンは最新のゲートウェイ構成を使用して引き続き API 要求を処理します。

前提条件

• API Management サービス インスタンスを作成していない場合は、API Management サービス インスタンスの作成に関するページを参照してください。 Premium サービス レベルを選択します。
• API Management インスタンスが仮想ネットワークにデプロイされる場合は、同じサブスクリプション内で、追加する予定の場所に仮想ネットワークとサブネットを設定します。 仮想ネットワークの前提条件に関するページを参照してください。

追加のリージョンに API Management サービスをデプロイする

1. Azure portal で、API Management サービスに移動し、左のメニューの [場所] を選択します。
2. 上部バーにある [+ 追加] を選択します。
3. ドロップダウン リストから、追加した場所を選択します。
4. その場所のスケール ユニット の数を選択します。
5. オプションで、1 つまたは複数の [可用性ゾーン] を選択します。
6. API Management インスタンスが仮想ネットワークにデプロイされている場合は、その場所に、仮想ネットワーク、サブネット、およびパブリック IP アドレス (可用性ゾーンを有効にする場合) などの仮想ネットワーク設定を構成します。
7. [追加] を選択して確定します。
8. すべての場所を構成するまで、この手順を繰り返します。
9. 上部バーにある [保存] を選択して、デプロイ プロセスを開始します。

API Management サービス リージョンを削除する

1. Azure portal で、API Management サービスに移動し、左のメニューの [場所] を選択します。
2. テーブルの右端にある [...] ボタンを使用して、削除する場所のコンテキスト メニューを選択します。 [削除] を選択します。
3. 削除されたことを確認したら、[保存] を選択して変更を適用します。

リージョンのバックエンド サービスに API 呼び出しをルーティングする

既定では、各 API によって、1 つのバックエンド サービスの URL に要求がルーティングされます。 複数のリージョンに Azure API Management ゲートウェイを構成した場合でも、API ゲートウェイは、1 つのリージョンのみにデプロイされる同じバックエンド サービスに要求を転送します。 この場合、要求に固有のリージョンで Azure API Management 内にキャッシュされた応答でのみパフォーマンスが向上し、グローバルなバックエンドへの接続では引き続き長い待ち時間が発生します。

システムの地理的な分散を活用するには、Azure API Management インスタンスと同じリージョンにバックエンド サービスをデプロイする必要があります。 その後、ポリシーと @(context.Deployment.Region) プロパティを使用して、バックエンドのローカル インスタンスにトラフィックをルーティングできます。

1. Azure API Management インスタンスに移動し、左側のメニューから [API] を選択します。

2. 目的の API を選択します。

3. [受信処理] で、矢印のドロップダウンから[コード エディター] を選択します。

   

4. set-backend と choose 条件ポリシーを組み合わせて使用して、ファイルの <inbound> </inbound> セクション内に適切なルーティング ポリシーを作成します。

   たとえば、次の XML ファイルは、米国西部リージョンと東アジア リージョンで機能します。

   <policies>
       <inbound>
           <base />
           <choose>
               <when condition="@("West US".Equals(context.Deployment.Region, StringComparison.OrdinalIgnoreCase))">
                   <set-backend-service base-url="http://contoso-backend-us.com/" />
               </when>
               <when condition="@("East Asia".Equals(context.Deployment.Region, StringComparison.OrdinalIgnoreCase))">
                   <set-backend-service base-url="http://contoso-backend-asia.com/" />
               </when>
               <otherwise>
                   <set-backend-service base-url="http://contoso-backend-other.com/" />
               </otherwise>
           </choose>
       </inbound>
       <backend>
           <base />
       </backend>
       <outbound>
           <base />
       </outbound>
       <on-error>
           <base />
       </on-error>
   </policies>
   

リージョン バックエンドへのルーティングに Traffic Manager を使う

バックエンド サービスの正面に Azure Traffic Manager を置き、API 呼び出しを Traffic Manager に誘導して、そこでルーティングを自動的に解決させることもできます。

• トラフィックの分散とフェールオーバーには、geography 型のルーティング方法を採用して Traffic Manager を使うことをお勧めします。 API Management バックエンドで重み付け型ルーティング方法を採用して Traffic Manager を使うことはお勧めしません。

• メンテナンス作業中のトラフィック制御には、優先度型ルーティング方法を使うことをお勧めします。

API Management リージョン ゲートウェイへのカスタム ルーティングを使用する

API Management は、最短の待ち時間に基づいてリージョン "ゲートウェイ" に要求をルーティングします。 API Management でこの設定をオーバーライドすることはできませんが、カスタム ルーティング規則を持った独自の Traffic Manager を使用することはできます。

1. 独自の Azure Traffic Manager を作成します。
2. カスタム ドメインを使用している場合、API Management サービスではなく、Traffic Manager と共に使用します。
3. Traffic Manager に API Management のリージョン エンドポイントを構成します。 リージョン エンドポイントは、https://<service-name>-<region>-01.regional.azure-api.net という URL パターンに従います (例: https://contoso-westus2-01.regional.azure-api.net)。
4. Traffic Manager に API Management のリージョン状態エンドポイントを構成します。 リージョン状態エンドポイントは、https://<service-name>-<region>-01.regional.azure-api.net/status-0123456789abcdef という URL パターンに従います (例: https://contoso-westus2-01.regional.azure-api.net/status-0123456789abcdef)。
5. Traffic Manager のルーティング方法を指定します。

リージョン ゲートウェイへのルーティングを無効にする

状況によっては、いずれかのリージョン ゲートウェイへのルーティングを一時的に無効にする必要がある場合があります。 次に例を示します。

• 新しいリージョンを追加した後、リージョンのバックエンド サービスの構成とテスト中にリージョンを無効にしておく場合
• リージョンでの定期的なバックエンド メンテナンス中
• リージョンが利用できないことをシミュレートする計画的なディザスター リカバリー訓練中、またはリージョンの障害中に、トラフィックを他のリージョンにリダイレクトする場合

API Management インスタンス内のリージョン ゲートウェイへのルーティングを無効にするには、ゲートウェイの disableGateway プロパティ値を true に更新します。 この値は、作成または更新サービスの REST API、Azure CLI の az apim update コマンド、Azure PowerShell コマンドレットの set-azapimanagement、またはその他の Azure ツールを使用して設定できます。

Azure CLI を使用してリージョン ゲートウェイを無効にするには:

1. az apim show コマンドを使用して、API Management インスタンス用に構成された場所、ゲートウェイの状態、およびリージョン URL を表示します。

   az apim show --name contoso --resource-group apim-hello-world-resource \
       --query "additionalLocations[].{Location:location,Disabled:disableGateway,Url:gatewayRegionalUrl}" \
       --output table
   

   出力例:

   Location    Disabled    Url
   ----------  ----------  ------------------------------------------------------------
   West US 2   True        https://contoso-westus2-01.regional.azure-api.net
   West Europe True        https://contoso-westeurope-01.regional.azure-api.net
   

2. az apim update コマンドを使用して、使用可能な場所 (米国西部 2 など) でゲートウェイを無効にします。

   az apim update --name contoso --resource-group apim-hello-world-resource \
   --set additionalLocations[location="West US 2"].disableGateway=true
   

   更新には数分かかる場合があります。

3. リージョン ゲートウェイ URL に送信されたトラフィックが別のリージョンにリダイレクトされることを確認します。

リージョン ゲートウェイへのルーティングを復元するには、disableGateway の値を false に設定します。

仮想ネットワーク

このセクションでは、API Management インスタンスが仮想ネットワークに挿入される場合の複数リージョン デプロイに関する考慮事項について説明します。

• 各リージョン ネットワークを個別に構成します。 追加されたリージョンの仮想ネットワークに必要なネットワーク セキュリティ グループ規則などの接続要件は、通常、プライマリ リージョンのネットワークの要件と同じです。
• 異なるリージョンの仮想ネットワークをピアリングする必要はありません。

IP アドレス

• パブリック仮想 IP アドレスは、仮想ネットワークで追加されたすべてのリージョンに作成されます。 外部モードまたは内部モードの仮想ネットワークの場合、このパブリック IP アドレスはポート 3443 上の管理トラフィックに使用されます。

  • 外部 VNet モード - パブリック HTTP トラフィックを API ゲートウェイにルーティングするには、パブリック IP アドレスも必要です。

  • 内部 VNet モード - 仮想ネットワークで追加されたすべてのリージョンにプライベート IP アドレスも作成されます。 これらのアドレスを使用して、ネットワーク内でプライマリ リージョンとセカンダリ リージョンの API Management エンドポイントに接続します。

ルーティング

• 外部 VNet モード - リージョン ゲートウェイへのパブリック HTTP トラフィックのルーティングは、ネットワークに接続されていない API Management インスタンスの場合と同様に、自動的に処理されます。

• 内部 VNet モード - プライベート HTTP トラフィックは、既定ではリージョン ゲートウェイにルーティングまたは負荷分散されません。 ユーザーは、ルーティングを所有しており、複数のリージョン間でルーティングとプライベート負荷分散を管理するための独自のソリューションを提供する責任があります。

次のステップ

• 高可用性のために API Management を構成する方法の詳細を確認してください。

• リージョン内の API Management インスタンスの可用性を向上させるための Availability Zones の構成方法の詳細を参照してください。

• 仮想ネットワークと API Management の詳細については、次を参照してください。

  • Azure API Management を使用して仮想ネットワークに接続する

  • Azure API Management を使用して内部モデルで仮想ネットワークに接続する

  • API Management の IP アドレス