はじめまして。adish雪風チームの@hige-taharaと申します。
このエントリは、Gaiax Advent Calendar 2015 の24日目のエントリです。
今日はクリスマス・イブですね...すみません。気の利いた言葉が浮かばないので、早速本題に入らせていただきます。
私は今、ソーシャルアプリサポート業務で使用するバックエンドシステムを、オンプレのシステムから、みんな大好き「ＡＷＳ」に移行する作業を行ってます。「ＡＷＳ」に移行する目的は、月並みではございますが、
- 可用性の向上
- コスト削減
- 運用の効率化
といったところです。
基本的には、改修なしの単純な移行です。一通り機能の稼働確認を実施し問題ないことは確認できました。しかし、もう一つ確認しておかないといけないことがあります。
「パフォーマンスは今まで通りか？」
ということです。これをやっておかないと、いざ本番運用始めた際に泣くことになります。
そこで、AWS移行後も移行前のパフォーマンスを保証できるか、確認するための負荷テストを実施します。ツールは、負荷テストの定番ツールとしてお馴染みの「JMeter」を使用します。また、パフォーマンスが出ない場合、AWSだからこそ簡単にできる「スケールアウト」の手法を使って、どういうスペックで構成すればいいのかを、併せて実験してみました。
テストシナリオの作成
まずは、テストシナリオを作成します。今回は機能テストではなく、負荷テストツールを使用してよく行われるここで作成したシナリオはJMeterのパラメータに入力することにもなります。
1. 同時アクセスユーザーの想定
実際にツールを使用する部署に、同時アクセスするユーザー数を確認します。今回のツールの場合は、業務ボリュームによって「30」「70」「105」というパターンを設けました
2. よく使う機能をピックアップ
今回は機能の検証ではなく、負荷テストなので、よく業務で使われる機能に限定することにします。本システムでは以下の機能になります。
- ログイン（最初の1回のみ）
- 初期画面表示（最初の１回のみ）
- 一覧画面表示
- 検索
- 詳細画面表示
- データ更新
3. 作業ルーティンの想定
ピックアップした機能を使った作業の流れ、ルーティンを想定します。今回は前述の「１.ログイン」～「６. データ更新」の作業を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にします。
2. ロジックコントローラーの設定
ロジックコントローラーにて機能の設定をします。
1. 一度だけ実行されるロジックコントローラの設定
ログイン処理とログイン後の初期画面表示は一度しか実施されないので、一度だけ実行されるコントローラを設定します。
- [負荷テスト]を右クリックして[追加]→[ロジックコントローラ]→[一度だけ実行されるコントローラ]を選択します。
- [一度だけ実行されるコントローラ]を右クリックして[追加]→[サンプラー]→[HTTPリクエスト]を選択します。
- 名前、webサーバー名、ポート番号、プロトコル、メソッドを指定します。
- リクエストパスを指定します。画面やアクセスログなどから事前にひろっておきます。
- idやpasswordなどのリクエストで送るパラメータを指定します。
- 同じようにして、[一度だけ～]の下に、初期画面のリクエストを設置します。
2. 繰り返し分実行されるロジックコントローラの作成
「一覧画面表示」から「データ更新」までの、50回繰り返す機能のロジックコントローラを作成します。
- [一度だけ実行されるコントローラ]の外（[負荷テスト]の下）に、前述の「ログイン処理」のリクエストを設置した方法と同じ方法で、遷移する各画面のリクエストを設定します。
3. ユーザーパラメータの指定
- ロジックコントローラを設定において、変数をパラメータ指定した場合（${tseq}など）のパラメータ内容を設定します。
- [負荷テスト]を右クリックして[追加]→[前処理]→[ユーザーパラメータ]を選択します。
- 変数名と各スレッド生成時（ユーザー単位）の値を設定します。
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 |
結果と方針（ざっくりですがｗ...）
- t2_microを使用した場合は、ちょっと厳しい
- t2_mediumを2台使用した場合は、同時アクセスユーザーが30人までは問題なさそう
- 同時アクセスユーザーが70人くらいになる場合は、t2_mediumのインスタンスを3台用意した方がいいかも
- 同時アクセスユーザーが100人くらいになる場合は、t2_mediumのインスタンスを4台以上用意した方がいいかも
- スケールアウトもいいですが、データベースについて、my.cnfのinnodbバッファ関連のパラメータ設定の見直しも
AWSは負荷テストに「接しやすかぁ～」
昔はインフラの構成を柔軟に変更して、いろいろな構成で負荷テストなんて、ほぼ不可能に近い話だったと思いますが、AWS上ではそれが可能なんですね。本当にいい世の中になったと思います。また、その結果によって、インスタンスを「垂直に」「水平に」「増やしたり」「減らしたり」自在にできるなんて...怠惰になりそうです...
明日はアドベントカレンダー最後です
12月1日から始まったアドベントカレンダーも明日で最後ですね。 明日の担当は、perl関連でググったときに、個人的にはよくお世話になってる@papix大先生が、トリを飾るのにふさわしい、感動するお話をしてくれるのでしょうか...楽しみにしましょう。
