Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Real World Mercari API Architecture
Search
kazegusuri
February 01, 2018
Technology
6.4k
1
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
Real World Mercari API Architecture
Bonfire API #1
kazegusuri
February 01, 2018
More Decks by kazegusuri
See All by kazegusuri
go-sqlite3を使ってCloud Spannerエミュレーターを作ってみた / Cloud Spanner emulator with go-sqlite3
kazegusuri
5
6.8k
handy-spanner GCPUG
kazegusuri
4
2.1k
Open SKT: メルペイ開発の裏側 / builderscon tokyo 2019 Open SKT
kazegusuri
22
28k
Keep watching and extending features of gRPC
kazegusuri
3
2.7k
Testing with microservices in merpay
kazegusuri
10
11k
gRPC and REST with gRPC in practice
kazegusuri
19
8.2k
Fluentdで始めるPrometheus / Prometheus Tokyo Meetup #1
kazegusuri
1
2k
GRPCの実践と現状での利点欠点 / Go Conference 2016 Spring
kazegusuri
44
32k
OutputとBufferedOutputの間の何か
kazegusuri
2
3.5k
Other Decks in Technology
See All in Technology
オブザーバビリティ、本当に活用できてる? 〜API連携×生成AIで成熟度を自動評価〜
dmmsre
1
3.4k
生成AI×AWS CDK×AWS FISで"振り返れる"ミニGameDayをつくろう
yoshimi0227
1
270
Devsumi 2026 Summer 人もAIも使える共通基盤を事業の加速装置にする~デザインシステム運用に学ぶ組織レバレッジ~ 渡辺 凌央
legalontechnologies
PRO
1
200
ポストモーテム! DDoSからサイトは守れた。 でもビジネスは守れなかった。
bengo4com
1
3.2k
世界、断片、モデル。そして理解
ardbeg1958
1
130
ZOZOTOWNの進化と信頼性を両立する負荷試験
zozotech
PRO
2
170
Oracle Base Database Service 技術詳細
oracle4engineer
PRO
15
110k
そのドキュメント、自動化しませんか?
yuksew
1
240
「早く出す」より「事業に効く」 ── 顧客の業務サイクルから逆算するAI時代の二重ループ開発と「変化の設計者」 / devsumi2026
rakus_dev
1
320
ruby.wasmとPicoRuby.wasmに対応した仮想DOMライブラリを作ってる話 #kaigieffect_kaigi
sue445
PRO
0
150
インフラと開発の垣根を超えていき!〜元AWSインフラエンジニアがAWS開発で奮闘している話〜
hatahata021
3
290
SREとQA 二人三脚で進めるSLO運用/sre-qa-slo
sugitak
0
730
Featured
See All Featured
We Are The Robots
honzajavorek
0
280
Ruling the World: When Life Gets Gamed
codingconduct
0
280
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
35
2.5k
DBのスキルで生き残る技術 - AI時代におけるテーブル設計の勘所
soudai
PRO
67
56k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
31
10k
Future Trends and Review - Lecture 12 - Web Technologies (1019888BNR)
signer
PRO
0
3.6k
Everyday Curiosity
cassininazir
0
250
JAMstack: Web Apps at Ludicrous Speed - All Things Open 2022
reverentgeek
1
490
Lightning talk: Run Django tests with GitHub Actions
sabderemane
0
220
Build your cross-platform service in a week with App Engine
jlugia
234
18k
Evolving SEO for Evolving Search Engines
ryanjones
0
240
Money Talks: Using Revenue to Get Sh*t Done
nikkihalliwell
0
380
Transcript
Real World Mercari API Architecture Bonfire API#1 Masahiro Sano (@kazegusuri)
自己紹介 • 佐野 正浩(@kazegusuri) • Mercari, Inc → Souzoh, Inc
→ merpay, Inc • Principal Software Engineer • サーバーサイドエンジニア • Goで決済システム全般を開発中 2
3
昨年末のMercari Advent Calendar 2017の 記事中にあった 「ソースコードのフォーク」 についてお話します 4
アーキテクチャ(~2016/12) 5 Monolithic API Monolithic API UK JP US Mercari
Client Mercari Client Atte API Atte Client 1 ソースコード 1 ソースコード
クライアントフォーク(2016/12) • アプリのソースコードをJP/US/UKでフォーク • リージョン固有の実装が複雑化 • テスト不足・QAの過負荷 • UKスタート •
US First 6
USアプリ刷新(2016/12) • フルスクラッチで開発 • Protobuf導入 • Microservice化に向けてAPI Gateway導入 • 株式会社メルカリの導入事例:Kubernetes
を駆使したマイクロサービス化 でグローバルサービスの開発効率を劇的に向上 • https://goo.gl/xcP4bb 7
アーキテクチャ(2016/12) 8 Monolithic API Monolithic API Monolithic API UK JP
US Mercari Client Mercari Client Mercari Client New Mercari Client API Gateway Atte API Atte Client 1 ソースコード
続々リリース (2017/3-5) • 2017/3 UK アプリリリース • 2017/4 US 新アプリ一本化
• Microserviceの本格導入 • 2017/5 JP メルカリカウルリリース 9
アーキテクチャ(2017/5) 10 Monolithic API Monolithic API Monolithic API UK JP
US Mercari Client Mercari Client New Mercari Client API Gateway Atte API Atte Client 1 ソースコード Kauru API Kauru Client Microservice
APIフォークの検討 • 増えてくるJPのアプリ • 構成の異なるUS/UK • メルペイに向けてのアーキテクチャ変更 • 2017/10 APIフォーク
11
アーキテクチャ(2017/10~) 12 Monolith ic API Monolithic API Monolithic API UK
JP US Mercari Client Mercari Client New Mercari Client API Gateway Atte API Kauru API MS MS MS MS MS Maisonz API MS MS MS Souzoh merpay MS MS MS
APIフォークの理由 • APIのコード的な側面 • 組織的な側面 • Microservice化へのアプローチの違い 13
APIのコード的な側面 • リージョン毎にやっていることが違いすぎる • API側で違いを吸収する必要がなくなってきた • リージョン毎に独立したエンドポイント • 修正したときに全アプリでQAするのが大変 14
組織的な側面 • 日本からUS開発の割合の変化 • 新アプリ化の時期で50:50 • US開発の現地化 • お互いが独立して異なる目的で同じソースを触る 15
Microservice化へのアプローチの違い • JPでは既存機能の共通化、プラットフォーム化が重要 • 既存機能のMicroservice化 • USでは新規機能をどんどん試していく • 新規機能をMicroservice化 •
既存機能はあまり変更しない 16
APIフォーク後 • フォークしたことでリージョン間の問題は解決 • ついでにソースコードは驚く程わかりやすく… • JPでの開発が進んだことで同じ問題がJP内でも • ソウゾウのプロダクト •
Nowやメルカリチャンネルなどの新領域 • メルペイ 17
未来に向けて • JPでもAPI Gatewayの導入(予定) • Microservice化の推進 • 異なるチームで同一システムを開発するのは難しい(個 人的感想) •
Microserviceでチームで閉じた開発体制 • システムの複雑化→運用の複雑化 • Microservice基盤の整理 • Kubernetes • CI/CD • Metrics/Tracing/Monitoring 18