負荷をかけてみよう

皆様お久しぶりです。
シニアプログラマの小田です。

今回は、今までお伝えしてきました負荷についてを理解を深めるために、実際に負荷をかける手順について記述致します。
あれ?Disk I/Oは?と思ったそこのあなたは、きっと私の追っかけでしょうw
ブログを読んでいただき有り難うございます。
また次回のタイミングでお話致します。

概要

今回行うのは「負荷をかける」なのですが、注意点にも触れていきたいと思います。

負荷テストの準備

  1. jMeter
    • 適切なシナリオ
  2. サーバ環境 ・・・ 今回はLAMPで行きましょう
    • xdebug ・・・ プロファイリングのために必要です
    • KCachegrind ・・・ Mac上でxdebugのプロファイル結果を見れます
      1. 準備編
      2. 入門編
      3. 実践編
    • MySQL ・・・ スロークエリの設定(まずは500msでいいかと思います)
  3. モニタリングツール
    • MUNIN
    • その他クラウドサービスに備え付けのモニタリングツール

適切なシナリオ

みなさんはどのようにシナリオを考えておりますでしょうか?
一番の負荷の想定で大事なのは同時接続数ですが、例えば以下のように考えてみてはどうでしょうか?
  1. ピーク時のDAUを想定
  2. DAUからピーク時間中のアクセス率を想定
    • 大体n〜m%ぐらい ・・・ 過去の経験から想定するとよりいいですね
  3. 1プレイで呼び出されるAPI数を想定
    • 朝昼夕夜の4ローテーションでAPI数を算出
  4. 2,3を元に、同時接続数を算出
いかがでしょうか?負荷テストは「想定」の上に成り立っておりますが、何事も仮説があって検証してこそ実証されるのです。
さて、私は特に注意しているのが、「3.1プレイで呼び出されるAPI数を想定」です。
ここを外してしまうと、全く意味のない負荷テストになってしまいます。

APIの想定

ではどのように、想定すればいいいのでしょうか?
要点だけ軽く説明致します。これは当然ゲームによっても異なりますし、ゲームの設計に合わせて変更すべき内容のため、みなさまの環境に応じて変更してください。
※注意点として、負荷テスト用にレスポンスのデータ構造を変更してはいけません。
 意図しないデータ構造での負荷テストは意味が無いためです。
  1. 呼び出し順序は適切か?
    • ログイン処理を毎スレッド通るようになっていないか?
  2. 呼び出し回数は適切か?
    • 例えば1日1回ガチャを回すということはあるのか?
    • 例えば1日1回パーティー編成を行うということはあるのか?
    • 例えば1日1回売却を行うということはあるのか?
この2点です。え?それだけ?と思ったかもしれませんが、私が注意するのはだいたいこの2点です。とはいえこの2点だけでも条件を満たすシナリオを作るのは骨が折れます。
jMeterでシナリオを作ったことがある人ならわかるはずです。ランダム、ループ、1度だけ実行といったさまざまな処理を組み合わせて用意してください。

負荷テストの実施

はっきり言います。負荷テストは「トライアンドエラー」しかありません。
楽してチューニングなどできないのですが、日頃の行いがいいと、負荷テストも楽になります。※前回のCPU使用率についての時のjMeterで自動化の話をすればいいのです。
実施方法ですが、
  1. jMeterシナリオの実行
    • 複数台から実行するときは
      • 【jMeterフォルダパス】/bin/jmeter.sh -n -t 【シナリオファイル名】
      • 止めるときはshut_down.shというのがあるので、それを使う
    • 単一実行の時は、Ctrl+Cで止めればいい
  2. モニタリングツールを常に監視
    1. 今までにあげた注目ポイントを見ましょう
  3. 2で負荷がかかっている箇所をチューニングしていきましょう
    • xdebugで無駄な呼び出し回数はないか?
    • スロークエリはないか?
      • インデックスの見直し
      • 呼び出し方法をリファクタリング
    • etc。。。。
  4. 3が終われば、また1からの繰り返し

まとめ

今回記述した内容は特別なことは書いておりません。もしかすると当たり前のことかもしれません。ですが、みなさんはその当たり前のことができておりますでしょうか?
負荷テストは本当に長いトンネルのように解決できない時は頭をかかえるかもしれません。そんなときは、一度シナリオから見直すことをオススメ致します。
想定が正しいのか?というところは常につきまといますし、私の経験上、それによって解決することもありました。大半は自分たちが書いたコードが原因ではありますが、常に「疑いを持って取り組む」ということをすれば、負荷テストもきっと楽におわらせられるようになるはずです。

番外編

今回説明した負荷テストで地味に負荷になりえるのが、ログ書き込みによるDisk I/Oです。
ログの残し方や対応方法によっては負荷にはなりませんが、知らないうちに負荷になりえるのです。ですので、ログの残し方は他のエンジニアがブログに書いていくと思いますので、私からは注意喚起だけにとどめて締めくくりたいと思います。

採用情報

クラウドクリエイティブスタジオではプログラマを募集しております。
ぜひ、一緒に面白いゲームを作りましょう!

コメント