stv1 プラットフォームでホストされている、VNet 挿入された API Management インスタンスを stv2 に移行する

[アーティクル]
11/04/2024

適用対象: Developer | Premium

この記事では、インスタンスが外部または内部の VNet に挿入 (配置) されている場合に、stv1 コンピューティングプラットフォームでホストされている API Management インスタンスをインプレースで stv2 プラットフォームに移行する手順について説明します。これを行う必要があるかどうかを確認してください。

Note

2024 年 8 月の新機能: VNet が挿入されたインスタンスの移行を支援するために、ポータルの移行オプションが改善されました。インスタンスをインプレースで移行し、同じサブネットと IP アドレスを保持できるようになりました。

VNet インジェクションインスタンスの場合、次の移行オプションがあります。

オプション 1: 同じサブネットを保持する - 配置を変えずにインスタンスを移行し、インスタンスの既存のサブネット構成を保持します。 API Management インスタンスの元の VIP アドレスを保持するか (推奨)、または新しい VIP アドレスを生成するかを選択できます。
オプション 2: 新しいサブネットに変更する - 同じまたは異なる VNet 内に、別のサブネットを指定してインスタンスを移行します。移行後、必要に応じてインスタンスの元のサブネットに移行し直せます。移行プロセスによって、インスタンスの VIP アドレスが変更されます。移行の後、新しい VIP アドレスを使うには、DNS、ファイアウォール規則、VNet などのネットワーク依存関係を更新する必要があります。

頻度の低い特定の条件下では、同じサブネット内で移行できない場合や、異なる動作をする場合があります。詳細については、「特別な条件とシナリオ」を参照してください。

stv1 プラットフォームでホストされている、VNnet 挿入されていない API Management を移行する必要がある場合は、「VNet に挿入されていない API Management インスタンスを stv2 プラットフォームに移行する」を参照してください。

重要

stv1 プラットフォームでホストされている API Management インスタンスのサポートは廃止処理中です。グローバル Azure では、 2024 年 8 月 31 日が廃止の期限です。 Azure Government と 21Vianet (中国の Azure) が運営する Azure では、 2025 年 2 月 24 日に廃止されます。 stv1 プラットフォームでホストされているインスタンスをご使用の場合は、サービスの中断を回避するため、この日付より前に stv2 プラットフォームへ移行してください。

注意事項

API Management インスタンスを stv2 プラットフォームに移行することは、実行時間の長い操作です。
stv2 への移行は元に戻すことはできません。

移行の間の動作

API Management プラットフォームを stv1 から stv2 に移行する際には、基になるコンピューティングのみが更新され、ストレージレイヤーに存在するサービスおよび API 構成への影響はありません。

アップグレードプロセスでは、古いコンピューティングと並行して新しいコンピューティングを作成します。これには最大 45 分かかる場合があります。複数リージョンのデプロイや、サブネットを複数回変更するシナリオでは、さらに長い時間を計画します。
Azure portal での API Management の状態は [更新中] と示されます。
特定の移行オプションでは、VIP アドレスを保持するか、新しいパブリック VIP を生成するかを選択できます。
新しい VIP アドレスが生成される移行シナリオの場合、以下のようになります。
- 移行は Azure によって管理されます。
- カスタムドメインを使っている場合は、ゲートウェイ DNS は引き続き前のコンピューティングを指します。
- カスタム DNS を使っていない場合は、ゲートウェイとポータルの DNS はすぐに新しいコンピューティングを指します。
- 内部 VNet モードのインスタンスの場合は、お客様が DNS を管理するため、DNS エントリでは、お客様が更新するまで引き続き前のコンピューティングが指し示されます。
- DNS では新しいコンピューティングか前のコンピューティングのどちらかが指し示されるため、API のダウンタイムはありません。
- 新しいコンピューティングサブネットからバックエンドにアクセスできるようにするには、ファイアウォール規則 (存在する場合) に変更を加える必要があります。
- 移行が成功し、短時間が経過した後、古いコンピューティングが自動的に使用停止になります。ポータルの [プラットフォーム移行] ブレードを使用して新しいサブネットに変更する場合、古いゲートウェイを 48 時間保持するように移行設定を有効にすることができます。 この 48 時間の遅延オプションは、VNet 挿入されたサービスでのみ使用できます。

前提条件

