IaaS障害、ユーザー企業はどう対処すればいい？　クラウドベンダーが教える対応法と振り返り（1/2 ページ）

　天災や人的ミスなどで起きるIaaS障害。ユーザー企業にとっては防ぐのが難しい問題で、基本的に障害解消に向けてユーザー企業側でできることはほぼない。待つしかないのだ。

　しかし、IaaS障害に端を発する自社サービスやシステムの障害はユーザー企業側でどうにかしなければならない。IaaS障害が発生してから復旧までの間やその後の対応など、ユーザー企業はどう行動すればいいのか。

　今回はさくらインターネットでクラウド事業本部の副本部長を務める大久保修一氏に、IaaS障害発生時の対応方法を聞いた。重要なのは「事前の備え」と「事後の振り返り」だ。

障害対応を左右する前提条件

　IaaS障害はクラウドサーバがダウンする、ネットワークが切断される、ストレージやデータが破損するなど、さまざまな形で現れる。いずれの場合も対応を左右するのは事前の備えがあるかどうかだという。

　事前の備えとは主に冗長化構成のことだ。プログラムやデータを1拠点のクラウドサーバやデータセンターだけに保存して運用するのではなく、複数の拠点に分散させることで障害の影響を最小化できる。

　冗長化しているかどうかで、障害対応は大きく変わる。何も対策していなければ障害が発生してすぐに問題が起きてしまうが、冗長化していれば1カ所で障害が起きても自社サービスを続行できる可能性が高い。

情報を取得、影響範囲を確認してエンドユーザーに告知

　冗長化していなかった、もしくは冗長化していたが自社サービスの一部で問題が起きた場合、まずするべきは障害情報の把握だ。

　サービスベンダーは、IaaSに限らずクラウドサービス障害の発生状況をWebサイトで公開する。まずはこれを見て状況を把握する。

　その情報を基に、ユーザー企業では自社サービスが受けた影響範囲を確認。どのサービスのどの機能がダウンしているのか、データは完全な状態で残っているかなどをチェックする。その上で、顧客や従業員などのエンドユーザーにサービスの稼働状況などを告知する。ここまでが第1フェーズだ。

　情報の告知場所も事前に考えておくのがいいという。自社のWebサイトはIaaS障害に巻き込まれてエンドユーザーから閲覧できない可能性があるため、SNSなど自社のインフラとは全く別の環境で動いているサービスを確保しておくのが事前の備えになる。

待つのが大切なこともある　ストレージの不具合に注意

　冗長化など事前の備えが十分にあり、サービスに問題が発生しなかった場合を除いて、IaaS障害による影響を最小化する作業や、サービスを復旧させる作業が必要になる。

　データにアクセスできない場合やデータが破損している場合は手元のバックアップデータを使って復旧する、処理性能が足りずにダウンしている場合はどうにか新規のサーバを立てて一時的にしのぐなど、対応方法はさまざまだ。

　このとき注意すべきが二次障害だ。IaaS障害に巻き込まれて焦ってしまい復旧方法を間違うと、より大きな問題が発生する可能性がある。

　「行き当たりばったりな作業をすると、確認漏れなどのミスで情報漏えいが起きたり、データが破損してサービスの復旧が困難になったりすることもある」（大久保氏）

　特にクラウドサーバのストレージに問題が起きている場合、無理やりデータの読み書きを行うとデータに不整合が発生し、その修正にも時間をとられてしまう。最悪の場合、システム全体が動かなくなることもある。慌てて復旧作業に取り掛かるよりむしろ、ただ問題が解消されるまで待っていた方がいい。

　だからこそ、最初に影響範囲の確認を行うのが重要だ。

　IaaS障害そのものは待つしかないが、逆に言えば自分で手を動かさなくても復旧してくれる。待つことも障害対応の一つの手だ。

　これは経営者など直接IaaSに触れるエンジニア以外も知っておくべきことだ。損害やブランドを守るため、即座に復旧するよう指示したい場面も多いだろうが、それが逆効果になる可能性もある。

　IaaS障害が復旧し、サービスを正常に再開させ、復旧した旨を告知したらメインの障害対応は終了する。

この記事の著者

関連記事

• 

  IaaS障害はどこでどうやって起きるのか？　ユーザー企業が受けるサービスダウン以外の影響とは

• 

  設定ミス→漏えいの影に潜む“クラウドへの誤解”　いま理解したい「責任共有モデル」

• 

  富士通、東証のシステム障害で謝罪　「原因究明、再発防止に取り組む」

• 

  「クラウドは信頼できない」は本当か？　AWS、Office 365、自治体IaaSの障害を経て、私たちが知っておくべきこと