痛い思いをしてAmazon S3障害から得た教訓、「クラウド利用時のDRは大丈夫？」：クラウドは管理不能という現実

Amazon Web Services（AWS）のようなクラウドサービスを利用している企業は、障害発生に備えて災害対策（DR）計画を策定しておく必要がある。

[Alastair Cooke，TechTarget]

アマゾン ウェブ サービスによる障害報告《クリックで拡大》

　あなたの会社の災害対策（DR：ディザスタリカバリー）計画には、サービスプロバイダー側で障害が発生した場合の緊急時対策は含まれているだろうか。われわれは頭では、全てのコンピュータシステムで障害が発生することを理解している。だが時には、障害を経験して初めてこの問題を痛感し、適切な計画の策定に動くこともある。

　2017年2月に「Amazon Simple Storage Service」（Amazon S3）で大規模な障害が発生した際、あなたの会社はDRを実行できただろうか。あなたの会社がDR計画で別のクラウドサービスを使用していても、この「Amazon Web Services」（AWS）の障害事例には学ぶべき教訓がある。特に、DR計画の各要素のサービスレベル契約（SLA）、中でもあなたの会社の管理が及ばない要素のSLAを認識する必要がある。

併せて読みたいお薦めの記事

AWSの障害に関する記事

• AWS大規模障害はなぜ起きた？　クラウド不安を払拭するためにやるべき対策

クラウドで障害に備える

• AWS、AzureがDDoS攻撃を受けたら？　ユーザーができる対策はこれ
• Oracle DatabaseをAWSへ、ダウンタイム別に考える3つの移行方法
• ソニーが明かす“障害頻発”写真共有サービスの再構築、AWS活用でどう改善？
• 事業者任せにしない、クラウドサービスのダウンタイムを削減する方法

何が問題だったのか

　AWSの障害の原因は、ごく単純なものだった。AWSのエンジニアが通常のメンテナンス時にコマンドを誤入力してしまったことだ。その結果、S3の管理と監視を行うAWSのインフラが正常に稼働しなくなった。S3を使用する米国東部（バージニア北部、US-EAST-1）リージョン内のアプリケーションは、新しいオブジェクトを作成できなくなったもようだ。

　そのせいでDRアプリケーションは、新しいバックアップを保存できなくなった。S3をDRに使用する顧客は、RPO（目標復旧時点）を満たすことができなくなっていたかもしれない。またDRアプリケーションは、既存バックアップからリストアを行うこともできなくなり、RTO（目標復旧時間）の達成にも影響が及んだ。

　AWSが完全にサービスを復旧するまでには約6時間かかった。AWSによると、S3は99.9％の月間稼働率を目標としている。これを1カ月当たりのダウンタイムに換算すると、44分弱となる。AWSが2月については、料金の一部を返金しなければならないのは明らかだ。AWSの障害の影響を受けた顧客にとっては、稼働率は90％にとどまったとみられるからだ。

　だが、返金を受けても、障害時にDRイベントが発生した顧客には、ほとんど慰めにならないだろう。障害が解消されるまで、最後に完成したバックアップを使ってリカバリーを開始することができなかったからだ。

クラウド障害にどう備えるか

　AWSの障害の第一の教訓は、クラウドサービスは管理不能であるということだ。特定のクラウドサービスがDRニーズを満たしているかどうかをビジネスの観点から判断するには、提供されるサービスレベルを認識する必要がある。

　クラウドプロバイダーのシステムと自社のプライマリーデータセンターで同時に障害が発生する可能性は低い。Google検索でざっと調べたところ、S3は2006年のサービス開始以来、大規模な障害が3回程度発生しているようだ。自社のデータセンターとAWSを結ぶネットワーク回線の方が、RPOやRTOの大きなリスクとなりそうだ。「これらのリスクがDR計画に文書化されているかどうか」「こうしたリスクを踏まえても、『サービスとしてのDR』（DRaaS）を利用することはビジネス上、理にかなっているかどうか」をチェックする必要がある。