stv1 コンピューティングプラットフォームでホストされている API Management インスタンス。インスタンスが stv1 プラットフォームでホストされていることを確認するには、「API Management インスタンスのホストとなっているプラットフォームは、どのようにして確認できますか?」を参照してください。
現在のところ、インスタンスは外部または内部の VNet にデプロイされる必要があります。

その他の前提条件は、各移行オプションに固有で、次のセクションで確認できます。

オプション 1: 同じサブネットを保持して移行する

既存のサブネット構成を維持したまま、API Management インスタンスを stv2 プラットフォームに移行できるため、移行が簡単になります。 Azure portal の [プラットフォーム移行] ブレードまたは Stv2 への移行 REST API を使用して移行できます。

前提条件

ネットワークセキュリティグループを各サブネットにアタッチし、stv2 プラットフォーム上の API Management のために、NSG 規則を構成する必要があります。最低限の接続設定を次に示します。
- ポート 443 経由の Azure Storage への送信
- ポート 1433 経由の Azure SQL への送信
- ポート 443 経由の Azure Key Vault への送信
- ポート 6390 経由の Azure Load Balancer からの受信
- ポート 3443 経由の ApiManagement サービスタグからの受信
- API Management サービスを呼び出すクライアントのポート 80/443 経由の受信
- サブネットでは、Azure Storage、Azure SQL、Azure Key Vault に対してサービスエンドポイントが有効になっている必要があります
既存の各サブネットのアドレス空間は、移行中に既存のサービスのコピーを並列してホストするのに十分な大きさである必要があります。
ネットワークに関するその他の考慮事項。
- サブネットにデプロイされた API Management インスタンス用に構成された、すべての自動スケーリングルールをオフにします。自動スケーリングルールは、移行プロセスに干渉する可能性があります。
- 同じサブネットに複数の API Management インスタンスがある場合は、各インスタンスを順番に移行します。同じサブネット内の異なるプラットフォームでホストされているインスタンスについての問題が発生しないようにするため、サブネット内のすべてのインスタンスを迅速に移行することをお勧めします。

Azure Cloud Shell で Bash 環境を使用します。詳細については、「Azure Cloud Shell の Bash のクイックスタート」を参照してください。
CLI リファレンスコマンドをローカルで実行する場合、Azure CLI をインストールします。 Windows または macOS で実行している場合は、Docker コンテナーで Azure CLI を実行することを検討してください。詳細については、「Docker コンテナーで Azure CLI を実行する方法」を参照してください。
- ローカルインストールを使用する場合は、az login コマンドを使用して Azure CLI にサインインします。認証プロセスを完了するには、ターミナルに表示される手順に従います。その他のサインインオプションについては、Azure CLI でのサインインに関するページを参照してください。
- 初回使用時にインストールを求められたら、Azure CLI 拡張機能をインストールします。拡張機能の詳細については、Azure CLI で拡張機能を使用する方法に関するページを参照してください。
- az version を実行し、インストールされているバージョンおよび依存ライブラリを検索します。最新バージョンにアップグレードするには、az upgrade を実行します。

パブリック IP アドレスオプション - 同じサブネットの移行

API Management インスタンスの元の VIP アドレスを保持するか (推奨)、または新しい VIP アドレスを生成するかを選択できます。

仮想 IP アドレスの保持 - 外部モードの VNet で VIP アドレスを保持する場合は、移行中も API 要求の応答性を維持できます (「想定されるダウンタイム」を参照)。内部モードの VNet の場合、一時的なダウンタイムが想定されます。インフラストラクチャの構成 (カスタムドメイン、場所、CA 証明書など) は 45 分間ロックされます。移行後にそれ以上の構成は必要ありません。

このオプションを使用すると、移行の完了後、 stv1 コンピューティングは完全に削除されます。これを一時的に保持するオプションはありません。

次の図は、IP アドレスが保持された場合の動作の概要を示しています。
新しい仮想 IP アドレス - このオプションを選択すると、API Management によってインスタンスの新しい VIP アドレスが自動生成されます。移行中も API 要求への応答は維持されます。インフラストラクチャの構成 (カスタムドメイン、場所、CA 証明書など) は 30 分間ロックされます。移行後に、新しい VIP アドレスを使うには、DNS、ファイアウォール規則、VNet などのネットワーク依存関係を更新する必要があります。

このオプションを使用すると、移行完了後、既定で stv1 コンピューティングが短期間保持されるため、移行されたインスタンスを検証し、ネットワークと DNS の構成を確認できます。

