はじめに
Microsoft Azure にファイアウォールのネットワーク仮想アプライアンス(NVA)を導入後、通信が遅延したり、パケットロスが起きるという事象が発生しました。ネットワークトラフィック量は NVA 製品のカタログスペックを下回っており、CPUやメモリなどの使用率も問題が無いにも関わらずです。結論としては、Azure 仮想マシンの ネットワークフロー数の制限 に引っかかっていたということでした。
ネットワークフロー数の制限とは
Azureの仮想マシンには、ネットワークフロー数に関する制限があります。
現在、Azure のネットワーク スタックでは、1 つの VM について合計 100 万個のフロー (50 万個の受信と 50 万個の送信) がサポートされています。
ネットワークフロー数は、ネットワーク接続数との関連性が高い概念ですが、セッション数と同等ではありません。TCP の three-way handshaking でいうところの、 SYN, SYN+ACK がそれぞれ 1フロー とカウントされます。このフローについて、 Inbound、Outbound それぞれの方向に関して、50 万個までのアクティブなフローがサポートされるという制限があります。一瞬でもフロー数が 50 万に達すると、通信の遅延やパケットロスが発生する可能性があります。
仮想マシンでどのくらいのネットワークフロー数が発生しているかは、 Azure Portal から確認することができます。仮想マシンのメトリックで、 Inbound Flows や Outbound Flows を選んでください。
また、NSGフローログでも確認することができます。NSGフローログの詳細は以下をご参照ください。
ただし、NSGフローログで確認できる値は、実際の数とは異なる可能性があります。
ユーザー定義の受信 TCP ルールの問題:ネットワークセキュリティグループ (NSGs) は ステートフルファイアウォール として実装されます。 ただし、現行のプラットフォームの制限により、受信 TCP フローを制御するユーザー定義ルールはステートレスな方法で実装されます。 これに起因し、ユーザー定義受信ルールに制御されるフローは終了しなくなります。 また、これらのフローのバイト数やパケット数は記録されません。 結果として、NSG フローログ (および Traffic Analytics) で報告されるバイト数とパケット数は、実際の数とは異なる可能性があります。
メトリックでのネットワークフロー数の確認方法について
Azure Portal でネットワークフロー数を確認できることは前述の通りですが、その確認方法について一つ注意点があります。
ネットワークフロー数の制限は、アクティブなフロー数に関するものであるため、確認すべきはアクティブなフロー数の推移です。
NICが一つである仮想マシンについては、メトリック Inbound Flows あるいは Outbound Flows で 集計 を 最大値 に設定すれば確認することができます。
しかし、NICが複数ある仮想マシンでは、その見方では確認したい値となりません。 最大値 の場合、複数の NIC の中で、最もフロー数が多い NIC に関する フローの最大値が表示されてしまうためです。ネットワークフロー数の制限は、NICごとではなく、仮想マシンごとの制限であるため、すべての NIC のアクティブなフロー数を合計した値を確認する必要があります。結論としては、 集計 を 合計 にし、 時間の粒度 を 1分 にして見る必要があります。
注意点として、 集計 を 合計 にすることは、 NIC の合計と、単位時間当たりの合計という2つの合計の意味があります。そのため、 時間の粒度 を 5分など、1分より大きい値とした場合、 その時間の合計値が表示され、アクティブフロー数の推移を確認するという目的には合わなくなります。
この仕様は、 2023年1月 現時点で Microsoft のドキュメントに記載はありません。Azure の技術サポートの方に教えていただいたことでわかりました。実際に、手元の検証環境でフロー数を確認した際、 NIC が一つの仮想マシンでは、 最大値 で確認できる値と、 集計 を 合計 にし、 時間の粒度 を 1分 にした値は等しくなりました。一方で、NIC が複数ある仮想マシンの場合は、 最大値 で確認できる値と、 集計 を 合計 にし、 時間の粒度 を 1分 にした値は、後者の方が多いという結果でした。
まとめると以下です。
仮想マシンのアクティブなフロー数を確認する方法
仮想マシンのNICの数 | 集計 | 時間の粒度 |
---|---|---|
1つ | 最大値 | 任意の時間で確認可能 |
2つ以上 | 合計 | 1分 |
おわりに
この事象が起きたプロジェクトでは、NVA 1台ではネットワークトラフィックをさばききれないということが分かったため、間に Azure Load Balancer を入れ、複数台の NVA で負荷分散する構成に変更することとなりました。
NVAの場合は、その機能の特性上、ネットワークフロー数が多くなることが予想されます。トラフィックが多くなる場合は、NVA をスケールアウトできる構成にすることをおすすめします。
また、このようなネットワークフロー数の制限について、現時点では Azure でしかドキュメントでも仕様を確認できていませんが、AWS や Google Cloud 等ほかのクラウドでも同様の事象が起こりうると想像されます(※違っていたらご指摘ください)。クラウドに NVA を導入する際には、事前にフロー数も確認いただければと思います。