最近、自分の周りではよくオンプレ環境や AWS 環境を GCP に移行する話を聞きます。

新設する API やダウンタイムメンテを許される一部の API は比較的移行しやすいと思いますが、そうじゃない API や特に Database の移行に関してはかなり悩むと思います。

自分も以前の職場で少し検討しましたが、いろいろ大変そうでした。

難関は Database 移行

サービスによって違う場合もあると思いますが、多くの場合は Database が二重に存在してしまうことが一番難しいポイントになりそうです。

「ダウンタイムなしだと、旧 Database から新 Database にリアルタイムで同期できる？一旦書き込み止めないと無理？」
「移行に失敗したら旧環境に戻したいけど、新 Database に追加されたデータはどう戻す？捨てられる？」
「それなら新 Database にも旧 Database にも両書きしちゃえば？」
「両書きだとどちらか片方だけ Transaction に失敗したら...？両方でデータの不整合が簡単に発生しない？ID の発行は？」
「インスタンスタイプとか気をつけないと性能劣化でヤバそう...」

などなど、突然のマルチマスター構成みたいになっちゃってそれなりに大変です。元環境に戻せないとなると、当日のリリース作業...怖い...。

そんな中 Netflix の課金系サーバーの AWS 移行の記事が見つかったので、その中の Database 部分に注目してみたいと思います。

Netflix 課金の構成

Netflix Data Center 上に構築していた構成が下記のようです。

https://medium.com/netflix-techblog/netflix-billing-migration-to-aws-451fba085a4

Subscriptions だけでなく DVD なども入っているところが Netflix 特有感はありますね。

Netflix はアカウント作成時やサブスクリプションの解約のタイミングにも処理が発生するため、様々なタイミングで Billing API が呼ばれるみたいです。

一方で新構成がこちらです。

https://medium.com/netflix-techblog/netflix-billing-migration-to-aws-451fba085a4

直接 Billing API を呼ばずに Billing Redirector を経由して呼ぶようにし、そこで旧環境と新環境を切り替えられるようになっています。

API Server の移行は、旧環境と新環境の2つを用意して API Gateway や Load Balancer などのレイヤーで向き先を切り替えられるようにすると良いみたいですね。

Mercari のリニューアル時の話にも似たような構成が紹介されています。

この構成実現に向けてコードを綺麗にしたり、不要なデータをパージしたりしています。

ユーザーワークフロー部分を全て非同期モデルに

パワフル！！！

例えば、ユーザー登録時には課金処理が遅れていることを考慮させる API 仕様に変更しています。
ここの改修コストは Billing API 仕様によって結構変わりそうですが、課金が失敗したときとか考えると全非同期は結構複雑になりそうですね。

Payments 処理側は、多少失敗することを許容して再実行可能にし、内部的には Transaction を維持できるようにダウンタイムありで移行を進めています。

そうすることにより

ユーザー影響の部分はダウンタイムなしで移行することができ
課金処理部分は若干のダウンタイムをとって安全に移行することができたようです。

全移行にかかったのは7年という長い月日...!

ちなみに今回は Billing 周りでしたが、Netflix の全サーバー移行はトータル7年もかかったらしいです。

なんかそこまで来るとベンダーロックインされていても、最初から楽な方選んでいて良いんじゃないかって思ってます。
Cloud Datastore は外部に移行できないから、って言いつつも大抵のサービスでは実際 Database 移行なんてしないのでは...と。

今回の記事はこちらを参考にしています。