JMeter基盤をAWSからニフクラへ移行した話

ディーネットでは、JMeterを使った負荷テストサービスを提供しています。

以前は、JMeterの動作基盤をAmazonWebServices(以下、AWS)上で動かしていたのですが、諸事情がありニフクラへ移行しました。

この記事では、JMeter基盤をAWSからニフクラへ移行した理由と、良かった点、困った点についてまとめています。

負荷テスト環境の構成

移行の話の前に、簡単に負荷テストサービスについて説明しておきます。

JMeterを利用することで次の2つが実現できます。

  • 「トップページ→会員登録→商品購入→ログアウト」のような特定のシナリオを作成する
  • 作成したシナリオを複数ユーザで同時実行させる

負荷をかけた状態のシステムを見ることで、キャパシティの確認や高負荷時のバグの再現などが可能です。

 ※負荷テストサービスに興味がある方は、サービス紹介:負荷テストをご覧ください※

JMeterは次のどちらかのパターンで構成しています。

  • マスタ構成・・・マスタ1台のみ
  • マスタ・スレーブ構成・・・マスタ1台、スレーブ複数台
マスタ・スレーブ構成

マスタ・スレーブ構成

小さな規模の負荷テストであればマスタ構成を利用しますが、通常はマスタ・スレーブ構成で負荷テストを行っています。

マスタ・スレーブ構成ではスレーブの台数を増やすことで負荷を大きくすることが可能です。スペック不足を数で補うことができるため、かなり大規模な負荷テストを行うことができます。

JMeter基盤に求めた要件

ディーネットでは、JMeter基盤に求める要件は次の3つで考えています。

  • 安定稼働
  • 支払いは、使った分だけ
  • 手軽に拡張や縮退が可能

安定稼働

対象システムの性能を測定するためには、負荷をかける側であるJMeter基盤の安定稼働が必要不可欠です。同一条件で測定しても、基盤の性能が不安定では、正しい測定を行うことができません。

安定稼働のためには、次のようなことが重要になります。

  • 高負荷時も安定した性能を発揮できること
  • 高トラフィックに対応可能な回線であること
  • 問題発生時に適切なサポートが受けられること

支払いは、使った分だけ

JMeterは特性上、常時稼働しておく必要はありません。負荷テストを実施するタイミングのみ使えればいいのです。そのため「従量課金」の費用体系が適しています。

テストの規模にもよりますが、トラフィックの費用が無視できなくなる場合があります。そのため、極力トラフィックに関する費用が安価なことが望ましいです。

ちなみに、負荷テストでは、Inboundのトラフィックが多く発生します。

通常WEBサーバでは、ブラウザからの要求を受け、htmlや画像などを返却します。つまりWEBサーバからブラウザへ向かうOutboundのトラフィックが多く発生します。

JMeter基盤ではブラウザの動きをシュミレーションするため、WEBサーバとは反対向きのInboundのトラフィックが多く発生することになります。

手軽に拡張や縮退が可能

大きな負荷をかけていくと、システム側ではなくJMeter側のスペック不足が問題になることがあります。問題解消のために、スペックの向上やサーバを追加を数分でできるかどうかは重要なポイントです。

また、「支払いは、使った分だけ」の内容と重複しますが、費用を抑えるために夜間や休日など、頻繁に停止や縮退を行うことになります。そのため、定型的な作業を「手軽」に出来る環境が必要になります。

AWSからニフクラへ移行した理由

ニフクラでは、原因不明の頭打ちは発生していない

ニフクラでは、原因不明の頭打ちは発生していない

原因不明のスループット頭打ち問題

3年前からAWS上でJMeter基盤を動かしていましたが、今年ニフクラへ移行させることになりました。

理由は、「原因不明のスループット頭打ち問題の発生」です。

大規模な負荷テストで問題発生

その問題は、JMeterのスレーブが10台規模の負荷テスト実施中におきました。そのテストでは、200PV/秒のスループットを目標に向けて、負荷テストとチューニングを実施していました。

しかし、目標スループットの半分である100PV/秒を超えたあたりで、頭打ちとなります。頭打ちの原因を調査しますが問題になるような箇所が見つかりません。負荷テスト対象のWEBサーバやDBサーバ、LB、CDN、負荷をかける側のJMeterマスタやJMeterスレーブを調査しますが、いずれも余裕がある状態です。

状況から推測すると、手元で確認できない「AWS側の回線まわり」が被疑箇所として考えられましたが、丸一日以上調査をしても原因の特定はできませんでした。

ニフクラへ移行することで問題解消

