一休のSQL Server AWS移行事例（前編）からの続きです。
実施当日
kudoy:
準備段階で色々踏んだので、だいぶリハーサルもしましたし、当日は作業スケジュール組んで、その通りにやった感じです。バッチを事前に流したり…
ninjinkun:
バッチというのは何ですか？
kudoy
宿泊とかレストランシステムなどで夜間に定時実行されているバッチ処理ですね。
ninjinkun:
ああ集計系の。
kudoy
そうですね。それを事前に流せるものは流して。
今回移行対象のDBが十数個あったんですが、各DBの環境上の都合で２通りの方法で移行する必要がありました。
１つ目の方法は、事前にオンプレ側で取得したフルバックアップを移行先となるAWS側にリストアしておく。切替までの間の差分データはトランザクションログを定期的バックアップして、それを使って移行先のAWS側も更新していく。大半のDBはこちらで対応できました。
２つ目の方法は、当日オンプレ側で完全にDBのデータ更新が終わってからフルバックアップを取得して、移行先のAWS側でリストアする。
いくつかのDBでこの対応が必要となりました。
リストア処理について
ninjinkun:
ちょっとそのリストアとそうではないものの違いがよく分からなかったんですが。
kudoy:
データベースの復旧モデルと呼ばれる設定の違いによってDBリストアとなるのかトランザクションログのリストアになるのかが分かれました。復旧モデルの詳細については、こちら
一休では移行前は、完全復旧モデルというトランザクションログが取得できるモデルと単純復旧モデルというトランザクションログが取得できないモデルの２つを用途別に採用していました。
多くのデータベースは、一般的に使用される完全復旧モデルを採用していましたが、1日に数回だけデータが更新される集計系テーブルなどやアプリケーションからは使用されない運用上で必要だけどフルバックアップを取得した時点まで戻せればよい性質のデータを扱っているデータベースについては、単純復旧モデルを採用していました。
こういった事情で事前にある程度移行できるものと当日に移行リストアしなければならないもの２パターンの移行手段が必要だったんです。
移行先のAWSにAlwaysOnをあらかじめ構築しておいて、データのみ差分更新でオンプレの環境と同期させておくといったことが出来れば、作業時間も短くて済むんですが、先ほど話した単純復旧モデルのデータベースがある、また今回移行するにあたって、SQLServerのバージョンも2012->2017へバージョンアップしたので、バージョンアップに対応する設定変更の必要もあったので、AlwaysOnの構築は当日行いました。 DBデータファイルの分割とインデックス再構築といった作業も移行時にやっておきたかったので、こういった作業も同日おこないました。
ninjinkun:
めっちゃ大変そうですね
kudoy:
細かい話をするとWindowsのクラスタ（WSFC）はDBリストアの影響を受けないので先に構築してあって、SQL ServerのAlwaysOnも全て当日構築すると時間が掛かるので、一度リハーサル時に構築して、移行直前に一部の設定だけ削除しておいて、DBリストア後から必要な設定だけしていくといった手順で作業時間を短縮しています。部分的な再構築するといったイメージですかね。
ninjinkun:
リストアというのはMySQLで言うmysqldumpしたものを食わせるのと同じようなものなんでしょうか
kudoy:
うーん、まあそんなイメージ？バイナリなんですが。
ninjinkun:
あーでは後から順次食わせるのではなく、テーブルごと一気に復旧してしまう感じなんですね。
kudoy:
そうですね。DBのオプション設定やユーザ、テーブルとかDBに格納されているものを一気に復旧する感じです。
あとは、アプリケーション側でクラウド移行後の設定とかを変えてもらった部分があるので、それをリリースしてもらって、定期実行のスケジュールを止めていたバッチを裏側で動かして、問題無かったのでサイトオープン。
でもオープンしたらCPU使用率高いね、という（笑）
akasakas:
バッチを走らせまくってちょっと焦ってましたね。
kudoy:
あーそれがありましたね。深夜作業対で走っていた破壊力のあるバッチを一度に動かしたので。
ninjinkun:
じゃあCPU使用率はそのバッチが原因だったんですか？
kudoy:
それもあったんですが、バッチが終わってもまだCPU使用率は高かったです。
ninjinkun:
そこからパフォーマンスチューニングみたいな話になったんですよね。
kudoy:
インデックスいっぱい作ってもらったりとか、アプリケーション側も直してもらったりとか。
akasakas:
当日朝からお祭り感がありましたね。
kudoy:
でも思ったほどではなかった。それまでもオンプレで運用している段階でDBの負荷は高くなってきていて、ちょくちょくアラートが鳴る頻度は高くなってきていたので。
そういう意味では結構移行はギリギリのタイミングでした。あのままオンプレ続けてたら、手の打ちようがなくなっていた。
akasakas:
あのままオンプレ続けていたら、この夏はもう…
kudoy:
ちょっと厳しかった。
当日起こったとしたら嫌だったこと
ninjinkun:
こういうのが起こってら嫌だったなというのありますか？
kudoy:
やっぱりリリースした後にあれこれ動かない系。事前に検証して貰っているので、そんなに心配しては居なかったです。でもフルの構成では検証し切れていないので、そこで何か出るのは嫌だなと思っていました。
あとは想定していてちょっと嫌だなと思ったことは、結局ハードを自分たちで管理できていないところなので、AWSに移行してしまった後は、転送速度が遅いとかあると今までと勝手が違うので嫌だなと思っていました。
ninjinkun:
それは今回は杞憂だったということですか。
kudoy:
そうですね。思ってたより逆に早かった。日中に試験しているときは転送速度遅いなと思っていたんですが、夜中に試したことはそれまでなくて。当日は夜中で帯域が空いている？のか早かったですね。
akasakas:
当日もちょっと巻いてましたよね。
kudoy:
EBS(io1)のIOPS上げたおかげもあると思うんですが、深夜という時間帯による影響もあったのかなと感じています。
準備段階で重点的にやったこと
ninjinkun:
この辺が怖かったので重点的にやった、みたいなのはありますか？
kudoy:
それはやっぱり時間の部分ですね。これはリハーサルを相当やったので。10回くらいはやってます。
ninjinkun:
リハーサルも最初はうまく行かなかったりしたんですか？
kudoy:
作業時間以外はうまくいかないといったことはないですね。1番の問題が作業時間が長いといったところだったので、各手順単位で作業(処理)時間を計測して、時間が掛かる作業を抽出して短縮する方法を検討/検証して時間を計測するといった繰り返して少しづつ時間を短縮していきました。
あとは机上で手順や作業を上手く組み替えて、何度もリハして何とか収まるようにした部分が一番苦労した部分ですかね。12時間かかりますとか言えないので（笑）
ninjinkun:
今回の作業はある程度リスクを取って実行していると思うのですが、やはり何度もリハーサルしたのが良かったんですかね。
kudoy:
いろんな検証を繰り返しやったので、その辺りは安心感に繋がってます。何か起きてもなんとかなるだろうと。アプリケーション
で何か起きても心強いアプリの担当エンジニアがなんとかしてくるだろうと（笑）負荷試験も元々は1週間の予定だったんですが、見直して3週間くらいやっていました。
akasakas:
負荷試験はJMeterを使ってコントローラーを1台置いて、slaveを15台置いて一度に投げたりしていました。実際のリクエストからパラメータを生成して主要な導線や負荷が高いAPIをピックアップして夏のピークの負荷x1.5くらいのリクエストを投げて試験しました。
kudoy:
世の中的に同じようにAWSでやっている事例が少なかったというのがありますね。同じようなのは日本だとH.I.S.さんくらいしか居ないですね。H.I.S.さんについては事例が出ています。
ninjinkun:
やっぱりSQL Serverでクラウドだと普通はAzureになるんですかね？
kudoy:
うーん、Microsoftの製品ですし親和性は高そうですよね。でもAzureは今回は見送りました。
決めるときはAWS、GCP、Azureで比較しました。GCPはその当時まだ追いついてなかったので外して。
結局AWSとAzureともDBがSQL Serverであることが引っかかっていて、それを安定的かつお金的にも最適なと考えるとAzureはちょっとバランスが悪かったんですよね。インスタンスを立ててそれを分けるという構成だと。そもそもPaaSは制限が多すぎて両方とも使えなくて。
ninjinkun:
なるほど、フルマネージドは無理だねと。
kudoy:
そう、それは無理でインスタンスでとなったときにIOPSの調整がAWSの方が柔軟だった。そこの決定的な違いは、AWSだとディスクのサイズがある程度あれば2万IOPSまで上げられるんです。500GBでも2万IOPSとかできる。Azureの場合は容量によって性能が決まっているので、IOPSを上げると容量全然使ってないのに使っていない部分に課金が発生してしまうので、これはクラウドのうまみがないよねという話になりました。
じゃあそうなるとAWSもWebサービスの事例自体はいっぱいあるし、こっちかなと。
ninjinkun:
なるほど、サービス特性に合わせられる柔軟性と事例の豊富さでAWSになったんですね。
以上で聞きたかった話はだいたい聞けたと思います。ありがとうございました。
すごく大変な移行だったとだけ聞いていて、詳細を知らなかったので、今回は勉強になりました。