次の図は、新しい IP アドレスが生成された場合の動作の概要を示しています。

移行用に事前に作成された IP アドレス

パブリック IP アドレスによって到達可能な API Management インスタンスの場合、API Management は、移行プロセスのパブリック IP アドレスを事前に作成します。事前に作成された IP アドレスは、API Management インスタンスのプロパティの JSON 出力で確認できます。 customProperties において、事前作成 IP アドレスは Microsoft.WindowsAzure.ApiManagement.Stv2MigrationPreCreatedIps プロパティの値です。マルチリージョンのデプロイの場合、この値は事前に作成された IP アドレスのコンマ区切りのリストです。

事前に作成された IP アドレスを使用すると、移行プロセスの管理に便利です。

VIP アドレスを保持して移行する場合は、元の IP アドレスが stv2 デプロイに割り当てられる前に、事前に作成された IP アドレスが新しい stv2 デプロイに一時的に割り当てられます。たとえば、API Management インスタンスにアクセスを制限するファイアウォール規則がある場合は、事前作成 IP アドレスを許可リストに追加すると、移行中もクライアントアクセスの継続性を維持できます。移行が完了したら、この事前作成 IP アドレスを許可リストから削除できます。
移行の際に新しい VIP アドレスを生成する場合は、移行中に事前作成 IP アドレスが新しい stv2 デプロイに割り当てられ、移行が完了した後も保持されます。事前作成 IP アドレスを使用して DNS やファイアウォール規則などのネットワーク依存関係を更新し、新しい IP アドレスを指すように変更します。

想定されるダウンタイムとコンピューティング保持期間

同じサブネット構成を維持して VNet インジェクションのインスタンスを移行する場合、API ゲートウェイで発生するダウンタイムは最小限になるか、まったくなくなります。次の表は、同じサブネットを保持する場合の各移行シナリオで予想される、ダウンタイムと stv1 コンピューティングのリテンション期間をまとめたものです。

VNet モード	パブリック IP オプション	想定されるダウンタイム	`stv1` コンピューティングリテンション期間
外部	VIP を保持	ダウンタイムなし。新しい `stv2` デプロイへの移行中、トラフィックは最大 20 分間、一時的な IP アドレスで処理されます	リテンション期間なし
外部	新しい VIP	ダウンタイムなし	ネットワークの依存関係を更新できるように、既定で 15 分間保持されます
Internal	VIP を保持	移行中、既存の IP アドレスが新しい `stv2` デプロイに割り当てられている間に、約 20 分間のダウンタイムが発生します。	リテンション期間なし
Internal	新しい VIP	ダウンタイムなし	ネットワークの依存関係を更新できるように、既定では 15 分間保持されます。ポータルを使用すると、48 時間に延長できます

Azure portal で、API Management インスタンスに移動します。
左側のメニューの [設定] で、[Platform migration] (プラットフォームの移行) を選びます。
[移行オプションの選択] で、[同じサブネットを保持する] を選択します。
[IP アドレスオプションの選択] で、2 つの IP アドレスオプションのいずれかを選択します。

Note

VNet が外部モードの場合は、移行プロセス用に事前に作成されたパブリック IP アドレスをメモしておきます。このアドレスを使用して、移行されたインスタンスのネットワーク接続を構成します。
(内部モードで挿入され、新しい VIP に移行するインスタンスの場合) [要件に合ったシナリオを選択] で、移行後に一定期間、元の stv1 コンピューティングを維持するかどうかに応じて 2 つのオプションのいずれかを選択します。
[検証] を選択して、サブネット上で自動チェックを実行します。問題が検出された場合は、サブネット構成を調整し、もう一度チェックを実行します。 DNS やファイアウォール規則などの他のネットワーク依存関係については、手動で確認します。
移行することを確認し、[移行の開始] を選択します。 API Management インスタンスの状態が [更新中] に変わります。移行プロセスは、完了するまで約 45 分かかります状態が [オンライン] に変わると、移行完了です。

移行スクリプト

次の Azure CLI コマンドを実行し Stv2 への移行 API を呼び出し、API Management インスタンスの名前とそれが作成されているリソースグループの名前とともに表示されている変数を設定します。

Note

bash シェル用に次のスクリプトが記述されています。 PowerShell でスクリプトを実行するには、変数を設定する際に、変数名の前に $ 文字を付けます。例: $APIM_NAME=...。

