【フォースタテックブログ】モノリシックなシステムをマイクロサービス化した実例とその効果について

フォースタートアップスで「STARTUP DB」（スタートアップデータベース）の開発を担当している竹内強（@manbo34）です。

前回はSTARTUP DBの技術を紹介しました。今回は小規模ですがマイクロサービス化に挑戦したときの話をさせていただきます。

tech.forstartups.com

まず、元々、弊社のシステムは次のような構成になっていました。弊社では大きくSTARTUP DB（以下、SDB）と弊社内で利用しているタレントエージェンシー支援システム（以下、SFA/CRM）があるのですが、SDBの一部はSFA/CRMと同一のシステムとして動いていました。これは開発リソースが少なく、開発速度優先で開発していたためです。

これを混在していたSDBの一部とSFA/CRMをDBごと完全に分離し、別システムとして切り離しました。

マイクロサービス化に挑戦した理由は、次の課題があったためです。

関連性のない情報が混在している
関連のない修正で関連のないサービスが停止する可能性がある
開発効率が落ちてきていた

開発効率が落ちてきていた

SFA/CRMの開発チームとSDBの開発チームが同じリポジトリで開発していました。結果、コンフリクトや検証環境の取り合いが発生するようになってきていました。チームを倍増していく計画もあり、対処しておきたい問題でした。

これらに対処するため、マイクロサービス化をスタートしました。
今回はそのプロジェクトについてお話します。

計画〜当初の構想とフェーズ分け〜

マイクロサービス化プロジェクトは全メンバーで行うわけでなく、SFA/CRMの開発と並列して行いました。そのため、SFA/CRMの開発に大きな影響が出ないことを重要視しました。これを達成するため、マイクロサービス化プロジェクトを4つのフェーズに分けて計画しました。

現行システム

当時のシステム構成図を掲載します。
計画した最終的な構想は次のとおりです。

データベースを分割し、それを扱うアプリケーションを作成します。
元々あるシステムは分割したデータベースのModelだけAPI経由で取得するようにし、画面などは変更せず、最低限の修正でデータベースの分割を実現します。
それでは、この構成に至るまでの道筋を説明します。

フェーズ1：SDB 管理 API の作成

SDB管理のデータを取得するAPIを実装
SDB管理のデータはAPIを経由して利用するように変更

SDBのデータベースに直接繋げられなくなるため、事前にSDB管理のデータはAPI経由で参照・編集するように変更します。
この対応を先に実装することでインフラ層を変更してもAPI Modelでインフラの変更を吸収できるため、以降のフェーズでControllerやViewを修正せずにプロジェクトを進められるようになります。

フェーズ2：SDB API と SDB管理 API の統合

元々存在していたSDB APIをフェーズ１で作成したSDB管理 APIを統合

フェーズ1で作成したControllerに元々存在していたSDB APIを統合し、システムを分割する準備を行います。
APIを利用するためのURLは変わらないためSDB側の修正はありません。

フェーズ3：データベース分割

SFA/CRMとSTARTUP DBのテーブルをそれぞれのデータベースに分割します

データベースを分割します。対象のテーブルの接続先を変更するだけでシステムの変更は必要ありません。

フェーズ4：システム分割

SDB管理 APIを別システムに移行する

システムを分割します。リポジトリは別になりますが実装自体は修正せずに移行します。このフェーズで行う主な作業はインフラ構築です。

上記手順であれば、SFA/CRM開発への影響を少なくしつつ、リリースできると判断しました。
次に実際どのようにプロジェクトが進んだかをお話します。

実績〜計画の変更理由と対応内容について〜

実際に作業をすすめてみたところ、計画通りに進めることができませんでした。ここから計画と実績で乖離していた部分について説明します。

計画通りに進められなかった主な原因は修正しない予定だったSDB管理のView部分に大きく修正が必要になったためです。

