クラウドの中身がどのような仕組みになっているのかを知るのに、とても参考になるのが中の人が書いている記事です。
たとえばAzureのネットワークについては宇田さんが書かれている記事があります。
Azure ネットワークのプロダクトマネージャ、Aimee Littleton氏の最近の２つの投稿について二回に分けてとりあげます。
今回は「Improve outbound connectivity with Azure Virtual Network NAT」について見ていきたいと思います。
Virtual Network NATとは
Aimee Littleton氏の記事に入る前にかんたんにVirtual Network NATについてのおさらいです。
Virtual Network NATはAzureでNATを利用する方法の１つです。NAT Gatewayとも呼ばれます。
NATを利用することで、仮想マシンにパブリックIPアドレスを割り当てることなく、インターネットに出ていくことができます。
NATの実現手段としてはこの他にもLoad Balancerを利用する方法や、Azure Firewallを利用する方法、Azureの既定のNATを利用する方法もありますが、この記事では取り上げません。
Improve outbound connectivity with Azure Virtual Network NAT
この記事はAzure Virtual Network NATを使って接続性を改善した事例の紹介になっています。
当初構成
- アプリケーションがVMSSで動いている
- NATはLoad balancerで行っている
- アプリケーションが利用するREST APIをインターネット越しに呼び出している
- REST APIの前段にはFirewallが入っている
当初構成の問題点
- 1つまたは複数の仮想マシンがREST APIエンドポイントからの応答を長時間待つことがある
- これらのレスポンス待ちは最終的にタイムアウトし、接続障害となることがあった
当初構成で問題が発生した原因
- REST APIの前段にあるfirewallがAzure ネットワークからの着信接続を無言で切断していた
- この時、対象とされていたのは直近（20秒程度）使用された接続元ポートとIPアドレスからの接続のみだった
- これはfirewallが、同じ送信元IPとポートから来る新しい接続に対して20秒間のクールダウン期間を強制しているために発生していた
- REST APIに新しいコネクションを生成する頻度が高いためにAzure仮想ネットワークからのSNATポートが短期間に再利用されていた
- firewallのクールダウンタイマーを変更することはできなかった
※引用画像です
Virtual Network NATによる解決
以下の2つの機能によって問題を解決することができたそうです
- Virtual Network NATは大量のポート在庫（最大16個のIPアドレス＝100万以上のSNATポート）からランダムに選択するために、新しいものである確率が高く、問題なくファイアウォールを通過することができた
- ソースポートが再利用される前に、少なくともファイアウォールのクールダウンタイマーと同じ時間、NATゲートウェイによって独自のクールダウンタイマーが設定されている
※引用画像です
逆にいうと。。。
上記が「Improve outbound connectivity with Azure Virtual Network NAT」の要約です。
これは逆にいうと、Azure Load balancerを使っている場合はこのような問題が発生するということだと思います。
クラウドのネットワークの接続性は「クラウドのネットワークでは瞬断があるのでリトライしよう」と言われて片付けられてしまうことがありますが、ちゃんと原因を調査してみると、より安定したネットワーク環境を実現できるという事例でもあります。
参考にしてみてください。
次回は「Dive deep into NAT gateway’s SNAT port behavior」を紹介します。