amazon EC2（クラウド）障害

twitterを愛用する人はHootsuiteが使えないということで気づいたかもしれない。
12時間以上も続く障害はamazonにしてはめずらしいほうだろう。

原因はミラーリングだという。
ミラーリングとは、万一の故障でデーターを失わないように、サービスを中断しないようにデータを多重に保存する方法。
安全策が裏目に出た皮肉な例。

さて、安全策が裏目に出たのはなにもamazonだけではなく、今年2月にGoogleのGmailが大規模障害を起こし、一時は消えたメールを復旧できないのではないかと思われたほど。この時も復旧にかなりの時間がかかった。

ところで、原発ではないけれどサーバーでシステムを構築するときは安全策を何重にもとります。
その中でもデーターの保護とサービス継続性の維持には最も注力する部分です。

その方法は

• ディスクの遠隔地とのミラーリング
• HA構成
• Oracle採用

が代表的なもので大規模なシステムはこの3つを全部採用することが多く、クラウドではOracleを選ばない例も増えてきています。

どれも安全策としては代表的なものですが、これが原因となって重大な障害に至ることもまた珍しくない。そしてこれら3つが障害の原因となった場合には、順にそれらの要求に沿った手順で処理しなければ稼働することができず、復旧にやたら長い時間がかかる原因となっています。

かと言って採用しなければもっと頻繁に問題が起こりやすいし、致命的なデーター喪失や、そもそも処理しきれないといった問題がおきます。

今回のような事故を見ると原発の事故も大差ないなという感じもしてしまいます。おそらく出来ることの限界をわきまえてサービスの上限、あるいは、そもそもやるかやらないかを決めるべきなのでしょう。

ちなみに、携帯電話の大規模なコンテンツサービスを運営していたときはHAはあきらめました。
Oracleを使っていると処理に一定以上時間がかかることがあり、HAが障害と誤検知して起動してしまいさらに状況を複雑にしてしまうということがあるのが原因でした。
ミラーリングは行いましたがディザスタリカバリーの一歩手前の遠隔地ミラーリングは転送速度を計算するととても帯域が足りないため実現できませんでした。

平常時の安全性とサービスレベル維持を重視しすぎると、それが原因で障害が起きたとき復旧が大変難しくなります。
ディザスタリカバリーも、即時性を重視するとレスポンスを低下させるしかなくなるのですが、超大手クラウドサービスではでょざすたリカバリをとって応答速度の低下を受け入れるか、あるいは日々のレスポンスを優先するかを選択性にすると先日報道がありましたが、こうしたユーザーがチョイス出来るメニューが欲しいですね。