APIM_NAME={name of your API Management instance}
# In PowerShell, use the following syntax: $APIM_NAME={name of your API Management instance}
RG_NAME={name of your resource group}
# Get resource ID of API Management instance
APIM_RESOURCE_ID=$(az apim show --name $APIM_NAME --resource-group $RG_NAME --query id --output tsv)
# Call REST API to migrate to stv2 and preserve VIP address
az rest --method post --uri "$APIM_RESOURCE_ID/migrateToStv2?api-version=2023-03-01-preview" --body '{"mode": "PreserveIp"}'
# Alternate call to migrate to stv2 and change VIP address
# az rest --method post --uri "$APIM_RESOURCE_ID/migrateToStv2?api-version=2023-03-01-preview" --body '{"mode": "NewIp"}'

API Management インスタンスの状態が [更新中] に変わります。移行プロセスは、完了するまで約 45 分かかります状態が [オンライン] に変わると、移行完了です。

Note

API Management インスタンスが複数のリージョンにデプロイされている場合、REST API は 1 回の呼び出しを使用して、インスタンスのすべての場所の VNet 設定を移行します。

オプション 2: 新しいサブネットに変更して移行する

Azure portal を使用すると、同じまたは異なる VNet 内の別のサブネットを指定することで、インスタンスを移行できます。移行後、必要に応じてインスタンスの元のサブネットに移行し直せます。

次の図は、新しいサブネットへ移行中に何が起こるかの概要を示しています。

新しいサブネットへのインプレース移行の図。

前提条件

API Management インスタンスが配置されている各リージョンにおける、現在の仮想ネットワーク内の新しいサブネット。 (または、API Management インスタンスと同じリージョンおよびサブスクリプション内の別の仮想ネットワークにサブネットを設定します)。ネットワークセキュリティグループを各サブネットにアタッチし、stv2 プラットフォーム上の API Management のために、NSG 規則を構成する必要があります。
(省略可能) API Management インスタンスと同じリージョンおよびサブスクリプションにある新しい Standard SKU パブリック IPv4 アドレスリソース。詳細については、「ネットワーク接続の前提条件」を参照してください。

重要

2024 年 5 月以降、内部モードの VNet に API Management インスタンスをデプロイ (インジェクション) するとき、または内部 VNet 構成を新しいサブネットに移行するときに、パブリック IP アドレスリソースは "不要になります"。外部 VNet モードでは、パブリック IP アドレスの指定は "オプション" です。指定しない場合は、Azure マネージドパブリック IP アドレスが自動的に構成され、ランタイム API トラフィックに使用されます。インターネットの受信または送信コミュニケーションに使用されるパブリック IP アドレスを所有および制御したい場合にのみ、パブリック IP アドレスを指定します。

移行手順 - 新しいサブネットに変更する

Azure portal で、API Management インスタンスに移動します。
左側のメニューの [設定] で、[Platform migration] (プラットフォームの移行) を選びます。
[移行オプションの選択] で、[新しいサブネットに変更] を選択します。
[要件に合ったシナリオを選択] で、移行後に一定期間、元の stv1 コンピューティングを維持するかどうかに応じて 2 つのオプションのいずれかを選択します。
[場所ごとに移行設定を定義する] で、以下を行います。
1. 移行する場所を選択します。
2. 移行先の [仮想ネットワーク]、[サブネット]、オプションの [パブリック IP アドレス] を選択します。
[サブネットが移行要件を満たしていることを検証する] で、[検証] を選択してサブネットで自動チェックを実行します。問題が検出された場合は、サブネット構成を調整し、もう一度チェックを実行します。 DNS やファイアウォール規則などの他のネットワーク依存関係については、手動で確認します。
移行することを確認し、[移行] を選択します。 API Management インスタンスの状態が [更新中] に変わります。移行プロセスは、完了するまで約 45 分かかります状態が [オンライン] に変わると、移行完了です。

API Management インスタンスが複数のリージョンにデプロイされている場合は、前の手順を繰り返して、インスタンスの残りの場所の VNet 設定の移行を続行します。

(省略可能) 元のサブネットに移行する

新しいサブネットに変更し移行した場合は、必要に応じて、各リージョンで使用していた元のサブネットに移行します。これを行うには、VNet 構成をもう一度更新し、今度は元の VNet とサブネットを各リージョンに対し指定します。前の移行と同様に、実行時間の長い操作を想定し、VIP アドレスが変更される必要があります。

