実測、VeloCloud 通信コネクション処理性能

VeloCloud実測シリーズ第三弾、今回はVeloCloudのデータシートに記載されている”Flow Per Second”の数値について、当社で検証した結果をご紹介します。

過去の実測 VeloCloud

・実測、NSX SD-WAN by VeloCloud Edgeのスループットとその真価
・実測、VeloCloud WAN最適化機能の効果

Flow Per Secondについて

VeloCloud公式データシート(2020年1月7日現在)には、Performance and Scaleの表にFlow per secondの項目があります。
VMware SD-WAN by VeloCloud VMware SD-WAN Edge Platform Specifications
https://sase.vmware.com/content/dam/digitalmarketing/vmware-sase/pdfs/sdwan-712-edge-platform-spec-ds-1020.pdf

話を解りやすくするため、以降Flowのことをコネクション(Connection)と呼ぶことにします。
厳密にはコネクション≠Flowなのですが、ここでは解りやすさを優先します。
また、性能の指標としてのFlow per secondをFPS、Connection per secondをCPSと省略して表記します。

Flow per secondの項目は”1秒間に何本の通信コネクションを新規に通すことが可能か”という性能を示す数値です。
具体的に何を基準として新規のコネクションであるのかを区別しているのかについては、残念ながら詳細は開示されていないため、このブログではご説明することができません。

これをお読みになる皆さんは既にこの数値がどのような意味を持つのかについて十分にご存じかもしれません。
一応、念のため、どういった意味があるのかをご説明します。

例えば、とあるクラウドサービスを利用する通信では、PC1台当たりおよそ50～100程度のコネクションがクラウド側との間で張られます(サービス、ソフトウェア、バージョン等によって大きく変動するため、あくまでも例えばの話)。
従業員200人が勤める建物の午前9時頃、出社してPCを起動し、今日のスケジュールを一斉に確認し始めた場合、200台のPC × 100 コネクション = 20,000 コネクションとなります。
1秒以内に全員が同時にせーの、というのはよほど訓練された企業でなければ起こりえない行動ですが、近年のPCは様々な通信を常に行っているため、実際はより多くのコネクションが新しく張られ続けています。

さて、20,000という数字はデータシートのFPS(CPS)の数値を超えています。
こうなると、VeloCloudは新たに発生したコネクションをクラウド側に転送することができなくなり、
・既に張られていたコネクションがリセットされる
・新たに到着したコネクション要求通信が破棄される
・新たに到着したコネクション要求通信の転送が遅れる
(TCPの性質上、破棄(ドロップ)や遅れ(遅延)が発生すると、アプリケーション側の待ち時間が大きく増幅されます)
といった動作をとります。
その結果、クラウドサービスを開こうとした利用者は
・ページが開かない
・動作が重い(モッサリしている)
といった悪い影響を感じます。
多忙な現代人はWebページの表示待ち時間が3秒を超えるとイライラするという調査結果もあり、”使い物にならない”という判断が下される恐れがあります。

FPS(CPS)とは、それほど重要な性能の一つなのです。
前置きがかなり長くなってしまいましたが、ようやく。

実測！

今回はすべて当社のラボ内でクローズドな環境を構築し、Spirent Avalancheを利用したHTTP Getの成功速度を判断基準としたCPSを計測しました。
測定対象機器はVeloCloud Edge(VCE) 2000 Version 3.3.2、データシートのCPSは19,200です。
なお、実際のインターネット回線やクラウドサービスを利用した場合、利用しているサービス、アプリケーション、通信内容、その他多くの要素により、性能の限界値が変動します。

測定結果グラフ

グラフの緑線と赤線が拮抗している部分が安定して処理が実行されているレートを示しています。
VCE2000において、25,000 CPSであれば安定して処理されていることがわかります。
メーカの公証CPSは19,200ですので、より高い性能を発揮しています。
グラフ横軸の70秒前後でSuccessfulレートが低下し、Unsuccessfulも右に行くにつれ増加していきますが、これはMax Concurrent Flow(保持可能なコネクション数=フローテーブル)の溢れによる影響と判断します。

負荷レートを30,000 CPSに増やしてみます。

※グラフの縦軸スケールが変化していますのでご注意ください。

横軸20秒を経過した後、瞬間的に27,000 CPSを超えましたが、その後はSuccessfulレートが低下していきます。
30,000 CPSには耐えられなかったようです。

まとめ

今回試験できたのはVeloCloud Edge 2000の1機種のみでしたが、データシートの数字のおよそ30%増しの性能が出ることがわかりました。

ただし、繰り返しますが、これはあくまでも試験環境での単一性能試験の結果です。

VeloCloudは他にも様々な処理を同時に実行しています。
それらの機能の利用状況や、クラウドサービスの利用、アプリケーション、バージョン、通信環境により性能の限界は変動します。

なお、今回測定に使用したVeloCloudのファームウェアバージョンは3.3.2です。
VMwareからは今後のバージョンアップによって更に性能の限界値を引き上げていく、といった旨の連絡を受けており、今後の進化が期待されます。

(このシリーズはいつまで続けられるのか、私の限界値にもご注目ください。)

※本記事の内容は執筆者個人の見解であり、所属する組織の見解を代表するものではありません。