ニフクラ ブログ

ニフクラ/FJcloud-Vやクラウドの技術について、エンジニアが語るブログです。

ニフティクラウドをベンチマークしてみた(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』も一度お考え頂ければと思います！！