【はじめての性能試験 #1】知識ゼロから始める性能試験 ― インフラ担当が主導してみた
「性能試験、インフラチームでやってもらえない？」
そう言われたとき、正直、何から手をつければいいのか分かりませんでした。性能試験に主体で関わるのは、今回が初めて。指標の見方も、テストのやり方も、どんなユーザー操作を想定すればいいのかも、見当がつきませんでした。
本シリーズでは、そんな白紙の状態から、資料を読み、有識者に頼り、アプリチームと一緒にボトルネックを潰していった数週間の記録を、全3回でお届けします。
同じように、初めて性能試験を任されて迷子になっている人の道しるべになれば嬉しいです。
本題に入る前に、性能試験全体の流れを先に共有しておきます。本シリーズはこの流れに沿って進むので、「こういう順番で進むんだな」と眺めてもらえればOKです。
対象システムと、私の立場
対象は、画像や動画といったメディア素材を共有するためのWebシステムでした。多くのユーザーが大小様々なメディアを日常的にやりとりします。そのため、本番で快適に使える性能が出ているかを、リリース前に確かめておく必要がありました。
なぜ、アプリではなくインフラ担当の私が主導したのか。理由はシンプルで、アプリよりインフラチームの方が少し余力があったからです。性能はインフラの領域でもあるし、手が空いている方がやろう、という程度で、深い理由はありませんでした。
ただ、そう簡単ではありませんでした。性能試験はインフラだけでは完結せず、ユーザーがどんな操作をどのくらいの割合で実行するか、というシナリオの部分は、どうしてもアプリの知識が要ります。アプリを細かくは把握していないインフラ担当が、その穴をどう埋めるか。これが、最初に立ち止まったポイントでした。
学び①：性能試験は「誰の担当か」で線を引けない。フロント・API・DBのどこにボトルネックが潜むか分からない以上、最初から越境する前提で臨む方がいい。
迷いに迷った、最初の一週間
いざ始めようとして、まず「そもそも何をどう測ればいいのか分からない」という壁にぶつかりました。
- どんな指標を見ればいいのか（レスポンスタイム？ リソース使用率？ エラー率？）
- テストを具体的にどうやって流すのか（どのツールで、どれくらい負荷をかけるのか）
- ユーザーはどんな操作を、どのくらいの割合でするのか
知ってる人からすると当たり前のことばかりですが、初めてだと、この一つひとつが分かりません。ここで自己流に走らなかったのは、我ながら良い判断でした。
頼れるものに頼る
転機は、プロジェクトリーダーが作ってくれた「リリース試験のススメ」という資料でした。性能試験・障害試験・運用試験を網羅した資料で、これを一読することで「何を見て、どう進めるか」の全体像がやっと掴めてきました。これがなければ一生迷子だったかもしれません（笑）
さらに、複数プロジェクトで性能試験経験のある有識者に、試験観点のレビューを頼みました。これがよく効きました。
正直、このレビューがなければ、この試験はまったく違って、的外れなものになっていたと思います。何を測るべきで、何は測らなくていいか。その線引きは経験の部分が大きく、資料を読むだけでは埋まりませんでした。
学び②：経験の浅い分野は、独学で抱え込まず、臆せず有識者を頼る。生半可な知識や小手先のテクニックを身につけるより、その方がずっと早く正解に近づける。
テスト項目を絞る
レビューで得た一番大きな成果は、テスト項目を現実的な範囲に絞れたことでした。
初心者ほど「あれもこれも測らないと不安」になります。しかし、やみくもに測ってもボトルネック調査の時間が膨らむだけです。このシステムならここを重点的に見れば十分、という当たりをつけられたおかげで、限られた期間で意味のある試験に集中できました。どんな観点に絞り、どんな試験種別を組んだかは第2回で書きます。
アプリチームとの協働
先に書いたとおり、私はアプリの中身を細かくは知りません。そこで、想定されるユーザー操作のシナリオはアプリチームに洗い出してもらいました。どの画面が一番使われるか、閲覧と書き込みの比率はどれくらいか、権限によって操作はどう変わるか。こういう実態は、アプリを作っている人にしか出せません。
インフラは負荷のかけ方と計測を、アプリはユーザー挙動の実態を持ち寄る。この分担が回り始めてから、シナリオが一気に本物らしくなりました。あとは、試験を流す、ボトルネックを見つける、チューニングする、もう一度流す、の繰り返しです。片方のチームだけでは、このループはまず回りませんでした。
学び③：チームをまたぐと調整の手間はかかる。それでもリターンの方が大きい。自分の担当外の情報こそ、手間を惜しまず取りに行く価値がある。
当時の自分に伝えるなら
初めて性能試験を任される人、つまり当時の自分に伝えるとしたら2つあります。
1つ目。最初から全部を完璧に測ろうとしないこと。初心者ほど「あれもこれも測らないと不安」になりますが、当たりをつけて重点を絞った方が、限られた期間で意味のある結果にたどり着けます。
2つ目。分からないことは、分かる人に早く聞く。資料を読むのも、有識者にレビューをもらうのも、アプリチームを巻き込むのも、結局は「独りで抱えない」の一言に尽きます。初めての性能試験を乗り切れたのは、この姿勢のおかげでした。
ここまでは、どちらかというと心構えの話が中心でした。次回からは、より具体的で、手を動かす話に入っていきます。
第2回のテーマは「翻訳」です。「レスポンス5秒以内」のような抽象的な非機能要件を、どうやって測れる試験項目に落とし込んだか。合格基準の決め方と、ボトルネックを切り分けるための試験の順序について書きます。
