3月11日、筆者は少し遅めの昼食をとっていました。ちょうど食べ終わる頃に、今まで経験したことのないような強さで、何度も、長時間に渡る揺れを体感しました。急いで職場に戻り、情報を収集し事の重大さを認識しました。

この度の東北地方太平洋沖地震により亡くなられた方々のご冥福をお祈り申し上げますとともに、被災されました皆様、またそのご家族の方々に対しまして心よりお見舞い申し上げます。少しでも早い被災地の復旧・復興を祈念いたします。

インフラエンジニアの対応

さて、このような状態になった場合、インフラエンジニアとしてはどのような対応をすべきか考えます。

データセンターの状況

まずは筆者の場合、オフィスは東京都内（23区内⁠）⁠、データセンターは別の東京都内（23区内）にあり、現地に向かいつつも電話でデータセンターの状況（情報）を入手します。これは、データセンターの受付、オペレータが見ることができる範囲が、ラックと搭載されているサーバ、機器のみに限られる可能性があり、あまり好ましくないことではあるのですが、ストック機器やラック内に工具類を入れてしまっていたり、その他備品関連が散らばってしまっていないかは、やはり目で見ておく必要があると考えるためです（さいわい、筆者の会社の利用センター、ラック、サーバなどの機器は無事でした⁠）⁠。

オフィスの状況

次にオフィスの状況です。

こちらはあまり好ましくなく、まず、社員利用のデスクトップPCが倒れてしまったり、書類などが崩れた力でディスプレイなども床に…。これらは普段からの啓発で防げる部分でもあるので、経営陣と共有し、反省しました。

また、オフィスのサーバ室も同様で、ケーブルが詰まった段ボールが崩れていたり、耐震補強をしていないラックの位置がずれてしまったりと、地震の力に驚かされました。オフィスのサーバ室は、データセンターほどルールが厳密ではなく、情シスの倉庫としての一面もあったので、散乱したもの、機器たちの片付けに追われました。

事業（サービス）の状況

自社でサービスを展開している場合、その状況を確認する必要があり、基本的に問題ないことを確認します。

筆者の場合、以前から一部の業者のクラウドサービス（インスタンス）が非常に不調でしたが、この不調もいつもとかわらず同様の確認をします。

大災害に対する会社の姿勢

その後の余震規模、交通網などの混乱を受けて、会社のスタッフは基本的に自宅待機ということになりました。

障害にどう対応するか

以上を受けて、在宅でも仕事ができるように調整を行うのですが、その中で先ほど少し触れた「調子の悪いクラウドサービス」をどのように扱うか決断をする必要が出てきました。

クラウドサービスにおける発生箇所が特定できない障害

どのように不調なのかもう少し掘り下げて記載しますと、サービス自体はソーシャルゲーム向けのサービスで、Webサーバ、DBサーバ、その他Flash生成など、基本的にはよく見かける構成です。これらの設計、構築、運用に関しては、同じソーシャルゲームを同様のクラウドサービスを利用して数多く提供している会社にお願いをしていました。

不調の事象は、アプリケーション（携帯電話）から接続できたりできなかったりといったことで、クラウドサービス業者が提供するモニタリング機能からでは全く原因を特定できませんでした。そのエラーの画面は「ただいま混雑していて……」や、「⁠httpの500番台のエラー⁠」⁠、たまに接続した際に入会前画面（アプリケーションチュートリアル）など、さまざまな事象がおこっていたため、基本的に毎日スタッフが注意深く確認し、早期の発見、対策を講じることが望まれていました。

しかしながら、会社の方針として自宅待機となってしまったため、迅速な意思決定ができなくなってしまうこととプラットフォーマーや開発会社、クラウド担当者などとの意思疎通に問題が生じる可能性が濃厚となり、何らかの解決を急ぐ必要が出てきました。そのため急遽以下の対策を講じました。

クラウド業者（国外）へ問い合わせ

ユーザとして満足のいく回答はなし。

運用会社へ他社のサービスで同様の現象を確認

詳細はNDAで開示できないものの、自社アプリの開発環境（同様のクラウド）などでも同様の現象を確認。

プラットフォーマーへ相談

自社の状況と他アプリケーションで同様の事象が発生していないかの問い合わせ。

もちろん、上記を実施する前より、OSやインスタンスの再起動、ロードの確認、アプリケーション自体の問題確認などは実施しており、それでも解決できていない状況が前提としてあります。

以上から、クラウドサービスのどこかで問題があるのではないかと疑われるものの、問題点の追求、確実な再現性が乏しく、また、これ以上の情報開示も難しいと判断し、自社でどのように扱うかを検討することとなりました。

該当アプリケーションの稼働率、売り上げ規模

こちらは幸か不幸かそれほど高くはなく、会社のスタッフが自宅待機という状況を加味した場合、サービスを停止することによる売り上げのインパクトは無いと判断。

課金処理の有無とそれに対する影響

ソーシャルゲームの場合、たとえ不人気であったとしてもサーバ（インスタンス）を稼働させておけば売り上げを上げてくれる可能性が高く、基本的に何も問題なければ稼働させておきたいところです。しかし、今回の一件から、「⁠たまたま接続できたときにアプリケーションのチュートリアル画面（入会前画面）になってしまう可能性がある」という点より、クラウドサービス側のWebサーバインスタンスで処理は受け付けたものの、DBサーバインスタンスへ参照しようとした際に不具合が生じ、結果が「未入会」として扱われるケースは、今までユーザが利用していただいた履歴、たまたま課金しようとした際の処理が保証できなくなる可能性が高いと判断し、サービスを停止することを決定しました。

ソーシャルゲームの公開停止方法

ソーシャルゲームにおけるサービスのクロージングに関しては、各プラットフォームから「停止前○日前からユーザに対して告知する」などといったレギュレーションがあります。今回はそれとは異なり、一時的に公開を停止するため、以下の2パターンを検討しました。

お詫びページを掲載する

企業の姿勢、担当者の道徳的な心使いからお詫びページを出力したいとの相談がありました。しかしながら、プラットフォーム側かみれば「お詫びページ」も「アプリケーショントップ画面」も同様のサービスとして扱われる可能性が高く、実際に、「⁠お詫びページもクラウドサービスにて稼働するインスタンス上に置く」ため、お詫びページが不具合になる可能性が捨てきれませんできた。そのため、本件は見送りとなりました。

プラットフォームからアプリケーションを公開停止に

この場合、プラットフォームのユーザにある「マイアプリ」リンクから遷移した場合、プラットフォームのエラー（お詫び）画面となります。利用していただくユーザ様のことを思うと心苦しい限りではありましたが、プラットフォーム側に迷惑をかけないこと、ユーザ様に対しては問い合わせにて随時対応することとなりました（実際かなりの数の問い合わせをいただきました⁠）⁠。

障害は自然回復

最終的に不具合は自社、他社含め誰も何も対応することなく、自然にもとに戻り、再度公開の判断を行うことになりましたが、スタッフの自宅待機期間中だったため引き続き公開は見送り、出勤後に再公開の手続きを実施、このサービスはクラウドを利用し続けるか、サービス自体やめてしまうか検討することとなりました。

クラウドサービスは成長している分野であり、今後についても十分期待できるものであることは間違えないかと思います。今回は、不安要素（リスク）としてこのようなことがあり得るという認識をいただければ幸いです。今後は、このような不安、イメージを補うようなサービス、抜本的な品質向上などにより、さらなる有望なサービスに成長していけたらと期待しています。