Okayama 2026
メルカリの Microservice は
何がうまくいって、
何がうまくいかなかったか？
@sinmetal
Agenda
今日話すこと
History
メルカリのインフラの歴史
最初はモノリスとして開発され、インフラはオンプレだった。
そして、モノリスで限界が来た
📅 リリースカレンダーの混雑
1 つのアプリケーションに全員の変更が乗るため、リリースの順番待ちが発生。
🗄️ CoreDB の限界
CoreDB と呼ばれている超巨大な MySQL が限界を迎えつつあった。
👥 全員が同じ Repository
どんどん増えていくエンジニア全員が、同じ Repository を編集する。
Microservice
2017 年、Microservice へ
アーキテクチャを Microservice に変更していくぞ！
組織もそれに合わせて変革していくぞ！と始まった。
メルカリが Microservice 化を開始
sinmetal がソウゾウに入社
sinmetal がメルペイに異動
💬 Microservice を作り始めた時から、sinmetal はなんとなーく横目で見ていた
Microservice
サービス毎のチームと Platform Team
サービス毎にチームを構成
各チームが自分たちの Microservice の開発と運用を行う。
Microservice Platform Team の誕生
Google Cloud を利用して各チームが完全に自由にやるというのは無理があるので、共通基盤を提供するチームが生まれた。
Microservice / Architecture
メルカリの Microservice
アプリケーションは 1 つの GKE Cluster にすべて Deploy
DB などのリソースは各 Microservice の Project にある
Shared VPC
VPC は共有。Cloud SQL など VPC が必要なものはそこに繋ぐ。
echo-jp
テンプレートを fork して各 Microservice が作られていった。
Go
基本的には全部 Go で書かれている。
gRPC
各 Microservice は gRPC で Protobuf をやり取りする。
Microservice / mk & mp
mk の Microservice と mp の Microservice
グループ全体のアーキテクチャは同一だが、組織によって事情が異なる部分がある。
mk
PHP の巨大なモノリスから少しずつ切り出し- DB も切り出されて、様々な状態が混在
Cloud SQL (MySQL) Spanner へ移行 CoreDB のまま
Problems
色んな運用。色んな問題。
Microservice を作りすぎた
新たに作るのは楽だが、削除ができなかった。エンジニアの数より Microservice の数の方が多くなった。
作り方が微妙に違う
どの世代の echo-jp から作られたのか？別の Microservice を参考に作られたのか？開発・Deploy の仕方もみんな少しずつ違う。
改善が全体に届かない
改善を入れても、すべての Microservice に適用するには多大なコストが必要になった。
運用の手間だけが残る
ビジネス的に機能改修がない Microservice は、運用の手間だけが残った。
専門家は各チームにいない
DB や Google Cloud に詳しい人が各 Microservice のチームにいるわけではない。
エンジニアは無限ではない
エンジニアも無限には採用しなかった。運用負荷は増大していく。
Problems / Too Many Microservices
増え続けた Microservice
- 新しい機能を作る度に、どんどん Microservice が増えていった
- そして、消されることはなかった
⚠️ オンコールの負担も増大。オンコールを1 人でやっている状態になっている Microservice も・・・。
🍕 ツー・ピザ・ルール（およそ 5〜10 人）どころか、1 人で 2 枚ピザ食べることになってる。
Problems / Distributed Monolith
開発も徐々に遅くなっていった
⭕ Microservice の良いところ
それぞれの Microservice を別々に開発できる。
❌ 実際に起きたこと
新しい機能を作る時に改修が必要な Microservice が徐々に増えていき、結局たくさんの人が同調して動かないと機能開発できなくなっていった。
🤔 オレたちが作ったのは Microservice だったのか、分散モノリスだったのか・・・。
Countermeasure / Too Many Microservices
対抗策: チームを合体してオンコール
複数のチームが合体して、複数の Microservice のオンコールを一緒に行う体制になった。
- オンコールはこの中で回す
- 開発はミックスしつつも、ある程度分かれた状態で行う
3 人ぐらいのチームが 3 つ合体すれば、10 人近い人数になる
Problems / Operations
運用負荷の増大: マイグレーションが終わらない
Platform Team が新しい Tool を作っても、各 Microservice Team は移行するモチベーションがなく、移行が進まない。（簡単に移行できるわけでもない）
📚 ライブラリの UPDATE
すべての Microservice で、それぞれ UPDATE していく必要がある。
🚚 運用ツールの移行
CI/CD Tool は変わっていったが、3 世代全部残っている。
Countermeasure / Operations
対抗策: 共通フレームワークとモノレポ
🚝 共通のフレームワーク monorail
アプリケーション側の自由度を減らし、以下を統一しようとしている。
既存の Microservice をこの仕組みの上に乗せるのは結構大変なので、じわーっと進めている。
📁 モノレポにしていくことを画策
共通部分を統一するに当たって、同じ Git Repository の方がやりやすそうだという気持ちになった。
全 Microservice が完全にばらばらの Repository ではなく、ある程度まとめていこうとしている。
例えば、go.mod を 1 つにするとか
Problems / Google Cloud
DB や Google Cloud の使い方の課題
- みんな結構適当に使っている
- DB や Google Cloud に詳しい人が、各 Microservice のチームにいるわけではない
💸 予算の概念が雑なので、アプリケーション側の作りが悪かったとしても、クラウド側のリソースを強化して対処してしまう。
Countermeasure / Google Cloud
対抗策: sinmetal が自分で全部 PR を作る・・・
- AI パワーで、よく知らない Repository でも気合で PR を作れるようになった
- なので、sinmetal が頑張る！！！となった
ただ、これはスケールしないので、教育コンテンツも合わせて作らねばなと思っている。
Problems / Batch Job
色んな作り方の Batch Job
- API は echo-jp からの派生なので、なんとなくは同じような作りになっている
- しかし Batch Job には何もなかったので、各々が作っている
動作の仕方から Deploy の仕方、監視の仕方まで、全部ばらばら。
Countermeasure / Batch Job
対抗策: まだ、無い。
- Batch Job はパターンが多い
- monorail もサポートしていない
なので、宙に浮いている。
😵 Batch Job は DB に負荷をかけていることが多く、sinmetal を悩ませている。
🙋 誰かいいアイディアないですか？
Problems / Architecture
効率の悪いアーキテクチャ
- データ連携 Batch みたいなのが多すぎる・・・
- なんでもかんでも分散してて、後で別途集約している
- データの重複も多いので、ストレージ効率も悪い
🤔 そんなにデータ連携したいのなら、もう同じ Microservice になればよいのでは・・・？
Countermeasure / Architecture
対抗策: DB も含めて統廃合
- DB も含めて、Microservice を統廃合していく必要がある
ダウンタイム無しでの DB 統合は一瞬ではできないので、地道にやっていく必要がある。
Modular Monolith
Modular Monolith へ
新しく構築された Global One Product と呼ばれているアプリケーションは、Modular Monolith で構築されることになった。
中間ぐらい
モノリスと Microservice の中間ぐらい。
モノレポ
モノレポで構築している。
Modular Monolith / Global One Product
Global One Product の思想と DB
🧵 Service Weaver のような思想
アーキテクチャの思想としては Service Weaver のような感じ。
ただし Service Weaver は開発が終わっているので、使ってはいない。
🐘 AlloyDB を採用
Global One Product では AlloyDB を採用している。
Existing Microservices
既存の Microservice たちをどうするか？
Modular Monolith に移行するのは簡単ではない
作りを揃えながら、少しずつ統廃合していくことになりそうだ
Existing Microservices
どのぐらいの単位で Modular Monolith にする？
どのぐらいの単位で 1 つの Modular Monolith にしていくかは決まっていない。
mk と mp は少なくとも別だろう
mp 内でも 1 つになるのは、でかすぎる気も
🤔 決済や会計を司る Core で 1 つと、それ以外みたいな感じだろうか・・・？
Existing Microservices
モノリスもまだ残っているので、3 世代運用に・・・
モノリス
まだ残っている
Microservice
大量に存在する
Modular Monolith
Global One Product
なんとか運用もしつつ、移行を進めていかなければ・・・。
CoreDB / TiDB
CoreDB は TiDB で延命を
超巨大な MySQL である CoreDB は、TiDB に気合で移行された。https://www.youtube.com/watch?v=aORW_AlCV-M
⭕ 移行がやりやすかった
TiDB は MySQL と同じインターフェースを持つため、移行がやりやすかった。
⚠️ それでも中身は別物
TiDB は分散 DB なので、中身のアーキテクチャは全く違う。Query のチューニングなどは必要だった。
🔁 MySQL で実行されている Query を Copy して TiDB 側でも実行し、Latency を確認しながら Query をチューニングしていった。
ただ、ずっと TiDB を使い続けたいわけではない。運用も大変なので、少しずつ移行して最終的には無くしたい。
Okayama 2026
Thank you!
@sinmetal
DevFest Okayama 2026 | メルカリの Microservice は何がうまくいって、何がうまくいかなかったか？