負荷テストへの想い プロジェクト大炎上から学んだこと

僕はどんなに小さなWebサービスのプロジェクトだったとしても、プロジェクト計画を考える際、必ず「負荷テスト」が必要かどうかを検討します。

 

理由は、過去に負荷テストをしないことで、大トラブルに巻き込まれた経験があるからです。

 

本日は、この失敗から学んだことについて紹介したいと思います。

 

プロジェクトが大炎上!!

その大トラブル案件は、プロジェクト初期に旧サーバから新サーバへデータ移設を行い、新サーバにあるサイトをリニューアルするというもので、僕がインフラを除いた範囲のプロジェクトマネージャーとして参画するころには、サーバ移設は完了していました。

 

（まぁ、今思えば、与えられたサーバを何も疑いもせずに利用したこと自体が悪いですね。う～ん、若かったなぁ～）

 

要件でもらったアプリを開発し、動作検証を経て「さぁ公開！」出だしは順調でした。

 

ところが、1時間もすると、

 

ん？サイトが重い。。。。

 

てか重いってレベルじゃねぇぞ。トップページ開くのに3分かかるって。

確かにアクセスは集中してるけど、おかしくないか？？？

 

結局、半日以上経ったところで切り戻しの判断がなされ、旧サーバでリニューアル前の状態に戻されました。

鎮火作業開始！でも誰が？

さぁ、メンバー全員集まって「仕切り直すか」ってなりましたが、「誰が？」となりました。
疑わしきは、インフラとアプリの箇所ですが、インフラは別会社にお願いをしていて、確認したら、担当者はもう退職。。。

 

すったもんだあって、「アプリが出来ればインフラも出来る」という無茶苦茶な理由で、僕が担当することになりました。

え～

 

アプリとインフラはまったく別物なんですけど。
システムって言葉で簡単にくくらないでください。

 

と、しがない平社員がいくら騒いでも何も変わらないのでインフラをよくわからない僕が指揮を取り、借りてきた猫みたいにアサインされたインフラ会社の別の担当と、あーでもない、こーでもないと原因調査しました。

 

原因調査の結果と対応

結果、

• サーバに入れたセキュリティソフトが常に全ファイルセキュリティチェックしてた。
• さらに、負荷テストはしていなかった（実施してたら上記の問題は気がつけた。

 

とわかりました。

 

さらに、ロードバランサー2台冗長化していたが、最初から片系運転だったことも判明しました。。。

どんだけだよ、、、

 

最終的に、

• サーバのセキュリティソフトは、必要ないということで停止
• ロードバランサーは初期不良ということで交換

 

で解決して、プロジェクトを収束させました。

この対応に費やした期間は約1ヵ月半。。。。。

 

これに伴う影響として、

• インフラ、アプリ会社からの追加請求
• 連日の徹夜対応
• クライアント側のデータセンターの契約延長（当然、請求は我々にきました、、、）

 

などがありました。

 

ちなみに収束するまで毎日のように栄養ドリンクの差し入れをもらい、

常にこんな感じでした。。。。

 

失敗から学んだこと

ちょっと長くなりましたが、とにかく大変だったのです！

 

プロジェクトマネージャーとしてメンバーに、二度とあんな思いをさせてはならない。

そういう積み重ねが人を強くするわけですね。うんうん。

 

とまぁそんな経験を経て必ず負荷テストが必要かどうかを考えるようになったわけですが、クライアントからしてみれば、「負荷テストを実施してください」なんて親切な要求はありません。

 

そのため、見積もりが予算オーバーになったときに、何を削るか、という調整のタイミングで、

 

たぶん問題は起きないと思うので負荷テストを削ってください

 

と、クライアントからいわれることがあります。

 

そのたびに、

「ん”ーーーーー！？この人は何を言ってるんだ？？？？」

となります。

 

やるべきか否かとなれば、当然「やるべきだ」となるわけですが、そうなると見積もりには相応のコストが反映されるわけで、僕が担当するプロジェクトはちょっとお高くなってしまいます。

 

ですが、前述した苦い経験からして問題があろうがなかろうが関係はないのです。

 

これは僕らが請け負うに当たって、品質を担保するために必要なタスクなので削れないのです！

 

ただ、実際には負荷テストなどせずとも問題なく稼動しているアプリは存在しているので、他社と相見積もりを取られたりすると突っ込まれます。仕方のないことだと思います。

 

今日まで、それが理由で案件が見送りになったことはありません。

 

ですが、仮に負荷テストを入れることで金額に折り合いが付かないのであれば、見送りになってしまったとしてもそれは仕方ないと思っています。

 

だって、問題が発生したら、倍以上の金額がかかりますから。

 

また、品質保証以外にも、

• 限界はどこなのか？
• どのページ・機能に処理が集中しているのか

 

などもわかるため、運用の中で、アクセスが集中した場合の被疑をかけるポイントにあたりがつけられるというベネフィットもあります。

 

なので、目先のコストなどで負荷テストの実施可否を判断するような会社であれば、逆にお仕事を請けないほうが正解です。

 

とはいっても、長いお付き合いの会社だからなどといった理由もあるかと思いますので、

 

ライトにやりましょう

 

といった提案をして最低限の作業内容にするのが、できるプロジェクトマネージャー/ディレクターかと思います。

（そういったタスクも必要なこととして説明し、クライアントの合意を得られる話術も身につけたいところですが、、、）

 

まぁ、僕はたまたま相談できる相手もいなかったので、自分でできるようにならないと、という結論に至ったわけですが、何でもかんでも自分でやらないで最初からそういうことができる人組んだり、相談できる相手を見つけておくというのも重要です。

 

後者は、必ずしも社員である必要はなく、外部のパートナー会社だっていいのです。

 

負荷テストに限らず、自分にわからないタスク・問題が発生したら、どうにかできるよう日ごろから準備をしておきましょう。

 

その準備がどれだけできるかによって、今後かかわるプロジェクトの成功率が変わってくるのではないかと僕は思っています。