Fusicきばんブログ

Fusic基盤ユニットの非公式技術ブログ

障害対応の裏側で何をやっているかの話

Fusic 平田です。
基盤ユニットの追加モジュール的な何かになりました。

何書こうかなーと思い、最近あったtypoとの悲しい戦い*1をまとめなおすとかでも良かったんですが、せっかくなので違う話を。

サイトが閲覧できない!な時に何をやっているか

障害対応なんかに遭遇しやすい、あるいは呼ばれやすい性質でして。
その時何やっているのかって話を少し。

あわてない、さわがない、はしらない

まあとりあえず。
何もいい結果に繋がらないので。

起きている状況をなるべく正確に知る

「全く閲覧できない」なのか、「閲覧できるけどすごく重い」なのか、それだけでも大きな違いなので、状況確認は正確に。

ネットワーク的に到達できるのか、サーバにログインできるのか

これすらできない場合は、

  • ネットワーク起因だったりするので周辺の状況(経路でネットワークダウンの障害報が出てないかなど)を確認する
  • OSがハングしている場合は、再起動を試みる

といった対応にシフトします。

リソースの使用状況の確認

dstatで確認することが多いです。
リソース監視を行っているのであれば、そのグラフ状況を見るなどして、リソースの使用状況を確認します。

  • メモリが枯渇している
  • CPUを使い過ぎている
  • I/O待ちが発生しまくっている

といった感じで、ボトルネックを特定します。

ログを見る

/var/log/ 以下であったり、アプリケーションのログであったりを確認して、特異な(OOM Killerなんかは特異の典型)ログが出ていないかを確認します。
特異点の判断ポイントとしては

  • 明らかに普段出ないログが出力されている
  • ログの量が普段より明らかに多い

といった観点になるでしょうか。

ただ目で追うのもさすがに辛いので、grepなりwcなり、コマンドと組み合わせて原因を探る感じです。

あと、アクセスログを精査するのであれば、Kataribeが便利です。
ISUCON御用達ツールですが、負荷の高い箇所だったりアクセス増だったりの一次調査で使えます。

対策を決めて実行する

原因が明確に特定できたのであれば、対応する内容も明確になります。
アプリケーションの修正であったり、ミドルウェアの設定値変更であったり。
緊急度と対応時間とを天秤にかけて、場合によっては一次対応(応急処置)と二次対応(抜本的な対策)を分けるケースもあります。

原因が分からないケース

というのも当然あるので、その際は出力するログを増やすなどして網を張るようにしています。

実例だとこんな感じ

1ヶ月ほど前に起きた事例ですが。

  1. 状況としては「繋がるけどすごく重い」 → OSがハングしているとか、全く手が付けられないわけではなさそう
  2. ssh繋いでみたところ、接続できた → 障害報もないし、ネットワークはあまり関係なさそう
  3. リソースを確認するとロードアベレージが異様に高い → CPU起因だから、どこかで重い処理が走っているとか?
  4. ログを確認すると、httpサーバのログが大量に出ている → アクセスが相当増えた?
  5. アクセスログを精査する → 特定のページに対してアクセスが集中していることが分かった(原因判明)
  6. 特定のページと関連リソース(ページ内の画像)に対して一時的にキャッシュするよう設定変更(対策)

実例その2

こんなケースも。

  1. 「サイトに繋がらない」 → あらゆる可能性あり
  2. ssh繋いでみたところ、接続できた → ネットワークはあまり関係なさそう、OSも大丈夫そう
  3. リソースはどれもおおむね問題なし → 明確な原因が不明
  4. ログを確認するが、どれも平常通り → 明確な原因が不明だけど、httpのプロセスがうまく動作しなくなっているのかもしれない
  5. 応急措置としてhttpサーバを再起動(一時対応)したら復旧した → 引き続き注視しつつ、ログを精査するなどして調査
  6. 特定の処理が重くて落ちた可能性がある → 開発環境で再現するかを検証(原因判明)
  7. 再現したのでアプリケーションを修正してリリース(抜本的な対策)

というわけで

何かものすごいことをやっている話ではないので恐縮なのですが、こんな感じで障害対応していますって話でした。

余談: ログをもっといい感じに可視化して集中管理したい

可視化 + 集中管理の仕組みを設ければ、調査系で呼ばれる回数が減りそうだなーと。
前時代感なまま過ごしていたんですが、この辺をKibanaに集めるような仕掛けをぼちぼち組まねばな、と。

って書いてしまったので、今年の前半はその辺を整備していきます。

*1:100以上のコミットを経て、ようやく落ち着いた。と思う。