クラウド基盤が丸ごと止まったときに備える設計・運用チェックリスト

この記事の要点

• どの基盤が失われたら何が止まるかを依存関係として書き出すと、冗長化の対象と範囲が具体的になる
• バックアップが同じ基盤やアカウントの中にある限り、基盤ごと失われる障害では復旧の材料にならない
• 監視・通知・告知の手段が止まる側に置かれていると、障害に気づく手段と顧客へ知らせる手段を同時に失う

想定する障害の範囲を決める

障害対策の議論がかみ合わない原因の多くは、どの単位の障害を想定しているかが揃っていないことにあります。少なくとも次の4つを分けて考えると、手段の違いが見えます。

• サーバー単体の故障: 同じゾーン内の予備機や自動再起動で吸収できる範囲
• ゾーン（データセンター）単位の停止: 複数ゾーンへの分散で吸収できる範囲。多くのクラウドの冗長構成はここまでを想定している
• リージョン全体の停止: 同じ事業者の別リージョン、または別の事業者・自社基盤へ切り替えないと再開できない範囲
• 事業者アカウント・契約の停止: 不正アクセスへの対処、支払いや規約の問題などでアカウント自体が使えなくなる範囲。同じ事業者の別リージョンでは吸収できない

どこまでを自社で備え、どこから先を受け入れるかは、サービスごとに決めてかまいません。決めていないことと、決めたうえで受け入れていることは、障害時の判断の速さが大きく違います。

依存関係と責任分界を棚卸しする

• サービスごとに、サーバー・データベース・DNS・認証・メール送信・監視・バックアップ保存先が、どの事業者のどのリージョンにあるかを一覧にしているか
• 自社が直接契約していない依存（利用しているSaaSの裏側のクラウド、委託先の基盤）を把握しているか
• ドメイン管理・DNS・証明書が、止まる側の基盤やアカウントに寄っていないか
• 事業者の責任範囲と自社の責任範囲の境目を確認しているか。SLAが定めるのは多くの場合、稼働率と未達時の返金で、データの復元や再開までの時間は利用者側の設計に残る

RTOとRPOをサービスごとに決める

RTO（何時間以内に再開するか）とRPO（どの時点までのデータを戻せればよいか）は、全サービスで同じ値にする必要はありません。

• 電話や監視のように、止まっている時間の影響が大きく、過去データより再開が優先されるもの
• 受発注や会計のように、再開が多少遅れてもデータの欠損が許されないもの

この2つを分けると、復旧の順番と暫定対応の形が決まります。当社の電話サービスでは、本復旧までの間に暫定の電話システムを用意して、発着信を先に戻しました。

• 各サービスのRTO・RPOが文書になっていて、社内の判断者と合意できているか
• 本復旧の前に提供できる暫定手段（縮退運転、別システムでの代替）を決めているか

バックアップと再構築の手順を点検する

• バックアップの保存先が、本番と別の事業者または別リージョンにあるか
• 本番と同じアカウント・同じ権限でバックアップを消せる状態になっていないか（不正アクセスでは、本番とバックアップが同時に消されることを想定する）
• サーバー構成・ネットワーク設定・アプリケーションの導入手順を、コードや手順書から一から再現できるか
• バックアップからの復元にかかる時間を、実際に測ったことがあるか
• 復旧後に確かめる項目（データの整合、外部連携、通知、課金）が一覧になっているか

監視・通知・告知の手段を分ける

• 監視とアラート通知の仕組みが、監視対象と同じ基盤に乗っていないか
• 障害を顧客へ知らせる手段（Webサイト、メール、電話）が、止まる基盤と別にあるか
• 社内の連絡網、判断の権限者、事業者の窓口と連絡方法が、基盤が止まっていても参照できる場所にあるか

切り替えと復旧を訓練する

• 別の基盤での起動を、年1回など決めた頻度で実際に試しているか
• 訓練の結果で、手順書と所要時間の見積もりを更新しているか
• 訓練していない手順を、障害時に初めて実行する前提になっていないか

ベンダー比較のときに確認する質問

クラウド基盤や運用委託先を比較するときは、稼働率の数字に加えて次を尋ねると、障害時の実際の動きが見えます。

• データとバックアップはどこにあり、事業者側の1回の障害で同時に失われる組み合わせはあるか
• リージョン全体が使えない場合の手順はあるか。その手順を最後に試したのはいつか
• 復旧目標（RTO・RPO）の想定値は、契約上の約束か、努力目標か
• 障害時の連絡経路、告知の場所、事後の報告書の有無
• 再委託先と、利用している基盤事業者

当社の障害から一般化できること

当社の障害では、利用していたパブリッククラウドのリージョン全体が停止し、その上のサーバーやデータも取り出せない状態になりました。クラウド基盤そのものが失われる事態は、当社の想定を超えていました。基盤を一から再構築して復旧できたのは、ネットワークから電話システムまでを自社で設計・運用していたため、本復旧と暫定対応を並行して進められたからです。

当社は現在、自社基盤を含めた複数の基盤でサービスを運用し、いずれかの基盤が失われても継続できる構成の設計を進めています。障害の経緯は「クラウド基盤障害に伴うサービス停止と完全復旧について」で公表しています。

次に読む記事

クラウド事業者は中身を知らない データ管理責任はユーザー側にある

クラウドの障害対策とは別に、預けたデータの管理責任がどこまで利用者側に残るかを、送信データの判断と契約の面から整理します。

「電話とネットワーク、どちらに相談すれば?」
― 分割発注の責任の谷と、一気通貫型事業者の価値

ネットワーク・電話・サーバー・クラウドを分けて発注したときに生まれる責任の谷と、一気通貫で相談できる事業者を持つ意味を確認します。

クラウドもAI基盤も、作っているのはインフラエンジニア
― 重要性が上がる3つの理由

クラウドやAI基盤を設計・運用するインフラエンジニアの重要性が上がる理由を、人材推計やデータセンター投資の動きから確認します。