Gaiax Engineers' Blog

Gaiaxのエンジニアブログです。 社内の様子をありのままに発信していきます。

AWS移行と負荷テスト

はじめまして。adish雪風チームの@hige-taharaと申します。
このエントリは、Gaiax Advent Calendar 2015 の24日目のエントリです。

今日はクリスマス・イブですね...すみません。気の利いた言葉が浮かばないので、早速本題に入らせていただきます。

私は今、ソーシャルアプリサポート業務で使用するバックエンドシステムを、オンプレのシステムから、みんな大好き「AWS」に移行する作業を行ってます。「AWS」に移行する目的は、月並みではございますが、

  • 可用性の向上
  • コスト削減
  • 運用の効率化

といったところです。

基本的には、改修なしの単純な移行です。一通り機能の稼働確認を実施し問題ないことは確認できました。しかし、もう一つ確認しておかないといけないことがあります。

「パフォーマンスは今まで通りか?」

ということです。これをやっておかないと、いざ本番運用始めた際に泣くことになります。

そこで、AWS移行後も移行前のパフォーマンスを保証できるか、確認するための負荷テストを実施します。ツールは、負荷テストの定番ツールとしてお馴染みの「JMeter」を使用します。また、パフォーマンスが出ない場合、AWSだからこそ簡単にできる「スケールアウト」の手法を使って、どういうスペックで構成すればいいのかを、併せて実験してみました。

テストシナリオの作成

まずは、テストシナリオを作成します。今回は機能テストではなく、負荷テストツールを使用してよく行われるここで作成したシナリオはJMeterのパラメータに入力することにもなります。

1. 同時アクセスユーザーの想定

実際にツールを使用する部署に、同時アクセスするユーザー数を確認します。今回のツールの場合は、業務ボリュームによって「30」「70」「105」というパターンを設けました

2. よく使う機能をピックアップ

今回は機能の検証ではなく、負荷テストなので、よく業務で使われる機能に限定することにします。本システムでは以下の機能になります。

  1. ログイン(最初の1回のみ)
  2. 初期画面表示(最初の1回のみ)
  3. 一覧画面表示
  4. 検索
  5. 詳細画面表示
  6. データ更新

3. 作業ルーティンの想定

ピックアップした機能を使った作業の流れ、ルーティンを想定します。今回は前述の「1.ログイン」~「6. データ更新」の作業を1ルーティンとし、それを50回繰り返します。 ただし、「ログイン」と「初期画面表示」については、実際の作業と同じように最初の1回のみとします。 また、各作業の間隔を2秒とします。

4. 目標値の設定

「今まで通りのパフォーマンス」 という目標を具体的な数値に落とします。どうやって数値を決めるかいろいろ方法はあると思いますが、ここでは単純に、移行前の現在の環境で、前述の機能を使った際にかかっているレスポンスタイムを目標値として設定します。今回はGoogle Chrome Developer Tools のNetworkメニューを使用して、レスポンスタイムを調査し、jQueryやjs、CSSや画像の読み込み時間を除いて、「5~8秒」という値に設定しました。 なお、「5~8秒」というのは、あくまで現状そうであるから、ということで設定した数字であり、改善すべき余地があるかもしれませんが、今回ここではスコープとしません。

JMeterにパラメータを入力

1. スレッドグループの作成

スレッド数、リクエストの頻度、などの基本的なスレッドの情報を設定します。[テスト計画]を右クリックして[追加]→[スレッドグループ]を選択します。

  • ユーザー30人の場合は、スレッド数30で設定します
  • 2秒ごとにログインするということで、Ramp-UP期間(秒)は30 x 2 で60にします。
    • Ramp-UP期間→指定したスレッド数が全て立ち上がるまでの時間を設定します。
  • 作業を50回繰り返すということで、ループ回数は50にします。 f:id:hige-hage:20151224214756p:plain

2. ロジックコントローラーの設定

ロジックコントローラーにて機能の設定をします。

1. 一度だけ実行されるロジックコントローラの設定

ログイン処理とログイン後の初期画面表示は一度しか実施されないので、一度だけ実行されるコントローラを設定します。

  1. [負荷テスト]を右クリックして[追加]→[ロジックコントローラ]→[一度だけ実行されるコントローラ]を選択します。
  2. [一度だけ実行されるコントローラ]を右クリックして[追加]→[サンプラー]→[HTTPリクエスト]を選択します。
  3. 名前、webサーバー名、ポート番号、プロトコルメソッドを指定します。
    1. リクエストパスを指定します。画面やアクセスログなどから事前にひろっておきます。
    2. idやpasswordなどのリクエストで送るパラメータを指定します。 f:id:hige-hage:20151224220136p:plain
    3. 同じようにして、[一度だけ~]の下に、初期画面のリクエストを設置します。

2. 繰り返し分実行されるロジックコントローラの作成

「一覧画面表示」から「データ更新」までの、50回繰り返す機能のロジックコントローラを作成します。

  1. [一度だけ実行されるコントローラ]の外([負荷テスト]の下)に、前述の「ログイン処理」のリクエストを設置した方法と同じ方法で、遷移する各画面のリクエストを設定します。 f:id:hige-hage:20151224220323p:plain f:id:hige-hage:20151224220330p:plain

