ソリューション

マクニカネットワークスが取り扱う製品で、皆様の課題を解決します

圧倒的なパフォーマンスの差が明らかに!
仮想ファイアウォールAltorの実力徹底検証

マクニカラボ便り

「マクニカラボ便り」は、ちょっとやってみたい検証や、このテクノロジー、こう使ってみたらどうなる?など、マクニカネットワークスのエンジニアが気になった製品や技術について、ディープな検証や評価を行い、面白かったら皆さんにも公開しようという、ちょっと気まぐれなコーナーです。

ハイパーバイザー組込型セキュリティソリューションAltor(アルタ)は、セキュリティ処理を完全にハイパーバイザーのカーネルに組み込む"VMsafe Fast-Path"方式に対応することで、導入によるオーバヘッドを極小化し、高いネットワーク・パフォーマンスを実現しています。このパフォーマンスについてのアドバンテージが一体どれほどのものなのか、弊社内で実際に構築した環境にて、他社製品とあわせてパフォーマンス計測を行うことで、その実態に迫ります。

【今回のチャレンジ】

今回、使用するのは、Altor、およびA社製品(Altorと同じくVMsafe対応で仮想ファイアウォールを実現できる)の2製品。弊社内に構築した検証用の仮想サーバ環境において、この2製品を用いてそれぞれ仮想ファイアウォールを有効化した上で、パフォーマンス計測を行ってみました。

仮想ファイアウォール検証のための環境

まずは各製品を使用するにあたり、必要な機材を用意した上で、検証用の仮想サーバ環境を新たに構築いたしました。

使用機材の詳細

今回の検証では、以下の機材を使用しました。

【サーバ】
Dell PowerEdge M610(ブレードサーバ)…… 2台
CPU Intel Xeon X5650 (2.66GHz/6コア) ×2
メモリ 48GB (6x8GB/2R/1333MHz/DDR3/RDIMM)
HDD 146GB (2.5インチ/SAS/15,000回転) ×2
PCI Broadcom 57711 10GbE Ethernetドーターカード
サーバ 【スイッチ】
Juniper EX3200-24T + EX-UM-2X4SFP(10Gアップリンクモジュール) スイッチ これらの機材をラックマウントし、弊社内の検証ルームに設置しました。 サーバ スイッチ

仮想サーバ環境の構成

上記の機材を用いて、今回の検証用に以下のような仮想サーバ環境を構築しました

仮想サーバ環境の構成

仮想ファイアウォールのルール設定

20台の計測対象VM に対して仮想ファイアウォールを有効化し、ルール設定を行いました。ダミーのDeny(拒否)ルールをインバウンド(インカミング)側に10個設定し、すべての通信がそれ以降に許可されるように設定しました(※以下はAltor Center での設定画面ですが、A社製品でも同等の設定を行いました)。

仮想ファイアウォールのルール設定

なお、両製品ともにログ出力等は極力無効化し、純粋に仮想ファイアウォールの処理のみが実行されるように設定しました。

Webリクエスト処理性能を徹底計測!

今回は、最も一般的なサーバ利用目的の1つであるWebサーバによるファイル公開について、そのリクエスト処理性能の計測を行いました。

計測内容

計測ツールとしては Apache Bench を使用しました。
計測対象VMに設置されたApache HTTP Serverで様々なサイズのファイルを公開しておき、計測実行VMからそれらの公開ファイルに対してApache Bench を同時実行します。実行条件については、1VMあたり10,000リクエスト、10同時接続で行いました。
また、計測実行中のCPU使用率について、ESXホスト上でesxtopコマンドを実行することで併せて計測しました。

計測結果

Apache Bench によって計測された単位時間あたりのWebリクエスト処理数(RPS)の結果は、以下のようになりました(※20台×3回分の計測値を平均)。

単位:RPS

  30kb 125kb 256kb
FSX単体 641.20 287.62 143.40
Altor 477.08 266.87 141.38
A社製品 69.97 30.91 16.18

この計測結果を分り易くするために、ESX単体(仮想ファイアウォールなし)の計測結果を100%とした比率でグラフ化すると、以下のようになります(※Altorについては、Denyルールを100、1000に増やした場合の計測結果についても参考として追加しています)。

計測結果

仮想ファイアウォールの有効化によりパフォーマンスはAltor、A社製品共に劣化していますが、特にA社製品のリクエスト処理数が約10%程度と極端に悪くなっていることが確認できます。

この原因についての考察ですが、A社製品の場合には実際のファイアウォール処理の大部分をESX上の1VMインスタンスである仮想アプライアンスで実行しているため、そこでの処理がボトルネックとなっているのだと考えられます。

計測実行中のESXホストのCPU使用率を見てみると、仮想アプライアンスのCPU処理により一部のCPUコアが100%の使用率を計測する一方で、全体平均としては50%程度のCPU性能しか使いきれていないということが確認できます。

計測結果

一方、Altorの場合には、ファイアウォール処理はESXホスト上のVMカーネルですべて実行される仕組み("VMsafe Fast-Path"方式)となっているため、CPUについてもほぼ万遍なく使用されていました(※グラフの横幅が10分間固定のため、3回分の計測が併せて記録されています)。

計測結果

また、これらの結果から1処理あたりの必要クロック数を256kbのケースで簡易的に計算してみると、A社製品で25.5MHz、Altorで4.6MHzとなります。A社製品ではAltorと比較して1処理あたり約5倍のCPUコストが掛かってしまっていたことになり、“速度”だけでなく“燃費”も悪かったということになります。

なお、参考として、仮想ファイアウォールを全く設定していないESX単体の状態のCPU使用率の結果についても併せて掲載しておきます。

計測結果

まとめ

今回の検証により、同じVMsafe対応の仮想ファイアウォール製品の間でも、そのパフォーマンスには大きな差があるということが実際に確認できました。

少なくとも今回の検証の条件下では「仮想アプライアンスでファイアウォール処理を実行しているA社製品を使用した場合には、Webリクエスト処理性能が極端に低下してしまう」ということが確認されています。実際の利用シーンでは様々な条件が異なってくるため一概には言えませんが、今回の結果から、仮想ファイアウォール製品の導入をご検討いただく際には「その製品を導入した場合に必要十分なパフォーマンスが確保できるのか?」という点についても十分にご確認いただいたほうが良いということは間違いなく言えそうです。

なお、従来型のファイアウォール製品(仮想アプライアンス版)については今回計測していませんが、アーキテクチャ上、A社製品と同じく仮想アプライアンスでの処理がボトルネックになることで同様の結果(あるいは更に悪い結果)になる可能性が高い、と考えられます。こちらについても、今後、機会があれば実際に計測を行ってみたいと思います。

いつか見た景色 from Staff's Albums