東日本大震災のあった3月11日は、たまたま有休を取っていて自宅におりました。家族で外出しようとしていた矢先に「グラッ」と来て、結構大きいな、と思いつつ、なかなか揺れが収まらない長い横揺れに「こりゃ尋常じゃないな」と思いました。
会社が心配になり連絡をしようと試みたのですが、もちろん携帯はつながらず、こういう時こそアナログ電話だ！と思いつつも、通電していないと使えない電話機であることが発覚…30分後位に3Gが復活したので、唯一社内でTwitterをやっている方と連絡が取れ、皆はひとまず無事らしい、という事が確認出来ました。
自宅にはテレビがないのですが、そもそも停電しているので見る事が出来ません。幸いにも、
iPod touch用 ワンセグチューナー
があったので、これでNHKを見ると津波に襲われる東北の光景が…
自宅近くの川も津波の影響で逆流していたり、コンビニが非常用電源でレジを稼働させてがんばって営業していたりと、これは相当大きい災害だ、という事がじわじわ分かってきました。その日は停電もさっぱり解消せず、暗闇の中、キャンプ用のランタンをつけて夕食をとりました。
週明けはJRが動かなくて出勤出来ず。でも息子は大喜びで一日遊んで攻撃に出会い、別の意味でヘトヘトに。でも、父親的にはじっくり遊べた事がいろんな事を考えさせられる良いきっかけにもなりました。
次の日はなんとか出勤出来ましたが、社内のサーバー達が心配でした。それらには、ソースコードを保管しているSubversionのリポジトリや
Redmine、Wikiなどの開発プロジェクト管理、他部署とデータをやり取りする為のファイルサーバーなどなど、壊れるととてつもなく困る重要なものばかりです。
もちろん、バックアップの体制は作ってありましたが、（過去にCVS、Subversionのリポジトリをぶっ飛ばした経験ありw）恥ずかしながら弊社は最小限の設備でやっておりますので、結構不安でした。中でも重要なソースコードは二重にバックアップをしていましたが、その二次バックアップ先である市販のRAID付きNASが華麗にラックから落下しており、こりゃマジでディザスタリカバリだな、と心に誓いました。（幸い中身は無事でしたが、外装には左写真のような傷が。）
この手のインフラ仕事だと、通常はある程度社内的な根回しをしてから実務の合間を縫って作業を行うのですが、今回ばかりは余震も続き、停電の問題もあったので時間が勿体なく、とにかくすぐにやる事を心がけ、問題ない所から順次クラウドに逃がしました。使ったクラウドはもちろんAWS（
Amazon Web Services）です。
やった事
まず、EC2インスタンスを一つ立てました。リージョンは少し考えましたが、ここはあえて東京を選びました。それじゃ意味ないかも？とも思いましたけど、国内からアクセスしやすいシンガポールも米国西海岸もよく地震の起きる地域ですので、ここはAWSを信頼しました。そのかわり、
バックアップを米国東海岸のS3に置いています。
また、外部に出してはならない重要なデータですので、セキュリティグループは慎重に設定します。ひとまず現段階では社内からのみSSHとSSLが通信出来る状態にしておきました。インスタンスはsmallインスタンスが1つです。（節電のため、と言っておきますw）
AMIはこの際Amazon Linuxを、とも思いましたが、時間の節約の為にも使い慣れているUbuntuをチョイスしました。
以下、かいつまんでやった事を書いておきます。結局は普通の物理サーバーと同じ手順です。
Subversionの移行作業
- 【社内】svndumpでダンプデータを取り、EC2へコピーします。
svnadmin dump /path/to/repos | gzip > svndump.all.gz
scp -i hoge.pem svndump.all.gz ubuntu@ec2-xxx-xxx-xxx-xxx.ap-northeast-1.compute.amazonaws.com:/tmp
- 【EC2】svnリポジトリを新規作成し、そこにダンプデータを読み込み直します。
sudo svnadmin --fs-type fsfs create /data/svn
zcat /tmp/svndump.all.gz | sudo svnadmin load /data/svn
- 【EC2】Apacheにdav_svnを入れて、httpsでアクセス出来るように設定します。詳細は割愛。
sudo apt-get install libapache2-svn
- 【社内】開発マシンに入っているチェックアウト済みのプロジェクトは、svn switch --relocateしておきます。
svn switch --relocate OLD_REPO NEW_REPO
※ここで失敗したのが、古いSVNクライアント（1.4）から新しいSVNリポジトリにrelocateしようとした時に、"UUID mismatch" のエラーが出てしまった事です。これを回避するには、リポジトリにダンプデータをロードする際、"--force-uuid" オプションをつけると良いみたいです。現行のバージョン（1.6系）ではこの問題は発生しません。
SubversionのバックアップをS3へ
社内の体制では、svnsyncで別サーバーのリポジトリへ同期をかけるという事をやっていました。今回はやり方を変えて、svn-backup-dumpsを使ってローカルにダンプデータを累積しておきつつ、米国東海岸のS3に作った同期させる、という体制にしておきました。
ダンプデータをためるディレクトリを作成し、svn-backup-dumpsを一日一回、夜中に実行します。S3にはバックアップ専用のバケットを一つ用意し、s3cmdでローカルバックアップディレクトリの中身をsyncをするという単純なやり方です。
#ダンプデータのバックアップディレクトリ作成
mkdir /data/svn-backup
#このスクリプトを一日一回実行する
svn-backup-dumps -z -c 50 /data/svn /data/svn-backup/
s3cmd -c /path/to/s3cfg sync /data/svn-backup/ s3://US_EAST_BACKUP_BUCKET/svn-backup/
これで、めでたく米国東海岸のAWSにソースコードをバックアップする事ができます。もっと心配な方は、同時にEUにもシンガポールにも置けます。
また、データを置いてあるボリューム自身も定期的にスナップショットを取っています。
こちらにそのスクリプトを置いてありますので、よろしければご覧ください。
EBS snapshotとS3を使い分ける
EBSのスナップショットは取るのも簡単、復帰するのも簡単なので非常に使い勝手が良いのですが、ボリューム丸ごとをバックアップするものなので、仮にファイルシステムそのものが壊れてしまった場合に復旧が難しくなる可能性があります。したがって、
- EBSのスナップショットはある程度履歴を取っておく
- DBやSubversionなど、「ダンプデータ」を取得できるようなものはS3にコピーしておく
という体制を取りました。
弊社の規模感では、このくらいで十分です。そもそもディザスタリカバリなんてクラウド以前ではちょっとした夢物語でした。今ではこんなに簡単に実現する事が出来ます。
さらにS3を使う
開発に直接的に関わる部分はこんな感じでOKなのですが、その他の重要な、しかも頭の痛い問題ととして、「ファイルサーバー」があります。弊社のケースで言うと、例えば印刷担当部署とのファイルのやり取りに使うようなもので、専門のエンジニア以外が扱えるようなツールじゃないと厳しい事になります。VPCの中にSambaのサーバーを立てて…とか、そんな余力はありません。そこでやはり出てくるのがS3です。SambaやAFPのような「ファイル共有」的な使い勝手からは少し離れてしまいますが、FTPソフトは普段使っている方たちなので、
Cyberduckや
CloudBerryであれば使えるだろうと判断しました。
その経緯は、また後日別エントリを起こします。
