Share via

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

  • [アーティクル]

適用対象: Developer | Premium

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

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

重要

stv1 プラットフォームでホストされている API Management インスタンスのサポートは、2024 年 8 月 31 日で廃止される予定です。 stv1 プラットフォームでホストしているインスタンスがある場合は、サービスの中断を回避するため、この日付より前に stv2 プラットフォームへ移行してください。 詳細情報。

注意事項

  • API Management インスタンスを stv2 プラットフォームに移行することは、実行時間の長い操作です。
  • インスタンスの VIP アドレスが変更されます。 移行後に、新しい VIP アドレスを使うには、DNS、ファイアウォール規則、VNet などのネットワーク依存関係を更新する必要があります。 移行を適切に計画してください。
  • stv2 への移行は元に戻すことはできません。

移行の間の動作

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

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

前提条件

  • stv1 コンピューティング プラットフォームでホストされている API Management インスタンス。 インスタンスが stv1 プラットフォームでホストされていることを確認するには、「API Management インスタンスのホストとなっているプラットフォームは、どのようにして確認できますか?」を参照してください。インスタンスは仮想ネットワークに挿入されている必要があります。

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

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

    重要

    stv2 プラットフォームへの移行のために VNet 構成を更新する場合は、パブリック IP アドレス リソース (API Management が複数の Azure リージョンに配置されている場合は複数個) を指定する必要があります。そうしないと、移行が成功しません。 内部 VNet モードでは、このパブリック IP アドレスは Azure 内部管理操作にのみ使用され、ゲートウェイがインターネットに公開されることはありません。 パブリック バックエンドでは、インスタンスのパブリック VIP が呼び出し元 IP として表示される場合があります。

  • (省略可能) 移行が成功してから最大 48 時間、元のサービス インフラストラクチャが並列して維持されるようにするには、Azure サポートに問い合わせて依頼してください。 このオプションでは、移行後に古いインフラストラクチャが使用できる期間 (消去されるまで期間) を、既定の 15 分を超えて延長します。 このオプションは、VNet に挿入されたサービスでのみ使用できます。これによって、サービス所有者はネットワーク設定を更新して、アプリケーションが新しいインフラストラクチャを使用することをテストできます。 この拡張機能の依頼は、サブスクリプション内のすべての API Management インスタンスに適用されます。

    Note

    移行後に、VNet に挿入された API Management インスタンスを元のサブネットに移行する予定がある場合は、48 時間の拡張機能を依頼しないことをお勧めします。

ネットワークに挿入された API Management インスタンスの移行をトリガーする

ネットワークに挿入された API Management インスタンスの stv2 プラットフォームへの移行をトリガーするには、既存のネットワーク構成を更新して、インスタンスが配置されている各リージョンで新しいネットワーク設定を使用するようにします。 更新が完了したら、省略可能なステップとして、使っていた元の VNet とサブネットに移行して戻すことができます。

Premium レベルで利用可能なゾーン冗長性を有効にすることで、stv2 プラットフォームに移行することもできます。

重要

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

ネットワーク構成の更新

Azure portal やその他の Azure ツールを使用して、同じ VNet または別の VNet 内の新しいサブネットに移行できます。 次の図は、新しいサブネットへ移行中に何が起こるかの概要を示しています。

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

たとえば、ポータルを使用するには、次のようにします。

  1. portal で、API Management インスタンスに移動します。
  2. 左側のメニューで、[ネットワーク]>[仮想ネットワーク] を選択します。
  3. 更新する場所でネットワーク接続を選択します。
  4. 構成する仮想ネットワーク、サブネット、および IP アドレス リソースを選択し、[適用] を選択します。
  5. API Management インスタンスの残りの場所に対して、VNet 設定の構成を続行します。
  6. 上部のナビゲーション バーで、 [保存] を選択してから、 [ネットワーク構成の適用] を選択します。

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

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

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

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

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

重要

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

Note

元のサブネットに移行する予定の場合は、古いインフラストラクチャを維持するためのサブスクリプションでの 48 時間の拡張機能を依頼しないことをお勧めします。そうしないと、移行が遅れます。 拡張機能を取り消す必要がある場合は、Azure サポートにお問い合わせください。

追加の前提条件

  • API Management インスタンスが配置されている、各リージョンのロック解除された元のサブネット。 ネットワーク セキュリティ グループをサブネットにアタッチし、API Management の NSG 規則を構成する必要があります。

  • API Management インスタンスと同じリージョンおよびサブスクリプションにある新しい Standard SKU パブリック IPv4 アドレスリソース。

VNet 構成を更新する

  1. ポータルで、元の VNet に移動します。
  2. 左側のメニューで [サブネット] を選択し、元のサブネットを選択します。
  3. 元の IP アドレスが API Management によってリリースされたことを確認します。 [使用可能な IP] で、サブネットで使用可能な IP アドレスの数をメモします。 すべてのアドレス (Azure 予約済みアドレスを除く) を使用できる必要があります。 必要に応じて、IP アドレスがリリースされるまで待ちます。
  4. 前のセクションの移行手順を繰り返します。 各リージョンで、元の VNet とサブネット、新しい IP アドレス リソースを指定します。
  5. 上部のナビゲーション バーで、 [保存] を選択してから、 [ネットワーク構成の適用] を選択します。

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

