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
メルカリ バックエンド領域のこれまでとこれから
Search
hidenorigoto
December 16, 2021
Technology
1
480
メルカリ バックエンド領域のこれまでとこれから
hidenorigoto
December 16, 2021
Tweet
Share
More Decks by hidenorigoto
See All by hidenorigoto
ドメインと向き合う - 旅行予約編
hidenorigoto
4
840
「ソフトウェア設計」のドメイン - 「データモデリングでドメインを駆動する」を読んで
hidenorigoto
9
3k
メルカリのエンジニアリング組織の変化〜Engineering Managerの視点から〜
hidenorigoto
0
8.2k
The changes of the engineering organization in Mercari - from the view of an engineering manager -
hidenorigoto
0
290
PHPerKaigi 2019 ランチセッション (3/31)
hidenorigoto
1
4k
抽象化って何? (What is abstraction?)
hidenorigoto
9
4.5k
抽象化って何? (What is abstraction?)
hidenorigoto
11
6.8k
続・SOLIDの原則ってどんなふうに使うの? 〜オープン・クローズドの原則 センパイのコーディングノート編〜
hidenorigoto
14
6k
SOLIDの原則ってどんなふうに使うの? 〜オープン・クローズドの原則編(拡大版)〜
hidenorigoto
9
5.1k
Other Decks in Technology
See All in Technology
技術者はかっこいいものだ!!~キルラキルから学んだエンジニアの生き方~
masakiokuda
2
260
AIと開発者の共創: エージェント時代におけるAIフレンドリーなDevOpsの実践
bicstone
1
310
OpenSearchでレガシーな検索処理の大幅改善をやってやろう
dznbk
2
170
AI Agentを「期待通り」に動かすために:設計アプローチの模索と現在地
kworkdev
PRO
2
440
20250411_HCCJP_AdaptiveCloudUpdates.pdf
sdosamut
1
110
Рекомендации с нуля: как мы в Lamoda превратили главную страницу в ключевую точку входа для персонализированного шоппинга. Данил Комаров, Data Scientist, Lamoda Tech
lamodatech
0
710
プロダクト開発におけるAI時代の開発生産性
shnjtk
2
240
JPOUG Tech Talk #12 UNDO Tablespace Reintroduction
nori_shinoda
2
140
LangfuseでAIエージェントの 可観測性を高めよう!/Enhancing AI Agent Observability with Langfuse!
jnymyk
1
220
クラウド開発環境Cloud Workstationsの紹介
yunosukey
0
140
似たような課題が何度も蘇ってくるゾンビふりかえりを撲滅するため、ふりかえりのテーマをフォーカスしてもらった話 / focusing on the theme
naitosatoshi
0
460
Spring Bootで実装とインフラをこれでもかと分離するための試み
shintanimoto
7
810
Featured
See All Featured
Building a Scalable Design System with Sketch
lauravandoore
462
33k
KATA
mclloyd
29
14k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
233
17k
What’s in a name? Adding method to the madness
productmarketing
PRO
22
3.4k
Six Lessons from altMBA
skipperchong
27
3.7k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
119
51k
Automating Front-end Workflow
addyosmani
1369
200k
Code Review Best Practice
trishagee
67
18k
It's Worth the Effort
3n
184
28k
Site-Speed That Sticks
csswizardry
5
490
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
Designing Experiences People Love
moore
141
24k
Transcript
1 メルカリ バックエンド基盤領域の これまでとこれから Mercari JP Camp 4 Engineering Head
@hidenorigoto 2021/12/16
2 Camp 4 Engineering Head @hidenorigoto (後藤 秀宣)
3 Agenda • メルカリバックエンドにおけるマイクロサービス化のこれまで • 基盤領域の強化へ
4 メルカリ バックエンドにおける マイクロサービス化のこれまで
5 当初の戦術 立ち上げ期(2018年) • 出品を受け付けるエンドポイントをマイクロサービス化 ◦ 背後にいくつかの基本的なマイクロサービスが必要(ユーザー、アイテム) • メルペイローンチ時に、メルペイから利用される機能のマイクロサービス化(通 知、ユーザー)
全チームでマイグレーション期(2019年〜) • エンドポイント単位、アクセス数の多いエンドポイントを優先 ◦ アクセス数が多い≒大きな価値を提供しており、今後も改善を行っていく可能性が見込める
6 • 物理的な距離 ◦ モノリス環境(プロダクションの DB含む)はさくらインターネットの石狩 DC。マイクロサービス環 境はGCP東京。距離1100km(レイテンシ>100ms) ◦ この状況のため、マイクロサービス側とモノリス側の依存関係を一方向にし、通信が往復しない
ようにする必要があった。採りうるマイグレーション戦略が絞られる。 初期の制約 モノリス側環境を東京へ寄せるインフラ移行プロジェクトを実施 → 現在は モノリスアプリ( GCE)+DB(東京のDC) → 2022年初期に、モノリスアプリは GKEへ移行。実行環境がモダン化 メルカリのマイクロサービス移行の進捗 (2019年冬) モノリスとマイクロサービス間でのコールが容易に。
7 例 • 出品機能 • 通知(アプリ内のお知らせ、プライベートメッセージなど) • 検索、ホーム画面バックエンド • 商品詳細、商品コメント、商品イイネ
マイクロサービス化が比較的上手くいっている領域
8 例 • 取引(購入〜発送〜評価までの一連のフロー) • 発送機能 • 出品アイテム管理(データに近いレイヤー) • ユーザー管理(データに近いレイヤー)
マイクロサービス化が道半ばになっている領域
9 領域による違い マーケットプレイスのグロース 安心・確実な取引 会員登録 検索 決済 アダプタ 商品閲覧 出品
通知 発送 評価 取引 アプリケーション全体から利用 アイテム ユーザー 認証 認可 1リソース書き込み 参照メイン 独立した関心 渾然一体 メルカリにおけるマイクロサービスマイグレーションの理想と現実
10 • 100%モノリスのまま • 密結合の中心にいる(出品アイテム、決済、発送、評価) ◦ 他の機能をとりまとめながら、状態遷移を管理する機能 ◦ とりまとめる先の機能は、それぞれ複雑度が高い 道半ばな状況
- 取引 「1つの取引では、1人の出品者の1つのアイテムを、1人の購入者と取引する」 → メルカリが生まれた時からある機能。当初の方針として正しかった(ビジネスは成長) → 想定していなかった要求と実装が、設計の限界を大きく超えてなされた 設計がプラクティカル=必要なことだけやる方針 WHY
11 • 提携先(ヤマト、日本郵便)と連携する部分などがマイクロサービスになっている • 取引機能と密接に連携しているロジックはモノリスのまま • 主要なデータもモノリスのMySQLのまま 道半ばな状況 - 発送
「メルカリの、取引機能の中での、発送機能」として開発されてきた → 当時のサービスとしては、必要最低限の前提。サードパーティとの提携含め、確実に 成果を挙げてきた → さまざまな発送オプションへと横展開される中で、複雑度、取引との結合度増大 設計がプラクティカル=必要なことだけやる方針 WHY
12 • テーブルへのデータアクセス部分、および状態遷移のバリデーションなど基本的 なロジックがマイクロサービスになっている • ストレージはモノリス時代のMySQLのまま • テーブルに、アイテムの基本情報、集計情報とが混在 • モノリス内の多数のビジネスロジックから参照。一部書き込みも。
• データ量およびDBアクセスは、メルカリ内随一 道半ばな状況 - 出品アイテム管理 モノリスにおけるアクティブレコード利用の規律不足 WHY
13 • テーブルへのデータアクセス部分のみがマイクロサービスになっている • ストレージはモノリス時代のMySQLのまま • テーブルに、ユーザー情報、認証情報、集計情報とが混在 • モノリス内の多数のビジネスロジックから参照。一部書き込みも。 道半ばな状況
- ユーザー管理 モノリスにおけるアクティブレコード利用の規律不足 WHY
14 マイクロサービス化自体がゴー ルなんだっけ? メルカリの状況で、本当に必要な ことは何?
15 基盤領域の強化へ
16 • マイクロサービス化を考える以前の問題と向き合う ◦ モノリス+アクティブレコード式 ORMで生じたツラミ ◦ 仕様面での抽象化、再利用性の検討不足 • 会社のフェーズの変化に適応する
◦ 1つのビジネスの立ち上げ〜成長 ← 再利用性よりもとにかく高速な PDCA、必要なことだけや る ◦ 複数事業への投資 ← メンテナンスとスピードのバランス、既存アセットの活用 どのような戦い方が必要か
17 • 世の中の多くの先輩企業と同様に、メルカリも基盤を整えるフェーズ ◦ ここでいう基盤は、アプリケーションの開発・実行基盤(インフラ)ではなく、汎用性・再利用性の あるビジネスロジックを指す ◦ なお、開発・実行基盤側(マイクロサービスプラットフォーム)は非常によく整備された • 再利用性・汎用性・安定性へ
• モノリスも、ROIに応じて積極的に改善 ◦ 段階的にモジュラー化(モジュラーモノリス化) 基盤強化 - Robust Foundation for Speed
18 • アイテム管理チーム • 取引機能チーム 本日のピックアップ(この後の話)
19 (選考に興味のある方へ)
20 • 理想と現実のギャップにワクワクでき、1歩でも前に進める推進力 • 理想状態は不確定で、状況に応じて常にアップデートをかけられる適応力 • 複雑な仕様をときほぐし、必要なレベルの抽象によって物事をシンプルにできる 設計力 • 大規模なコードベースに立ち向かうための知識・実践両面でのソフトウェアエン
ジニアリング力 エンジニアに求めたいこと ソフトウェアエンジニアリングとは 時間で積分したプログラミングである
21 • Meety ◦ https://meety.net/matches/pjTdJYwOJlUW 直接お話させてください