Baseconnect、企業情報データベース「Musubu」の営業リスト機能をRails+Neo4jからGoへ移行

Baseconnectが提供する企業情報データベース「Musubu」は、メインDBにNeo4j、検索用のDBとしてElasticsearchを採用し、バックエンドはRuby on Railsで実装されていた。ところがグラフDBであるNeo4jの特性は、採用された当初で想定していたほどには必要とされておらず、Neo4jを採用するメリットが極めて薄い状態になっていた。技術的な足かせも大きく、Neo4jのORMであるactivegraphが内部で依存しているドライバー（neo4j-ruby-driver）はNeo4j公式サポートのものではなく、さらにORMの最新のメジャーバージョン11ではCRuby自体のサポートが切られていたため、Neo4jのバージョンを上げていくことも難しくなっていた。運用面では、データの変更があった場合にそれをElasticsearchへ逐次反映させる必要があり、この「複数DBの更新」という行為がトランザクションの制御や更新トリガーの漏れといった問題を容易に引き起こし、かなりのデータのずれを引き起こしていた。Rails MVCではビジネスロジックの記述場所が不明確でモデルが肥大化しやすい、という設計上の課題も重なっていた。

Goへのリプレイスを既存のアプリケーション全てで行うことは、あまりにもシステムが大きすぎるため現実的ではないと判断された。そこで機能領域で分割し、段階的に進める形を採った。

• 営業リストの機能をGoでリプレイスし、それ以外の機能はRailsに残す
• Go側のアーキテクチャとして軽量DDDとクリーンアーキテクチャを採用し、関心の分離とレイヤーの責務を明確化する
• アーキテクトがベースとなる実装を用意したうえで、Go未経験のエンジニアも開発に加わる体制をとる
• パフォーマンス最適化とコードの可読性のトレードオフを都度検討しながら実装する

Goの厳密な型定義により、Rubyのメタプログラミングによる曖昧さが排除され、IDEの補完も効くようになった。一方でGo向けのデファクトスタンダードと呼べるライブラリが不足している領域もあり、選定には手間がかかった。

営業リスト機能をGoへ移すことで、Neo4jのORMとドライバーのサポート状況に開発が縛られる状態から抜け出せた。アーキテクチャ面では、軽量DDDとクリーンアーキテクチャの採用によりレイヤー間が疎結合になり、単体テストもしやすくなった。それまではほぼAPIのテストしか書かれていなかったが、安心してコードの再利用ができるという状態になった。型が厳密になったことで認知負荷も下がっている。なお記事中に移行期間やコスト削減額などの定量的な数値は示されていない。