Mercariのマイクロサービス移行 — モノリスから次世代へ

株式会社メルカリは、フリマアプリのリリースから約十年の間に、Ruby on Railsの巨大なモノリスから、数百の独立した小さなサービスへと基盤を再構築してきました。この移行は一夜で完了したものではなく、数年にわたって段階的に進めてきた長期プロジェクトです。
Mercari has, over roughly the decade since launching its flea-market app, rebuilt its infrastructure from a giant Ruby on Rails monolith into hundreds of small, independent services. This migration was not completed overnight but is a long-term project advanced in phases over multiple years.
出発点:モノリスの限界
初期のメルカリは一つの大きなRailsアプリケーションで出品・取引・決済・メッセージなどを全て処理していました。当初は迅速な開発が可能でしたが、利用者が増えるにつれて、デプロイの頻度が落ち、障害の影響範囲が広がり、新しいメンバーが全体を把握するのも困難になっていったと語られています。
Early Mercari handled listings, transactions, payments, and messaging all within a single large Rails application. Initially this enabled rapid development, but as users grew, deploy frequency dropped, the blast radius of failures widened, and onboarding new engineers to grasp the whole system reportedly became increasingly difficult.
GKEへの移行と基盤の刷新
メルカリは既存のさくらインターネット時代の環境から、Google Cloudの管理Kubernetes(GKE)上に新しいサービスを構築する方針を採りました。Kubernetes上に載せることで、コンテナの配置・自動スケール・障害時の再起動などを宣言的に扱えるようになり、各サービスチームが基盤を気にせずリリースできる状態を目指しました。
Mercari adopted a policy of building new services on Google Cloud's managed Kubernetes (GKE), away from its earlier Sakura Internet–era environment. By running on Kubernetes, container placement, autoscaling, and restart-on-failure could be handled declaratively, aiming for a state where each service team could ship releases without worrying about infrastructure.
サービス間通信:gRPCの採用
内部サービス同士の通信には、当初のJSON over HTTPに代わってgRPCが本格的に採用されました。Protocol Buffersで定義されたスキーマから各言語のクライアント・サーバーコードを自動生成できるため、型安全性と後方互換性を両立しやすいことが評価されています。
For internal service-to-service communication, gRPC was adopted in earnest in place of the original JSON over HTTP. Because client and server code in each language can be auto-generated from schemas defined in Protocol Buffers, gRPC is valued for making it easier to achieve both type safety and backward compatibility.
サービスメッシュ:Istioの役割
サービスの数が増えると、リトライ・タイムアウト・mTLSによる認証・流量制御といった共通関心事を各サービスに実装するのは現実的ではありません。メルカリはIstioを基軸としたサービスメッシュを導入し、これらの機能をサイドカーProxy(Envoy)に委譲することで、アプリケーションコードからネットワーク制御の関心を抽象化しています。
As the number of services grows, it becomes impractical to implement common concerns — retries, timeouts, mTLS-based authentication, traffic control — inside each service. Mercari has introduced a service mesh centered on Istio, delegating these features to sidecar proxies (Envoy) and thereby abstracting network-control concerns away from application code.
分散トレーシングと観測
モノリスでは一つのリクエストの流れは基本的にスタックトレースで追えるのに対し、マイクロサービスでは一つのユーザー操作が十を超えるサービスをまたぐことも珍しくありません。メルカリはOpenTelemetryなどの標準を活用し、分散追跡・メトリクス・ログを統合した観測基盤を整備してきたと公表されています。
Whereas a single request's flow can usually be followed via stack traces in a monolith, in microservices a single user operation often spans more than ten services. Mercari has reportedly built an observability foundation that integrates distributed tracing, metrics, and logs by leveraging standards such as OpenTelemetry.
組織変更:サービスの所有権
技術移行と同じくらい重要だったのが組織改革です。メルカリは「各サービスは一つのチームが所有し、開発から運用・当番まで責任を持つ」というモデルを採用したと語られています。これにより、Platformチームは共通基盤に集中し、プロダクトチームは自分たちの領域で速く動ける体制を整えています。
Equally important to the technical migration was organizational reform. Mercari has reportedly adopted a model in which "each service is owned by one team, which is responsible from development through operations and on-call." Under this structure, the Platform team focuses on common infrastructure while product teams can move quickly within their own domains.
段階的抽出:Strangler Fig パターン
既存モノリスを一気に書き換えるのではなく、新しい機能や切り出しやすい領域から順にサービスを抽出し、API Gatewayでルーティングを切り替えていくStrangler Figパターンが基本戦略とされてきました。既存モノリスと新サービスを並行稼働させ、トラフィックを徐々に移していくことで、リスクを抑えながら移行を進めてきました。
Rather than rewriting the existing monolith all at once, the basic strategy has been the Strangler Fig pattern: extracting services starting from new features or areas easier to carve out, then switching routing at the API Gateway. By running the existing monolith and new services in parallel and gradually shifting traffic, the migration has progressed while keeping risk in check.
データ一貫性という難題
モノリスでは一つのDBトランザクションで済んでいた更新が、サービス分割後は複数サービスをまたぐ一連の操作になります。メルカリではSagaパターンや、最終整合性を前提とした非同期メッセージング、補償トランザクションなどを組み合わせてこの課題に向き合っていると言われています。
Updates that fit in a single DB transaction in the monolith become a series of operations spanning multiple services after splitting. Mercari is reportedly addressing this challenge by combining the Saga pattern, asynchronous messaging premised on eventual consistency, and compensating transactions.
これからの課題
サービス数の増加は、CI/CDパイプラインの複雑化、依存関係の把握困難、インフラコストの肥大化など新たな課題を生みます。メルカリはInternal Developer Platform(IDP)の整備や、Backstageのような開発者ポータル、Policy as Codeによるガバナンスといった手段で、これらと向き合っているとされます。
A growing number of services brings new challenges — increasingly complex CI/CD pipelines, difficulty tracking dependencies, and bloating infrastructure costs. Mercari is reportedly tackling these through means such as building an Internal Developer Platform (IDP), developer portals like Backstage, and governance via Policy as Code.
おわりに
メルカリの事例が示しているのは、マイクロサービスは単なる技術選択ではなく、組織構造・運用文化・データ設計を巻き込んだ全体最適化の取り組みだということです。一つの正解ではなく、組織の成長に合わせた継続的な再設計が求められています。
What Mercari's example shows is that microservices are not merely a technical choice but a whole-system optimization effort that involves organizational structure, operational culture, and data design. There is no single correct answer; continuous redesign aligned with the organization's growth is required.