クルーバー技術顧問の五十嵐(igaiga)です。今年の3月から技術顧問として勤務しています。クルーバーではカー用品・バイク用品に関する複数のECサービスを開発して運用しています。
今日はクルーバーが行っているレガシーとの闘い、大規模な設計変更についてお話しします。
旧設計とそのつらいところ
移行前に困っていた点としては次のようなものが挙げられます。
データが点在していた
たとえば在庫データなどが各サービスなどに散らばって保管されていたため、各サービス間でやりとりが多く発生していました。また、そのやりとりもCSVファイルでエクスポートしてファイルを転送してインポートするなど、レガシーな方法で行われていました。
レガシーなミドルウェアに依存していた
廃れてしまった旧世代の技術をつかったミドルウェアで書かれたサービスがあり、継続が困難な上に、技術の習得も難しく、人の交替もままならない状況でした。
ほかにもいろいろと挙げられますが、レガシーな領域が多く、それらを使い続けたまま存続させることはとても困難な状況となっていました。
新しい設計
これに対応すべく、新システムとして新しいアークテクチャを設計して対応することにしました。具体的には、次のようなマイクロサービス構成で設計しています。
Rails + GraphQL API を基本構成とする複数の基盤サービスで構築しています。ユーザーが利用するWebサービス部分はNuxt.js + Railsで構築し、必要に応じて基盤サービスを利用します。利用技術を揃えて、1人のエンジニアが複数のサービスに渡って新機能を実装しやすくしています。
前述した「データが散らばっていた」は既に「在庫基盤」として改善がなされた新設計で稼働をはじめています。図の右下に書かれている旧DBから左上に書かれた新DBへデータを同期する仕組みが稼働し、新DB側へデータが集まるようになりました。旧DBの古いしがらみは捨てて新DBはスキーマも新たな設計を採用し、しかも旧DBから新DBへサービス群を止めずになめらかに移行する仕組みを実装して稼働している状況です。ただし、規模も大きく全ての移行を一発で終わらせるには難しいため、まだ旧DBを見ていたり、旧DB時代のしがらみを解消する途上の箇所もまだまだあります。
共通で利用される「基盤サービス」としては前述の「在庫基盤」のほか「ユーザ基盤」「検索基盤」「帳票基盤」などが実装されて、部分的に、または機能全体が稼働しています。
現在と今後の課題
レガシーな旧システムを新設計によって改善を進めています。まだ基盤部分も実装途上の部分、足りない部分の方が多いですし、旧システムの上で動くサービス群は大半がこれから移行となります。
また、マイクロサービスやGraphQLなどのアーキテクチャを導入したため、新たな課題も生まれました。サービスを横断してトランザクション処理が必要な場合にどのように解決するのか。リポジトリを横断して開発をするためにDockerプロセスを多数起動しているが、開発環境をシンプルにつくるのにはどうすれば良いのか。運用コストを下げるために監視などをどのように改良していけば良いのか。GraphQLをつかって良いAPIを設計するためにどうすれば良いのか。
ここまでの新設計とその改善は私が入った3月時点で既にできていました。現在、私は同僚と一緒にこの新設計への移行を進めています。また、この機会からRailsをつかって開発するようになったメンバーもいるので、「パーフェクトRails」をつかった読書会を実施するなどして学習の仕組みも整えています。
まだまだやることも課題も山積みですが、より良いシステムへ進化させていくため、私たちと一緒に設計してコードを書いてくれるメンバーを大募集しています。マイクロサービスで運用される基盤群やサービス群を設計実装したり、GraphQLをつかってAPIを設計実装したりと、考え甲斐のある技術課題を解決したい方の応募をお待ちしています！
