はじめに
はじめまして。株式会社マネーフォワードのグループ会社であるマネーフォワードケッサイ株式会社のカミジマです。2018年にマネーフォワードに新卒として入社し、法人向けにサービス提供している「マネーフォワード クラウド」の横断的な技術課題の解決に取り組んだのち、現在はソフトウェアエンジニア・SREとしてマネーフォワードケッサイが創業以来蓄積しているデータを活用した新規事業の立ち上げに従事しています。
前回は、複数のサービスが1つのメインデータベースを利用することで、サービス開発の立ち上がり速度を支えたアーキテクチャーが、サービスの成長とメインデータベースを利用するサービスの増加にともない、開発速度が低下するといった問題を引き起こしていることをお話しました。
また、その問題を解決する方針として「全てのデータはそれぞれ単一のサービスからのみ直接的に参照・更新され」「他のサービスがそのデータを参照・更新したい場合はアプリケーション層で定義されたインターフェースにのっとって操作する」という疎結合な状態を目指して行ったデータ整理の取り組みについても紹介しました。
そのほかマネーフォワードでは、共有データベース パターンがもたらす技術的負債と向き合う方法として、マイクロサービスアーキテクチャーの採用にも取り組んでいます。今回はその取り組みの中から法人向けに現在、20弱のサービスを提供している「マネーフォワード クラウド」が共通して使っているアカウント基盤のマイクロサービスの開発経緯やアーキテクチャーの変容について紹介します。
この記事では以下の3つのポイントを通して、データベースを共有するアーキテクチャーをマイクロサービスアーキテクチャーに移行する時に意識すると良い点や意思決定の事例に関する知見が得られます。
- サービス成長にともない共有データベース パターンがもたらす課題
- 共有データベース パターンによる負債解消のアプローチ方法
- 共有データベース パターンからマイクロサービスアーキテクチャーへの移行フロー
マネーフォワード クラウドのアカウントデータの管理方法と課題
法人向けバックオフィスSaaS「マネーフォワード クラウド」では、会計のみならず人事労務、法務領域など20弱のサービスを提供しています。サービスの利用を開始する際に法人情報（法人名など）と法人に属するユーザーの情報（従業員名など）を入力してもらい、アカウントデータとして保存しています。
このアカウントデータは他のマネーフォワード クラウドのサービスと共通して利用することが可能であり、例えば会計サービスを利用中のアカウントデータを使って経費サービスも利用することで、サービス間でシームレスにデータを連携できます。この仕組みは以下の図のようにメインデータベースに保存しているアカウントデータとデータへの参照・更新ロジックを共通化しているライブラリを複数のサービスで共有することで実現しています。
RDBMSのトランザクションやJOINなどの機能をそのまま利用できるため、開発の初期フェーズにおいてこの仕組みは開発速度向上に貢献しましたが、事業成長にともないさまざまな課題を生みました。今回は法人のアカウントデータに関する取り組みの紹介なので、アカウントデータに関連した課題についてお話します（※共有データベース パターンが生んだ課題について広く知りたい方は前回の記事をご参考ください）。
メインデータベースのライフサイクルにサービスの稼働時間が影響をうけやすく単一障害点となっていた
アカウントデータに関連するテーブルにマイグレーションが必要となった際、変更内容によってはサービス全体に影響を与える可能性が考えられます。そのためメインデータベースに依存するサービスをメンテナンス状態にしてからマイグレーションを実行することが求められるようになりました。
また、負荷が高いクエリが流れるとデータベースの性能が劣化し、結果的に全てのサービスが不安定になることもありました。こちらは前回紹介したスロークエリの監視と改善活動やデータの責務を整理し、サービス専用データベースに持ち帰ってもらうことで徐々に頻度は減っていきました。
他のサービスとアカウントデータを共有できないサービスが生まれた
アカウントデータを参照・更新するためのAPIが存在しなかったため、アカウントデータを共有するにはメインデータベースに依存することが必須となっていました。しかし、メインデータベースに依存すると上記の単一障害点の問題などを抱えることになるため、いくつかのサービスでは可用性を重視してメインデータベースに依存しない意思決定をしました。
結果的にこれらのサービスとメインデータベースに依存するサービス群の間では、アカウントデータが別れた状態となってしまい、サービスを併用してくださっている利用者の視点に立つと、同じマネーフォワード クラウドのサービスを利用しているのにログインIDやパスワードなどの認証情報や、法人名などの情報を複数管理することになっていました。
サーバーサイドにRuby on Railsを使わざるを得ない状態になっていた
メインデータベースへの参照・更新ロジックは共有ライブラリに実装されており、このライブラリはRubyのライブラリ形式であるGemとしてRuby on Railsの実装を共有できるRails Engineを採用しています。
サービスの成長にともない共有ライブラリが複雑化したことで、このライブラリを通さずに参照・更新を行うとデータが意図した状態になるかどうかわからない、という状態に。結果的にメインデータベースを利用したサービス開発では、共有ライブラリを使用するためにサーバーサイドにRuby on Railsを使わざるを得ない状態となっていました。
アカウントデータに責務を持つマイクロサービスを開発することになった背景
アカウントデータが直接共有されている状態はいくつかの課題を生み出してはいたものの、サービス開発をストップさせるものではなく、新機能や新サービスの開発は続けられていました。そんな中アカウントデータに関する責務をアカウント基盤に切り出し、マイクロサービス化していく意思決定を行ったのは大きく2つの理由があります。
1. メインデータベースに依存するサービス数を減らすことで今後の負債解消を効率的に進めたい
メインデータベースに依存するサービスの中には、以下の図のサービスA、Bのようにアカウントデータのほかにも特定のドメイン固有のデータを共有している依存が強いサービスと、サービスCのようにアカウントデータだけに依存しているサービスが存在していました。
実際の環境ではサービスCのような依存が弱いサービスの方が多く、これらからメインデータベースへの依存を切り離してメインデータベースの影響範囲を小さくすることができれば、残される依存が強いサービスの依存性を弱らせる取り組みを行いやすく、効率的に負債解消の進めていけるのではと考えました。
2. アカウントデータを統合することで、中長期的に仕様の簡素化や開発速度向上などのメリットを得ることができる
先ほども紹介したように、一部のサービスでは可用性を重視してメインデータベースに依存しない選択肢を取り、サービス間でアカウントデータが分れている状態が生まれました。
ユーザー視点で見てログイン情報などが別になっていることを話しましたが、開発視点から見るとサービス間連携の仕様を作る、実装する難易度が高くなっており開発速度を落とす側面があったため、今後の事業成長を鈍化させないためにもアカウントデータの統合に投資することは大きなメリットがあると考えました。
これら2つの理由はいずれも中長期的な視点に立ったものでした。短期的に見ると会計サービスなどのドメインサービスの開発者に、アカウント基盤導入のための工数を作ってもらう必要がありましたが、課題を解決した先にどのようなメリットがあるのかを開発やビジネス観点で説明する資料を作ったり、経営陣から全体に向けた発表をしたり、情報発信にも努め開発に着手することとなりました。
