よってらっしゃい見てらっしゃい!!

Security商材のサイジングでお困りのそこのあなた!!

耳寄りな情報がございますよ!!

＿人人人人人人人人人人人人人人人人人＿

＞　みなさま こんにちは林です( ˘ω˘)   ＜

￣Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^￣

今年で入社5年目、良い感じに脂の乗った若手SEです。お腹の脂も良い感じに乗っており、皆さまよりご好評頂いております。入社してから現在まで、Router・Switch・Wireless商材を主戦場として対応してまいりました。そろそろ飽きてきたので新しいフィールドで自分の力を試したいと思っており、現在はSecurity製品を勉強中です。  

弊社ネットワンパートナーズでは様々なSecurity商材を取り扱っており、その中でもUTM Firewallに関するお問い合わせを頂くケースが多いです。お問い合わせの中でも特に気を配るのが、UTM Firewallをご提案する際の”機種選定”です。基本的にメーカーが提供しているカタログスペック表やデータシートを参考にする機会が多いです。  

しかしながら、性能に関する部分については検証を行う環境に依存しますし、どのメーカーも自社が一番だと言ってのけます。全く同じ環境で、異なるメーカーのFirewallの性能を比較するのがフェアな条件と言えますよね。ということで今回は、社内のFirewallをたくさん寄せ集めまして、Avalancheというトラフィックジェネレーターを使って性能の比較検証を行ってみました！      

検証構成はシンプルに以下の様になっております。測定方法としてはトラフィックジェネレーター(Avalanche)よりHTTP1.1のトラフィック印加し” bit per second(以下bps)”と” Connections per second(以下cps)”をそれぞれ測定します。   

CPSは1秒間当たりにFirewallが処理できるコネクションの数です。Firewallをサイジングするうえで重要な指標となります。数年前であれば、１ユーザー当たり8CPSほどで見積もっていましたが、WEBの進化に伴いまして現在では、１ユーザー当たり30CPSで見積もっています。もし、既存でFirewallが導入されているのであれば、既存Firewallのスペックが指標となります。  

以下がcps(tps)の測定結果となります。通常1つのコネクションに対し複数のトランザクションが発生する場合もあるので、cpsとtpsはわけて考慮いたしますが、今回の検証パターンの場合、1つのコネクションに対し複数のトランザクションが発生しないためcpsとtpsがほぼ同じ結果となります。このため今回はTPSのグラフを利用させて頂きます。

 上記グラフについて、縦軸がトランザクション、横軸が時間となっております。また、赤色のグラフ(Attempted)が印加したトラフィック、緑色のグラフ(Successful)はコネクションをはるのに成功したトラフィック、紫色のグラフ(Unsuccessful)はコネクションをはるのに失敗したトラフィックとなります。  

このグラフで注目するところは2つあります。

1つは赤色のグラフ(Attempted)緑色のグラフ(Successful)が乖離しはじめている個所となります。理由としてTCPでは再送処理があるため1度失敗したと言ってもすぐにはUnsuccessfulとなりません。このため上記グラフでUTMにおける最大CPS(TPS)は紫色のグラフ(Unsuccessful)が上昇し始めた個所ではなく(Attempted)緑色のグラフ(Successful)が乖離しはじめた直後という事となります。  

もう１つは、紫色のグラフ(Unsuccessful)が上昇し始めた後の緑色のグラフ(Successful)についてです。こちらはUTMでさばききれない過度なトラフィックが流れた際の挙動を考察する事が出来ます。  

1つの結果を抜粋してみると  

上記の通りほぼメーカから開示されているスペック通りの結果を確認できました。

注目すべき点は過度なトラフィックが流れてからの製品の挙動です。今回検証した製品にて過度なトラフィックが流れている状況では、どの製品でもCPUが高騰しております。   このCPUが高騰した状態でも一定のTPSを担保する挙動をする製品や逆に既存のセッションをリリースしないような製品など製品毎で違った挙動が確認できました。こういった挙動に関してはメーカドキュメントなどでは確認する事が出来ずこういった検証を行って初めてわかる情報となります。  

今回はあくまで簡易検証という事でHTTPのトラフィックのみを利用しました。

ほぼメーカから開示されているスペック通りの結果は得られましたが、次回は各機器の特性を考慮した上でマルチプロコルを利用した検証を実施できればと思います。

★おまけ

Cisco Spark  & Cisco Spark Board使ってみました。  

本検証で最近話題のCisco Spark & Cisco Spark Boardを活用してみました。  

◆Cisco Sparkって？

Cisco Sparkは、いつでも・どこでも・だれでも・だれとでもクラウド上でつながる次世代コラボレーションプラットフォームです。チャットや資料共有だけではなく電話をかけたりビデオ会議に参加をしたりを１つのアプリに集約しております。  

Cisco Sparkの詳細については、また別記事で紹介します。  

◆Cisco Spark Boardって？

他社製品でもチャットや資料共有や電話・テレビ会議を行える製品はございます。

これらのデバイスは聞く・話す・書く・共有するといったコミュニケーションは可能でしたがCisco Sparkでは新たに”描く”というコミュニケーションが可能です。

Cisco Spark Boardこの”描く”というコミュニケーションに特化した利用方法が可能です。文字だけでは伝わりにくいかと思いますので実際の利用しているイメージがこちらです。

この写真だけですとただの電子ホワイトボードですが、Cisco Spark はCisco Spark Boardで描いた絵を他のデバイスでも共有する事が出来ます！！

また、共有だけではなく共有されたデバイスから書き込むことも可能です。

今回の検証においてなかなか検証メンバーが全員集まれないといった場面もありましたが、Cisco Sparkを利用する事で検証の構成イメージをスムーズに共有したり、意見があれば直接描き込むなどスマートなコミュニケーションをとる事が出来ました。

Cisco Sparkの詳細に関しては改めてこちらのブログでも紹介いたしますが、ご興味を持たれた方は是非弊社までお問い合わせください。