負荷試験でエンジニアの実力大体分かる説

俺の観測範囲内によると、良くも悪くも「え、この人マジでやばみが深い」となるのは負荷試験のフェーズが圧倒的に多い。俺の思うポイントをまとめておく。

以下はとあるwebサービスの負荷試験を実施するときを想定して欲しい。

まずは目的とゴールを決めろ

負荷試験を実施して欲しい人の思惑や事情によって目的とゴールはブレまくる。その結果、誰も見ることのない意味のない大量の負荷試験結果レポートが出来上がるのだ。コンセンサスを取っておき、目的とゴールをブレさせないことが最重要だ。

無邪気な彼らの要求はいつだってこうだ。

「ピーク時でも落ちないようにして欲しい」

彼らはとにかく臆病だ。失敗を恐れている。それはとても良いことだが、意思決定が遅れることの原因でもある。まずは彼らにこう言おう。

「そんなことより自衛隊式懸垂何回できますか？」

日々鍛錬している印象を与えるんだ。これは信頼を得るのに非常に有効だ。

それから具体的な話に落としていこう。ここではほんの一例を示す。
【ピーク時ってなんぞ？】
　・何時何分何秒地球が何回回った時間？JST？UTC？
　・最大瞬間風速はユーザー数ですか？リクエスト数ですか？
　・秒間/分間/時間？（ここの単位はしばしば認識齟齬の原因になるので表記揺れに十分注意する）
　・最大瞬間風速に到達するまでにどれくらいかかる？
　・高負荷状態はどれくらい続くか？

【落ちないってつまりどういうことだってばよ？】
　・パフォーマンスが劣化しつつも反応があるのはセーフ？
　・パフォーマンス劣化はどれくらいを許容するか
　・Sorryページや429(too many request)などの仕組みが用意されているか？

【その他】
　・絶対に落としてはならないデータや処理はあるか（決済処理がある場合など、特に注意が必要である。）

挙げたらキリがないが、手段と目的を履き違えてはダメだ。大切なのはお互い納得して意味のある目的とゴールを設定してコンセンサスを取ることだ。ここにたっぷり時間を掛けろ。

最後に俺が良く使う奥義を教えておく。他言無用だ。

「お前が心配していることは明日地球に隕石が降ってくる確率より低いから安心しろ」

負荷試験の実施

負荷試験ツールは多種多様なものがあるが、
目的とゴールが決まっていれば、ツールの選定や設定など容易だろう。

使い慣れたものがあれば尚良いし、目的やゴールもツールファーストで決めてしまえるという利点もある。このアドバンテージはかなり強力だ。

なお、俺の場合は、Go言語で作った自作の負荷試験ツールがある。
並列処理の性能とGCPとの相性でGo言語を選択した。

秒間数万リクエストを出す場合、大抵はクラウドに用意したVMから実行することが多いと思うが、意外とコスト掛かってしまうことがある。

そこでPaaS環境からリクエストを出すという発想になったわけだ。

ボトルネックの特定と対処

前置きが長くなったが本題はここだ。
ボトルネックの深淵を覗く時、深淵もまたこちらを覗いているのだ。

サチる[saturation（サチュレーション）]、という言葉があるので使うと業界人っぽくみられてカッケーので使っていく。

どれだけスケーラブルに設計しても、負荷を上げ続ければ必ずどこかでサチる。「クラウドなんだから負荷なんか関係ねぇよ」なんてことを言っているプロテインのバニラ味より甘い甘ちゃんがいたら、自衛隊式懸垂で己がサチるまで追い込まれるので気をつけろ。

限界値というのは様々な箇所に設けられている。クラウドにも限界はある。どこかがサチると、その先に負荷が掛からず、負荷試験は永遠に終わらない。ボトルネックが判明しないと、しまいにはウソついたりデータを改ざんしたり設計や人のせいにしたりしてプロジェクトは炎上してしまう。誰も幸せにならないので絶対にやってはいけない。

一方で、経験豊富な強エンジニアがいると、魔法のようにズバリ言い当てることがある。彼らは公式ドキュメントにひっそりと記載されている一文はおろか、ドキュメントに記載されていないブラックボックスな部分まで知っている。なんでそんなこと知ってんの？うわ引くわ。マジやばみざわ。ちょっと今晩ビール奢らせてください。みたいなことは良くある。

以下は私の経験でのサチりあるあるポイントや要チェックポイントなどである。
・サーバーのCPU、メモリ、disk I/O
・使っているサーバーは共有か専有か？
・各所ロードバランサはどこに設置されていて限界値と確認方法はあるか？
・各所スループットに限界値と確認方法はあるか？
・ソフトウェアの問題か？
・ミドルウェアの問題か？
・ハードウェアの問題か？
・キャッシュは効いているか？逆にキャッシュが悪さしてないか？
・リトライ処理は入っているか？
・各箇所のタイムアウトの設定は適切か？（request timeout、connection timeout、session timeout、command timeout）
・接続数に限界はないか？
・接続はプールされているか？
・排他制御は楽観か悲観か？
・トランザクション分離レベルは適切か？無駄にロックしてないか？
・DBのindexは狙い通り効いているか？
・外部サービスを利用している場合、rate limitがあるだろう？
・SaaSを利用している場合、怪しいと思ったらすぐにサポートに確認メールを出すんだ。英語でも躊躇するな。彼らのレスポンスは物凄く早くて真摯だ。
・PaaSとIaaSを利用している場合もすぐにサポートに確認メール、またはtwitterなどで凸するんだ。日本法人はあてにならないことが多い。英語でも躊躇するな。彼らのレスポンスは物凄く早くて真摯だ。
・スケールアウトやスケールアップのスピンアップはどの程度だ？その間のリクエストはどうなってしまう？

つらつらと書いてしまったが以上だ。あとから加筆するかもしれないが、大したこと書いてないけど良いこと書いてあるなこれ。3年前くらいにこの記事に出会いたかったものだ。誰かビール奢ってくれないかな。

負荷試験を綺麗に着地させることは至難の技だが、誰かの助けになれれば幸いだ。

現場からは以上です。