Amazon EC2の障害
こんにちは、丸山満彦です。クラウドシステムがとまると。。。今回はまだ軽症なのかもしれません。。。
■Amazon
●Service Health Dashboard
■報道
●日経新聞
・2011.04.22 Amazon EC2の障害、外付けストレージの復旧が長引く
＝＝＝＝＝
・・・アマゾン・ウェブ・サービシズは、EBSで障害が発生した経緯も明らかにした。それによれば21日未明、米国東海岸データセンターでネットワーク障害が発生し、それがトリガーとなって、EBSのディスクボリュームの複製を作り直す（再ミラーリング）というオペレーションが大量に発生した。
複製の作り直しが多発することで、あるAZにおけるストレージ容量が足りなくなり、EBSの新しいボリュームが作成できなくなったほか、複製を作り直すという作業自体にも遅れが生じ始めた。さらに、複製の作り直しの多発やストレージ容量の枯渇によって、EBSの管理ノードも1台ダウンし、障害が拡大した。
同社は現在、ストレージ容量の追加を行うことで、ディスクボリュームの複製作業を早期に完了させようとしている。それでも日本時間22日午後1時現在で、一つのAZでEBSが復旧していない。障害が発生しているAZでは、EBSのディスクボリュームに記録したユーザーのデータなどが、読み出せなくなっている。
＝＝＝＝＝
●Internet Watch
・2011.04.22 Amazon EC2に障害、HootSuiteやfoursquareにも影響
＝＝＝＝＝
障害が発生したのは北バージニア（US-EAST-1）地域のデータセンターで提供するクラウドサービス。EC2は複数の異なる「Availability Zone」でサービスを提供することで障害に対応しているが、今回は2つのAvailability Zoneで仮想マシンへの接続エラーや遅延が発生した。このほか、「Amazon CloudWatch」「Amazon Elastic MapReduce」「Amazon Relational Database Service（RDS）」などでも同様のトラブルが見られた。
＝＝＝＝＝
Comments
丸山 様
夏井です。
仮想システムでは，いったん何かのエラーが発生すると，そのエラーまでミラーリングされてしまい際限なく危機的状況が増幅されることがあり得ます。
原発で臨界事故が発生すると，どうにも手の打ちようがなくなってしまうことがあるのと同じです。
分散システムでは，そのような連鎖反応をブロックしやすいのですが，集中システムでは不可避の脆弱性の一つと言えますね。
集中システムは駄目です。
Posted by: 夏井高人 | 2011.04.24 16:32
夏井先生、コメントありがとうございます。集中システムにするのであれば、完全にコントロールできないとどうしようもないですよね。。。クラウドシステムはかつての汎用機と比較される場合がありますが、特定の1社がハードからOSやユーティリティにいたるまで、すべてに対応すうことがてきるかどうかという視点でみると大きく異なる様相になると思います。
オープン系を使った集中システムというのはかなり難しいのではないかと思っています。
Posted by: 丸山満彦 | 2011.04.24 16:45
丸山 様
夏井です。
「完全なコントロール」を実現することは，誰がやっても絶対に不可能ですので，「安全な集中システムは存在しない」という結論になりますね。
なにせ，コントロールする主体である人間または組織は，もともと不完全な存在なので，完全なコントロールを実行する能力を最初から欠いています。
かつてIBMが世界を支配していたころでさえ，IBMの汎用機を完全な存在だと信じていた人は世界中に一人もいなかったし，（人間系の事故も含めると）現に多数の事故が発生しました。
まして，安っぽいボードやディスクをかき集めて組み立て，特許侵害だとして処罰されたり特許侵害訴訟をいくつも提起されてしまうような安易なやり方でOSのようなものを構築・インストールし，素人に近い人々が運用し，サービス提供しているパブリッククラウドシステムだと，危険すぎて評論のしようもありません。
Posted by: 夏井高人 | 2011.04.24 17:45
夏井先生、コメントありがとうございます。
自分たちだけでかなり作りこんできたシステムであってもコントロールが難しかったわけd酢から、様々な人が係わって作られてしまったシステムはさらにコントロールが難しくなりますね。。。
Posted by: 丸山満彦 | 2011.04.24 22:47