サービスを運用しているとたぶんどこかで障害の対応をしていると思います。
前職が受託案件が多かったのと、サービスの規模が小さかったため対応までやったことはなかったですが、
最近多くなってきたので、やっている内容の備忘録です。
復旧のために
- サーバーを増やす
- 再起動
- サーバーのスペックアップ
このあたりがメインでやることになりますが、やっぱりクラウドはこのあたりが柔軟で素晴らしいです。
基本的にはサーバーの状態を確認し、原因がなにかをざっくり見極めて作業しますが、WEB系なのでポイントがいくつかあります。
- WEBサーバーの負荷
- DBサーバーの負荷
WEBサーバー
WEBサーバーなら、apacheの再起動。
で、ダメだったらサーバー系を試します。サーバーを増やして再起動して、ダメだったらサーバーを強化。
大体このあたりでなんとかなりますね。ならない場合はプログラムが悪いか本格的な攻撃だと思う。
大量アクセスなどの攻撃の場合はファイアーウォールで弾きます。
DBサーバー
最近こっちが厄介で影響がでることが多いのですが、基本はスペックアップ一択です。
データを分散していないので、スペックアップで乗り切るしかない感じがありますが、それだけでダメなケースが多くなった印象なので、パターンを書いてみます。
CPUが継続的に高い
スペックアップするか、常に利用してそうなテーブルにインデックスを貼る
CPUが一時的に高くなる
スロークエリを見る。時間がかかっているSQLがあれば、そのクエリが原因でCPUが上がっている場合が多い。
インデックスを貼ったりクエリの見直しをする。
コネクションが多い
スペックアップも検討するが、どこからのアクセスで多いかボトルネックを調査
コネクションが多すぎて繋がらない
再起動に賭ける。ダメな場合はコネクション数を調整して試す
100→2000などにして変更後ログインして、プロセスでなにがあるか調査。結局はボトルネックをなんとかしないとダメ
再インデックス
indexが壊れている可能性もあるので、試してみると効果があるときがある。
バキューム（Postgresの場合）
再インデックスと同じ理由。最適化される可能性がある。
AWSのRDSの場合、ストレージタイプを見直すのも検討する（障害の後で）
ストレージタイプなどで性能も変更できるのが容易されていれば、そちらも検討する。
I/Oなどがボトルネックの場合は効果的だと思われる。
復旧後に再度原因調査
根本原因がわからないと再度発生する可能性があるので、調査するがわからない場合が多くなってきた。
もっと調査に使えるログをわかりやすい環境にしていきたい。
newRelicとか入れてるけど使い方がいまいち分かってない。多分障害時とかすごく使える気がしているのに、勉強できていない。
詳しい人間でも育てるかな。サーバー関連はある程度でプログラムに専念したい今日このごとです。
