メガリザードンYと同じ身長・体重なことに気づきました。スマートキャンプの今川です(@ug23_)。
前編 の記事ではGatlingを使った負荷テストなどについてソースコードを載せつつ説明しました。
後編ではどちらかというとプロセス的な部分により着目してまとめていきます。
【ポイント6】ミスを防ごう
私は負荷テストで1件やらかしました。
本番環境に負荷テストをしてしまうという失態を。翌日に本番インスタンスの2台が過負荷で死んでいました。 幸いサービス提供には大きな問題はなかったものの冷や汗ものでした。
こういったミスが起きないように以後は以下のことに気をつけています。
- 負荷テスト環境にドメイン（本番のサブドメイン）をつけて明確に分け、試験中は負荷の向き先を変えない
- 負荷テスト環境のELBのインスタンス付け外しの場合にダブルチェックを実施する
- 負荷シナリオを作る際、負荷の増大量を急激にしない
負荷テスト環境は本番環境とVPCやセキュリティグループレベルで分けて同じようにアクセスできないようにするのが理想ですね。
【ポイント7】ボトルネックかどうかを確かめるために消してみる
前回の【ポイント2】でもお伝えしましたが、負荷テストのゴールを決めてそれを満たすことを目的として試験を実施することを目的としました。
「この問題を修正したらパフォーマンスが○割改善するのでやらせてください！」などと交渉するためにも、
見えている課題がどれぐらいのボトルネックになっているのかを把握する必要があります。
一方で、負荷テスト環境ですべての仕様を満たすものを提供し続ける必要はありません。
負荷テスト環境にデプロイするブランチからボトルネックになっている機能を消してみましょう。
- 人気順に並べている部分が重い ⇒ ソートしないでだしてみる
- DBアクセスが多い部分がある ⇒ その部分まるっとコメントアウト
- データ量が多い ⇒ 0個で出してみる
それによって 理想状態にするとどれぐらい改善するのか を把握するとその後の改善がやりやすくなります。 思い切ってやってみましょう。 間違って本番適用しないように…。
【ポイント8】誰でも使えるようにしよう
さて、ここまで定期的に実施するポイントを説明してきましたが、環境を整備しても誰かが負荷テスト担当になってしまうのはもったいない！と思います。 自分だけでなく、他のメンバーにも負荷テストをやってもらうようにすればチーム全体の力が伸びます。
リポジトリやAMIにしてすぐ使えるようにしておく
- 負荷ツール用のスクリプト
- 負荷テスト環境用のインスタンスイメージ
これらを残しておきましょう。
スクリプトについてはコピペやちょっと編集するだけで使えるように、
インスタンスイメージは立ち上げてスクリプトを置けばすぐ負荷を与えられるように、
環境を立ち上げるのがすばやくなるようにしました。
頻繁に負荷テストが行われる場合には負荷テスト環境を毎回片付けずに残しておくのも手かもしれません。
残しておくインフラコストと毎回立ち上げ直す人的（あるいは心理的）コストを比較してみましょう。
具体的な手順を共有する
スマートキャンプではesaを使ってエンジニア間での情報共有を行っています。
解説エントリを作ってインスタンスの立ち上げ方からGatlingの設定方法、シナリオの組み方までざっくりですが書いておきました。 はじめてやるメンバーにも任せられる内容にしました。
チュートリアルを実施する
ぶっちゃけ、ドキュメントを書くだけ ではだれも使ってくれないんですよね。 実演会をやって実際に見せたり、やらせてみましょう。それだけでも心理的障壁がだいぶ取り払われます。
【ポイント9】開発プロセスに組み込もう
定期実施するといっても抜き打ちでやる必要はないでしょう。 ただし、折に触れてパフォーマンスを確認するために開発プロセスの中に負荷テストを組み込んで、それにフックできるようにしましょう。
人は忘れるという能力を持っています。だからこそ、なにかと一緒に組み合わせて思い出しましょう。 例えばこんな感じかなと思います。
- 依存ライブラリやミドルウェアのバージョンアップ時
- テストフェーズ開始時
- テレビ等メディアに出る予定ができた時
- 新機能のリリース前
もしかして○○に負荷かかるんじゃ…？ 的な発想を頭の片隅にでもおいておきましょう。
まとめ
前後編にわけて9つのポイントを紹介しました。負荷テストは奥が深いです。 開発だけしている分には必要にならないスキルです。ただし、Webサービスとして提供するならいつか必須になるものです。 早めに環境を整えるに越したことはありません。その際にこれらの知識がお役にたてれば幸いです。
私は負荷テストを進めることで「このシステムに求められているのは秒間○リクエストを耐えうる性能なんだ」という明文化されていなかったビジネス的な要件が見えてきました。 テストというのは バグや瑕疵を見つけるだけでなくシステムのありようを形作り決定づけるもの でもあると思いました。
お読みいただきましてありがとうございます！