次の図は、元のサブネットへの移行中に何が起こるかの概要を示しています。

元のサブネットへのインプレース移行の図。

重要

VNet とサブネットがロックされている場合 (他の stv1 プラットフォームベースの API Management インスタンスがそこに配置されているため)、または元の VNet が配置されているリソースグループにリソースロックがある場合は、元のサブネットに移行する前に必ずロックを解除してください。ロックの削除が完了するまで待ってから、元のサブネットへの移行を試みます。詳細情報。

追加の前提条件

API Management インスタンスが配置されている、各リージョンのロック解除された元のサブネット。ネットワークセキュリティグループをサブネットにアタッチし、API Management の NSG 規則を構成する必要があります。
(省略可能) API Management インスタンスと同じリージョンおよびサブスクリプションにある新しい Standard SKU パブリック IPv4 アドレスリソース。
重要
- 2024 年 5 月以降、内部モードの VNet に API Management インスタンスをデプロイ (インジェクション) するとき、または内部 VNet 構成を新しいサブネットに移行するときに、パブリック IP アドレスリソースは "不要になります"。外部 VNet モードでは、パブリック IP アドレスの指定は "オプション" です。指定しない場合は、Azure マネージドパブリック IP アドレスが自動的に構成され、ランタイム API トラフィックに使用されます。インターネットの受信または送信コミュニケーションに使用されるパブリック IP アドレスを所有および制御したい場合にのみ、パブリック IP アドレスを指定します。

VNet 構成を更新する

ポータルで、元の VNet に移動します。
左側のメニューで [サブネット] を選択し、元のサブネットを選択します。
元の IP アドレスが API Management によってリリースされたことを確認します。 [使用可能な IP] で、サブネットで使用可能な IP アドレスの数をメモします。すべてのアドレス (Azure 予約済みアドレスを除く) を使用できる必要があります。必要に応じて、IP アドレスがリリースされるまで待ちます。
API Management インスタンスに移動します。
左側のメニューの [ネットワーク] で、[仮想ネットワーク] を選択します。
更新する場所でネットワーク接続を選択します。
元の VNet ネットワークとサブネットを選択します。必要に応じて、新しいパブリック IP を選択します。適用を選択します。
API Management インスタンスが複数のリージョンにデプロイされている場合は、インスタンスの残りの場所に対する VNet 設定の構成を続行します。
上部のナビゲーションバーで、[保存] を選択します。

VNet 構成を更新すると、API Management インスタンスの状態が [更新中] に変わります。移行プロセスは、完了するまで約 45 分かかります状態が [オンライン] に変わると、移行完了です。

移行を検証する

移行が成功したことを確認するには、状態が [オンライン] に変わったら、API Management インスタンスのプラットフォームバージョンを調べます。移行が成功すると、値は stv2 または stv2.1 になります。

古いゲートウェイが消去される前に設定を確認する

移行後に古いゲートウェイが一時的に保持されるシナリオでは、移行中に作成された新しいコンピューティングが古いコンピューティングと短時間 (約 15 分間) 共存するので、デプロイの検証に使用できると同時に、アプリケーションを想定どおりに動作させます。特定のシナリオでは、必要に応じてポータル設定を使用して保持期間を 48 時間に延長できます。

この期間には、古いゲートウェイと新しいゲートウェイは共にオンラインで、トラフィックを処理しています。この期間中は課金されません。
この期間を利用して、DNS、ファイアウォール規則、VNet などのネットワーク依存関係を、新しい VIP アドレスまたはサブネットアドレス空間を使うように更新します。
また、インスタンスのネットワークの状態をチェックして、インスタンスからその依存関係への接続を確認します。ポータルの左側のメニューにある [デプロイとインフラストラクチャ] で、[ネットワーク]>[ネットワークの状態] の順に選択します。必要に応じて、UDR や NSG ルールなどの設定を更新します。
この期間の後、古いゲートウェイは使用停止になり、新しいゲートウェイだけがトラフィックを提供するようになります。

移行が失敗した場合は自動的に元に戻す

移行プロセス中にエラーが発生した場合、インスタンスは自動的に stv1 プラットフォームに戻ります。移行が正常に完了した場合 (インスタンスのプラットフォームバージョンは stv2 または stv2.1 として表示され、状態は [オンライン] として表示されます)、stv1 プラットフォームにロールバックすることはできません。