解決の糸口が見つからなかったため、思い切ってJMeter基盤を別のクラウドへ移してみることにしました。移行先はサーバ性能の評価が高かったニフクラにしました。

JMeter基盤の移行は半日ほどで完了しました。マスタサーバとスレーブサーバを1台づつ構築します。スレーブサーバはコピーで増やせるためそれほど手間はかかりませんでした。

移行が完了して、テストを実行してみると、100PV/秒の壁をあっさりと超えることができました。

それ以降、ディーネットではニフクラ上でJMeterを動かしています。

移行して良かった点

AWSからニフクラへ移行して良かった点をまとめてみます。

トラブルフリーでサポートも手厚い

移行して半年ほど経ち、JMeterのスレーブを30台ほど利用する大規模なテストも実施していますが、ニフクラに起因するトラブルに見舞われたことはありません。

トラブル時のサポート体制にも安心感があります。ニフクラの場合は、利用ユーザなら誰でも利用できるテクニカルサポート窓口が設けられています。別件で何度か利用したことがありますが、質問に対して的確な回答をしてもらえ、仮想ホストのライブマイグレーションまで対応してもらったことがあるので、安心して利用できています。

スレーブのグローバルIPアドレスが固定されるのでアクセス制限し易くなった

負荷テストを受ける側の環境では、しばしばアクセス制限が必要な場合があります。

IPアドレスで制限が必要な場合、JMeterのIPアドレスを固定させる必要があるのですが、AWSでは困難でした。ElasticIPを使うことで固定させることはできますが、標準で5個が上限になっており、解除するためには申請が必要です。

その点、ニフクラのサーバは、作成時にグローバルIPアドレスが振られると変更されることはありません。予め必要な台数分JMeterサーバを作っておくことで、アクセス制限に関する手間を最小限に抑えることが可能になりました。

移行に伴い困ったことと解決方法

良かった半面、困った点もありました。主に費用に関することになりますが、困った内容とその解決方法についてもまとめてみます。

Inboundのトラフィック費用についても料金が発生する → 10TBまで無料なので影響なかった

AWSとニフクラでは、トラフィックに関する費用について、次のような違いがあります。

環境 Inbound Outbound 費用
AWS 無料 課金対象 1GBまで無料
0.09ドル/GB
ニフクラ 課金対象 課金対象 10TBまで無料
15円/GB

※2016年10月26日時点の情報です

「JMeter基盤に求めた要件」で書いた通り、JMeter基盤ではInboundのトラフィックがメインになります。その点AWSの場合は、Inboundが無料となっているので費用を気にする必要がありません。

ニフクラの場合は、10TBを超えると課金対象になってしまいます。10TBを超えるためにはかなり大規模なテストとなるので、普段はあまり気にする必要はありません。

とはいえ、知らない間に「多額の費用が発生していた」となってしまうと怖いので、たまにコントロールパネルから現在の転送量を把握して対応しています。

参考:無料枠のネットワーク転送量10TB/月で何ができるのか?

停止時にも費用が発生する → APIでサーバタイプを簡単制御

もうひとつ費用的に困ったことがありました。なるべく利用料金を下げるために、休日や夜間など利用していないタイミングは「停止」させておくなどして、極力費用がかからない運用をしています。

AWSの場合は、サーバを停止している間はストレージ以外の費用はかかりません。そのため、利用しない間はサーバを停止させておくことで利用料金を下げることが可能です。

一方ニフクラの場合は、サーバ停止期間中もサーバタイプに応じて3円から24円までの間で費用がかかります。そのため、サーバの「停止」だけではなく、最小のタイプへ「変更」してあげる必要がでてきます。

タイプ変更はコントロールパネルから一台づつ実施する必要があるので、十台以上の規模になってくると数十分単位の時間がかかってしまいます。一日二回、朝にタイプを上げて夜に下げることを考えると、かなりの時間ロスです。

これを解消するために、APIを利用しました。あらかじめ対象サーバのタイプを変更するスクリプトを作っておくことで、劇的に作業の手間と時間を短縮し、利用料金を圧縮することができました。

まとめ

原因不明の性能に関するトラブルの発生で、JMeter基盤をAWSからニフクラへ移行しました。

移行後に、より大きな規模の負荷テストを実施していますが、いまのところ安定して動作しています。

当初は、課金体系の違いなどから若干の困難はありましたが、APIを利用するなどして解決できる問題ばかりでした。

JMeterの性能で問題が発生することがあれば、ニフクラへ移行することを検討してみてはいかがでしょうか。

負荷テスト