stv1 プラットフォームでホストされている、VNet 挿入された API Management インスタンスを stv2 に移行する
適用対象: 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 分かかります 状態が [オンライン] に変わると、移行完了です。
オプション 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 つのオプションのいずれかを選択します。
[場所ごとに移行設定を定義する] で、以下を行います。
- 移行する場所を選択します。
- 移行先の [仮想ネットワーク]、[サブネット]、オプションの [パブリック 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 サポートにお問い合わせください。
手動でロールバックする機能が必要な場合は、元の API Management インスタンスと side-by-side で新しい stv2 インスタンスを配置することをお勧めします。
ヘルプとサポート
サービスの中断を最小限に抑えながら、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