移行に失敗した場合のヘルプについては、Azure サポートにお問い合わせください。

手動でロールバックできるようにする必要がある場合は、新しい stv2 インスタンスを元の API Management インスタンスと side-by-side でデプロイすることをお勧めします。

特別な条件とシナリオ

特定の条件下では、オプション 1: 同じサブネットを保持して移行するが利用できないか、異なる動作をする場合があります。ポータルはこれらの条件を検出し、移行オプションを推奨します。オプション 1 を使用できない場合、または複数の条件が存在する場合は、オプション 2: 新しいサブネットに変更するを使用します。

特別な内部条件のある VNet - API Management インスタンスが (顧客の設定とは無関係の) 特別な内部条件を持つ VNet に現在デプロイされている場合、ポータルで同じサブネットに移行するオプション 1 には追加のダウンタイム (約 1 時間) が含まれることが通知されます。移行にはポータルを使用することをお勧めします。また、変更した次の Azure CLI スクリプトを使用して、約 1 時間のダウンタイムで同じサブネットを移行することもできます。
```
APIM_NAME={name of your API Management instance}
# In PowerShell, use the following syntax: $APIM_NAME={name of your API Management instance}
RG_NAME={name of your resource group} 
# Get resource ID of API Management instance
APIM_RESOURCE_ID=$(az apim show --name $APIM_NAME --resource-group $RG_NAME --query id --output tsv)
# Call REST API to migrate to stv2 and preserve VIP address for special condition
az rest --method post --uri "$APIM_RESOURCE_ID/migrateToStv2?api-version=2024-06-01-preview&migrateWithDowntime=true" --body '{"mode": "PreserveIP"}' 
```
サブネットの複数の stv1 インスタンス - インスタンスを同時に移行しようとすると、同じサブネットの移行に十分な空き IP アドレスが利用できない場合があります。オプション 1 を使用してインスタンスを順次移行できる場合があります。
サブネットの委任 - API Management がデプロイされているサブネットが現在他の Azure サービスに委任されている場合は、オプション 2 を使用して移行する必要があります。
Azure Key Vault がブロックされている - Azure Key Vault へのアクセスが現在ブロックされている場合は、Azure Key Vault へのアクセス用に新しいサブネットで NSG ルールを設定するなど、オプション 2 を使用して移行する必要があります。

ヘルプとサポート

サービスの中断を最小限に抑えながら、stv2 プラットフォームに移行できるようお手伝いします。

質問がある場合は、Microsoft Q&A でコミュニティの専門家が速やかにお答えします。サポートプランに加入していて技術的な支援が必要な場合は、サポートリクエストを作成してください。

[要約] に、問題の説明 (「stv1 の廃止」など) を入力します。
[問題の種類] で [技術] を選択します。
[サブスクリプション] でご使用のサブスクリプションを選択します。
[サービス] で [使用中のサービス] を選択し、[API Management サービス] を選択します。
[リソース] で、サポートリクエストを作成する Azure リソースを選択します。
[問題の種類] で [管理] を選択します。
[問題のサブタイプ] で [Upgrade, Scale or SKU Changes] (アップグレード、スケーリング、SKU の変更) を選択します。

よく寄せられる質問

移行パスを選ぶためにはどのような情報が必要ですか?
- API Management インスタンスのネットワークモードは何ですか?
- カスタムドメインが構成されているか?
- ファイアウォールが関係しているか?
- 関係する IP でアップストリーム/ダウンストリームに既知の依存関係があるか?
- 複数リージョンへのデプロイですか?
- 既存のインスタンスを変更可能であるか並行セットアップが必要であるか?
- ダウンタイムが発生してもかまわないか?
- 移行を営業時間外に実行できるか?
移行にはどのような前提条件がありますか?

VNet インジェクションインスタンスについては、同じサブネットを保持して移行、または新しいサブネットに変更して移行オプションの前提条件を参照してください。
移行によってダウンタイムが発生しますか?

同じサブネット構成を維持して VNet インジェクションのインスタンスを移行する場合、API ゲートウェイで発生するダウンタイムは最小限になるか、まったくなくなります。「想定されるダウンタイム」の概要表を参照してください。