移行を検証する

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

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

VNet に挿入された API Management インスタンスの移行が成功すると、移行中に作成された古いコンピューティングと新しいコンピューティングが短時間 (約 15 分間) 共存します。この短い期間を、配置とアプリケーションが想定どおりに動作するかのを検証に利用できます。 (この期間の長さは、Azure サポートに事前に連絡することで 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 (外部または内部モードいずれも) への移行には、新しいサブネットおよびパブリック IP アドレスが必要です。 こちらのページで説明しているように、サブネットには、stv2 プラットフォームの規則に従って NSG がアタッチされている必要があります。

  • 移行によってダウンタイムが発生しますか?

    古いゲートウェイが消去されるのは、新しいコンピューティングが正常でオンラインになった後であるため、既定のホスト名が使用されている場合はダウンタイムは発生しないはずです。 影響を受ける API が機能するように、ネットワークの依存関係すべてに事前に対処しておく必要があります。 ただし、カスタム ドメインが使用されている場合、これらは更新されるまで消去されたコンピューティングを指すことになり、これによってダウンタイムが発生する可能性があります。 または、サポート チケットを事前に作成することで、古いゲートウェイを最大 48 時間保持するように求めることもできます。 古いコンピューティングと新しいコンピューティングを共存させることで、検証が容易になり、その後にカスタム DNS エントリを任意のタイミングで更新できます。

  • トラフィックがファイアウォールを介して強制的にトンネリングされます。 どのような変更が必要ですか?

    • まず、移行用に作成した新しいサブネットで次の構成 (現在のサブネットで既に構成されている必要がある) が保持されていることを確認してください:
      • こちらのページで説明されているようにサービス エンドポイントが有効になっている
      • UDR (ユーザー定義のルート) で ApiManagement サービス タグのホップがファイアウォール アドレスのみでなく [インターネット] に設定されている
    • stv2 の NSG 構成の要件は、ファイアウォールの有無を問わず変わりません。新しいサブネットにそれがあることを確認してください。
    • API Management インスタンスの現在の IP アドレス範囲を参照するファイアウォール規則を、新しいサブネットの IP アドレス範囲を使うように更新する必要があります。

  • 移行により、または移行中にデータまたは構成の損失が発生する可能性はありますか。

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

  • 移行が正常に完了したことを確認するにはどうすればよいですか?

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

  • ポータルを使って移行できますか?

    VNet 挿入されたインスタンスは、[ネットワーク] ブレードでサブネットを変更することで移行できます。

  • インスタンスの IP アドレスを保持できますか?

    VNet に挿入されたインスタンスの場合は、現在のところ IP アドレスを保持する方法はありません。

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

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

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

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

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

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

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

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

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

    実際の移行に使う新しい VNet、サブネット、VIP で、新しい API Management インスタンスを配置することもできます。 デプロイが完了したら [ネットワークの状態] ページに移動し、すべてのエンドポイント接続状態が緑色になっているかどうかを確認します。 そうなっている場合は、この新しい API Management インスタンスを削除し、元の stv1 でホストされたサービスでの実際の移行に進んでかまいません。

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

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

    VNet に挿入されたサービスが正常に移行された後には、古いゲートウェイがトラフィックを処理し続け、ネットワーク設定を確認できる期間が少しあります。 「古いゲートウェイが消去される前に設定を確認する」を参照してください。

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

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

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

    複数地域配置には、他の場所に配置されるより多くのマネージド ゲートウェイがあります。 新しいサブネットと新しいパブリック IP を提供して、各場所を別々に移行する必要があります。 [場所] ブレードに移動し、リストされている各場所に変更を加えます。 インスタンスは、すべての場所が移行された場合のみ、新しいプラットフォームに移行されたと見なされます。 移行プロセスの間はすべてのゲートウェイが正常に動作し続けます。

  • API Management インスタンスが内部モードのみでの VNet インジェクションである場合でもパブリック IP は必要ですか?

    API Management stv1 では、内部モードであっても管理トラフィックに Azure マネージド パブリック IP が使われます。 ただし、stv2 では、同じ目的で、ユーザー管理パブリック IP が必要です。 このパブリック IP は、Azure 内部管理操作のみに使われ、インスタンスをインターネットに公開しません。 パブリック (インターネット向きの) バックエンドでは、インスタンスのパブリック IP が要求の配信元と見なされる場合があります。 詳細については、こちらをご覧ください。

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

    • stv1 インスタンスをダウンタイムなく単一パスで同じサブネットに移行することはできません。 ただし、移行したインスタンスを移動して元のサブネットに戻すことはできます。 詳細については、こちらをご覧ください。
    • 古いゲートウェイがサブネットを解放するまでには 15 分から 45 分かかるため、この行動を開始することができます。 ただし、サポート チケットによって、この時間を最大 48 時間に増やすことを要求できます。
    • 切り替えごとに新しいパブリック IP が必要です。
    • 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

ビデオ

関連するコンテンツ