この記事はWHITEPLUS Advent Calendar 2018 - Qiita 20日目になります。

WHITEPLUSで基盤回りの担当をしているakaimoです。

リネットではマイクロサービス化を進めるために、Elastic BeanstalkからGKE+Istioに移行しました。そのときにWebサーバーだけでなくログ基盤やDBなども一緒に移行し、インフラの大部分がAWSからGCPに変わりました。その中でも一番気を使ったDBの移行について書いていきます。

Cloud SQLはRDSの移行先として使えるか

Cloud SQLのMySQL事情

Cloud SQLには第１世代と第２世代があり、第１世代ではMySQL 5.5と5.6に対応していて、エンジンにはMyISAMとInnoDBが使えます。第２世代ではMySQL 5.6と5.7に対応していて、エンジンはInnoDBのみ対応しています。

後述しますが、第１世代はRDSと比較すると機能・性能面で実用性に欠けるため、バージョンやエンジンが要因で第２世代が使えないのであれば、Cloud SQLへの移行は諦めるべきです。

リネットではGKEへの移行の前にMySQL5.7のInnoDBにアップデートしていたため、この問題はクリアです。

あまり主要なものではありませんが、使えない機能などがあるので公式ドキュメントは必読です。

Cloud SQL for MySQL Features | Cloud SQL for MySQL | Google Cloud

第１世代と第２世代

第１世代と第２世代の違いはこの公式ドキュメントに書かれています。

Second Generation Capabilities | Cloud SQL for MySQL | Google Cloud

プロダクションで運用する上で重要なのはここらへんでしょうか。

第 1 世代に比べ、最大でスループットが 7 倍、ストレージ容量が 20 倍
オプションで高可用性フェイルオーバー、レプリケーションの読み取りを追加。

プロダクションで運用するならフェイルオーバーレプリカやリードレプリカは必須と言っていいでしょう。また、公式のベンチマークやユーザーが行ったベンチマークの結果を見たところ、第２世代 ≧ RDS ＞ 第１世代
であることは間違いなさそうです。性能や機能の面から見てもRDSの代わりに使うことはできると思います。公式が公開しているベンチマークはこれです。

移行プロセス

ここからはどのようにデータを移行したかについてです。

レプリケーションの昇格

最初に考えていた方法はRDSからCloud SQLに対してレプリケーションを貼って昇格させる方法でした。Cloud SQLはレプリケーションをする上でGTIDの使用を必須としています。しかし、移行当時RDSではGTIDの使用ができず、RDSとCloud SQLでレプリケーションを貼ることができませんでした。

未検証ですが、2018/10/10にRDSでGTIDがサポートされたので、現在はレプリケーションが貼れると思います。

Amazon RDS for MySQL がグローバルトランザクションアイデンティファイア (GTID) へのサポートを開始

ダンプデータのインポート

最初の方法がダメになってしまったので、次に深夜にメンテナンスを入れてダンプしたデータをCloud SQLにインポートする方法を考えました。

この方法でネックとなるのは移行にかかる時間です。1分たりとも停止させることができないサービスもあると思いますが、幸いリネットでは深夜で終わるのであれば問題ないという判断になったため、スマートではありませんがこの方法を検証しました。

複数回の検証の結果、リネットのDBのデータ量は深夜の想定作業時間内にギリギリ間に合うことがわかり、この方法でいくこととなりました。データ容量の関係上、この方法で移行できるのは今回が最後となりそうです。

リネットのデータ量でもインポートに数時間かかり、インポート中にネットワークエラーなどが発生した場合、再度頭からインポートしていては時間切れになってしまいます。そんな問題のためにGCPが公開しているcloudsql-import
というツールがあり、これを使えば予期せぬエラーや再起動が発生しても続きから再開できます。

Cloud SQLのGUIにあるインポートからでも、同じようにエラーで止まることなく動作します。

また、公式ドキュメントに書いてある通り、トリガーなどはインポートできないため、インポート後に忘れずに作成し直す必要があります。

トリガー、関数、ストアド プロシージャ、ビューは、Cloud SQL にインポートまたはエクスポートできません。ただし、Cloud SQL インスタンスでこれらの要素を作成して使用することはできます。

Cloud SQL for MySQL Features | Cloud SQL for MySQL | Google Cloud

リカバリープラン

移行後に許容できない不具合が発生したときのために、GCPからAWSへ戻す方法も考えておかないといけません。

レプリケーションが貼れていればマスターの昇格で戻せますが、データをコピーする方法だと、戻すときも変更分をコピーしないといけません。これだと不具合が発生する時間帯が読めないことにより、だいぶリスクが高くなってしまいます。

そこで、DBはCloud SQLのままにし、AWSの旧環境からCloud SQLにアクセスする方法を実験してみました。GCPが公開しているcloudsql-proxyを使用すればDBへのアクセスは暗号化されるため、問題となりうるポイントはレイテンシです。

こちらも計測してみたところ、AWSとGCP間のレイテンシは、AWSのアベイラビリティーゾーン間のレイテンシと同程度であることがわかり、この程度のレイテンシならば許容できる範囲と判断して、不具合発生時はクラウドをまたいで通信することにして移行に望みました。数日で解消できない不具合だった場合は、もう一度深夜メンテナンスをしてRDSに戻すという最後の手段も用意していました。

終わりに

事前の検証と練習により、何事もなくDBの移行は完了しました。移行後もRDSと比べ劣っているような部分は感じられていません。

後日、移行当日の作業内容を時系列で公開したいと思っています。