MongoDBであるメリットが無くなってしまったのでMySQLに移行したはなし

SREチームの長田です。

この記事はTech Kayac Advent Calendar Migration Track 1日目の記事です。

今回はLobiで使用していたMongoDBをMySQLに移行したはなしです。

MongoDBを何に使っていたか

DAUなどのKPIレポートや、サービスの状況を把握するための各種集計結果を保存するために使っていました。サービス開始直後はこれらの数字を色々と試行錯誤しながら追加したり、減らしたりしていました。

頻繁な追加削除があるデータ構造を保存するために、スキーマレスなデータベースであるMongoDBはちょうどよかったようです。 (当時スキーマレスデータベースが流行っていたというのもあるでしょう)

なぜ移行したのか

MongoDBに保存されたドキュメントは、スキーマ管理がされていませんでした。スキーマレスであることをいいことに、その時時によって様々なデータ構造を使ってしまっていたのです。保存する値の種類によって異なっていたり、種類が同じでも時期によって異なっていたりしました。

何が入っているのかが把握しづらい
最近はデータ構造の変更がほぼないのでスキーマレスであるメリットがない
バックエンドをECS化するにあたって別のデータベースに移行するかDocumentDBに移行するかの選択を迫られていた

ということでMongoDBから使い慣れたMySQLに移行することにしました。

移行

幸いレポート表示関連のテストは必要最低限のものは揃っていたので、データベースをMySQLに置き換えた上でテスト実行して、テストを実行しながらトライアンドエラーで移行を進めていきました。

保存されているドキュメントをざっと眺めて移行スクリプトを書き、失敗したら(=予期せぬデータ構造に出会ったら)場合分け対応を行い、なんとかMySQLにデータを移しました。

レポート表示時にMongoDBのAggrigationで行っていた集計処理をサーバーサイドのコードで書き直したのですが、数値の丸め方や有効数字の違いによってテストに失敗する場合がありなかなか大変でした。集計系のテストはつくるのも失敗したときの調査もしんどいんですよね・・・。

実装以外で時間がかかったのが「このレポートは必要なのか？それとも不要なのか？」の確認。レポート表示アプリのアクセスログを見る限り全く使われていなくても、確認は必要です。数字は過去にさかのぼって変化を追えることに意味があるので。各担当者に確認を取る必要があり、やり取りの待ち時間がそれなりに発生しました。

なんだかんだで1ヶ月くらいかかりました。