SQL Database のエディション選びには注意した方が良い話 - しばやん雑記 で書いたように、今朝 Azure を使って動かしている Web サービスを東アジアから東日本へ移行させました。
ちなみに移行対象の Azure サービスは以下のような感じに。
- Web サイト x2
- 仮想マシン
- ストレージ
- スケジューラ
- SQL Database
あと、今回はせっかく時間と手間をかけて移行させるので、CDN を使って静的なコンテンツを配信することにしました。
準備しておくもの
- 簡単でもいいから手順書的なもの
- SE の雑記
- 眠気に耐えるためのレッドブル
4 時を回ると物凄く眠たくなるので、先に寝ておくかレッドブルで翼を授かっておいた方が良いと思います。あと、困った時の SE の雑記頼みという感じです。
移行開始
今回の移行ではデータベースへのアクセスを止めるために、一度完全にサービスへのアクセスを止めてから行いました。サービス自体にはメンテナンスモードといった機能は用意していませんでしたが、URL Rewrite を使ってメンテナンス画面を全ての URL に対して表示する方法を使いました。
Windows Azure Web サイトでメンテナンス画面を表示する方法を考えてみた - しばやん雑記
少し応用し、自分の IP アドレスからのアクセスだけ例外扱いするように修正したものを使いました。
<?xml version="1.0"?> <configuration> <system.webServer> <rewrite> <rules> <rule name="Maintenance" stopProcessing="true"> <match url="^(.*)$" ignoreCase="true"/> <conditions> <add input="{REMOTE_ADDR}" pattern="127.0.0.1" negate="true" /> </conditions> <action type="Rewrite" url="maintenance.html" /> </rule> </rules> </rewrite> </system.webServer> </configuration>
pattern の IP アドレスは自分の IP アドレスに書き換えて使います。これでユーザーからの全てのリクエストは maintenance.html の内容が返されるようになりました。
Web サイト
Azure Web サイトのリージョン間移行手順としては、以前に書いた以下の記事を参照してください。もちろん独自ドメインを割り当てているのでこの方法が簡単に使えました。
Windows Azure Web サイトで独自ドメインを設定している場合にリージョン移動をスムーズに行う方法 - しばやん雑記
東アジアと東日本の Web サイトで同じドメインマッピングを持っている状態にしておきます。これでアクセスの振り分けは DNS での設定次第という形になります。
あまり関係ないですが、今回は折角なのでステージング用の展開スロットを用意し、スワップを使って最新バージョンへのアップデートを行っていくスタイルに変更しました。これでもし問題があった時にも、すぐにスワップで戻すことが出来るようになります。
仮想マシン
仮想マシンに関しては、東アジアで使っていた OS が Windows Server 2012 だったので、OS イメージをコピーすることなく、これを機に Windows Server 2012 R2 へ変更しました。
主にバッチ処理アプリケーションを動かしていたので、ファイルをコピーし接続文字列を変更するぐらいで対応完了しました。
ストレージ & CDN
実は予めストレージだけは東アジアから東日本にコピーしておいたので、今朝の作業としては CDN エンドポイントを作成してアプリケーションに反映させるところまでを行いました。
リージョン間の Blob コピーには AzCopy を使うことで高速に処理することが出来ます。
cd "C:\Program Files (x86)\Microsoft SDKs\Windows Azure\AzCopy" azcopy https://oldstorage.blob.core.windows.net/container/ https://newstorage.blob.core.windows.net/container/ /sourceKey:SOURCEKEY /destKey:DESTKEY /S /Y
以上のようなコマンドを叩くと指定したコンテナに格納されている Blob を全て非同期でコピーすることが出来ますが、思ったより帯域を消費するので XS な仮想マシンから実行などはお勧めできないです。
スケジューラ
メンテナンス中にスケジュールしたタスクが動作してしまうのは好ましくないので、ジョブ一覧から無効化を選んで全てのジョブを無効化しておきました。
ジョブをコピーすることは出来ないので、新しく東日本にジョブコレクションを作成して追加していきます。
SQL Database
やはり一番大変だったのが SQL Database の移行でした。リハーサルではデータの移行に 2 時間もかかってしまったので、これをまず何とかしなければいけませんでした。
まずは元々のデータベースから不要なデータを削除し、レコード数とデータサイズを半分ぐらいまでに圧縮することにしました。そのためにはローカルで処理を行う必要があったので、BACPAC を管理ポータルからエクスポートし、東日本の Blob に転送してからローカルマシンにインポートしました。
SQL Database のデータベースをリージョン間で移行するにはどうするか?? | SE の雑記
SE の雑記を読みまくりながら SSMS から SQL Azure への配置を選択し、本番用の SQL Database へのインポートを開始しました。SQL Server 2012 の SSMS では Web / Business エディションしか選べませんが、SQL DB の New Tier はコスパが最悪なので今と同じ Web エディションを選択しました。
リハーサル時には 2 時間ほどかかったインポートが、今回は 10 分かからずに完了してくれました。
DNS の切り替え
これで全てのデータ、環境を東日本へ移行できたので、ドメインが指している IP アドレスを東日本 Web サイトのものへ変更しました。
これで設定が反映されていけば、東日本への移行が完了です。
移行結果
今回は予定時間を 2 時間ほど見積もっていましたが、実質 1 時間ほどで移行自体は完了しました。DNS の設定が反映されるまでに追加で少しかかりましたが、予定していた 5 時までには全ての処理が完了したので、メンテナンスモードを解除しました。
CDN も無事に反映が間に合ったので、既に東日本で何の問題もなく動作しています。結構簡単でしたよ。