本文へジャンプします。

ニフティクラウドをベンチマークしてみた(L7ロードバランサー Stingray編)

みなさま、はじめまして。
ニフティ入社1年目の岡田です。

ご存知の方も多いと思いますが、ニフティクラウドではL4ロードバランサーの他に、L7ロードバランサーをご用意しております。
ということで、今回はニフティクラウドでL7ロードバランサー(Stingray Traffic Manager L7LB)を用いた構成を組み、ベンチマークを行いました!

ちなみに、Stingray Traffic Manager L7LB(以下、Stingray)については図研ネットウエイブ株式会社様のページに記載しておりますのでご覧ください。

ベンチマーク概要

ベンチマーク条件は後述しますが、ベンチマークの概要は下図の通りです。
Stingray配下にWebサーバーを複数台配置し、ページサイズの異なる7種類のHTMLファイル(128B, 2KB, 8KB, 32KB, 64KB, 28KB, 256KB, 512KB)を用意しました。負荷発生サーバーとStingray間の通信はHTTPSで行っています。

また、結果は負荷発生サーバーからリクエストを送り、レスポンスを受け取るまでを1トランザクションとし、『Transaction per sec: 1秒当たりに処理されたトランザクション数』(以下、TPS)を性能指数として、Stingrayのサーバースペック別に比較しております。

gaiyou

ベンチマーク結果

Webサーバー2台構成

それでは早速結果を見ていきましょう。こちらはStingray配下のWebサーバーをwlarge64で2台用意して計測しました。どうやらStingrayはサーバースペックによってパフォーマンスに違いが出るようですね。
p1

Webサーバー4台構成

続いてStingray配下のWebサーバーをmediumで4台用意して計測した結果を見ていきましょう。TPSはページサイズによりますが、微増する結果となりました。ただし、64KB以上においては2台構成時と同等の値に収束する結果となっています。
p2

分析

結果をご覧になりいかがでしょうか?注目していただきたいのは、最も利用されるページサイズである64KB~512KB時の結果です。64KBの時点で流量は1Gbpsを超え、512KBの時には2.5Gbpsを確認しました。Stingrayはネットワークがボトルネックになり十分な性能を発揮できない事がありますが、ニフティクラウドは強固なネットワーク基盤を準備しているのでそのような心配はありません。
とはいえ、サーバースペックによって性能差が出た要因はどこにあったのでしょう?
ということで監視サーバの出番ですね!ちなみに、監視サーバはmuninを利用しました。

メモリ

それではまずはStingrayサーバのメモリ使用量を見てみましょう。

m1

余裕ありですね!参考までにlarge32での結果も見てみましょう。

m2

どうやらStingrayはメモリの利用量は低く、余裕を持っても2GBあれば十分ということがわかります。

CPU

では次にCPUの利用率を確認します。
まずはsmall8から見ていきましょう。

c1

ものすごく負荷が高いですね。CPUの利用率がほぼ100%で張り付いています。
どうやらCPUが怪しいみたいですね。確認のためにlarge32の時の状況も見てみましょう。

c2

small8との差は歴然ですね。やはりHTTPS通信を利用していることで、パフォーマンスがCPUに依存する結果となったようです。
以上のことからStingrayの導入を考える場合、サーバーはmedium以上を指標として、性能を求める場合はlarge以上を選ぶのが宜しいでしょう。また、メモリ利用の状況を考慮するとmedium, large, xlarge16の中から選定できそうです。

エラー

Webサーバーの台数を多くしたところTPSは微増でした。しかし、2台構成時ではリクエストが集中したときにWebサーバーで待ちが発生し、タイムアウトとなる確率が高まることを確認しています。
参考までに2台構成時に行ったテストで発生した最大エラー値をご覧ください。

 リクエスト数:700000    エラー率:1.27%    

値としては大きくありませんが、エラーの発生は信頼性の低下につながります。しかし、4台構成にすることでエラー率は全テストケースにおいて 0% に抑えることができました。
つまりはL7ロードバランサーにおいても配下に並べるサーバーは多い方が信頼性の向上につながるということです。利用する際は高スペックサーバーを少数台設置するより、スペックを落として複数台並べる設計がオススメです。

ベンチマーク条件

今回のベンチマーク条件は以下の通りです。

ツール

ベンチマークツール

Apache JMeter Version2.9

テストケース

スレッド数:700 Ramp-Up期間(秒):10 ループ回数:1000

各サーバー情報

負荷発生サーバー

スペック : xlarge36
イメージ : Microsoft Windows Server 2008 R2

Stingrayサーバー

スペック : 可変(small8,medium16,large32)
イメージ : StingrayTM92

Webサーバー

スペック : wlarge64(2台構成時)、medium(4台構成時)
イメージ : CentOS 6.3 64bit Plain
※Webサーバーは1台準備して設定が終了した後に『サーバーコピー』を利用すると便利です!

監視サーバー

スペック : small2
イメージ : CentOS 6.3 64bit Plain

ネットワーク

負荷サーバー~Stingray間

