【計画編】スカウト機能のマイクロサービス化を辞める判断について

こんにちは。ウォンテッドリーのEnablingチームでバックエンドエンジニアをしている冨永(@kou_tominaga)です。Enablingチームでは技術的な取り組みを社外にも発信すべく、メンバーが週替わりで技術ブログをリレー形式で執筆しています。前回は市古さんによる「2025年から Elasticsearch に入門して、同義語検索を理解する」でした。今回は「【計画編】スカウト機能のマイクロサービス化を辞める判断について」についてです。

近年、マイクロサービス化が多くの現場で導入されていますが、その一方で「うちの規模・状況に合っているのか」「本当に効率が上がっているのか」と悩んでいる方もいるのではないでしょうか。
まさに我々のケースはそうで、数年前にスカウト機能をマイクロサービスとして切り出したものの時間が経つにつれて様々な課題が出てきました。

今回のブログでは、「なぜ再統合に踏み切ったのか」「何をやったのか」「気をつけたポイントは」といった観点でまとめてみます。

はじめに

このブログの背景と目的

この記事は、Wantedlyのスカウト機能のマイクロサービスをモノリスに統合する事についてまとめたものです。以下内容を整理して同じように「マイクロサービス化してみたけど辛い...」という方に、少しでも参考になる情報を届けたいと思っています。

なぜ今モノリスに戻そうとしているのか
どんな課題があったのか
どういうアプローチで進めているのか

想定読者

マイクロサービスを運用していて、開発の辛さに悩んでいるエンジニア
モノリス vs マイクロサービスで設計判断に悩んでいる方
Wantedly の開発事例に興味がある方

なぜ今「モノリスへの統合」なのか

元々はスカウト機能の規模が大きくなったことにより、2019年にマイクロサービスとして切り出して運用してきました。ところが年月が経つにつれ逆に開発・運用が辛くなってきたため、今回モノリスに戻す方針を取ることになりました。

前提と背景

マイクロサービス化の狙いと現実

スカウト機能をマイクロサービスとして独立される事で以下のような狙いがありました。

機能単位で責務分離をしてシンプルに保つ
テスト・デプロイの独立化

ただ、現状ではマイクロサービスにした事により以下の問題が発生していました。

元のサービスとのロジックやデータに依存が大きく完全な独立が難しかった
機能追加のたびにマイクロサービス間で行き来が必要になり開発効率が悪化した
横断的な実装やデータ整合性のため、複雑な例外ルールや分散トランザクションのリスクが増加

モノリス化の目的と方針

スカウト機能の開発が統合側のみで完結する事で、より生産性が高い状態にするというゴールをおきました。モノリス化で以下状態を目指しました。

保守性向上：コード構造の単純化
認知負荷の軽減：新規 joiner でも把握しやすい
開発効率向上：スカウト機能の今後の進化をより素早く進められる状態にする

統合方法

ただ、統合対象のサービスはプロダクト開発チームが修正を加えており、統合プロジェクトがプロダクト開発チームの生産性に影響を与えない事が必須でした。よって、以下の移行案を作成しました。

ビッグバン型のリリースでの統合

スカウト機能を完全実装
徹底的なテスト
修正をデプロイ
問題なければ旧サービス廃止

マイクロサービスとして統合

スカウト機能のコードを統合先のサブディレクトリに全て移動
部分的にコードをマージしていく

APIベースの統合

統合するAPIを選定
API単位で統合してリリースする

以下メリットとデメリットを検討して「APIベースの移行」で進める事としました。

ビッグバン型リリースでの統合
- メリット：移行期間が最も短い
- デメリット：リスクがかなり高い。コンテキストが大きくなるのでAIエージェントの活用が難しい。
マイクロサービスとして統合
- メリット：リスク低。段階的な統合が可能。複数リポジトリを見なくて良いのでコードレビューが楽。
- デメリット：両サービスに重複するコードが長期間発生して、プロダクト開発チームが両方のコードを修正する必要がある。デッドコードも統合される
APIベースの統合
- メリット：リスク低。段階的な統合が可能。デッドコードが移行されない。
- デメリット：APIと共に関連するロジックが移行され1つの統合の差分が大きくなる。よって、PRをどの単位で分割するかなどの意思決定がAPI事に発生する。

統合するAPIを選定

APIの実行ログをBigQueryに記録しており、以下観点で直近1ヶ月のAPI実行状況を出力しました。

どのマイクロサービスから呼び出されているか
何回呼び出されているか

結果、アクティブなAPIは71個ありました。上記情報からAPIと呼び出し元の組み合わせを列挙して、高トラフィックなAPIはCanary Releaseをするなどの整理をしました。

API単位で統合してリリースする

前項目で列挙したAPIのリストを元にAPIを統合していきます。予期せぬ副作用が発生していないか、リリース後のモニタリングを行います。また、リリース後は統合元のgRPCエンドポイントの実行がなくなっているかまで確認します。

まとめ

これからマイクロサービスを統合しようとする人へは以下を留意いただければと思います。

メリットとコストを定期的に見直すこと
- 一度マイクロサービス化したものは「当初の目的が達成できているか」と問う事が大事です。問題が解決できておらず、むしろ他の問題が発生していたら素直に見直す事が大事だと思いました。
段階的に確実に進める
- 大きな統合は一気に行うとリスクが高いです。コストとのトレードオフですが小さく区切ってテストを確実に実装しつつ移行をする事が大事だと思いました。
背景のドキュメント化は重要
- 「なぜマイクロサービス化したのか」、「なぜ統合したのか」の背景を把握する事は大事です。ドキュメントに残しチームに共有してください。

現在、スカウト機能の開発加速に向けてこの統合プロジェクトを進めています。同じような悩みを持つ方の参考になれば幸いです。