障害と解決報告(サーバー不安定化&トップページの更新停止)

総閲覧回数:3,978,162回 / ブログ拍手:2,585
作品DB等各サービスの機能追加情報や、技術系・面白系記事を中心に提供。
記事の投稿は基本Twitterでも告知させて頂いています。
連絡は作品DBの論客の方なら私書、DB外ユーザの方ならメールTwitterで可能です。
アクセス記録[推移 / PV内訳(過去1日 / 過去1週間) / 外部アクセス元 (昨日 / 過去1週間) / ログイン論客足跡]
プロフィール私書(メール)
   /   /送済
評価(一覧   /)
投票   /共:   /
ファン登録
作品/情報/
DB構築()
ブログ
[書く]
攻略記事リンク集
My Play List
<=次の記事 東京雪景色@神田
=>前の記事 攻略記事を書くにあたってのルールを拡張しました

1.
2014/02/14 作品DB開発/運用 > 障害と解決報告(サーバー不安定化&トップページの更新停止)」
[この書込みのみ表示(記事URL紹介用) / 編集 / 削除 / トラバ送信 / 共有分類に追加(タグ付け)]拍手:5個

1. 障害報告: 昨日夜から昼迄のサーバー不安定化 & 昼から本日夜までの作品DBトップの更新ストップ
2. 経緯
3. 反省点&今後の改善策

1. 障害報告: 昨日夜から昼迄のサーバー不安定化 & 昼から本日夜までの作品DBトップの更新ストップ

昨日夜から本日昼過ぎまで作品DBのサーバーが不安定化し、
昼過ぎから夜まではトップページが更新されないという障害を引き起こしていた事を報告させて頂きます。
ご迷惑をおかけ致しました。
2. 経緯

最初は些細な事から、風吹けば桶屋が儲かるのような連鎖で、こんな事に派生してしまいました。

[昨日夜]
1. Yahooニュース
http://news.yahoo.co.jp/pickup/6107084
で銀河英雄伝説が取り上げられてる事に気付く

2. Yahooニュースからのリンクからといえ、サーバーが反応困難になる程忙しくなるとは思えないのに、サーバーが忙しいから後でこのページにはアクセスしてね、というクッションページが付けられている事に疑問を持つ

3. access_logを眺めていて、ユーザーエージェント(=ブラウザー名)が空のアクセスがそのページに繰り返し来ている事に気付く。
そのIPを調査してみるとアクセス元はYahooだった。
つまりYahooはニュースでリンクを張った記事に対して、サーバーBusy有無判断をしていて、その判断をする処理をUserAgent(=ブラウザー)名を空でアクセスしてきていた。
しかし、こっちはWebサーバーの設定として、ブラウザー名を渡さないアクセスは、怪しいアクセスとしてアクセスを遮断していたので、YahooのBusyチェッカーがサーバーにアクセス出来ない = サーバーが忙しい状態に違いない、という誤判断されている状況になっていた。

4. しょうがないという事でブラウザー名が空でもアクセスを許可する。

5. その後そのアクセスを見かけなる。
が、実はこれのアクセスによってエラーが発生していて、このアクセスが問題を起こす事態に繋がっていたと思われる。

[朝]
6. 朝起きたらWebサーバーの再起動が頻発している事に気付く。
1分毎に稼動apacheプロセス数が指定値を下回って、監視プログラムによりWebサーバーの再起動が繰り返されるという状態。

7. エラーログを見てみると、apacheがsegmentation errorで落ちているという記録がある。
segmentation errorだと理由のトレースがログからだけではできないので、今迄のパターン的に大体BerkeleyDBだろうと思ってあれこれ触るが解決せず

8. 調査の為にgdbをインストール。
yum install gdb;
debuginfo-install --nogpgcheck --enablerepo debug expat-2.0.1-11.el6_2.x86_64 glibc-2.12-1.80.el6_3.7.x86_64 keyutils-libs-1.4-4.el6.x86_64 krb5-libs-1.9-33.el6_3.3.x86_64 libcom_err-1.41.12-12.el6.x86_64 libgcc-4.4.7-3.el6.x86_64 libselinux-2.0.94-5.3.el6.x86_64 nss-softokn-freebl-3.12.9-11.el6.x86_64 openssl-1.0.0-27.el6_4.2.x86_64 zlib-1.2.3-27.el6.x86_64
し、coredumpさせ
そのログを見る
gdb /usr/local/apache2/bin/httpd -c /tmp/core.23257;
所まで持っていくけど時間切れ

[昼]
9. gdbの出力を見ながら調整していて、最終的にmod_evasiveという連続アクセスを攻撃とみなして遮断するapacheモジュールの中で、
自分が改造して加えた関数
int is_whitelisted_ua(const char *ua);
...
if (is_whitelisted_ua(lookup_header(r, "User-Agent"))){
return OK;
}
...

int is_whitelisted_ua(const char *ua) {
if(strstr(ua, "Googlebot")!=NULL){
return 1;
}
else{
return 0;
}
}
で問題が発生している模様という事を把握。
恐らく
lookup_header(r, "User-Agent"))
からNULL値が渡される形で、最終的にstrstrの部分でエラーが起きていたのではないかと思われるけど、それは後で検証予定。
ずっと昔からあった機能ですが、今迄はUAが空のアクセスを許可していなかった為、この問題の発生が無かったのではないかと思われる。

10. とりあえずmod_evasiveを外してサーバの安定化はもたらす

11. この時点でcoreファイルを扱う為、rootで作業をしていた時に、トップページの生成過程のファイルをroot権限で生成してしまった模様。
これで作品DBのトップページが更新されなくなるがそれには気付かず作業離脱(14:00前)

[夜]
12. 自分の時間とれる時間になったので確認してみたら、私書での報告でトップページが更新されていないという報告を受けてる事に気付く。
見てみて問題はすぐ特定して解決させる。

13. ぐあーと、壁をガンガン蹴ってから、反省文兼報告書を書く(←今ここ)
3. 反省点&今後の改善策

1. gdbを使える環境を用意していなかった <= gdbを全サーバーで使えるようにしておく
2. 携帯変わってアドレスも変わっていたけど、障害報告のメールアドレス設定を変えていなかった <= 早急に変えておく
3. 携帯持たずに出かけた <= 家にいる時も胸ポケットに入れておく

その時間帯に不安定な現象に遭遇した方にはご迷惑をおかけ致しました事をお詫びさせて頂きます。

コメントする5個


[他の記事も読む]
<=次の記事 東京雪景色@神田
=>前の記事 攻略記事を書くにあたってのルールを拡張しました


大分類が「作品DB開発/運用」の記事
この論客の記事全て
↑上へ