443番ポートかつプライベートIPで接続

Stingray~Webサーバー間

80番ポート接続かつプライベートIPで接続

監視サーバー~各サーバー

4949番ポートかつプライベートIPで接続

Stingray

ライセンス

Stingray Traffic Manager VH4000

チューニング

以下がアプリケーション側での設定です。設定値はRiverbed社のTuning Stingray Traffic Manager for best performanceを参考にしました。

・Global Settings
 recent_conns    : 0
 Verbose logging  : すべて【NO】に設定

・VirtualServers
 ssl_decrypt   → Yes 
 keepalive     → No
 add_cluster_ip → No
 Memory Limits  → 204800

・Pools
 keepalive    → No
 LoadBalancing  → Round Robin 
 Monitor     → PING
 max_connect_time : 8 sec
 Basic Settings  : delay 6 sec
            timeout 12 sec
            failures 4

Stingrayサーバーはカーネルチューニングを行っています。チューニング値に関してはRiverbed社のTuning the Linux operating system for Stingray Traffic Managerを参考に設定しました。

# cat /proc/sys/net/ipv4/ip_local_port_range
32768   61000
# cat /proc/sys/net/ipv4/tcp_fin_timeout
30
# cat /proc/sys/net/ipv4/tcp_syncookies
1
# cat /proc/sys/net/core/somaxconn
1024
# cat /proc/sys/net/ipv4/tcp_max_tw_buckets
7200000
# cat /proc/sys/net/ipv4/tcp_slow_start_after_idle
0
# cat /proc/sys/net/ipv4/tcp_timestamps
0
# cat /proc/sys/net/ipv4/tcp_window_scaling
0

Webサーバー

ソフトウエア

Apache 2.2.15

チューニング

【2台構成時】

# cat /etc/httpd/conf/httpd.conf | grep '' -A 7

StartServers       8
MinSpareServers    5
MaxSpareServers   30
ServerLimit    3840
MaxClients      3840
MaxRequestsPerChild  2000

【4台構成時】

# cat /etc/httpd/conf/httpd.conf | grep '' -A 7

StartServers       8
MinSpareServers    5
MaxSpareServers   30
ServerLimit    1024
MaxClients      1024
MaxRequestsPerChild  2000

ベンチマーク方法と結果の見方

ベンチマーク方法と実行結果の見方について以下に記載します。
Stingrayでは設定項目が多く、自由度も高いのでいろいろ試すと面白いと思うので是非お試しください。
※以下のインストール手順や実行方法は今回のベンチマーク環境下によるものです。
※ベンチマークはサーバーを一時的に高負荷状態にさせますので、注意して実行してください。

Javaのインストールと設定

今回利用するJMeterはJavaで動作するアプリケーションですので負荷発生サーバーにJavaをインストールする必要があります。
1.負荷発生サーバーにJavaを下記のサイトからダウンロードします。
http://java.com/ja/

2.ダウンロードしたファイルを実行し、指示に従って進めればインストール終了です。

JMeterのインストール

1.負荷発生サーバーにJMeterを下記のサイトからダウンロードします。
https://jmeter.apache.org/

2.ダウンロードしてきたファイルを解凍することでインストールの完了です。

テスト計画の作成

1.JMeterを解凍したディレクトリのbin配下にあるjmeter.batを実行します。

2.テスト計画にスレッドグループを作成し、スレッドプロパティにテストケースを入力します。

スレッドグループ
3.HTTPリクエストを作成し、Stingrayサーバーを対象に指定し、HTTPS通信を利用するように設定します。

SnapCrab_NoName_2013-9-20_15-12-16_No-00

4.テスト計画の作成が完了したら保存します。

JMeterの実行

1.コマンドプロンプトを開き以下のコマンドを実行します。

# java -jar \binApacheJMeter.jar -n -t <テスト計画パス> -l <ログ保存先パス> 

※テストケースによってはJavaのヒープサイズを変更する必要があります。

実行結果の見方

1.JMeterを解凍したディレクトリのbin配下にあるjmeter.batを実行します。

2.テスト計画に『統計レポート』を追加します。
SnapCrab_NoName_2013-9-20_15-43-8_No-00

3.統計レポートの『すべてのデータをファイルに出力』でJMeterを実行したときに保存したログデータを指定することで各結果の出力が可能です。なお、今回のご紹介したTPSは、表の「Throughput」の値と対応しています。

終わりに

今回はニフティクラウドにおけるStingrayの性能特性を分析しました。Stingrayの性能の良さもさることながら、強固なネットワーク基盤を持ったニフティクラウドとの相性の良さもご確認いただけたでしょうか。

Stingrayは性能以外にもL7ロードバランサーならではの魅力と利点があります。私は初めてStingrayに触れましたが、管理しやすいUIと多彩な機能が用意されており、細かなカスタマイズが可能です。それによってメンテナンス性・セキュリティ性・信頼性の向上が見込めます。機会があればそちらもご紹介したいと思います。

