コドモン Product Team Blog

株式会社コドモンの開発チームで運営しているブログです。エンジニアやPdMメンバーが、プロダクトや技術やチームについて発信します!

モノリスからマイクロサービスへの旅:データの移行

🎅 こちらは「コドモン Advent Calendar 2022」の22日目の記事です 🎅 qiita.com

先日、あっさり娘にクリスマスプレゼントを早期発見されてしまったプロダクト開発部のチャブです。

今回の投稿では最近マイクロサービスとして切り分けされたコドモンのサービスを事例に、どのようにして既存のデータの移行を行ったか紹介します。

モノリスからマイクロサービスへ

コドモンでは今後の迅速なサービスの拡張を可能にするために、現行のシステムのマイクロサービス化を進めています。

マイクロサービス化の方針として、サービスの単位はビジネスドメインを表す単位で切り分けています。ドメイン内で発生するユースケースの実現に必要なデータは(なるべく)マイクロサービス自身で管理します。

そのため切り分けされるサービスの性質によっては、既存のデータを新しいシステムに持っていく必要があります。

対象のサービス

今回事例となるサービスは「保育施設が資料を保護者に共有する」「保育施設が資料を管理する」などの資料にまつわるユースケースを扱うものです。そこで、今まで溜まってきた資料のデータを引き継ぐ必要があります。

データ移行戦略の選択肢

既存のデータを新しいサービスに持っていく手段として複数考えられます。

データダンプ

データダンプを行う際は、ある瞬間でのデータのスナップショットを用いて新しいサービスにデータのコピーを作成します。この場合はコピー元で今後発生するデータには対応できません。

データ同期

データ同期を行う場合は、2つのサービスのデータを常に同期状態になるようにします。つまり、現在稼働中のサービスのデータと、今後作成・編集・削除される変更をすべて新しいサービスのデータベースに随時反映します。

データダンプする際の世界線

データダンプをする場合は基本的に「稼働中のサービスの停止」「データのコピー」「新しいシステムの稼働」を同じタイミングでやらなければなりません。人類はそれを「ビッグバンリリース」と名付け、多くのエンジニアの不眠の原因になりかねないでしょう。

データ同期のメリット

ふたつのサービスでデータの同期状態を担保するのは一見余計に複雑そうに見えます。ただ運用上のメリットが大きいです。データ同期状態を実現することで以下の大きなメリットがあります。

リリースの単位

データの移行と新サービスの稼働を一緒に行う必要がなくなります。そのため、データ移行の機構とアプリケーションを独立してリリースすることができます。データが常に同期されている場合は、新しいサービスのリリースは理論上いつでも可能です。

メンテナンスを設ける必要がない

ユーザから見てもメンテナンス状態になることがないので、何も変更を感じることなく裏でデータの同期をすることができます。

カナリアリリース

常にデータが同期されているので新旧のサービスが並行稼働することが可能になります。並行稼働した上で徐々にトラフィックを切り分けるなどして、カナリアリリースを行うことが可能になります。

最終的に生まれたもの

データダンプと違ってデータ同期をするためには、常に稼働するシステムを構成する必要があります。

チームで設計を叩き合った末に以下のような形になりました(イメージ)。データ同期期間中にリリースしたいマイクロサービスに工数をなるべく割けるように、運用工数がミニマムな自己回復性の高いシステムになるよう心がけました。

さいごに

今回の戦略でデータ移行を行ったことでリスク(とストレス)を軽減することができました。

  • データの移行とアプリケーションが別単位でリリースできたこと
  • 並行稼働でカナリアリリースができたこと
  • 並行稼働でフェイルセーフを導入できたこと(新しいサービスに問題があったら自動的に現行のサービスを利用する)

このように開発者として嬉しい条件でマイクロサービスの切り分けをリリースすることができました。 ユーザーへの影響も最小限にできたのでユーザーにもストレスなく使ってもらえます。

マイクロサービス化したいサービスはまだ多数あり、今後もみんなが安眠できる状態で進めたいと思っています。

コドモンでは一緒にマイクロサービス化を推進していく仲間を募集しています。このような開発が面白いと思う方は是非、一緒に(安眠しつつ)日本の保育環境をよくしていきましょう!


最後まで読んでいただいてありがとうございます!

明日の投稿では同じくプロダクト開発部の岡村が投稿する予定です!