突然 API Management に新しく Basic v2 / Standard v2 という Tier が Public Preview として追加されました。来月が Ignite なのでそこまで待っても良かったのではという気もしますが、App Service などの PaaS / Serverless のチームはイベントを気にせずアップデートしてきますね。
新しい Basic v2 / Standard v2 は高速なリソースのデプロイ、スケーリングが大きな特徴と言えます。そしてこれまで Premium でしか利用できなかった VNET Integration が Standard v2 では利用可能となっています。
現在サポートされていない機能としては Private Endpoint と Availability Zones が大きいです。特に Standard v2 では Availability Zones とマルチリージョンへのデプロイが GA までにサポートされる予定らしいので、Premium よりも圧倒的に安くそして早く高可用性の API Management が利用可能になります。
これらの特徴はプラットフォームの Cloud Services / VM から App Service への変更で実現されています。
新しい Basic v2 / Standard v2 の立ち位置について
現在提供されている Basic / Standard と、新しい Basic v2 / Standard v2 はプラットフォームが大きく変更されていますが、機能としてはほぼ同一のものが提供される予定のようです。それを物語るように v1 から v2 への移行機能も提供予定となっています。
プレビュー中の機能制限としては、まだかなり多くの機能が残っていますが Standard v2 が Premium の機能を多く取り込んでいるように見えます。Premium の機能でサポートされそうにないのは VNET 内にインスタンスをデプロイする機能ぐらいです。
恐らく v2 では Premium あるいは VNET 内にインスタンスをデプロイする機能は提供されないでしょう。その代わりに Private Endpoint は Basic v2 / Standard v2 でサポート予定なので、それを使う形になると思われます。基本的には Private Endpoint と VNET Integration で大体の要件は満たせるはずです。
気になる価格ですが v1 と v2 で同じ Tier の場合はほぼ同じ金額で設定されています。v2 固有の特徴としては API の呼び出し回数での課金が追加されていることと、追加のインスタンスは割安に設定されていることにあります。Basic v2 / Standard v2 でそれぞれ API 呼び出し回数の無料枠が含まれていますが、使われ方次第では v1 よりも割高になる可能性もあります。
このような課金体系からも、将来的には Basic と Standard の v1 については v2 へ一本化されることが想像つきますね。安くなるといったことはないですが、App Service ベースになったことによりデプロイとスケーリングの高速化が得られるのはかなり大きいですし、将来的にはオートスケールもサポートされる予定なので価値はあると考えています。
ここまでの内容を Tier 毎に簡単にまとめておきました。Consumption は一足早く App Service ベースで構築されていたので、試金石だったのかもしれませんね。
- Developer / Basic / Standard / Premium
- Cloud Services / VM ベースのアーキテクチャ
- 2024/9 で Cloud Services のサポートが切れるので stv1 がディスコン、stv2 はそのまま
- API の呼び出し回数が非常に多い場合にはコストメリットが出る可能性
- Consumption / Basic v2 / Standard v2
- App Service ベースのアーキテクチャ
- 今後のメインストリームは全て v2 になるものと思われる
- API の呼び出し回数での課金が追加されているので、v1 よりも高くなる可能性
ここから先は実際に Standard v2 の API Management をデプロイして、一番使われるであろう VNET Integration 周りの確認をしておきます。
これまで VNET Integration を使いたくても Premium しかなく価格的に諦めていたケースも多いと思いますが、v2 では Standard から使えるようになっているので、気になっている方は多いはずです。
API Management をデプロイする
まずは Standard v2 の API Management をデプロイするところから始めます。API Management の Tier が多くなったので、将来的には UI が整理されそうな気もします。
UI 上は Japan East / Japan West が指定できますが、残念ながら Basic v2 / Standard v2 は現時点では日本リージョン非対応なのでエラーとなります。しかし経験上 App Service 上に展開されているサービスはリージョンの拡充が早いので、比較的早くに Japan East には来るのではないかと考えています。
プレビュー中は例によって SLA は提供されていませんが、ベースとなっている App Service の SLA が 99.95% になっているので、GA 後には Basic v2 / Standard v2 も 99.95% になるようです。
デプロイ自体は 1 分程度で完了するので、これまでの API Management の Standard に比べると異次元の早さです。これだけでも Standard v2 を使うメリットになっているレベルです。
VNET Integration を有効化する
API Management の Standard v2 デプロイが完了した後は、適当に Virtual Network と Subnet を作成して API Management で VNET Integration を設定します。この辺りは完全に App Service の VNET Integration と同じになるので、あまり独特な挙動はないように見えますね。
設定画面や Subnet Delegation の設定値も App Service と同じなので、一度でも App Service で VNET Integration を設定したことがある人は悩むことはないでしょう。但しマルチリージョン対応のために UI は少し異なっている部分があります。
現時点では Azure Portal で Virtual Network を選択した後に Subnet の一覧が出ない不具合があるようなので、Azure Portal では VNET Integration の設定が行えませんでした。
仕方ないので ARM Explorer を利用して VNET Integration 設定を追加することで対応しました。具体的には ARM Explorer の Raw モードを利用して、以下のように Subnet のリソース ID を渡してあげるだけです。
PATCH /subscriptions/000/resourceGroups/xxx/providers/Microsoft.ApiManagement/service/xxx?api-version=2023-05-01-preview
{
"properties": {
"virtualNetworkConfiguration": {
"subnetResourceId": "/subscriptions/000/resourceGroups/xxx/providers/Microsoft.Network/virtualNetworks/xxx/subnets/xxx"
},
"virtualNetworkType": "External"
}
}この作業を行うと Azure Portal 側でも API Management の VNET Integration 設定が完了したことが確認出来るようになります。Azure Portal 上は完了までに時間がかかると記載されていますが、実際には 1 分弱で完了するので App Service は偉大だと感じました。勿論 Public VIP が変化することもありませんでした。
Azure Portal のメッセージは v2 向けになっていない部分が多いので、あまり気にせず進めるのが良いです。
非常に素早く API Management のデプロイから VNET Integration の設定まで行えましたが、検証を行っていると VNET Integration を有効化中には、スケーリングの設定変更が必ず失敗することに気が付きました。
あくまでも一時的な問題であり、VNET Integration を有効にしているとスケーリングが行えないということではありませんので注意してください。App Service では対応している設定が、それを利用している API Management では非対応というのはあり得ません。
Service Endpoint で保護された API へ接続する
ここまでの作業で API Management の VNET Integration 設定が完了したので、これからは実際に VNET 経由での安全なアクセスが行えるのかを確認します。まずはシンプルに Service Endpoint を使って保護された API へのアクセスが行えるのか試します。
API は ASP.NET Core のテンプレートで生成したものを App Service にデプロイして試していきます。まずは全てのアクセスを拒否する設定を追加して、API Management からアクセスできないことを確認します。これは App Service の Access Restriction から Unmatched Rule Action を Deny にするだけで対応できます。
API Management の Test を使ってアクセスしてみると 403 Ip Forbidden が返ってきます。想定通りですね。
確認後に API Management が VNET Integration している Virtual Network の Subnet からのアクセスを許可する設定を追加します。Azure Portal 上には記載されていませんが、これは App Service の Service Endpoint を使っている機能です。
再度 API Management の Test からアクセスしてみると、今度は 403 Ip Forbidden が返ってくることなく 200 OK となり、API が正しくペイロードを返しているのを確認出来ます。
これで API Management の Standard v2 でサポートされた VNET Integration は、Service Endpoint で保護された API に対して正しくアクセスできることが確認出来ました。多くのケースでは Service Endpoint を使ったアクセス制限が出来れば十分です。
Private Endpoint で保護された API へ接続する
今度は Private Endpoint で保護された API へのアクセスが行えるのか確認していきます。準備として App Service で Private Endpoint からのアクセスのみ許可する際には、Allow Public Access をオフにしておく必要があります。オンになっているとインターネットからのアクセスが可能になるので、Private Endpoint を使っている意味がなくなってしまいます
Public Access をオフにした後に App Service に対して Private Endpoint を追加します。少しデプロイに時間はかかりますが、Connection state が Approved になれば完了です。
デプロイ完了後に Service Endpoint の時と同様に Test からアクセスしてみると、API へのアクセスが正しく行えることが確認出来ました。App Service では Private Endpoint を利用する際には旧称 Route All 設定*1を有効化する必要がありましたが、API Management ではデフォルトで有効化されているようです。
結果としては問題なく動作したのですが、Private Endpoint の設定直後は API Management から API にアクセスできない事象が発生しました。原因は分かっていませんが、API Management の設定変更を行い、内部的に再起動させることで解消したように見えました。
GA までに挙動が安定することを期待しますが、現時点では Private Endpoint の設定直後はキャッシュなどの影響を受けてしまう可能性がありそうです。
*1:現在は Outbound internet traffic という設定になっている