新しい VIP アドレスに変更して移行する場合、既定のホスト名が使用されていれば、ダウンタイムは発生しません。影響を受ける API が機能するように、ネットワークの依存関係すべてに事前に対処しておく必要があります。ただし、カスタムドメインが使用されている場合、これらは更新されるまで消去されたコンピューティングを指すことになり、これによってダウンタイムが発生する可能性があります。また、特定の移行オプションでは、古いゲートウェイを 48 時間保持するように、移行設定を有効にできます。古いコンピューティングと新しいコンピューティングを共存させることで、検証が容易になり、その後にカスタム DNS エントリを任意のタイミングで更新できます。
トラフィックがファイアウォールを介して強制的にトンネリングされます。どのような変更が必要ですか?
- まず第一に、移行に使用するサブネットが次の構成を保持していることを確認します (現在のサブネットを保持して移行する場合は、先にこれを構成する必要があります)。
  - こちらのページで説明されているようにサービスエンドポイントが有効になっている
  - UDR (ユーザー定義のルート) で ApiManagement サービスタグのホップがファイアウォールアドレスのみでなく [インターネット] に設定されている
- stv2 の NSG 構成の要件は、ファイアウォールの有無を問わず変わりません。新しいサブネットにそれがあることを確認してください。
- API Management インスタンスの現在の IP アドレス範囲を参照するファイアウォール規則を、新しいサブネットの IP アドレス範囲を使うように更新する必要があります。
移行により、または移行中にデータまたは構成の損失が発生する可能性はありますか。

stv1 から stv2 への移行では、コンピューティングプラットフォームのみが更新され、内部ストレージレイヤーは変更されません。そのため、構成はすべて、移行プロセスの間も安全です。これにはシステム割り当てマネージド ID が含まれ、有効になっている場合は維持されます。
移行が正常に完了したことを確認する方法

[概要] ページで状態が [オンライン] になっており、プラットフォームバージョンとして stv2 か stv2.1 が示されていれば、移行は正常に完了しています。また、必要な接続すべてについて、[ネットワーク] ブレードにあるネットワーク状態が緑色で表示されていることを確認してください。
ポータルを使って移行できますか?

はい。VNet インジェクションインスタンスは、[プラットフォームの移行] ブレードを使用して移行できます。
インスタンスの IP アドレスを保持できますか?

はい。ポータルの [プラットフォーム移行] ブレードと REST API には、IP アドレスを保持するオプションがあります。
既存のインスタンスを変更しない移行パスはありますか?

はい。side-by-side での移行を行う必要があります。つまり、新しい API Management インスタンスを、現在のインスタンスがある状態で作成し、その構成を新しいインスタンスにコピーします。
移行に失敗するとどうなりますか?

移行を開始した後、API Management インスタンスでプラットフォームバージョンが stv2 または stv2.1 と示されず、状態が [オンライン] と示されない場合は、失敗している可能性があります。サービスは自動的に前のインスタンスにロールバックされ、変更は加えられません。
移行中はどの機能を使えなくなりますか?

移行中も API 要求への応答は維持されます。インフラストラクチャ構成 (カスタムドメイン、場所、CA 証明書など) は 30 分間ロックされます。
移行にはどのくらい時間がかかりますか?

新しい VNet 構成への移行に予想される所要時間は約 45 分です。移行が既に実行されたかどうかを知るには、インスタンスの状態が [オンライン] に戻っており [更新中] でないことを確認します。複数リージョンのデプロイや、サブネットを複数回変更するシナリオでは、さらに長い時間を計画します。
移行を試みる前に VNet 構成を検証する方法はありますか?

移行中にサブネットを変更する予定の場合は、実際の移行に使用する VNet、サブネット、(オプションの) IP アドレスリソースを使用して、新しい API Management インスタンスをデプロイできます。デプロイが完了したら [ネットワークの状態] ページに移動し、すべてのエンドポイント接続状態が緑色になっているかどうかを確認します。そうなっている場合は、この新しい API Management インスタンスを削除し、元の stv1 でホストされたサービスでの実際の移行に進んでかまいません。
必要に応じて移行をロールバックできますか?

移行プロセスの間にエラーが発生した場合、インスタンスは自動的に stv1 プラットフォームにロールバックされます。ただし、サービスが正常に移行された後、stv1 プラットフォームにロールバックすることはできません。
カスタムドメインまたはプライベート DNS ゾーンで必要な変更はありますか?

