Slide 1

Slide 1 text

1 メルカリ バックエンド基盤領域の これまでとこれから Mercari JP Camp 4 Engineering Head @hidenorigoto 2021/12/16

Slide 2

Slide 2 text

2 Camp 4 Engineering Head
 @hidenorigoto (後藤 秀宣)


Slide 3

Slide 3 text

3 Agenda ● メルカリバックエンドにおけるマイクロサービス化のこれまで ● 基盤領域の強化へ

Slide 4

Slide 4 text

4 メルカリ バックエンドにおける マイクロサービス化のこれまで

Slide 5

Slide 5 text

5 当初の戦術 立ち上げ期(2018年) ● 出品を受け付けるエンドポイントをマイクロサービス化 ○ 背後にいくつかの基本的なマイクロサービスが必要(ユーザー、アイテム) ● メルペイローンチ時に、メルペイから利用される機能のマイクロサービス化(通 知、ユーザー) 全チームでマイグレーション期(2019年〜) ● エンドポイント単位、アクセス数の多いエンドポイントを優先 ○ アクセス数が多い≒大きな価値を提供しており、今後も改善を行っていく可能性が見込める

Slide 6

Slide 6 text

6 ● 物理的な距離 ○ モノリス環境(プロダクションの DB含む)はさくらインターネットの石狩 DC。マイクロサービス環 境はGCP東京。距離1100km(レイテンシ>100ms) ○ この状況のため、マイクロサービス側とモノリス側の依存関係を一方向にし、通信が往復しない ようにする必要があった。採りうるマイグレーション戦略が絞られる。 初期の制約 モノリス側環境を東京へ寄せるインフラ移行プロジェクトを実施 → 現在は モノリスアプリ( GCE)+DB(東京のDC) → 2022年初期に、モノリスアプリは GKEへ移行。実行環境がモダン化 メルカリのマイクロサービス移行の進捗 (2019年冬) モノリスとマイクロサービス間でのコールが容易に。

Slide 7

Slide 7 text

7 例 ● 出品機能 ● 通知(アプリ内のお知らせ、プライベートメッセージなど) ● 検索、ホーム画面バックエンド ● 商品詳細、商品コメント、商品イイネ マイクロサービス化が比較的上手くいっている領域

Slide 8

Slide 8 text

8 例 ● 取引(購入〜発送〜評価までの一連のフロー) ● 発送機能 ● 出品アイテム管理(データに近いレイヤー) ● ユーザー管理(データに近いレイヤー) マイクロサービス化が道半ばになっている領域

Slide 9

Slide 9 text

9 領域による違い マーケットプレイスのグロース 安心・確実な取引 会員登録 検索 決済 アダプタ 商品閲覧 出品 通知 発送 評価 取引 アプリケーション全体から利用 アイテム ユーザー 認証 認可 1リソース書き込み 参照メイン 独立した関心 渾然一体 メルカリにおけるマイクロサービスマイグレーションの理想と現実

Slide 10

Slide 10 text

10 ● 100%モノリスのまま ● 密結合の中心にいる(出品アイテム、決済、発送、評価) ○ 他の機能をとりまとめながら、状態遷移を管理する機能 ○ とりまとめる先の機能は、それぞれ複雑度が高い 道半ばな状況 - 取引 「1つの取引では、1人の出品者の1つのアイテムを、1人の購入者と取引する」 → メルカリが生まれた時からある機能。当初の方針として正しかった(ビジネスは成長) → 想定していなかった要求と実装が、設計の限界を大きく超えてなされた 設計がプラクティカル=必要なことだけやる方針 WHY

Slide 11

Slide 11 text

11 ● 提携先(ヤマト、日本郵便)と連携する部分などがマイクロサービスになっている ● 取引機能と密接に連携しているロジックはモノリスのまま ● 主要なデータもモノリスのMySQLのまま 道半ばな状況 - 発送 「メルカリの、取引機能の中での、発送機能」として開発されてきた → 当時のサービスとしては、必要最低限の前提。サードパーティとの提携含め、確実に 成果を挙げてきた → さまざまな発送オプションへと横展開される中で、複雑度、取引との結合度増大 設計がプラクティカル=必要なことだけやる方針 WHY

Slide 12

Slide 12 text

12 ● テーブルへのデータアクセス部分、および状態遷移のバリデーションなど基本的 なロジックがマイクロサービスになっている ● ストレージはモノリス時代のMySQLのまま ● テーブルに、アイテムの基本情報、集計情報とが混在 ● モノリス内の多数のビジネスロジックから参照。一部書き込みも。 ● データ量およびDBアクセスは、メルカリ内随一 道半ばな状況 - 出品アイテム管理 モノリスにおけるアクティブレコード利用の規律不足 WHY

Slide 13

Slide 13 text

13 ● テーブルへのデータアクセス部分のみがマイクロサービスになっている ● ストレージはモノリス時代のMySQLのまま ● テーブルに、ユーザー情報、認証情報、集計情報とが混在 ● モノリス内の多数のビジネスロジックから参照。一部書き込みも。 道半ばな状況 - ユーザー管理 モノリスにおけるアクティブレコード利用の規律不足 WHY

Slide 14

Slide 14 text

14 マイクロサービス化自体がゴー ルなんだっけ? メルカリの状況で、本当に必要な ことは何?

Slide 15

Slide 15 text

15 基盤領域の強化へ

Slide 16

Slide 16 text

16 ● マイクロサービス化を考える以前の問題と向き合う ○ モノリス+アクティブレコード式 ORMで生じたツラミ ○ 仕様面での抽象化、再利用性の検討不足 ● 会社のフェーズの変化に適応する ○ 1つのビジネスの立ち上げ〜成長  ← 再利用性よりもとにかく高速な PDCA、必要なことだけや る ○ 複数事業への投資  ← メンテナンスとスピードのバランス、既存アセットの活用 どのような戦い方が必要か

Slide 17

Slide 17 text

17 ● 世の中の多くの先輩企業と同様に、メルカリも基盤を整えるフェーズ ○ ここでいう基盤は、アプリケーションの開発・実行基盤(インフラ)ではなく、汎用性・再利用性の あるビジネスロジックを指す ○ なお、開発・実行基盤側(マイクロサービスプラットフォーム)は非常によく整備された ● 再利用性・汎用性・安定性へ ● モノリスも、ROIに応じて積極的に改善 ○ 段階的にモジュラー化(モジュラーモノリス化) 基盤強化 - Robust Foundation for Speed

Slide 18

Slide 18 text

18 ● アイテム管理チーム ● 取引機能チーム 本日のピックアップ(この後の話)

Slide 19

Slide 19 text

19 (選考に興味のある方へ)

Slide 20

Slide 20 text

20 ● 理想と現実のギャップにワクワクでき、1歩でも前に進める推進力 ● 理想状態は不確定で、状況に応じて常にアップデートをかけられる適応力 ● 複雑な仕様をときほぐし、必要なレベルの抽象によって物事をシンプルにできる 設計力 ● 大規模なコードベースに立ち向かうための知識・実践両面でのソフトウェアエン ジニアリング力 エンジニアに求めたいこと ソフトウェアエンジニアリングとは 時間で積分したプログラミングである

Slide 21

Slide 21 text

21 ● Meety ○ https://meety.net/matches/pjTdJYwOJlUW 直接お話させてください