Amazon Web Services(AWS)のようなクラウドサービスを利用している企業は、障害発生に備えて災害対策(DR)計画を策定しておく必要がある。
あなたの会社の災害対策(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)を利用することはビジネス上、理にかなっているかどうか」をチェックする必要がある。
Copyright © ITmedia, Inc. All Rights Reserved.
トランプ氏当選でイーロン・マスク氏に追い風 過去最高の投稿数達成でXは生き延びるか?
2024年の米大統領選の当日、Xの利用者数が過去最高を記録した。Threadsに流れていたユー...
トランプ氏圧勝で気になる「TikTok禁止法」の行方
米大統領選で共和党のトランプ前大統領が勝利した。これにより、TikTokの米国での将来は...
インバウンド消費を左右する在日中国人の影響力
アライドアーキテクツは、独自に構築した在日中国人コミュニティーを対象に、在日中国人...