RM-BLOG

IT系技術職のおっさんがIT技術とかライブとか日常とか雑多に語るブログです。* 本ブログに書かれている内容は個人の意見・感想であり、特定の組織に属するものではありません。/All opinions are my own.*

【障害記録】No.6:大容量データのFTP転送によるサーバ過負荷と、それに伴うシステム一時停止

自分が体験したシステム障害を紹介してトラウマを抉り返す自虐コーナー
※特定避けるため一部脚色・変更しているが、大体ほぼ実体験。

障害No障害分類No
(自分用)発生分類
アプリ/データ/ミドル/ハード案件名個人的ヤバイ度
(5段階評価)

6 B ハード 大容量データのFTP転送によるサーバ過負荷と、それに伴うシステム一時停止 ★★★★☆

 


 

 

発生日時 2011年某日 解決日時 当日中 発見者 お客さん 対応者 みんな 原因者 俺ではない!(笑)
障害の詳細内容 既に稼働中のシステムの追加機能開発プロジェクトのリリースに向けた準備(いわゆる「移行」)のため、
別環境(移行データを作った環境)からデータを抽出して本番環境に移送する作業を行った。
当時の記憶があいまいだが、そのデータが、圧縮かけても全部で120GBほどだったと思う。
それを無策にも移行環境⇒本番環境にFTPで生PUTした。
そしたら本番環境側のサーバが過負荷でリソース不足に陥り、
一時的にシステムがダウンした

という笑えない問題。

ちなみにDISK I/Oというよりは、メモリがいっぱい(空き容量が0)になっている様子が
直前まで吐かれていたシスログからなんとなく追うことが出来た。
FTPの設定とかにもよるのかもしれないが、
サーバ間でFTPのデータ転送をする場合、
一時的にサーバのメモリ内に転送データを蓄積してから出力するような動きをするようだ。
これによりメモリを使い切ってしまってサーバが高負荷状態に陥った、というのが事の真相と思われる。
結果的に全部のデータを転送しきるまでの約10分間、この状態が継続した。

その意味でいえば発生が「ハード」っての確かにそうなんだけど、
一方的にハードのせいにしてしまうのもなんかハード側に悪い気はする(そんな気を使っても意味ないんだが)。
とりあえずハードの問題として詳細記載していくが、
実質的にはその作業背景を追及することに終始すると思われる。
対応内容・経緯等 最初は
「ログイン画面が開かないって問い合わせが各所から来るんですが、なんかしてませんか?」
という1本の電話からだった。
うっそだろぉ~(半信半疑)と思って自分でログイン画面のURLたたいてみたら確かに応答がない。
マジか?!と思ってTera Termを立ち上げてサーバへのログインを試みるも応答がない。
なんかヤベエぞ!!で大事になった。

ただシステムのドメイン(インターネット公開されている)に対してはpingも通るしnslookupで名前も引ける、
どうもネットワークの問題ではないらしい。
負荷分散装置も問題なく動作していた。
となると少なくとも負荷分散装置より先に問題がある。
アプリかDB、もしくはサーバ自体に何らかの問題がありそうだが、
リリースもしてないのに日中突然アプリがイカれるというのは考えにくいし(なくはないがw)、
DBには普通につながるしSQL投げるのも問題ない。
⇒となるとサーバ自体に何かが起きている!

というところまではなんとなくたどり着いたのだが、
いかんせんサーバで何が起きてるか確かめるにしてもTera Termで接続できないので状況がわからない。
「なんか負荷の高い作業してないかー!?」と周りに聞いてみたところ
「ひょっとしてこれかな?(´・ω・`)とKさんが手を挙げる。
俺自身はそこで初めて120GBのFTP転送が行われていることを知った。

十中八九それが原因とは思えたが、
コマンドキャンセルを受け付ける余裕すらサーバが持っておらず、
結局全データの転送が終わるまでその状態が継続した。
その直後、一気にシステムが復旧。
ログイン画面も普通に開き、ログインもできた。
反省点・あとがき 説明の都合上(と、一応責任逃れをするためにw)、原因となった実作業者のKさんを登場させたが、
この件に関してKさんを追及する気は少なくとも個人的には全くない。
確かに今振り返ってみれば、
120GBものデータをFTP転送するってのがそもそも危なっかしいっちゃ危なっかしいが、
それがこういう事態を引き起こすとは作業前わかっていなかったのだ。
少なくとも俺は知らなかったし(この件で勉強させてもらった)、
担当が俺だったら俺がこの件の当事者になっていただろうことを考えると、
決してKさんを問い詰められるものではないと思っている。

俺自身は、その日その時間にこの作業をするっていうのを知らなかったが、
Kさんは、本番環境作業をするうえでの必要なプロセス(作業手順のPJ・顧客レビューを経ての申請・承認)を
ちゃんと踏んだ上で作業に臨んでいたので、
PJ内の必要メンバーにはこの話は通っていたし、なんならお客さんも知っていたわけである。
そしてその意味で言えば俺やお客さんを含めたPJ内の全メンバーが
「この作業に伴いシステムダウンする」という問題を知らなかった(予期できなかった)のだ。
結果として残念な事態を引き起こした点については申し訳なく思うが、
イレギュラーな形での本番作業が実施された結果ではないというのは一応言い訳しておきたい。

当然な話だが、、
「120GB転送するから一時的にサーバ死ぬけどやるよ。いいよね?(^^」
という意味の作業申請ではもちろんないし、
そんな作業申請が出たらお客さんはおろかPJ内ですら一度止めるはずである。
(システム停止に対して事前に明確な合意がある場合は除くが)
申請した作業内容は
「120GB転送するよ。いいよね?(^^」
という、単にこれだけだ。(もちろんこんなフランクな言い方じゃないが)
その結果システム停止するとわかっていれば事前に言ったはずだし、
言わなかったのは隠蔽したからではなく本当に知らなかったからなのだ。
要は「システム停止」するということが俺らもお客さんもみーんなわかっていなかった、ということがいいたい。

ただ、「この作業の結果、引き起こされる事態の予想が、誰ならばついたのか」という問いに対しては、
実作業者である我々しかいなかったと考えれば、
やはり、この件の責任、問題の所存は我々SIベンダーにあるのは間違いないだろう。
その意味では、単純に「知識不足だった」というのが原因の根本なのかなと思っている。

ちなみにシステムを一時的にとめたという問題であるこの件すら
「個人的ヤバイ度」は★4つとしている。
それはこの問題を超えるヤバイ案件を経験しているからである。
いつか話したいが、それはこんな単票ベースで話せるほど生易しい問題ではないので、
どのような構成で話そうか思案中である。