クラウドの中身がどのような仕組みになっているのかを知るのに、とても参考になるのが中の人が書いている記事です。
前回に続きて今回もAzure ネットワークのプロダクトマネージャ、Aimee Littleton氏の「Virtual Network NAT」についての投稿について紹介します。

前回のおさらい

前回は、Virtual Network NATがランダムなSNATポートの選択と再利用タイマーによって、同じ宛先エンドポイントで発生する接続障害を軽減することができた事例の紹介でした。

Dive deep into NAT gateway’s SNAT port behavior

以下、画像はすべて元記事からの引用です。

SNATポート枯渇問題

NATを利用している時の最も一般的な接続障害はSNATポートの枯渇です。接続元側がインターネット上で新しい接続を行うためのSNATポートを使い果たすことで発生します。

Virtual Network NATは、サブネット内のVMのPrivate IPとポートをVirtual Network NATのPublic IPとポートにSNATしてからアウトバウンド接続します。同じ宛先IPとポートに新たに接続するたびに、新しいソースポートが使用されます。新しいソースポートは、各接続を互いに識別できるようにするために必要です。そのためSNATのポート枯渇は同じ宛先のエンドポイントに繰り返し接続する場合に発生しやすい問題であると言えます。

Virtual Network NATによるSNATポートの割り当て方法

Virtual Network NATによるSNATポートの割り当て方法の特徴は動的なプールからオンデマンドで割り当てを行うことです。
これによってSNATが枯渇するリスクを大幅に低減することができます。

記事の中では動的に割り当てない場合の説明がないので分かりにくいですが、動的に割り当てない場合はVM毎に固定の範囲の割り当てる方法になります。この場合、あるVMでバースト的なリクエストが発生するとSNAT枯渇が発生しやすくなります。

割り当てるSNATポートの選択方法

まず初回ですが、前回も紹介があったようにランダムでポートが割り当てされます。
同一の宛先に対する二回目の通信の場合ですが、一度使われたポートはすぐには再利用されず、クールダウン期間経過後に再利用される動きをします。
異なる宛先エンドポイントに接続する場合は、現在使用中のSNATポートをクールダウン期間を待たずに再利用します。

逆にいうと。。。

上記が「Dive deep into NAT gateway’s SNAT port behavior」の要約ですが、やはりこれも逆にいうと、Azure Load balancerを使っている場合はこのような問題が発生するということです。

SNATポート枯渇問題についてはコネクションプールを利用するなど、ここでは紹介されなかった、アプリケーションとして実施可能な対策も重要ですが、Virtual Network NATがこうした動きをするということは理解しておくべきでしょう。