メルカリ バックエンド領域のこれまでとこれから

Transcript

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

   View Slide

2. 2
   Camp 4 Engineering Head

   @hidenorigoto (後藤 秀宣)

   

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

15. 15
    基盤領域の強化へ
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

19. 19
    （選考に興味のある方へ）
    

    View Slide

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

    View Slide

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

    View Slide