仮想ネットワーク統合とプライベート エンドポイントで使用するサブネットのサイズについて考える
概要
少し地味な内容かもしれませんが、App Service の 仮想ネットワーク統合や、プライベート エンドポイントで使用するサブネットのサイズについて、どの程度確保するべきか迷う事があるかと思います。注意する点等を調べてみたのでここで紹介します。
- App Service の Vnet 統合
- プライベート エンドポイント
詳細
App Service の Vnet 統合
まず、これは Vnet 統合にかかわらず、単純に仮想ネットワーク内にサブネットを作成した際に、当該サブネットでいくつの IP を使用可能かという話ですが、実際に使用可能な IP アドレス数は、5 を引いたものとなるようです。
例えば、/26 の場合は 64 ですが、使用可能な IP は、59 となっています。
その他のものも、5 引いたものになっているのがわかります。
実際に App Service から仮想ネットワーク統合を実施してみます。
以下は実施後に App Service のネットワーク ブレードを見た様子ですが、赤枠の部分は「58 個が利用可能 (合計 59 個) 」となっています。
現在 1 インスタンスで動作させているので、1 つ使用されているという事です。
なお、実際に割り当てられた Private IP は WEBSITE_PRIVATE_IP で確認する事ができます。
- 仮想ネットワーク統合のしくみ
https://learn.microsoft.com/ja-jp/azure/app-service/overview-vnet-integration#how-regional-virtual-network-integration-works
仮想ネットワーク統合が有効になっている場合、アプリは仮想ネットワークを介して送信呼び出しを行います。 アプリのプロパティ ポータルに一覧表示される送信アドレスは、引き続きそのアプリによって使用されるアドレスです。 ただし、送信呼び出しが、統合仮想ネットワークまたはピアリングされた仮想ネットワーク内の仮想マシンまたはプライベート エンドポイントに対して行われる場合、送信アドレスは統合サブネットのアドレスになります。 インスタンスに割り当てられたプライベート IP は、環境変数 WEBSITE_PRIVATE_IP によって公開されます。
- 仮想ネットワーク統合の管理
https://learn.microsoft.com/ja-jp/azure/app-service/overview-vnet-integration#manage-virtual-network-integration
インスタンスに割り当てられたプライベート IP は、環境変数 WEBSITE_PRIVATE_IP によって公開されます。 Kudu コンソールの UI にも、アプリで使用できる環境変数の一覧が表示されます。 この IP は、統合されたサブネットのアドレス範囲から割り当てられます。 この IP は、Azure 仮想ネットワークを通じてリソースに接続するために アプリで使用されます。
Kudu の Environment タブを行くと、確かにサブネット範囲内の IP が割り当てられている事が確認できました。
次にスケール アウトして、インスタンスを １ から 3 へ増やしてみます。
暫く経過してインスタンスが稼働すると、表示が 「56個が利用可能 (合計 59 個)」に変わりました。
Kudu の Environment タブでそれぞれのインスタンスをみると以下の通りでした。
もう少しテストして、限界値を見てみたいと思います。
テストのために、/28 のサブネットを用意して使用します。合計 11 個利用できるはずです。
スケールアウトで 12 インスタンスを指定しましたが、想定通りこれはできませんでした。
11インスタンスを指定しましたが、これはできました。想定通りですね。
Kudu で見てみましたが、無事 11 インスタンスに増えている事が確認できます。
ネットワーク ブレードを見てみると以下の通り、「0 個が利用可能」となり、使い切りました。
なお上記はあくまでもテストのためにやってみましたが、実際の運用においては以下の通り、一時的に必要なアドレス空間が 2 倍になる事があるので、上記のような使い方は避けたほうがよいでしょう。公式ドキュメントでも余裕をもったサイズをすすめているため、あまりかつかつな使い方はしないほうがいいです。
サイズのスケールアップ/スケールダウン、またはインスタンス数のイン/アウトを行うと、必要なアドレス空間が短時間で 2 倍になります。 スケーリング操作では、同じ数の新しいインスタンスが追加された後、既存のインスタンスが削除されます。 スケール操作は、特定のサブネット サイズでサポートされる実際の使用可能なインスタンスに影響します。 プラットフォームのアップグレードでは、送信トラフィックを中断せずにアップグレードできるようにするために、空き IP アドレスが必要です。
もう少し遊んでみます。
/29 でも一応作成自体はできました。(ポータル上注意はされます)
/29 だと 3 つ使用できるのですが、インスタンスを 3 へと増やして使いきってみます。
3 インスタンスで使用されているIPは以下でした。
つまり使用できない IP は、以下とういう事かと思います。
最初から 4 つと最後の 1 つが使用できない IP になるようです。
10.0.6.0
10.0.6.1
10.0.6.2
10.0.6.3
10.0.6.7
プライベート エンドポイント
プライベート エンドポイントについては、特段サブネットのサイズについて注意事項等は公式ドキュメント上ないようです。
1 つのプライベートエンドポイントを設定すると、IP を 1 つ使用する形になります。
同一サブネットに対して、複数のプライベート エンドポイントを設定できるので、プロジェクトの要件次第でプライベート エンドポイントを特定のサブネットにまとめるのもいいかもしれません。
(例えば、App Service のプライベート エンドポイントで使用するサブネットを作成し、その他のサービスで利用するサブネットを別途作成する等)
まとめ
App Service の仮想ネットワーク統合や、プライベートエンドポイントで使用するサブネットのサイズについて考えてみましたが、仮想ネットワーク統合については余裕をもったサイズを見積る必要がありそうです。
Discussion