NSX ALB Service Engineのメモリサイジング

今回はService Engineのメモリサイジングについて調べた内容をメモ程度に書いていきたいと思います。

Service Engineが通信のロードバランスを行う際、いくつまでの同時接続数を処理できるかを左右するのはメモリの容量となります。
そのため、Service Engineをデプロイする際、本番サービスでどの程度の同時接続数が発生するのかを事前に考慮し、その数を処理できるだけのメモリを割り当てておかなければなりません。

1. Service Engineに設定可能なメモリ容量

Service Engineでサポートされるメモリ容量は1～128GB
※AviVantageでは最小でも2GB以上を設定するよう推奨しているようです。

2. メモリサイジングの考え方

AviVantageによると、Service Engine（SE）で処理可能な同時接続数は以下の式で計算できます。

処理可能な同時接続数 = （（SEのメモリ容量 － 500MB － （100MB×vCPU数）） × 接続パーセンテージ）÷ 1接続あたりのメモリ容量

SEのメモリ容量はそのままService Engineに設定したメモリの容量ですね。
500MBというは、SEが稼働するために使用されるベースのメモリ容量です。
そして、Service EngineはvCPU毎に100MBのメモリを割り当てるため、それらの分をメモリ容量から引いたものが接続を処理するためのメモリ容量となります。

接続パーセンテージというのは、Service Engineに設定された接続を処理するための共有プールのパーセンテージのことです。
Service Engineでは接続を処理するためのメモリ容量を共有メモリプールとして保持し、それをConnectionsとBuffersの2つのコンポーネントに分割しています。
この２つのコンポーネントが使用するメモリの容量はService Engineの「接続メモリの割合」という項目で増減させることができます。

この割合はそれぞれに最低10%を割り当てる必要がありますので、どちらかを100%にすることはできません。
また、設定は新しく作成されるService Engineだけに適用され、既存のService Engineには適用されないので注意。

この中のConnectionsが接続を処理するための項目で、Buffersはパケットをキューに入れておくための容量です。
Buffersは、例えば【クライアント】-【Service Engine】-【サーバ】という構成の中で、クライアントとService Engine間のネットワークで遅延が発生しているが、Service Engineとサーバの間では遅延が発生していない場合、サーバからクライアントへの応答をService Engineがバッファ領域に溜めて少しずつ応答を返していくという動作をするために必要な容量となります。
ですので、Service Engineのメモリ容量は、同時接続の処理量だけでなく、Buffer分も含めて考えなければなりません。

1接続あたりのメモリ容量は異なるレイヤー毎の1つあたりの通信量となります。
例えば、こちらはAviVantageが示している標準的なメモリ消費量です。
　L4：10KB（0.01MB）
　L7：20KB（0.02MB）
　L7+SSL：40KB（0.04MB）

1接続あたりこれだけのメモリを消費しますので、どのレイヤーの通信をロードバランスするのかも事前に考慮する必要があります。

以上がService Engineのメモリサイジングの考え方となります。

仮に、50%の接続パーセンテージで8vCPU、8GBのService Engineで、L4の通信をロードバランスする場合、処理可能な同時接続数は以下のようになります。

（（8000 － 500 －（100×8））× 0.5 ÷ 0.01 = 335,000

接続パーセンテージについては実際の環境で使ってみてどの程度にするかを考えていかなければならないので、運用の中で少しずつ修正していく必要はありそうですね。

Service Engineのメモリサイジングの考え方でした。