マイクロサービス化プロジェクトのAPI ModelにはRESTful APIのORMであるHerライブラリを選択しました。Herライブラリを利用したことでAPI経由のモデルもActiveRecordのモデルと同等に扱えるため、Controller層の修正を大きく抑えることができます。ただ、KaminariといったGemやRailsの機能を使えなくなる箇所が発生し、それらに対応するため大量のラッパークラスの開発が必要になりました。また、独自のラッパークラスなどを利用することで保守の難易度も上がってしまいました。

Gemへの対応が必要になりフェーズ1の終わりが見えなくなったこと、本来解決したかった開発効率の改善が達成できなくなることから、1ヶ月半ほどたってから計画通り進めることを断念しました。

計画を変更し、最終的に次の構成を目指します。

計画との差分は画面も移行対象としたことです。
移行対象が増えますが、利用するモデルがHerからActiveRecordになるので全体の修正量は減ります。

実際の各フェーズについて説明していきます。

フェーズ1：SDB 管理 API の作成および画面分割

View, Controller, Modelの分割
SDB管理 API Controllerの作成
SFA/CRMはSDB管理のデータはAPIを経由して利用するように変更

Rails エンジンを利用して同じリポジトリ内でシステムを分割しました。
それ以外については、計画通りです。

フェーズ2・4

フェーズ2も大きく計画を変更したフェーズのひとつです。
元々フェーズ2はフェーズ3でSFA/CRMの開発と並行して開発するための準備フェーズでした。フェーズ4で捨てるコードも多く、計画遅れもありスケジュールの短縮を狙いフェーズ2・フェーズ4を同時に行いました。

問題点はフェーズ4を同時に行うことでリリースできなくなったことです。このフェーズからSFA/CRMのリリース内容を常に把握しフェーズ2・4用のブランチへ取り込む作業が発生してしまいました。

フェーズ3

フェーズ3に関しては元々計画していた内容と差異がなく、ソースコードの修正もほぼ無いフェーズなこともあり予定通り進めました。
これにてリリース完了です！

振り返り

モノリシックな構成のシステムをマイクロサービスとして実際に移行した取り組みについてご紹介しました。

振り返ってみて、最初に取り組みの全体像を把握して計画を行うことが重要だと感じました。今回は前提として、複数あるサービスの稼働は停止せずにマイクロサービス化を進めるという要件がありましたので、フェーズを分けて段階的に移行することでダウンタイムを発生させない計画を立て、結果として一度も稼働を停止すること無く完遂できました。

また反省すべき点として、今回特に気を使って計画し、フェーズ分けを行いましたが、作業を一定進めてから問題が発現し、計画の見直しが必要になりました。
一度立ち止まって俯瞰して現状を把握したうえで判断し、計画を見直すこと自体は行われるべきですが、判断のタイミングを逃すと全体のスケジュールへの影響が大きく出てしまいます。

計画の振り返りと見直しが最適なタイミングで行われることが大切だと感じられたプロジェクトでした。

マイクロサービス化の効果

メインデータベースの利用がしやすくなり、また個別のサービスの修正に他のシステムへの影響を気にしなくて済むようになり、各自が担当するサービスの開発に集中できるようになったのは最大の効果であり、今後の開発効率へ大きく影響します。

さらに、各サービス間の依存が無くなったことで、一方でトラブルが発生しても他方に影響を与えることが少なくなりました。そしてシステムや環境が分離されたことで、お互いのシステムを意識しなくともリリース・デプロイできるようなりました。

今後の開発について

弊社ではエンジニアの組織が拡大する中で、各エンジニアの責任の範囲を明確化しています。マイクロサービス化によってバックエンドをAPIにして、フロントエンドと分離する取り組みを引き続き行っていきます。
バックエンドとフロントエンドそれぞれの役割と担当範囲が明確になっていくので、お互いがそれぞれの範囲の開発に集中できる環境が整いつつあると言えます。

日本No.1の成長産業支援プラットフォームをテクノロジーで実現するために、バックエンド・フロントエンドそれぞれエンジニアがさらに必要で、仲間を募集しています。

興味がありましたら是非話を聞きに来てください！
お待ちしております！！