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

2024-07-29

適用対象: Premium

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

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

リージョンがホストするスケールユニットの数。
オプションの可用性ゾーン (そのリージョンでサポートされている場合)。
既存のリージョンでネットワークが構成されている場合は、追加されたリージョンの仮想ネットワーク設定。

重要

顧客データを 1 つのリージョンに格納できるようにする機能は、現在のところ、アジア太平洋地域の東南アジアリージョン (シンガポール) でのみ使用できます。その他のすべてのリージョンでは、顧客データは geo 内に格納されます。

重要

API Management サービスのインフラストラクチャ (カスタムドメインの構成、CA 証明書の追加、スケーリング、仮想ネットワーク構成、可用性ゾーンの変更、リージョンの追加など) の変更は、サービスレベルとデプロイのサイズによっては、完了するまでに 15 分以上かかることがあります。スケールユニットまたはマルチリージョン構成の数が多いインスタンスの場合、より長い時間が予想されます。 API Management へのローリング変更は、容量と可用性を維持するために慎重に実行されます。

サービスの更新中は、他のサービスインフラストラクチャの変更を行うことはできません。ただし、API、製品、ポリシー、およびユーザー設定を構成できます。サービスではゲートウェイのダウンタイムが発生せず、API Management は中断することなく API 要求に サービスを提供し続けます (開発者レベルを除く)。

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

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 要求を処理します。
構成されている場合、レート制限ポリシーとキーごとのレート制限ポリシーは、デプロイ内の各リージョンゲートウェイで個別に呼び出しをカウントします。ポリシーでは、インスタンスのすべての呼び出しデータが集計されるわけではありません。同様に、 azure-openai-token-limit ポリシーと llm-token-limit ポリシーは、デプロイ内の各リージョンゲートウェイで個別にトークンの使用状況をカウントします。

前提条件

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

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

Azure portal で、API Management サービスに移動し、左側のメニューから [場所 ] を選択します。
上部のバーで [ + 追加] を選択します。
ドロップダウンリストから、追加した場所を選択します。
場所のスケール ユニット の数を選択します。
必要に応じて、1 つ以上 の可用性ゾーンを選択します。
API Management インスタンスが仮想ネットワークにデプロイされている場合は、仮想ネットワーク、サブネット、パブリック IP アドレスを含む場所で仮想ネットワーク設定を構成します (可用性ゾーンを有効にする場合)。
[ 追加] を選択して確定します。
すべての場所を構成するまで、この手順を繰り返します。
上部のバーで [保存] を 選択して、デプロイプロセスを開始します。

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

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

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

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

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

Azure API Management インスタンスに移動し、左側のメニューから API を 選択します。
目的の API を選択します。
[受信処理] の矢印ドロップダウンから [コードエディター] を選択します。

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 に転送し、ルーティングを自動的に解決することもできます。

トラフィックの分散とフェールオーバーには、 地理的 ルーティング方法で Traffic Manager を使用することをお勧めします。 API Management バックエンドで重み付け型ルーティング方法を採用して Traffic Manager を使うことはお勧めしません。
メンテナンス作業中のトラフィック制御には、優先度型ルーティング方法を使うことをお勧めします。

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

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

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

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

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

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

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

注

リージョンゲートウェイへのルーティングを無効にできるのは、カスタムのルーティングソリューションではなく、API Management の既定のルーティングを使用している場合のみです。

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

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

az apim update コマンドを使用して、使用可能な場所 (米国西部 2 など) でゲートウェイを無効にします。
```
az apim update --name contoso --resource-group apim-hello-world-resource \
--set additionalLocations[___location="West US 2"].disableGateway=true
```
更新には数分かかる場合があります。
リージョンゲートウェイ URL に送信されたトラフィックが別のリージョンにリダイレクトされることを確認します。

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

仮想ネットワーク

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

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

重要

内部 VNet モードで構成する場合、各リージョンゲートウェイは、ポート 1433 で、"プライマリ" リージョンにのみ存在する API Management インスタンス用に構成された Azure SQL データベースへの送信接続も必要です。セカンダリリージョンのネットワークに対して構成したルートまたはファイアウォール規則で、この Azure SQL データベースの FQDN または IP アドレスへの接続を許可していることを確認します。このシナリオでは、Azure SQL サービスタグは使用できません。プライマリリージョンで Azure SQL データベース名を見つけるには、ポータルで API Management インスタンスの [ネットワーク>ネットワークの状態 ] ページに移動します。

IP アドレス

パブリック仮想 IP アドレスは、仮想ネットワークで追加されたすべてのリージョンに作成されます。外部モードまたは内部モードの仮想ネットワークの場合、このパブリック IP アドレスはポート 3443の管理トラフィックに使用されます。
- 外部 VNet モード - パブリック HTTP トラフィックを API ゲートウェイにルーティングするには、パブリック IP アドレスも必要です。
- 内部 VNet モード - プライベート IP アドレスは、仮想ネットワークで追加されたすべてのリージョンにも作成されます。これらのアドレスを使用して、ネットワーク内でプライマリリージョンとセカンダリリージョンの API Management エンドポイントに接続します。

ルーティング

外部 VNet モード - リージョンゲートウェイへのパブリック HTTP トラフィックのルーティングは、ネットワークに接続されていない API Management インスタンスの場合と同じように、自動的に処理されます。
内部 VNet モード - プライベート HTTP トラフィックは、既定ではリージョンゲートウェイにルーティングまたは負荷分散されません。ユーザーは、ルーティングを所有しており、複数のリージョン間でルーティングとプライベート負荷分散を管理するための独自のソリューションを提供する責任があります。

高可用性のために API Management を構成する方法について説明します。
リージョン内の API Management インスタンスの可用性を向上させるために可用性ゾーンを構成する方法について説明します。
仮想ネットワークと API Management の詳細については、次を参照してください。

次の方法で共有

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

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

前提条件

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

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

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

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

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

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