Tweet
Tweet

Slide 1

Slide 1 text

Real World Mercari API Architecture Bonfire API#1 Masahiro Sano (@kazegusuri)

Slide 2

Slide 2 text

自己紹介 • 佐野 正浩(@kazegusuri) • Mercari, Inc → Souzoh, Inc → merpay, Inc • Principal Software Engineer • サーバーサイドエンジニア • Goで決済システム全般を開発中 2

Slide 3

Slide 3 text

3

Slide 4

Slide 4 text

昨年末のMercari Advent Calendar 2017の 記事中にあった 「ソースコードのフォーク」 についてお話します 4

Slide 5

Slide 5 text

アーキテクチャ(~2016/12) 5 Monolithic API Monolithic API UK JP US Mercari Client Mercari Client Atte API Atte Client 1 ソースコード 1 ソースコード

Slide 6

Slide 6 text

クライアントフォーク(2016/12) • アプリのソースコードをJP/US/UKでフォーク • リージョン固有の実装が複雑化 • テスト不足・QAの過負荷 • UKスタート • US First 6

Slide 7

Slide 7 text

USアプリ刷新(2016/12) • フルスクラッチで開発 • Protobuf導入 • Microservice化に向けてAPI Gateway導入 • 株式会社メルカリの導入事例：Kubernetes を駆使したマイクロサービス化 でグローバルサービスの開発効率を劇的に向上 • https://goo.gl/xcP4bb 7

Slide 8

Slide 8 text

アーキテクチャ(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 ソースコード

Slide 9

Slide 9 text

続々リリース (2017/3-5) • 2017/3 UK アプリリリース • 2017/4 US 新アプリ一本化 • Microserviceの本格導入 • 2017/5 JP メルカリカウルリリース 9

Slide 10

Slide 10 text

アーキテクチャ(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

Slide 11

Slide 11 text

APIフォークの検討 • 増えてくるJPのアプリ • 構成の異なるUS/UK • メルペイに向けてのアーキテクチャ変更 • 2017/10 APIフォーク 11

Slide 12

Slide 12 text

アーキテクチャ(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

Slide 13

Slide 13 text

APIフォークの理由 • APIのコード的な側面 • 組織的な側面 • Microservice化へのアプローチの違い 13

Slide 14

Slide 14 text

APIのコード的な側面 • リージョン毎にやっていることが違いすぎる • API側で違いを吸収する必要がなくなってきた • リージョン毎に独立したエンドポイント • 修正したときに全アプリでQAするのが大変 14

Slide 15

Slide 15 text

組織的な側面 • 日本からUS開発の割合の変化 • 新アプリ化の時期で50:50 • US開発の現地化 • お互いが独立して異なる目的で同じソースを触る 15

Slide 16

Slide 16 text

Microservice化へのアプローチの違い • JPでは既存機能の共通化、プラットフォーム化が重要 • 既存機能のMicroservice化 • USでは新規機能をどんどん試していく • 新規機能をMicroservice化 • 既存機能はあまり変更しない 16

Slide 17

Slide 17 text

APIフォーク後 • フォークしたことでリージョン間の問題は解決 • ついでにソースコードは驚く程わかりやすく… • JPでの開発が進んだことで同じ問題がJP内でも • ソウゾウのプロダクト • Nowやメルカリチャンネルなどの新領域 • メルペイ 17

Slide 18

Slide 18 text

未来に向けて • JPでもAPI Gatewayの導入(予定) • Microservice化の推進 • 異なるチームで同一システムを開発するのは難しい(個 人的感想) • Microserviceでチームで閉じた開発体制 • システムの複雑化→運用の複雑化 • Microservice基盤の整理 • Kubernetes • CI/CD • Metrics/Tracing/Monitoring 18