3. ユーザーパラメータの指定

  • ロジックコントローラを設定において、変数をパラメータ指定した場合(${tseq}など)のパラメータ内容を設定します。
  • [負荷テスト]を右クリックして[追加]→[前処理]→[ユーザーパラメータ]を選択します。
  • 変数名と各スレッド生成時(ユーザー単位)の値を設定します。 f:id:hige-hage:20151224220435p:plain

4. HTTPクッキーマネージャーの設定

今回はクッキーを使用していますので、HTTPクッキーマネージャーを設定します。 [負荷テスト]を右クリックして[追加]→[設定エレメント]→[HTTPクッキーマネージャー]を選択します。

5, 定数タイマの設定

各リクエストを3秒おきに実施するということで、定数タイマを設定し、スレッド遅延時間を3000ミリ秒で設定します。 [負荷テスト]を右クリックして[追加]→[タイマ]→[定数タイマ]を選択して、値を設定します。

6. リスナーの作成

リスナーとは、テストの実行に得られる情報の収集・表示をするためのものです。今回は以下のものを設定します。 * 統計レポート

7. テスト開始

全てのデータを入力し終わったら、テストを実施します。 「実行」メニューより「開始」を選択してください。

テスト結果について

  • リスナーで設定した統計レポートより、主に使われる以下の作業の結果を抜粋してます。
    • 検索
    • 詳細画面表示
    • データ更新
  • 単位は
    • Samplesはリクエスト数
    • Average以降はミリ秒
  • 太字は、8秒以内のレスポンスになります。

チケット検索

ec2 type Samples(件) Average(ms) 90%Line(ms) 95%Line(ms) 99%Line(ms)
t2_medium_x2_105 5250 16844 41718 50025 57610
t2_medium_x3_105 5250 9501 25925 31116 47382
t2_medium_x4_105 5250 5730 7159 15363 20964
t2_medium_x2_70 3500 7622 8789 12994 18808
t2_medium_x3_70 3500 4024 5576 5904 6589
t2_medium_x2_30 1500 1780 2764 2943 3286
t2_medium_x3_30 1500 851 1289 1382 1574
t2_micro_x2_105 5250 22081 24555 25122 26273
t2_micro_x2_70 3500 22281 59692 59695 59868
t2_micro_x2_30 1500 4787 6521 6984 7614
t2_micro_x3_30 1026 4655 15913 25109 37082

チケット詳細画面

ec2 type Samples(件) Average(ms) 90%Line(ms) 95%Line(ms) 99%Line(ms)
t2_medium_x2_105 5250 10544 25190 31357 38410
t2_medium_x3_105 5250 8201 8448 34714 44822
t2_medium_x4_105 5250 5146 6954 9740 20793
t2_medium_x2_70 3500 6155 6807 12999 17342
t2_medium_x3_70 3500 4420 5844 6135 6686
t2_medium_x2_30 1500 3089 3954 4119 4514
t2_medium_x3_30 1500 2397 3586 3887 4967
t2_micro_x2_105 5250 13632 16010 16516 17362
t2_micro_x2_70 3500 18740 59691 59694 59702
t2_micro_x2_30 1500 6627 7963 8312 9096
t2_micro_x3_30 1019 9174 18351 59060 59816

コメント登録

ec2 type Samples(件) Average(ms) 90%Line(ms) 95%Line(ms) 99%Line(ms)
t2_medium_x2_105 5250 19680 48496 57683 67046
t2_medium_x3_105 5250 13057 32210 38666 63915
t2_medium_x4_105 5250 7987 11661 14199 23587
t2_medium_x2_70 3500 10459 11353 21604 27479
t2_medium_x3_70 3500 6744 8691 9136 9886
t2_medium_x2_30 1500 4291 5599 5799 6208
t2_medium_x3_30 1500 3010 4457 4803 6171
t2_micro_x2_105 5250 25317 28389 29089 30220
t2_micro_x2_70 3500 27106 59692 59695 59886
t2_micro_x2_30 1500 9684 11774 12176 12975
t2_micro_x3_30 1013 11568 34920 53083 80114

結果と方針(ざっくりですがw...)

  • t2_microを使用した場合は、ちょっと厳しい
  • t2_mediumを2台使用した場合は、同時アクセスユーザーが30人までは問題なさそう
  • 同時アクセスユーザーが70人くらいになる場合は、t2_mediumのインスタンスを3台用意した方がいいかも
  • 同時アクセスユーザーが100人くらいになる場合は、t2_mediumのインスタンスを4台以上用意した方がいいかも
  • スケールアウトもいいですが、データベースについて、my.cnfのinnodbバッファ関連のパラメータ設定の見直しも

AWSは負荷テストに「接しやすかぁ~」

昔はインフラの構成を柔軟に変更して、いろいろな構成で負荷テストなんて、ほぼ不可能に近い話だったと思いますが、AWS上ではそれが可能なんですね。本当にいい世の中になったと思います。また、その結果によって、インスタンスを「垂直に」「水平に」「増やしたり」「減らしたり」自在にできるなんて...怠惰になりそうです...

明日はアドベントカレンダー最後です

12月1日から始まったアドベントカレンダーも明日で最後ですね。 明日の担当は、perl関連でググったときに、個人的にはよくお世話になってる@papix大先生が、トリを飾るのにふさわしい、感動するお話をしてくれるのでしょうか...楽しみにしましょう。