Webアプリケーションが止まったときの障害の掘っていきかた

Webアプリケーションの障害対策あるある。いわゆるLAMP環境を想定しています。

1. 緊急時は、メールではなく、電話で人を捕まえる
• ありがちなのがメールで必要な人を捕まえようとして、「待ち」の状態に入るという人。悠長なこと言ってられないので、電話で捕まえる
• インフラ周りは、アプリの担当でなくても、障害ポイントが分かるので、己のサービスを復旧させるためには、上司だろうとたたき起こして助けを求める。
2. マシン再起動もためらわない
• がっつり止まっている時には、ためらう必要はない。再起動することで原因を探るための証拠が消えるリスクもあるが、サービス停止のままの方がいいってことはあまりない
• リモートから再起動できないときには、データセンターに電話をして、物理的に再起動してもらいましょう
• たまには再起動の練習をしておきましょう。再起動時に自動起動して欲しいサービスが登録されてないというミスは早めに見つけておきましょう
3. すぐにできる調査あれこれ
1. 別のルートでアクセスしてみる
• 携帯からのアクセスだと、いろんなところを経由していうので、別経路としてPCなどのまるで別のネットワークからアクセスしてみる。
2. エラーログをみる
• アプリのログや、Apacheのエラーログなど、すぐにアクセスできるように。以外にそのまんまの理由が書かれていることが多い。
• いつでも見れるように。ログ参照の権限をあまりケチらない。
3. ロードアベレージみてみる
• ＷｅｂやＤＢのロードアベレージを見る
• cactiなどのツールは過去にさかのぼってみるには便利だけど、障害時は「今」をみなくちゃいけない
• ロードアベレージが高い時には、CPUの使用率とIO待ちを見る。ありがちなのは、CPUをあまり使って無くて、DBのクエリを待つApacheプロセスがずらりずらりと並んでいるという状態。そのときにはすぐにDBを疑う
• PHPでAPCを導入してると、PHPの処理速度がボトルネックになることはほとんど無いけどねー
4. DBでshow procecsslistしてみる
• ダメなSQLが滞留しているかも知れない。だめなSQLがロックをかけているかも知れない。phpmyadminだと「プロセス」タブで同じものが見れる。スローログを見てもいいが、閾値以上のSQLが全部でちゃうので、緊急時はどれがダメな子か見分けにくい。
5. IOが少ないはずのに、IO待ちが多いときにはdstatで見てみる
• 大した処理が流れてないのに、IO待ちが多いというときには、何か悪さしてないかを疑う。dstatコマンドで、IOがリアルにモニタリングできる
• 例えばデバッグ用のログを吐きだし続けていて、そこがIOのボトルネックになっていないか疑う
• Apacheのコネクションを多くしすぎて、メモリが不足し、SWAPすることでディスク書き込みが発生していないか疑う

そんな感じ。ざっとまとめると。

1. ボトルネックは一つ。それを探す
2. 遅いというのは「待ち」が発生している状態。ロードアベレージは「待ち」を表す指標でそれそのものは原因を表さない
3. コンピュータのリソースで、ボトルネックになるのは、CPUとIO。どちらかを特定する。