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

適用対象: Developer | Premium

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

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

• オプション 1: 同じサブネットを保持する - 配置を変えずにインスタンスを移行し、インスタンスの既存のサブネット構成を保持します。 API Management インスタンスの元の VIP アドレスを保持するか (推奨)、または新しい VIP アドレスを生成するかを選択できます。 現在、Stv2 への移行 REST API では、同じサブネット構成を使用したインスタンスの移行がサポートされています。

• オプション 2: 新しいサブネットに変更する - 同じまたは異なる VNet 内に、別のサブネットを指定してインスタンスを移行します。 移行後、必要に応じてインスタンスの元のサブネットに移行し直せます。 移行プロセスによって、インスタンスの VIP アドレスが変更されます。 移行の後、新しい VIP アドレスを使うには、DNS、ファイアウォール規則、VNet などのネットワーク依存関係を更新する必要があります。 現在、Azure portal の [プラットフォームの移行] ブレードで、この移行オプションがサポートされています。

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

移行の間の動作

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

• アップグレード プロセスでは、古いコンピューティングと並行して新しいコンピューティングを作成します。これには最大 45 分かかる場合があります。 複数リージョンのデプロイや、サブネットを複数回変更するシナリオでは、さらに長い時間を計画します。
• Azure portal での API Management の状態は [更新中] と示されます。
• 特定の移行オプションでは、インスタンスの VIP アドレス (マルチリージョンデプロイの場合はアドレス) が変更されます。 同じサブネット構成を保持して移行する場合は、VIP アドレスの保持を選択しなければ、新しいパブリック VIP が生成されます。

  重要

  2024 年 8 月の時点で、VIP アドレスを保持するオプションは、同じサブネットに移行する VNet 挿入インスタンスでは一時的に使用できません。 この期間中の stv2 プラットフォームへのすべての移行では、新しい VIP アドレスを使用する必要があります。

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

前提条件

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

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

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

既存のサブネット構成を維持したまま、API Management インスタンスを stv2 プラットフォームに移行できるため、移行が簡単になります。 現時点では、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 アドレス - このオプションを選択すると、API Management によってインスタンスの新しい VIP アドレスが自動生成されます。 移行中も API 要求への応答は維持されます。 インフラストラクチャの構成 (カスタム ドメイン、場所、CA 証明書など) は 30 分間ロックされます。 移行後に、新しい VIP アドレスを使うには、DNS、ファイアウォール規則、VNet などのネットワーク依存関係を更新する必要があります。

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

移行用に事前に作成された 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 コンピューティングのリテンション期間をまとめたものです。

移行スクリプト

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

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"}'

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

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

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

前提条件

• API Management インスタンスが配置されている各リージョンにおける、現在の仮想ネットワーク内の新しいサブネット。 (または、API Management インスタンスと同じリージョンおよびサブスクリプション内の別の仮想ネットワークにサブネットを設定します)。 ネットワーク セキュリティ グループを各サブネットにアタッチし、stv2 プラットフォーム上の API Management のために、NSG 規則 を構成する必要があります。

• (省略可能) API Management インスタンスと同じリージョンおよびサブスクリプションにある新しい Standard SKU パブリック IPv4 アドレス リソース。 詳細については、「ネットワーク接続の前提条件」を参照してください。

移行の手順

1. Azure portal で、API Management インスタンスに移動します。

2. 左側のメニューの [設定] で、[Platform migration] (プラットフォームの移行) を選びます。

3. [プラットフォームの移行] ページの手順 1 で、移行の要件と前提条件を確認します。

4. 手順 2 で、移行設定を選択します。

   • 移行する場所を選択します。

   • 移行先の [仮想ネットワーク]、[サブネット]、オプションの [パブリック IP アドレス] を選択します。

     

   • 移行後、できるだけ早く元のサブネットに戻るか、新しいサブネットに留まり、48 時間は stv1 コンピューティングを維持するかを選択します。 前者を選択した場合、stv1 コンピューティングは移行の約 15 分後に削除され、必要に応じて、直接手動での元のサブネットへの移行を続行することができます。 後者を選択した場合、stv1 コンピューティングは 48 時間保持されます。 この期間を使用して、ネットワーク設定と接続を検証できます。

     

