AED検索ではMBaaS (Moble Backend as a Service) としてMicrsoft Azure Mobile ServicesとMicrosoft Azure SQL Databaseを活用しています。
パブリッククラウドであるMicrosoft Azureでは適切なサービスを選択することで冗長性が簡単に確保できるため、物理破壊によるサービス停止などはMicrosoft AzureのSLAである99.9% (Mobile ServicesとSQL Database)を手軽に確保できます。
http://azure.microsoft.com/ja-jp/support/legal/sla/
このようにSLAが確保されているクラウドを使ってサービスを提供するときに、一番SLAを下げる要因の１つとなるのが、データベースに対して誤ったデータを投入してアプリがダウンしたり、データベースを管理操作しているときに誤ってデータを削除したりデータベースを削除したり誤った変更を加えてしまったなどです。
そこでAED検索が利用しているMicrosoft Azure SQL Databaseに対してデータベース削除を行い、そこから復旧できるかの復旧試験（防災訓練）を実施しました。
破壊シナリオとしては、
- AED検索用のMobile Serviceの他に、もう１つMobile Serviceを作成
- 作成したMobile Serviceの構成画面にて接続先データベースをAED検索用SQL Databaseに切り替え
- 作成したMobile Serviceを削除するときに関連するデータベースも削除する
というシナリオでSQL Databaseが稼働するサーバーを残してSQL Databaseを全削除するという弁明の余地のないケアレスミスから想定される最悪のシナリオを用意しました。
対する防災計画ですが、SQL Databaseについては自動エクスポートを毎日実施するように設定しておき、万が一に備えてDDLやデータ投入用のDDLもすべてgistなど別クラウドサービスにて保管しておきます。
破壊シナリオ実施直前に強制エクスポートしたら「えい！」とシナリオを実施してきれいにデータベースを消し去りました。
復旧シナリオスタート！
Azureポータルからデータベースで管理⇒構成をえらび自動エクスポートの情報を設定してから、エクスポートから新しいデータベースを作成して元のサーバーを指定して復旧したところ見事に破壊シナリオ直前の状態に復旧できました。
これで不慮の事故（＝メンテ中のミス）は、Mobile Service側停止による更新の停止とその直後の強制エクスポートをおこなっておけば、最悪の状態からでもデータ復旧が短時間に行えることが検証できました。