内部モードの VNet インジェクションインスタンスで、新しい VIP に変更する場合は、プライベート DNS ゾーンを、移行後に取得した新しい VNet IP アドレスに更新する必要があります。 Azure 以外の DNS ゾーンも更新することを忘れないでください (たとえば、API Management のプライベート IP アドレスを指しているオンプレミスの DNS サーバーなど)。ただし、外部モードでは、既定のドメインを使っている場合は移行プロセスによってそれらが自動的に更新されます。
stv1 インスタンスを複数の Azure リージョン (複数地域) に配置してあります。 stv2 にアップグレードするにはどうすればよいですか?

複数地域配置には、他の場所に配置されるより多くのマネージドゲートウェイがあります。 portal の [プラットフォームの移行] ブレードを使用して移行する場合は、それぞれの場所を個別に移行します。 Stv2 への移行 REST API は、1 回の呼び出しですべての場所を移行します。インスタンスは、すべての場所が移行された場合のみ、新しいプラットフォームに移行されたと見なされます。移行プロセスの間はすべてのゲートウェイが正常に動作し続けます。
stv1 インスタンスをアップグレードして同じサブネットにすることはできますか?

はい。ポータルの [プラットフォーム移行] ブレードを使用するか、stv2 への移行 REST API を使用します。
ライブトラフィックを切り替える前に、新しいサブネットで新しいゲートウェイをテストできますか?
- 新しいサブネットに移行する場合、既定では、新旧のマネージドゲートウェイが 15 分間共存します。これは、デプロイを検証するための短い時間枠です。前のゲートウェイを 48 時間保持する移行設定を有効にすることができます。この変更により、新旧のマネージドゲートウェイがアクティブなままトラフィックを受信するので検証が容易になります。
- 移行プロセスでは、既定のドメイン名が自動的に更新されます。既定のドメイン名を使っている場合は、トラフィックがすぐに新しいゲートウェイにルーティングされます。
- カスタムドメイン名を使っている場合は、CNAME を使っていなければ、対応する DNS レコードを新しい IP アドレスで更新する必要があることがあります。お客様は、切り替える前に、ホストファイルを新しい API Management IP に更新し、インスタンスを検証できます。この検証プロセスの間は、前のゲートウェイで引き続きライブトラフィックが処理されます。
新しいサブネットで既定のドメイン名を使用する場合の考慮事項はありますか?

外部モードで、既定の DNS 名が使われているインスタンスでは、移行プロセスによって DNS が自動更新されます。また、必ず既定のドメイン名が使われる管理エンドポイントは、移行プロセスによって自動的に更新されます。移行が正常に完了するとすぐに切り替えられるため、新しいインスタンスがすぐにトラフィックを受信し始めます。影響を受ける API が使用不可にならないように、ネットワークの制限や依存関係に事前に対処しておくことが重要です。
セルフホステッドゲートウェイの場合はどのような考慮事項がありますか?

セルフホステッドゲートウェイにおいてはユーザーは何も実行する必要がありません。必要なのは、Azure 上で実行されている、stv1 プラットフォームの廃止に影響を受ける API Management インスタンスを移行することのみです。なお、API Management インスタンスの構成エンドポイント用に新しい IP が存在する可能性があり、その IP に固定されているネットワーク制限を更新する必要があることにご注意ください。
移行によって開発者ポータルにどのような影響がありますか?

開発者ポータルに影響はありません。カスタムドメインを使っている場合は、移行後に、有効な IP で DNS レコードを更新する必要があります。ただし、既定のドメインを使っている場合は、移行が正常に完了するとそれらが自動的に更新されます。開発者ポータルには、移行の間のダウンタイムはありません。
stv2 に移行するとコストに影響がありますか?

課金モデルは stv2 の場合も変わらず、移行中および移行後に追加コストが発生することはありません。
stv1 から stv2 への移行には、どのような RBAC アクセス許可が必要ですか?

移行を行うユーザー/プロセスには、API Management インスタンスへの書き込みアクセス権が必要です。さらに、次の 2 つのアクセス許可が必要です。
- Microsoft.Network/virtualNetworks/subnets/join/action
- Microsoft.Network/publicIPAddresses/join/action

次の方法で共有

stv1 プラットフォームでホストされている、VNet 挿入された API Management インスタンスを stv2 に移行する

移行の間の動作

前提条件

オプション 1: 同じサブネットを保持して移行する