5. 手順 3 で、移行することを確認し、[移行] を選択します。 API Management インスタンスの状態が [更新中] に変わります。 移行プロセスは、完了するまで約 45 分かかります 状態が [オンライン] に変わると、移行完了です。

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

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

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

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

追加の前提条件

• 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 で API Management インスタンスのゾーン冗長を有効にする場合は、新しいパブリック IP アドレスを指定する必要があります。

VNet 構成を更新する

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

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

移行を検証する

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

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

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

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

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

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

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

手動でロールバックする機能が必要な場合は、元の API Management インスタンスと side-by-side で新しい stv2 インスタンスを配置することをお勧めします。

ヘルプとサポート

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

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

1. [要約] に、問題の説明 (「stv1 の廃止」など) を入力します。
2. [問題の種類] で [技術] を選択します。
3. [サブスクリプション] でご使用のサブスクリプションを選択します。
4. [サービス] で [使用中のサービス] を選択し、[API Management サービス] を選択します。
5. [リソース] で、サポート リクエストを作成する Azure リソースを選択します。
6. [問題の種類] で [管理] を選択します。
7. [問題のサブタイプ] で [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 アドレスを保持できますか?

  はい。同じサブネットを保持して移行することで、IP アドレスを保持できます。

• 既存のインスタンスを変更しない移行パスはありますか?

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

• 移行に失敗するとどうなりますか?

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

• 移行中はどの機能を使えなくなりますか?

  移行中も API 要求への応答は維持されます。 インフラストラクチャ構成 (カスタム ドメイン、場所、CA 証明書など) は 30 分間ロックされます。 新しいサブネットに移行するシナリオでは、移行後に DNS、ファイアウォール規則、VNet などのネットワーク依存関係を更新して、新しい VIP アドレスを使用できるようにする必要があります。

• 移行にはどのくらい時間がかかりますか?

  新しい VNet 構成への移行に予想される所要時間は約 45 分です。 移行が既に実行されたかどうかを知るには、インスタンスの状態が [オンライン] に戻っており [更新中] でないことを確認します。

• 移行を試みる前に VNet 構成を検証する方法はありますか?

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

• 必要に応じて移行をロールバックできますか?

  移行プロセスの間にエラーが発生した場合、インスタンスは自動的に stv1 プラットフォームにロールバックされます。 ただし、サービスが正常に移行された後、stv1 プラットフォームにロールバックすることはできません。

  新しい VIP に変更して移行する場合、移行後、古いゲートウェイがトラフィックを処理し続ける短いウィンドウが存在するので、この時間にネットワーク設定を確認できます。 「古いゲートウェイが消去される前に設定を確認する」を参照してください。

• カスタム ドメインまたはプライベート DNS ゾーンで必要な変更はありますか?

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

• stv1 インスタンスを複数の Azure リージョン (複数地域) に配置してあります。 stv2 にアップグレードするにはどうすればよいですか?

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

• stv1 インスタンスをアップグレードして同じサブネットにすることはできますか?

  • 現時点では、 Stv2 への移行 REST API を使用する場合、1 つのパスで同じサブネットにのみアップグレードできます。

    現在、portal で [プラットフォームの移行] ブレードを使用する場合は、新しいサブネットに移行してから、元のサブネットに移行し直す必要があります。

    • 古いゲートウェイがサブネットを解放するまでには 15 分から 45 分かかるため、この行動を開始することができます。 ただし、前のゲートウェイを 48 時間保持する移行設定を有効にすることができます。
    • NSG とファイアウォールのための以前のサブネット ネットワークが stv2 の依存関係について更新されていることを確認してください。
    • サブネット IP アドレスの割り当ては決定的ではありません。そのため、元のサブネットに戻ったときに、"内部モード" 配置の元の ILB (イングレス) IP は変更される可能性があります。 このため、A レコードを使用している場合は、DNS の変更が必要になります。

• ライブ トラフィックを切り替える前に新しいゲートウェイをテストできますか?

  • 既定では、新旧のマネージド ゲートウェイは 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

関連するコンテンツ

• API Management インスタンスのホストとなっているプラットフォームは、どのようにして確認できますか?

• API Management の stv2 コンピューティング プラットフォームの利点

• Stv1 プラットフォームの提供終了 - グローバル Azure (2024 年 8 月)

• Stv1 プラットフォームの提供終了 - 21Vianet が運営する Azure Government と Azure (2025 年 2 月)