Road to migrate JP Web as a microservice

Road to migrate JP Web as a microservice

Mercari Tech Meetup #1 〜 Microservices 始めました! 〜 にて発表しました

https://techplay.jp/event/687031

046baac588d91fd78a85b189847a151d?s=128

Sota Sugiura

August 06, 2018
Tweet

Transcript

  1. Road to migrate JP web as microservices @sota1235 2018/8/6 Mercari

    Tech Meetup #1
  2. console.log(me); • Sota Sugiura(きりん) • @sota1235 • Web Rearchitect, Tech

    Lead • 将来の夢はJavaScript になることです
  3. Webの話をします

  4. Agenda • メルカリWebについて • JP Web Rearchitectについて • Rearchitectの道のり

  5. メルカリWebについて

  6. おかげさまで5周年 https://about.mercari.com/press/news/article/20180702_mercarinumbers/

  7. ⼀⽅のWeb https://speakerdeck.com/yuisakamoto/apurihuasutofalseying-dewan-zhang-ruwebfalsehua

  8. これまでのメルカリの事業 • ⾮連続な成⻑のための開発スピード • スマートフォンで売る/買うという体験 • 選択と集中による開発リソースの配分

  9. これまでのメルカリWeb • 新たな顧客層へのサービス提供 • SNSシェアやSEO等、Webへの展開 • ⼀部、WebViewとブラウザで両⽴するページ の展開

  10. 現状のメルカリWebの課題

  11. アプリとの機能差分 アーキテクチャ

  12. アプリとの機能差分 アーキテクチャ アプリとの機能差分

  13. アプリとの機能差 • Webは必要最低限の機能のみ実装されている • 購⼊/出品/検索 • いくつかの機能はアプリへ誘導している • 配送機能(⼀部)、オファー、フォロー etc…

  14. 全部コピー、が正解ではない • アプリ、Webそれぞれ良さがある • Webで活きるものは実装したい • 逆にWebだけの機能があってもいい

  15. アプリとの機能差分 アーキテクチャ アーキテクチャ

  16. アーキテクチャ • Monolithicな構成になっている • フロントエンドエンジニアが触りづらい • BackendのMicroservices化についていくのが 難しい

  17. アーキテクチャ • dietcube(hosted by PHP 7.1) • jQuery • React

    • ⼤抵のviewはTwigでrenderingされる
  18. このままでよいのか

  19. よくない • Webもメルカリの重要なファクター • ブラウザ上でのお客さまの体験の最適化 • AMP化によるアクセスの爆増や細かい改修に よる売上の向上等、まだまだポテンシャルを 秘めている

  20. JP Web Rearchitect team

  21. JP Web Rearchitectについて

  22. Goal

  23. 新アーキテクチャの構築

  24. 新アーキテクチャの⽬的 • 今後のメルカリWebの進化を促進する • 数多くのチーム、エンジニアの協調

  25. 進化の促進 • やりたいことは⼭程ある • 新しい技術的チャレンジをする⼟壌を整える • PWA化や新ライブラリの積極的な導⼊ • 新しいWebサービスの展開

  26. エンジニアの協調 • フロントエンドとバックエンドの関⼼事を分 離する • 100⼈のフロントエンドエンジニア、10個の Webチームがあっても成り⽴つアーキテクチャ

  27. Rearchitectの道のり

  28. テーマ Monolithic to Microservices

  29. なぜか • フロントエンドとバックエンドを分離する • 多サービスが協調して1ドメイン下のサービス 開発をできる基盤を整える

  30. 今 ϝϧΧϦ ϝϧΧϦ ϘοΫε ϝϧΧϦ ΨΠυ Ωϟϯϖʔϯ ϖʔδ #BDLFOE 'SPOUFOE

    #BDLFOE 'SPOUFOE #BDLFOE 'SPOUFOE #BDLFOE 'SPOUFOE single repository
  31. 今 • Webのすべての機能が1リポジトリに • 担当チームという概念が無く、Ownershipを 持ちづらい構造 • BackendとFrontendも同じリポジトリにあり、 責務分離がきれいにされていない

  32. 未来 (SBQI2- 443 ϝϧΧϦ 3&45"1* 'SPOUFOE ϝϧΧϦϘοΫε #BDLFOE4FSWFS ϝϧΧϦΨΠυ

  33. 未来 • 1つのサービスに1つのチームが責任を持つ • それぞれが技術選定を⾃由にできるように • デプロイ、開発すべてを⾃治する

  34. 今と未来のギャップを埋める

  35. [WIP]初期フェーズの計画

  36. [WIP]初期フェーズの計画 • BFF + Frontend • Web Gateway • Session

    Consistency
  37. BFF + Frontend

  38. なぜBFFを選択するか • 新アーキテクチャの⽬標の1つとして「フロン トエンドエンジニアの⽣産性を極限まで上げ る」 • これから複雑化していくBackendを隠蔽する ⼿段としてBFFという考え⽅を取り⼊れた

  39. BFF + Frontend • Next.jsでSSR + SPA 構成に • Data

    resourceは GraphQLサーバ • SSR Serverより先を BFFと定義
  40. 責務の分離 • Frontendエンジニア はSSR Server • Backendエンジニア はGraphQL Server

  41. Web Gateway

  42. Web Microservices • 同⼀ドメイン下に複数のServiceを展開したい • その際RoutingやBalancingが必要になる • また、初期は新しいWebへのMigrationが必要

  43. Migration • 新アーキテクチャへのMigrationはページ単位 で⾏う • Web Gatewayを⽴てて、Migrationをシーム レスに⾏えるようにする

  44. None
  45. 特定のパスは新しい⽅方へ

  46. 移⾏行行前のものは すべてそのままパスする

  47. Session Consistency

  48. Session Consistency • Microservices間でStorageやデータの共有は ⾏わない • SessionをそれぞれのServiceで扱うことにな る

  49. Spec • ログイン/アウト状態の同期 • 強制ログアウトの同期 • Be secure • 現在のWebとのセッション同期

  50. Session Service • Webのセッションを管理するMicroserviceを ⽴てる • 各WebのMicroserviceはここと通信する

  51. 初期フェーズ

  52. 新しいServiceも ここを使う

  53. 実際にどう 設計を進めているのか

  54. 現場の進め⽅ • チーム内で設計、壁打ち • Microservices Platformチームに相談 • Tech lead間で相談

  55. まとめ

  56. メルカリWebは進化します • まずはMonolithic to Microservicesを達成す るべく既に動き出しています • また、その先の未来を⾒据えたアーキテクチャ を設計し実装しています

  57. 乞うご期待 • 直近は⼤規模なリプレースでなく部分的な Migrationを⾏う • ⼩さい成功を積み重ね、理想の世界とのギャッ プを少しずつ埋めていく

  58. https://twitter.com/sota1235/status/934336948885381121

  59. Thank you