AWSのClassic環境をVPCへと移行する

Classicのコンプレックス

最近AWSを使い始めた人には意味が解らないと思いますが、
AWSにはClassicというVPCの中に入っていない構成（クラスタ）があります。
EC2やELCやRDSなどです。
自分が使っている環境はClassicで動いていてこれが結構前からコンプレックスでした（なんとなく）

新世代のインスタンスが使えなかったり、サービス自体が対応してなかったりで色々と不便が多いです。

とはいえ安易にサービスをstopしてメンテナンスタイムを取る事が出来ないのも実情です。
そこで少しでもダウンタイムを短く移行する事を考え実践した事を記述します。
（なのでしっかりとメンテタイムを取って移行する時間が取れる方にはあまり役に立たない記事です）

読むと参考になるかもしれない人

• AWSのClassic環境からVPCに移行したいと思ってる方
• 何かしらの理由でRDSでオレオレなreplicationを貼りたいと思ってる方

ここでは記述しない事

• VPCのネットワーク設計について

今回の移行対象

• EC2(ElasticBeanstalkを利用）
• ElasticCache
• RDS

ElasticCacheの移行

使い方によると思いますが、
基本的にElasticCacheに入れてるデータは揮発性(Redisは永続性とかいう突っ込みは無しで）なので
2重に書き込んでおいて、古い方がexpireして、新しい方にどんどん溜まってきたら古い方を切り離す
というアプローチができるはず。
ではどうやってVPCのリソースへアクセスするのか？

ClassicLinkの光

ClassicLinkという機能を使うとClassicのEC2から一つのVPC内部へのリソースへとアクセス出来ます。
http://aws.typepad.com/aws_japan/2015/01/classiclink.html
（おそらく内部的にはサブネットをくっつけてるっぽい）
これをアプリケーションサーバに設定してClassicのEC2からVPC内のELCへアクセスします。

まずはこんな感じになっています

ClassiLinkで繋ぐ

新しいCacheが温まったらClassic側はさようなら

RDSとEC2(ElasticBeanstalk)の移行

と　に　か　く　辛　い　の　は　R D S だ
と　に　か　く　辛　い　の　は　R D S だ
と　に　か　く　辛　い　の　は　R D S だ

200G近いRDSインスタンスだったためsnapshot作成してリストアしようとすると、
３時間以上かかる見積もりだった。
他の作業を含めるとどう考えても深夜だけでは終わらない。

そこでclassicにあるmasterからVPCへのreplicationが貼れないか模索してみたところ、
幾つか参考になる文章を見つけた。
(replicationさえ貼れれば最小の時間でmasterへ昇格出来る）

ざっくりとした設計

ストアドプロシージャのリファレンス

どうもオンプレのMySQLからRDSへの移行のためのツールが用意されてるみたいで、
replication系のコマンドを直接叩く事は出来ないけどストアドプロシージャでの用意があるみたいです。

そこでいろいろ試してみて上手く行ったのでここに残しておきます。
（自己責任必須でございます）

大まかな流れ

準備

• ClassicのRDSからオレオレなreplicationでVPC側に新しいmasterを作成する
  • オレオレreplicaを作る方法

メンテナンス日

必要ならVPC側でサービスに使うreplicaを作成する（オレオレでなく通常のコンソール or cliで）多段でreplicationしている状態

VPC側にアプリケーションサーバのセットを組む

classicのアプリケーションサーバからのreadをvpc側へ向ける(ClassicLink)

ダウンタイム開始(メンテナンスモード等）

vpc側からclassicのmasterへ貼っているreplicationをstopする

Route53やELB等使用しているサービスリクエストの向き先をVPC側の環境に変更する

ダウンタイム終了

• 数分(上手く行けば数秒)のダウンタイム確保で移行出来る

一番のポイントであるオレオレなreplicaを作成してmaster昇格候補とする方法

• オレオレreplicationでVPC側にmasterを作成する方法（vpc側で次期master昇格)
• 稼働中のRDSからサービスに使用しないreplicaを作成する
• 作成したreplicaの自動バックアップを有効にする
• Classic側のmasterと作成したreplicaのbinlog保存期間を適当な時間にセットする（保存するようにする）
• 以降のコマンドはRDSのadminなユーザで行ってください
  • ex:6hにセットする
    • call mysql.rds_set_configuration('binlog retention hours', 6);
    • call mysql.rds_show_configuration; (確認)
• 作成したreplicaのreplicationを止める
  • call mysql.rds_stop_replication;
  • stopしたreplicaからreplicationの情報を取得する
  • show slave status\G;
    • Read_Master_Log_Pos: nnn Master_Log_File: mysql-bin-changelog.nnn この2つを控える
• replicationを止めたreplicaからsnapshotを取得する
  • snapshotが出来上がったらこのreplicaは不要になるのでterminateしてもok(実際は他作業が終わるまで取っておいてもいい気がする）
• 作成したsnapshotからvpc側に新規masterを作成する
• vpc側からclassicへbinarylogを取得出来るようにセキュリティグループを設定する
  • port3306が通信できればok
• VPC側のmasterからclassic側のmasterをreplicationのmasterとして指定する
  • CALL mysql.rds_set_external_master(‘masterのホスト名', 3306, ‘replicationユーザ名', 'パスワード', ‘Master_LogFileで取得したバイナリログファイル', Read_Master_Log_Posで取得したposition, 0);
  • 最後の0はsslを使うかどうかのオプション。
• vpc側のmasterでreplication開始
  • CALL mysql.rds_start_replication;
  • show slave statusのSeconds_Behind_Masterが追いついたらreplication完了

まとめ

• 実際はHAProxyを使ったより短い移行プロセス&ロールバックの確保を行ったが本題ではない&複雑な話になるので割愛しました
• ちなみにRDSのsnapshot機能は素晴らしいです。リストアにやたら時間がかかるのはアーキテクチャの問題。
• それでも移行用のツールを残しておいてくれたお陰でなんとかVPCへ移行出来た。
• メンテ完了したらすぐ打ち上げに行きたいところですが、一日くらいは様子をみておきましょう。