こんにちは。メルカリでエンジニアリングマネージャーとして働いています@tokkuuです。
この記事は、Mercari Advent Calendar 2025 の12日目の記事です。
今回は、私たちのAds事業が急成長する過程で直面したシステム課題と、それを乗り越えるために立ち上げたプロジェクト「PJ-MARP」について紹介します。
「PJ-MARP」は “Make Ads Robust and Profitable” の略称で、Adsシステムを「堅牢（Robust）」かつ「収益性の高い（Profitable）」状態へと再構築することを目的とした社内プロジェクトです。
急成長する事業の足元を支えるため、技術的負債の解消からインフラ最適化、チーム運営の改善までを横断的に推進しました。
事業の急拡大に伴うシステム負荷の増大、それに伴うコストの増加やインシデントの多発は、多くのプロダクトが通る「成長痛」ではないでしょうか。
本記事では、私たちがどのようにしてシステムの信頼性と収益性を取り戻したのか、技術的なアプローチと組織的な取り組みの両面からご紹介します。
急成長の裏で直面した「壁」
Ads事業はリリース当初から飛躍的に成長していきました。
具体的な数字で言うと、インプレッション数はローンチ前の4倍、コンバージョン数（CV）に至っては5〜10倍という規模にまで拡大しています。
初期フェーズでは、市場探索と仮説検証を最優先し、広告主や代理店が利用したいと思うようなプロダクトへと早く成長させる必要がありました。
このようなスピードと成長を重視する戦略をとった結果、広告在庫が十分に溜まり、アカウント数が増加していき、ビジネスとして順調にスケールしていきました。
しかし、その急成長の裏でシステムでは課題が徐々に露呈していきました。
直面していた3つの課題
特に2024年の年末から2025年の年始にかけて、私たちは以下のような深刻な課題に直面していました。
頻発するインシデント
我々のビジネスの成長が加速したことと相まって、広告業界として盛り上がりを見せる年末にかけてインシデントが多発しました。
インシデントの突発的な対応が増え、対処療法的なスケールアップなどの対応を繰り返し、結果としてチームとして徐々に疲弊していきました。
インフラコストの増大
売上は伸びていましたが、その分それと同じ勢いでクラウド（GCP）の利用費も増大していました。スピードを優先したため非効率にコストがかかっている部分も多く、増えた売上がそのままGCP費用に消えていくような状況になりつつありました。
広告表示機会の損失（Fill-rateの低下）
Fill-rateとは広告リクエストに対して実際に広告を返せた割合のことです。
システム遅延により、タイムアウトが発生し、本来表示できるはずの広告が表示できないケースが増えていました。
具体的には改善前の1月の時点で、Worst caseでは iOSで51%、Androidで26% という危機的な状況でした。
急成長したことによりこのような問題が多発したため、このままでは事業の成長を阻害してしまいます。
そこで私たちは、収益性と堅牢性を確立することを目的としたプロジェクト、PJ-MARPを立ち上げました。
技術的アプローチ：アーキテクチャレベルでの見直し
PJ-MARPでは、単なる対症療法的なバグ修正ではなく、根本的なアーキテクチャの見直しを行いました。リアーキテクチャ前のシステムでは非効率な処理やデータストアのアクセスが多く、処理速度の向上がそのままコスト最適化に結びつくケースが多々ありました。
また、広告においてログはとても重要な役割を持つため、ログを記録するパイプラインやデータストアについてはセンシティブに扱う必要があります。
私たちはこれらの理由から、パフォーマンスとコストの最適化とデータストアとインフラの改善の2つの観点を重点的に対応することにしました。
詳細はこの記事では紹介しませんが、主に効果が高かった施策について簡単に紹介します。
パフォーマンスとコストの最適化
まず着手したのは、リクエスト処理の効率化です。
Cache-chainingの導入
頻繁にアクセスされるデータに対して、多層的なキャッシュ戦略（Cache-chaining）を導入しました。これにより、DBへの直接的なアクセス数を大幅に減らし、レイテンシを短縮しました。
DBへのアクセス数を減らすことで、DB側のコストも削減することができました。
Redisコマンドの最適化
Adsでは検索結果のページング処理の過程で、Redisへ検索セッションのキャッシュを行っています。
このときのアクセスパターンを見直し、非効率なRedis操作コマンド実行を削減しました。
gRPCコールの削減
Adsのシステムは広告を絞り込む過程で様々なマイクロサービス間の通信が発生します。
スピード重視の開発によって整理されていなかったマイクロサービス間の通信においても、Profilerを用いて処理を解析し、不要なgRPCコールを洗い出すことによって、通信オーバーヘッドを削減しました。
データストアとインフラの改善
インシデントの問題となりやすい、データストア周りについても改善を行いました。
BigTableのホットスポット解消
特定のノードに負荷が集中していたBigTableのキー設計を見直し、ホットスポットを解消することでスループットを安定させました。
Elasticsearchのインデックス再構築
Adsではユーザーの検索語句に基づいて広告をマッチングするためにElasticsearchを使用しています。このマッチングパフォーマンスを向上と、オーバーヘッドを減らす目的でインデックスのマッピングやシャード設定を見直し、再構築を行いました。
データパイプラインのリファクタリング
ログ収集やその後の集計処理を行うデータパイプラインを最適化し、遅延・欠損なくデータを処理できる基盤を整えました。
具体的にはDataflow上で動く各ジョブのコードレベル、フローレベルのリファクタリングや、失敗時の対処、モニタリングの強化を行いました。
プロセスと組織：チームをどう動かしたか
これらの多数の取り組みを素早く完了させるために、技術的な修正と同じくらい重要だったのが、徹底的な可視化でした。
システム構造の可視化で現状を正しく捉える
複雑化したシステムを改善するには、まず現状を正しく理解することが欠かせません。
今回のプロジェクトは、Adsチームだけでなく他チームからの協力も多く得ながら進めたため、システム全体の理解を深め、共通認識を持つことが重要でした。
そこで私たちは、時間をかけてアーキテクチャ図や処理フロー図を詳細化することにしました。
あえて非同期で進めず、長い時間を確保してドキュメントを繰り返し更新しながら議論を重ねることで、ステークホルダー全員の認識を丁寧に揃えることを狙いました。
その結果、「現在のシステムがどうなっているのか」「どこがボトルネックなのか」という点について、徹底的に共通理解を築くことができました。
KPIの可視化で改善効果をリアルタイムに把握
また、DataDogやLooker Studioを活用し、主要KPIを継続的にトラッキングできるダッシュボードを構築しました。
これにより、改善施策の効果をリアルタイムに可視化し、意思決定のスピードと精度を高めることができました。
たとえば、「この施策を導入した結果、コストがどれだけ削減されたのか」「Fill-rateがどの程度改善したのか」といった成果を即座に確認できます。
数値として成果が見えることで、チーム全体の達成感や次の改善への意欲が自然と高まり、モチベーション維持にも大きく貢献したと感じています。
成果
PJ-MARPの取り組みの結果、劇的な改善が見られました。
改善前は危機的状況だったFill-rateは、施策適用後の直近1ヶ月では、プラットフォームを問わず 一貫して95%以上の水準 を維持できるようになりました。
またコスト面でも大きな成果が出ました。1月と比べて、3月は約28%のコスト削減を実現しました。
ビジネスの成長を止めずに、利益率を大きく改善することに成功しました。
まとめ
今回のプロジェクトを通じて、私たちは多くの学びを得ました。
- コストダッシュボードは初期に作る: 何かが起きてから見るのではなく、常にモニタリングできる状態にしておくことで、異常検知やトリアージが容易になります。
- キャッシュは最初から考える: パフォーマンス向上のため、特に広告プロダクトのような高トラフィック低レイテンシが求められるシステムでは、キャッシュ機構はサービス開発の初期段階で組み込んでおくのがよいと感じました。
- 定期的な見直しと外部の視点: アーキテクチャは一度作って終わりではなく、効率化のために定期的に見直す必要があります。その際、チーム外のエキスパートの視点を入れることが非常に有効です。
- 本番投入後の再評価: 本番環境での挙動を確認し、設定値を再評価・チューニングするプロセスは考慮しておくべきだと感じました。この再評価とチューニングを継続的に行うことがシステムを堅牢にするうえで重要だと思います。
PJ-MARPを通じて、システムが堅牢になっただけでなく、Adsチームの結束力が強まり、特定の個人のスキルに依存しない体制が整いました。
今後も、システムの信頼性と収益性のバランスを取りながら、Ads事業のさらなる成長を支えていきたいと思います。
明日の記事は @t-hiroiさんです。引き続きお楽しみください。
