はじめに
システム間のデータ連携は、まず API が候補にあがるくらい、API は広く使用されるようになっています。
多くの API を管理するためのサービスとして、Azure には “API Management” というサービスが用意されています。
とても便利なサービスですが、より機能が強化されている新しいプラットフォーム バージョン stv2 というものが存在します。
比較的最近デプロイした API Management は、意識しなくとも stv2 になっていると思います。
だいぶ前にデプロイした API Management は、 stv1 の可能性があります。
この stv1 ですが、2024/08/31 に廃止され、サポート対象外となることが発表されています。
なので、できるだけ早く stv1 から stv2 に移行することが望ましいです。
ところで、API Management は、より安全に運用するために VNet の中にデプロイすることができます。
VNet 内にデプロイした API Management を stv1 から stv2 に移行したい場合、移行方法によっては注意しないといけない点があります。
この記事では、その注意しないといけない点を紹介したいと思います。
プラットフォーム バージョンの確認
まずは、既存の API Management のプラットフォーム バージョンを確認します。
プラットフォーム バージョンの確認は、Azure ポータルでも確認できますし、Azure PowerShell でも確認できます。
【Azure ポータル】
【Azure PowerShell】
PS > Get-AzApiManagement -ResourceGroupName "tst-mm-rgp" -Name "tst-mm-apim" | grep "PlatformVersion"
PlatformVersion : stv2
※ Azure Cloud Shell を使用
ここで、プラットフォーム バージョンが stv2 になっていれば、今回は対応不要です。
(いつか、さらに便利になっているであろう stv3 が登場するまでは…)
stv1 になっている方は、移行が必要になります。
移行方法の検討
移行する方法としては、下記の方法が思い浮かびます。
- 既存の
stv1の API Management の VNet 構成 を更新する。 stv2の API Management を新規デプロイし、バックアップ・リストアの機能などを使用して、既存の API Management の設定を移行する。
この記事では 『後者の方法かつ、VNet の中に API Management をデプロイする』という想定で進めます。
VNet / サブネット の仕様について
サブネットの作成時、IP アドレス範囲を指定します。
たとえば、 10.127.250.0/28 と指定した場合、本来なら 10.127.250.0 - 10.127.250.15 の 16 個の IP アドレスが使用できるはずですが…
Azure の VNet / サブネットの仕様として、サブネットごとに「最初の 4 個」と「最後の 1 個」の合計 5 個の IP アドレスが予約アドレスとなり使用できなくなります。
図にすると、こんな感じになります。
API Management を VNet 内にデプロイするときに必要な IP アドレス数
先述のとおり、API Management は VNet の中にデプロイすることができます。
その場合、いくつの IP アドレスが必要なのでしょうか？
下記ページに、その回答が記載されています。
- 仮想ネットワークの Azure API Management との使用 > サブネットのサイズ
- Basic SKU、Standard SKU、または Premium SKU のユニットごとに 2 つの IP アドレス。
- Developer SKU 用に 1 つの IP アドレス。
- 内部 VNet にデプロイする場合は、内部ロード バランサー用に追加の IP アドレスが必要。
Premium SKU の API Management (1 ユニット) を、内部モードで VNet にデプロイする場合は…
「ユニット数：1 x 2 IP アドレス (計 2 個)」 + 「内部ロード バランサー用 (1 個)」 = 3 個 のIP アドレスが必要です。
これをさっきの図に当てはめると、こんな感じになります。
注意しないといけない点
さて、ここからがこの記事の本題になります。
今、 /28 で作成したサブネットは、いくつ IP アドレスが空いているでしょうか。
- 本来使用可能な IP アドレス数：16
- サブネットの仕様による予約分：5
- API Management (Premium SKU, 1 ユニット、内部モード)：3
16 – 5 – 3 = 8 個の IP アドレスが空いているはずです。
先にデプロイしてある API Manegement が stv1 だったとして、この空いている範囲に stv2 をデプロイすれば、少し移行の手間が省けそうに思えます。
API Management がオンプレ環境にアクセスしている場合、オンプレ側のファイアウォールの通信許可申請など必要になることもあるかと思いますが、既存のサブネットを流用できれば、あらためての申請もしないで済みそうです！
つまり、こういう風にできれば良さそうですが…
残念ながら、このような構成は実現できません。
なぜ、この構成ができないかというと、 stv1 の仕様によるものです。
stv1 の API Management インスタンスは、専用のサブネットが必要 となります。
ということは… stv2 の API Management を VNet の中にデプロイしたい場合、サブネットを新たに作成する必要があります。
これが、この記事で伝えたいことになります。
API Management (Premium SKU) を利用している場合、ユニット追加を想定し、少し大きめの範囲のサブネットを割り当てていることもあるかと思います。
その結果、IP アドレス数の空きに余裕があったりするかもしれませんが、残念ながら stv2 をデプロイするために流用はできません。
まとめ
- API Management の
stv1とstv2は、同じサブネットに共存できない！
おわりに
API Management を stv1 から stv2 に移行するにあたり、移行中・移行後のサブネット構成の見直しをする方が少なくないかと思います。
そのときに、 「stv1 と stv2 は共存できると思っていたのに、共存できない！ IP アドレス数が足りない！」 ということが、取返しのつかないタイミングで発覚すると、大変なことになるのは火を見るよりも明らかです。
そんな出来事を、この記事で未然に防ぐことができればと思います。