AWSバージニア北部リージョンで障害が起きたオブジェクトストレージのAmazon S3はAWSを象徴する存在で、ほかのサービスに広く組み込まれています。改めて障害の内容や原因を教えてください。
吉田 原因は、AWSのS3チームのメンバーが入力したコマンドのミス。バージニア北部で、S3の請求システムを修正する際のミスのようです。
ミスによって、意図した以上の多数のサーバーが停止しました。その他の重要なサブシステムにも影響が広がり、システム全体を再起動したのです。再起動の間、S3のAPIが利用できなくなり、バージニア北部の他のサービスも影響を受けました。復旧には4時間以上掛かりました。
日本のユーザー企業には、どんな影響があったのでしょうか？
秋永 当社（NTTドコモ）はユーザーとしてAWSを大規模に使っていますが、大きな影響はなかったですね。影響を受けた日本企業は少なかったと思います。
先日のE-JAWS（Enterprise JAWS-UG、AWSのユーザー企業のコミュニティー）で、S3の障害の話が出ました。影響を受けたと言っていたのは一部の企業だけで、しかも影響の範囲は限定的だったとのことです。
吉田 私はAWSのパートナーの立場です。特段、ユーザー企業向けに対応する必要はありませんでした。
今回のような障害は、東京リージョンで起こり得るのでしょうか。
秋永 東京リージョンでも起こる可能性はあります。ただ、よく障害が起きるのはバージニア北部ですね。
障害は電車の遅延や停電と同じ
吉田 バージニア北部はAWSの新機能やサービスがいち早く展開される分、ほかのリージョンに比べて障害が起きやすいと思います。バージニア北部は利用料が安い。その分、そういうリスクを引き受けている、というのが私の考えです。
私にとってクラウドで障害が起こるのは、例えるなら電車が止まったり、停電が起きたりといったことと同じ感覚ですね。そもそもAWSも「クラウドは障害で停止することがある」といっています。意図せず停止することがあるというリスクを許容できるか。これが、クラウドを使うかどうかを判断するポイントになります。
秋永 AWSは「クラウドは障害で停止することがある」と口酸っぱく言っています。これまで日本のユーザー企業でクラウドが停止するリスクを理解せずに導入を決めたところは少ないでしょう。障害が起こり得るのは、他のクラウドも同じです。
ユーザー企業のすそ野が広がるにつれ、リスクを十分に理解しないまま導入しようとするケースが増えていると聞きます。
秋永 そういうユーザーは、いざというときに慌てるでしょう。そもそもクラウドの利用にはリスクがつきもの。適切にリスクを取れる企業が恩恵を受けられる。そうでない企業は受けられない。これは当然です。
今回の障害で考えれば、止まることを想定していないシステムであれば、そもそも安易なクラウド利用は避けるべきだったということです。
吉田 私もそう思います。停止させたくないシステムをクラウドで稼働させるのはそもそも無理があります。アーキテクチャーの構成や運用の方法によって、ダウンタイムを短くすることはできますが、コストが高く付きます。それでもクラウドに乗せる必要があるのか。慎重に考えるべきだと思います。
停止させたくないシステムはクラウドに乗せないとしても、ダウンタイムは短いほうがいい。今回のような障害がAWSの東京リージョンで起こるかもしれないという前提に立ったとき、どんな対策を取ればいいでしょうか。
吉田 S3であれば、複数のリージョンに同じデータを保存しておき、障害発生時にすぐ切り替えられるようにすることです。簡単に、リージョンを横断した冗長化をできるのがクラウドの利点ですから。
しかし無条件にそうすべきというわけではありません。冗長化にはコストが掛かる。同じコストを掛けるなら、1年に1回も起こらないリージョン単位の障害に備えるよりも、優先すべきことがあるのではないでしょうか。例えば、自社で利用しているEC2（仮想マシン）を冗長化したほうが効果が高いと思います。
