クラウドは管理不能という現実
痛い思いをしてAmazon S3障害から得た教訓、「クラウド利用時のDRは大丈夫？」
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）を利用することはビジネス上、理にかなっているかどうか」をチェックする必要がある。
AWSの障害をきっかけに、クラウドを使ったDRに経営陣が不安を感じるようになった場合は、使用するサイトを増やすといった手がある。例えば、US-EAST-1リージョンにおける冬の嵐は、欧州西部（アイルランド、EU-West-1）リージョンに影響しない。バックアップを含むS3バケットをUS-East-1からEU-West-1にレプリケーションしたり、バックアップアプリケーションが両方のリージョンにバックアップを直接送信したりするようにすれば、AWSの特定リージョンにおける障害の影響を受けずに済む。
また、S3と互換性のあるストレージシステムをリモートオフィスに用意し、バックアップソフトウェアにそこにも書き込ませるという選択肢もある。
極めて懐疑的なユーザー向けには、全く別のインフラを持つ2つの異なるクラウドプロバイダーにバックアップを送信するという方法も取れる。ただし、この方法は、バックアップを2カ所に送ることから、ストレージとネットワーク転送の料金が跳ね上がるというデメリットがある。さらに、データをレプリケーションする場所ごとに、それぞれのDR計画を管理する必要もある。少し計算すれば、コストの増加に見合うほど可用性が向上しないことが分かるだろう。
どのようなコンピュータシステムでも、ダウンタイムは発生し得るし、実際に発生する。クラウドベースのDRaaSも例外ではない。あなたの会社は、クラウドでAWSのケースのような障害が発生し、DRが影響を受けた場合、事業継続にどのような影響があり得るかを理解しているだろうか。
大部分の企業は、出費を増やしてまでDR自体の信頼性を高めようとはしないだろう。だが、少数ながら、いくらコストがかかっても、最高のDR体制を構築する必要がある企業もあるだろう。
Copyright © ITmedia, Inc. All Rights Reserved.
この記事の著者
関連記事
新着ホワイトペーパー PR
-
製品資料
[株式会社MatrixFlow] 「物流リソース最適化」ガイド：人員・配車・傭車を出庫依頼の確定前に決めきる -
製品資料
[株式会社キーエンス] なぜRPA導入は頓挫する？ シナリオ作成の壁を乗り越える解決策とは -
製品資料
[株式会社セールスフォース・ジャパン] 「CRMは設計と無関係」は本当か？ PLMとの融合で実現する高速開発 -
事例
[日本ヒューレット・パッカード合同会社] AIエージェントの時代にどう備える？ 「新たな働き手」を支える3要素とは -
製品資料
[日本ヒューレット・パッカード合同会社] “横並びの自動化”から脱却、AI活用で生産性と競争力を高める秘訣
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
なぜ「全社配布Copilot」は使われないのか？ 失敗に学ぶAI定着
-
2
法務と開発者で「言葉が通じない」問題 トヨタやソニーが語るOSS管理の真実
-
3
なぜ「Gemini 4 Argon」は出遅れたのか？ Googleが狙う“逆転のシナリオ”
-
4
損保ジャパンはなぜ「COBOL」を捨てなかったのか？ 脱メインフレームの真相
-
5
情シスの約8割が転職や退職を意識 調査で分かった“辞めたくなる最大の理由”
-
6
ChatGPTは“検索しまくり”でGeminiは“淡泊”？ データが明かすAIの裏側
-
7
情報漏えいはなぜ繰り返されるのか 今すぐ見直すべき「境界」
-
8
「Wi-Fi 7」経由でWindowsが乗っ取られる？ 最高権限奪取の恐怖
-
9
「結局使わなくなる」Microsoft 365 Copilotを半年で定着 キリンの3施策
-
10
「中堅・中小企業のネットワーク・セキュリティ運用実態」に関するアンケート
ホワイトペーパーランキング PR
-
1
不審メールの経路や見せ方に変化？ 2026年夏の3事例から見えた動向と対処方法
-
2
家庭用Wi-Fiルーターの業務利用は危険？ 避けるべき理由と具体的な対策
-
3
Microsoft 365を安全に運用 うっかりミスやサイバー攻撃に備えるデータ保護術
-
4
財務部門がAIを最大限に活用する方法 無駄のない戦略的リーダーシップへの道
-
5
LLMが兵器化？ 元FBI高官が鳴らす警鐘とセキュリティツール統合のポイント
-
6
「オンプレミス回帰」せざるを得ない“合理的な理由”
-
7
なぜRPA導入は頓挫する？ シナリオ作成の壁を乗り越える解決策とは
-
8
生成AIを開発に導入しても効果が見えない？ 実証実験で分かった成果と課題
-
9
経産省DX指針から読み解く、受発注業務デジタル化ロードマップ
-
10
HDDを使わない「SSDオンリー」が無謀なのはなぜ？
TechTargetジャパン SNS
@techtarget_itmをフォロー
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー