DC/クラウド/通信事業者サービスの障害事例よせあつめ
はじめに
データセンタ障害の話題がちらほら流れておりますが、その中で見かけた「データセンタでそんな障害あったら意味ねえじゃん」みたいなコメントにちょっと引っかかるところがありまして。まあ確かに電源の二重化云々とかいろいろ災害やトラブルに対する対策はしてますよ。してますけど、でもデータセンタ・オーダーの障害とかも実際あるんですよね。落ちるときは落ちるんですよデータセンタだろうと。信頼性は高いけど100%じゃない。
ということで、じゃあ過去どんな事例があったのか、ざっと事例を挙げてみようと思いました。基本的には過去の私のツイートとかはてブとかネットをざーっと検索して出てくるものを取り上げています。「データセンタ使ってるからオールオッケー」みたいな話ではなくて、その上で・さらにこういうこともあるんだ、という話を見るのに参考にしてもらえれば良いかと思います。
なお、ここで取り上げている事例は、特定の会社やサービスをdisる意図で挙げているのではありません。
DC持ってるところだと、何らかの大規模障害の経験があるところはそれなりにあるんだと思うんですけど、それが特定ユーザ向けとかある程度影響範囲が「握れる」場合、外に情報が出てこなかったりするんですよね(特にエンタープライズ系だとね)。そうなると表に出ている範囲って、複数(多数)のユーザに影響があって、公開せざるを得なかった事例…ということになるかと思います。そういうところでちゃんと障害原因や事後対応について突っ込んだ情報を開示していることは、その企業/サービスの誠実さの表れだと思うのです。トラブルに対して責任ある対応をしているかどうか。
きっかけはデータセンタ(ファシリティ)障害についてですが、ファシリティ障害以外の話も含めて、データセンタ・その上に乗っているであろうクラウドサービスやキャリア(通信事業者)サービスなどの障害についての事例を取り上げています。
参考
- こんなにあった!クラウド大規模障害まとめ - NAVER まとめ
- システム障害事例情報の分析に基づく 教訓・対策を共有する仕組み 〜智の共有が安心・安全社会を創る〜 重要インフラセキュリティセミナー 2014年12月4日 独立行政法人情報処理推進機構(IPA) 技術本部 ソフトウェア高信頼化センター(SEC) (pdf)
- 情報システム障害の発生原因や状況など各種調査・分類など
- JANOG35 ネットワーク災害訓練 BoF
- 柏崎先生。スライドだけ見てもわわからないと思うけど、災害訓練の話聞けるととても参考になると思う。
2016
[2016/01/31追記] github障害事例を追加
- Data Center Power Outage Brings Down GitHub | Data Center Knowledge
- Update on 1/28 service outage
- ハードウェア故障(電源設備故障)
- "A brief power disruption at our primary data center caused a cascading failure that impacted several services critical to GitHub.com's operation." (プライマリデータセンタで発生した停電が連続した障害を引き起こし…)
- GMO、先週の24時間にわたるサービス障害時にはデータセンター内の約12%が電源喪失。変圧分電盤故障が原因の可能性。監視体制の強化など対策 − Publickey
- ハードウェア障害(電源設備故障)
2015
- Google Compute Engine、いつもは自動で行うネットワーク操作を手動で行い、ミスに気付かず一部でネットワーク障害 − Publickey
- ヒューマンエラー
- ニュース - au携帯電話のEメール、159万台で利用できない状況続く:ITpro
- DC火災報知器作動(誤作動?)→空調停止→室温上昇→サーバ停止
2013
- ニュース - [続報]住基ネット障害の原因は「文字化け」、231市町村に影響:ITpro
- ソフトウェア障害
- 「gooメール」ログイン不能の障害、データセンターの電源工事ミスに起因 -INTERNET Watch
- ヒューマンエラー
- KDDI、LTE障害の原因判明 ソフトと機器が同時故障 :日本経済新聞
- ソフトウェア障害+ハードウェア障害の連鎖 (ソフトウェア障害に対するパッチ宛てのため方肺運転中にハードウェア障害が発生)
- auのメール障害、KDDIが原因を正式発表。 手順書の誤りによる人的ミス、障害への対策不足が明らかに。 – すまほん!!
- ヒューマンエラー
- ニュース - GMOクラウドで障害、原因は台湾DCでの火災:ITpro
- 横浜第一データセンターの電源設備障害について (pdf)
- 当社サービスの不具合に関するお詫び|住信SBIネット銀行
- ハードウェア障害(電源設備故障)
2012
- 富士通の旗艦、館林データセンターが電源障害でダウンし、金融機関やニフティクラウドに影響。日経コンピュータ誌 − Publickey
- ハードウェア障害(電源設備故障…基板に塵・ほこりが付着したことによるリレー誤作動)
- Windows Azureの欧州リージョンがダウンした原因は、ネットワークの設定ミスとバグだったとマイクロソフトが報告 − Publickey
- ヒューマンエラー+ソフトウェア障害の連鎖
- [2012/6/20に発生した大規模障害に関するお詫びとお知らせ] ファーストサーバ株式会社
- Google App Engine、全データセンターを巻き込む連鎖的障害で能力半減、復旧のためフルリスタート − Publickey
- 2012年のクリスマスイブ、Amazonクラウドから降ってきたシステム障害。原因はオペレーションミス − Publickey
- ヒューマンエラー
- Amazonクラウド、ストレージ障害は潜在バグからメモリリーク発生が原因。きっかけはDNSの変更 − Publickey
- ソフトウェア障害
- Amazonクラウドを襲った嵐が、EC2、EBS、ELB、RDSの障害に発展した理由(前編) − Publickey
- ハードウェア障害(DC電源設故障→UPSに切り替わるも電池切れ)
- Amazonクラウド先週のシステム障害、原因は電源トラブル。二重三重の防護策が次々と倒れる − Publickey
- ハードウェア障害(DC電源設故障→バックアップ電源へ切り替わるも、ブレーカ設定が不適切で電源ダウン)
- Salesforce.com suffers worldwide disruption after power outage | ZDNet
- Geekなぺーじ:Google Appsの障害はBGPハイジャック?
- ニュース - [続報]東証トラブル、原因はL3スイッチの障害:ITpro
- ハードウェア障害(ネットワーク待機系切替失敗)
- 日経コンピュータReport - 東証で大規模システム障害:ITpro
- ハードウェア障害+ヒューマンエラー? (三重化サーバの切替ミス)
- ニュース - 東証、システム障害の原因は「人為ミス」、診断レポートを“解読”できず:ITpro
- 全国でspモードメールが利用しづらい状況に〜現在は回復 - ケータイ Watch
- ハードウェア障害(通信設備故障)
- 一連のネットワーク障害への対策について - NTT docomo (pdf)
- ニュース - NTTドコモで11月14日発生したspモードの通信障害、影響数は最大270万人:ITpro
- ヒューマンエラー(ネットワーク機器設定漏れ)
2011
- 東日本大震災:データセンター稼働状況まとめ(18日11:50更新) - ZDNet Japan
- 「Mobage」などのアクセス障害が復旧、データセンター会社も謝罪 -INTERNET Watch
- ヒューマンエラー(DC側回線工事中のオペミス)
- 「さくらのクラウド」ストレージネットワーク障害に関するご報告(3月16日更新) | さくらのクラウド
- ソフトウェア障害
- 国内でもクラウド障害、復旧見通し立たず。NTTPCコミュニケーションズ − Publickey
- ソフトウエア障害
- Amazon Web Services ブログ: 米国東リージョンにおけるAmazon EC2とAmazon RDSのサービス障害の概要
- UQ WiMAX障害、原因は高トラフィック時のバグ KDDI田中社長が謝罪 - ITmedia ニュース
- ソフトウェア障害
- Geekなぺーじ:解雇されたエンジニアが外部からVM削除で業務停止
- 関西で発生のソフトバンク通信障害は内部の犯行、被疑者は逮捕 - ケータイ Watch
2009
- 「西新宿データセンター」における電源障害に関する質問および回答(最終版) | さくらインターネット
- ハードウェア障害(電源設備故障と発煙)
- Geekなぺーじ:2009年2月17日 世界的インターネット経路障害解説
- ソフトウェア障害
2006
- Googleのデータセンターで火事、6台の消防車が出動して消火活動 - GIGAZINE
- NCレポート - 大規模停電がデータセンターにも影響:ITpro
- ハードウェア障害(停電時の待機系電源障害)
- 首都圏大規模停電 - Wikipedia
おわりに
ということで、まあいろいろありますね…。特に二重障害の発生や、切替・片寄せにともなう高負荷状態の発生と連鎖(将棋倒し)とか、もうこれどうしろって言うんですか的な事例とかもある。publickeyの記事タイトルにもあるみたいに、こうしたことを踏まえてそれでも動くシステムを考えようと思うと、サービス/DC/リージョンをまたいで冗長化するようなシステムを考えないといけなかったりするってことですね。まあパブリッククラウド上でのシステムを作る場合はもちろんそこらへんまで考えるよね、という話になってきてると思いますが…。
ともかく、予期しないことが起こりうるという心構えは持っておきたいものです。
そのほかこういう事例もあるで、というのがあったら教えて下しあ。