1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

仮想ネットワークアプライアンスを導入するときは、スループットだけではなく「ネットワークフロー数」も確認しましょう

Posted at

はじめに

 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 FlowsOutbound 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 を導入する際には、事前にフロー数も確認いただければと思います。

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?