サービス数が増えても事業成長を止めない基盤を目指す
アカウント基盤による負債解消の最終的なゴールは「全てのサービスがメインデータベースに接続せずにアカウントデータを取得可能にする」です。しかし、この状態を一気に実現すると膨大な時間がかかってしまうため、段階的に結果が出せるように5つのフェーズに分けて対応を進めていくことにしました。
1. アカウント基盤自体のリリース
アカウント基盤はメインデータベースに保存されているアカウントデータの関心事を責務とするため、アカウント基盤自身がメインデータベースに接続した状態で稼働することが必要です。そのため、これまで運用してきたサービス群と同じならびにアカウント基盤のサービスを稼働させました。リリースにあたって共有ライブラリに実装を追加する必要がありましたが、既存のサービス（以下の図内のA、B、C）のUI/UXへの変更はほぼない状態でリリースを行うことができました。
アカウント基盤自体のリリースに既存サービスの開発者の工数を大幅に取ってしまうと調整コストが必要となりリリースまでに多大な時間がかかってしまうため、横断的な開発工数の確保をなるべく少なく済ませることに注力しました。
2. 新規サービスのリリース
アカウント基盤にメインデータベース内のアカウントデータをAPIで公開する責務を持たせたことにより、メインデータベースに依存しない形でほかのサービス群とアカウントデータを共有し、サービス提供を行うことが可能になりました。
このAPIの最初の利用者は、新しい取り組みを実施しやすい新規サービスにやってもらうこととしましたが、新規サービスを開発するごとにAPIをたたくためのクライアントを実装するのは効率が悪く、APIエンドポイントや提供するオプションが増えた場合にそれぞれのサービスのコードを修正してもらうのはコミュニケーションコストが高くなるため、アカウント基盤の開発チームがAPIクライアントを実装し、社内向けに提供をしています。
APIクライアント以外にもアカウントデータを使うにあたって全てのサービスで共通して実現してほしいUI/UXや処理フローは社内ドキュメントツールに仕様をまとめ、サービスの開発者が自分のドメインの開発になるべく多くの時間を使えるような工夫もしています。
また、特に技術的に考慮したのは新規サービス側の可用性です。例えば、ユーザーのリクエストの度に、法人名を表示するためにアカウント基盤のAPIをたたいていると、アカウント基盤に障害が発生した時にサービス側も引きずられて障害となってしまいます。そのため、図のように新規サービス（図ではD）はAPIで取得したアカウントデータをサービスのデータベースに保存し、ユーザーのリクエスト時に同期的にアカウント基盤のAPIをたたく必要がないようにしています。
もう1つ別の成果として、新規サービスではデータベースへの参照・更新操作を行う必要がなくなったため、Rails Engine製のライブラリを使う必要もなくなり、サーバーサイドにGoを採用する事例が出るなど新しい技術を採用しやすい土壌を作ることにも成功しました。
3. アカウントデータが分離していたサービスとのデータ統合
次にメインデータベースに依存するサービス群と依存しないサービス群との間でアカウントデータが分離していたものを統合することにしました。サービスの構成自体は先にアカウント基盤のAPIを利用している新規サービスと同じ構成になるため、下図のように新規サービスDの隣にサービスEが並ぶだけのシンプルなものです。
新規サービスの実装を参考にしてもらい、コードの変更はスムーズに進みましたが、データの統合は前例がなかったため定例的に情報共有・相談する場を設けて細かく方針を決定、修正するように努めました。統合作業においてアカウント基盤側のメインデータベースのデータを更新する必要性をなくしたことは統合作業の影響範囲を小さくし、想定外のことが起こった時のロールバックを簡単にするなど、もたらしたメリットが大きい取り組みでした。
難易度の高いデータ統合にこのタイミングで着手したのは、アカウントデータが分離していることからマネーフォワード クラウドのサービスを併用しているユーザーに認証情報や法人情報を複数管理してもらう複雑な状態をいち早く解決したかったからです。
4. メインデータベースに依存しているサービスの依存を剝がす
ここから先は現在取り組み中のフェーズとなっているため、現段階で検討、着手中の内容を紹介します。
メインデータベースに依存しない形でアカウントデータを共有する実績を作ることができたので、本命の負債解消の取り組みを進めています。これまでのフェーズの中でアカウント基盤を利用することになったサービスからの機能要望や修正依頼に対応しているため、メインデータベースに依存しているサービス群がアカウント基盤のAPIからデータを取得する形式に移行するための必要な機能はすでにそろっている状態です。サービスA、B、C側の対応が終われば、依存を剝がせる状態となっています。
移行する際は、図の赤線のようにメインデータベースのアカウントデータをサービス側のデータベースにコピーすることを考えており、不要なカラムやデータの削除は移行後に影響範囲がサービス側のデータベースに閉じた状態で実施することを検討しています。このようにサービスを1つずつ漸進的に移行することで影響範囲を限定的にしており、不具合が起きた時の調査を特定領域に絞ることができます。
5. アカウント基盤自体をメインデータベースから剝がす
メインデータベースに障害が発生するとアカウント基盤も障害に巻き込まれるため、メインデータベースのアカウントデータを専用データベースに持ち帰り、アカウント基盤自体の可用性を高めることが最終的なゴールとなります。
図ではメインデータベースにアカウント基盤とサービスA、Bが依存している状態で、アカウント基盤とメインデータベースの依存関係を剝がすように記載しています。サービスA、Bのメインデータベースとの依存関係を先に剝がして、最後にアカウント基盤の依存を剝がすのが一番安全ですが、サービスA、Bのような一部のサービスではドメインデータもメインデータベースに保存し、RDBMSのトランザクションやJOINを前提としたデータ共有をしており、この依存関係を剝がす活動も終わらせないとメインデータベースとの依存関係が剝がせない状態となっています。
このドメインデータの依存関係の解決を待っているとアカウント基盤の可用性向上までに時間がかかってしまうため、サービスA、Bはメインデータベースとの依存関係を残しつつ、アカウント基盤のAPIを利用してアカウントデータを取得する対応を行い、その後アカウント基盤をメインデータベースから切り離して可用性を高める方針にしてはどうか、という方針が挙がっています。
まとめ
初回に紹介したマルチテナントEKSを用いたプラットフォームによってアプリケーションの実行環境がクラウド化し権限移譲もされたため、クラウドサービスを活用したサービス開発に取り組みやすくなりました。さらに、今回紹介したアカウント基盤を利用することで、アプリケーションレイヤーでの技術選択の幅も広げることができました。
ただし、マイクロサービスアーキテクチャーでサービス開発・運用をした経験を全てのエンジニアが持っているわけではないため、アカウント基盤に関する仕様がなぜ必要なのか注意点はどこなのかなどをわかりやすく、かつ網羅的にドキュメントに記載してつまずくポイントを減らすことや、時にはシーケンス図などを使って口頭で説明するといったオンボーディングを行い、立ち上がりをサポートする必要性はあります。
また、アカウント基盤の開発プロジェクト発足にともない専門のチームを立ち上げましたが、このチームは社内のいろんなチーム（開発だけでなくビジネス含め）とコミュニケーションを取ることが求められるため、関連チームがアカウント基盤チームに質問しやすいようにSlackに専用の質問・相談チャンネルを作ってわからないこと・困ったことがあれば気軽にメンションしてほしいことを伝えるなど、コミュニケーション部分の文化に対しても変化を推進することが求められました。
最終的なゴールであるアカウント基盤とメインデータベースの依存をなくすことを達成するためにはまだ向き合わなければならない課題が残っていますが、ここまで我々が共有データベースやマイクロサービスアーキテクチャーへの移行に向き合ったことで得られた知見が何かお役に立てば幸いです。
次回は、アプリケーションの実行環境として初回に紹介したマルチテナントEKSを用いたプラットフォームを採用し、他のサービスとアカウントデータを共通して利用するためにアカウント基盤を使いサービスをリリース・運用した開発者の目線から、今のマネーフォワードの技術選定や開発の取り組みについて紹介します。
