2017年04月28日 12時00分 UPDATE
特集/連載

クラウドは管理不能という現実痛い思いをして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のエンジニアが通常のメンテナンス時にコマンドを誤入力してしまったことだ。その結果、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)を利用することはビジネス上、理にかなっているかどうか」をチェックする必要がある。

この記事を読んだ人にお薦めのホワイトペーパー

この記事を読んだ人にお薦めの関連記事

Loading

注目テーマ

ITmedia マーケティング新着記事

news018.jpg

サイバーエージェントがDDTプロレスリングを買収
サイバーエージェントは、DDTプロレスリングの発行済み株式の全株式を取得したことを発表...

news069.png

Twitter投稿を基に番組視聴者のペルソナを可視化、データセクションのテレビ番組口コミ分析サービスに新機能
データセクションは、テレビ番組口コミ分析サービス「TV Insight」において、ソーシャル...

news058.jpg

アプリ利用者を特定してアンケート調査、「App Ape」と「TesTee」が連携
フラーは、リサーチツールの提供を行うテスティーと共同で、アプリ所持ユーザーや休眠ユ...