もしロードバランサーの導入を検討していましたら、ニフティクラウドのL4ロードバランサーだけでなくL7ロードバランサー『Stingray』も一度お考え頂ければと思います!!

ニフティクラウド 導入相談窓口
ニフティクラウド 無料セミナー

閉じる

閉じる

クラウドブログ編集部

クラウドブログ編集部

ニフティクラウド ユーザーブログ編集部のアカウントです。 編集部からのお知らせや、レギュラーライター以外のゲストによる寄稿記事を掲載していきます。

浜中 慶

浜中 慶

1980年、神奈川県生まれ。2003年ニフティ入社。 ポータルサイト開発を中心に、音楽配信サービス、CGMサービスなど様々なプロジェクトに企画/デザイン/システム担当として参加。現在は@niftyのポータルサービス向けコンテンツ管理システムの企画/開発/運用を担当。

吉田 雄哉

吉田 雄哉

株式会社co-meetingの創業メンバー。「取締役&External- facing Technologist」と名乗り新しいIT技術を広く伝える活動とWebアプリケーション開発を行う毎日。パッケージベンダーでのSaaS立上げ・製造業の情報システム部門で企画やPM・受託開発と従事してきたため、ベンダーサイドとユーザサイド の両方の視点を持ち合わせる。

石田 健亮

石田 健亮

株式会社ドリーム・アーツで小売事業者向けSaaS「Shopらん」を企画、開発。メインの仕事はプログラマーだがサーバー管理や営業もこなすユーティリティプレイヤー。最近好きな事はパフォーマンスチューニング。特に並列化プログラミングがマイブーム。キライなことはデータセンターでの作業。騒音と乾燥が弱点。ニフティクラウドでデータセンターに行く必要が無くなったことが本当の利点だ と思っている。

五月女 雄一

五月女 雄一

ニフティでは「インフラを守る簡単な様で奥が深いお仕事」をしています。 夢はインフラの気持ちが読めるエンジニアになること。

わたなべ かずひろ

わたなべ かずひろ

専門学校卒業後、ソフトウェア開発会社で電力系統制御システムの開発に従事。その後、CD-ROM等マルチメディア系PCソフトの開発を経て、1998年フリーランスに。 2000年8月に株式会社イーツーの設立に参画。携帯を含む様々なWeb系のシステム開発に携わる。現在はiPhone/Androidアプリなどの開発も手がけている。

市角

市角

ニフティクラウドのコントロールパネル設計・開発をメインに、たまにインフラの運用やお手伝いもやっていたりします。コントロールパネルや新機能の活用方法、アイデアなどを中心に書いていく予定です。

仲山 昌宏

仲山 昌宏

歌って踊れるインフラエンジニア兼、PHPもRubyもJavaも書くPerl使い。 物理サーバの運用に飽きて、フルラックに格安サーバ詰めて自宅プライベートクラウドを構築中。 今年は個人的には分散処理を攻めていきます。

猪飼 賢広

猪飼 賢広

1984年、愛知県名古屋市生まれ。大学は福島県にある某大学。2008年ニフティに入社。 開発系部署に配属後、主に各種テーマサイト開発のシステム面調整、開発進行管理役などとして参加。 現在もPC・ガラケーサイトの開発まわりを担当。インフラまわりを触る案件にも携わっており、日々修行中。 好きな芸人はなかやまきんに君とレイザーラモンRG。

久江 裕之

久江 裕之

ニフティクラウドのインフラ運用、OS提供の仕事をしています。 新しいOSやイメージが出る時にこのブログでご紹介いたします。入社5年目。一流のインフラエンジニアを目指して日々勉強中。

竹内 豪

竹内 豪

ニフティクラウド エンジニア

山口

山口

ニフティクラウドの基盤設計、新サービス/アライアンス/インフラ企画、その他雑用全般を担当しています。 クラウドに欲しい機能や、こんなふうに使ってほしいという想いが共有できれば良いですね。

芳中 隆幸

芳中 隆幸

ニフティクラウドの開発、運用を担当しています。

酒井 浩平

酒井 浩平

ニフティクラウドの中にいます。 ネットワークまわりの運用・開発や自動化などに取り組んでいます。 すべてのエンジニアを幸せにすることを目指しています。

higebu

higebu

ニフティクラウド IaaSのエンジニアです。 ネットワーク、DRサービス with VMware vCloud® Air™ Technology辺りの担当をしています。

武田

武田

ニフティクラウドの開発・運用を担当しています。 各種機能の内容についてなどで執筆させていただく予定です。

森藤 大地

森藤 大地

データに関する仕事が好きです。

宮原徹

宮原徹

日本仮想化技術株式会社 代表取締役社長兼CEO。仮想化技術に関するコンサルタントとして長年活動しており、特にベンチマークテストによる性能評価を得意としている。

荒谷翔

荒谷翔

株式会社はてなでMackerelのセールスデベロッパーとして勤務しています

東條 望

東條 望

2014年にニフティへ中途入社。 入社後から現在まで、ニフティクラウドのサービス企画・開発を担当しています。 各サービスの紹介を執筆させていただく予定です。