【黒歴史】Apache Benchで負荷試験をしたら複数のシステムをダウンさせた話

6265 ワード
apache2 Apache ApacheBench DDoS Apache テキストリンク

背景

すごーく昔の話です。　10年以上前のお話。

新たに構築するシステムの試験にて、負荷試験を行うことになり
当時のPMとこんなやりとりをしていました。

PM氏
　『うちの他システムの会員数って今800万人くらい？　会員さんの1%が同時にアクセスする感じで負荷試験ってできる？　新システムは注目度高いからそれくらい同時アクセスあるかもしれないし。』

若かりし自分
　『技術的には可能ですね。』

PM氏
　『1人あたり100回操作する感じでテストしてみますか～』

若かりし自分
　『はい！』

当時の線は、ベストエフォートで10Mbps程度でした。
しかもテスト環境も本番環境も同じ線の上にのっている状態でした。

そして、この線の上で色んなシステムが稼働している状態でした。

　

Apache Benchとは

Apache Benchについて

Apache HTTP Serverをインストールすると一緒に付いてくる
性能検証のためのツールです。

例えば、100人が同時にシステムにアクセスして、、、
10回操作したらシステムは耐えることができるのか？
接続エラーが発生したり応答時間に変化は起きるのか？

こんな感じの検証をコマンド一発で実現することができる神ツールです。

概要はこちら
https://httpd.apache.org/docs/2.4/programs/ab.html

　

Apache Benchでこんなこともできる

・認証が発生するシステムにおける認証後の画面を対象にした負荷テスト
・Cookieを用いたリクエスト
・カスタムしたHTTPヘッダを用いたリクエスト

　

Apache Benchで難しいこと

・リクエスト結果をもとに次のリクエストを投げるテスト
　※フロー、シナリオみたいなやつが苦手
・リクエスト結果に追従して発生するリクエストの時間計測
　※iframe、埋め込み動画、画像、JS等
　

Apache Benchで性能テストを行う際の簡易コマンド説明

$ ab -n 8000000 -c 80000 http://localhost/search/
オプション 設定内容 説明
n リクエスト数 8万人が100回アクセス
c コネクション数 8万人の同時アクセス

　

やらかした

800万人の1%が同時アクセスして、100回システムを操作するので
ベンチマークは以下のような設定になります。

$ ab -n 8000000 -c 80000 http://localhost/search/

コマンドを発射した瞬間に起きたこと

　

コマンドを投げた環境が操作を受け付けない状態となりコマンドを停止できない状態に

localhostにコマンドを発射しているので、自滅状態となった

　

電話が鳴り始めた

同じネットワーク内のシステムが落ち始めて、電話が鳴りまくった
回線が落ちてチャットツールが使えない状態に

・メインのテスト対象システム と もろに影響を受ける他システムが真っ先にダウン
・回線を圧迫してしまったことにより同一ネットワーク内のシステムにアクセスできない状態が発生し、事実上のダウン

中で起きていたこと

ざっくりいうと以下のような環境だったんですが・・・

　

ベンチマークツールの実行で想像以上に大事になってしまった

テスト環境だけでなく、本番環境にも影響が及んでいた。。。。
　

ベンチマークが止まって、回線の圧迫が解消され、問題が特定され、Skypeに問い合わせ殺到

『一体何やらかしたんですか？』

『何やってるんだ』

厳しいお叱りメッセージが各所から寄せられ、ひたすら謝りまくることに。
後日に報告書、是正対策を作成した。

反省点とやるべきだったこと

ベンチマークツールの設定値の根拠が超適当

PM氏
　『うちの他システムの会員数って今800万人くらい？　会員さんの1%が同時にアクセスする感じで負荷試験ってできる？　新システムは注目度高いからそれくらい同時アクセスあるかもしれないし。』

今800万人の会員さんの1%がリアルタイムに同時アクセスすることがあるのか？
アクセスログ調査して実態を把握するべきだった。

また負荷試験の対象システムで他システムと同等のアクセスが発生しうるのかの確認も必要だった。

　
　

負荷テストの実行により発生する影響の洗い出しが必要だった

負荷テストの実施で、どのシステムにどんな影響が出るかを事前に整理し
関係者に事前連絡を入れるべきだった。

　

　

いきなりMAXスタートしてしまった

負荷テストの基本はミニマムスタートし、徐々に負荷を高めていくことが大切。

いきなり限界を大幅に超えたリクエストを投げたことにより
全システムダウンといった結果を招いてしまった。

　

　
　

第三者が他システムへ影響がある負荷試験の実施を把握できる状態になかった

PM氏
　『うちの他システムの会員数って今800万人くらい？　会員さんの1%が同時にアクセスする感じで負荷試験ってできる？　新システムは注目度高いからそれくらい同時アクセスあるかもしれないし。』

この発言に全く違和感を持たずに「そうなんだ。　それが正しい」と思ってしまったこと。
負荷試験の設計書をこのPM氏がレビューしていたため、第三者が負荷試験の設計書を見ることがなく試験が前に進んでしまった。

最後に

全システムダウンはベンチマークツールが自滅したこともあり
１分にも満たない出来事であったのは不幸中の幸い。

ベンチマークツールが自滅せずに外部コマンドを受け付けずに実行を続ける状態になっていたらと思うと
冷や汗が出ます。

・負荷試験の設計は計画からきちんとたて、第三者レビューを行いましょう。
・負荷試験は徐々に負荷を高める感じにしましょう。
・負荷試験を行う際は影響を受けるシステムを洗い出して、関係者に事前に連絡を入れましょう。

　
　
　
Twitterはじめました！
フォロー技術QAいただけたら嬉しいです！