Upgrade to Pro — share decks privately, control downloads, hide ads and more …

MTC2018 - Web Application as a Microservice

mercari
October 04, 2018

MTC2018 - Web Application as a Microservice

Speaker: Sota Sugiura

Mercari Web was developed to support Mercari’s growth, and it has grown in tandem with Mercari for approximately two years. The Japan Web Re-architecture Team was created to improve Mercari Web by staying on top of the constantly evolving web-related technology and preparing for a growing frontend team. In this talk, Sugiura will talk about the details of the new architecture the Web Re-architecture Team is implementing, and what’s in store for Mercari Web after the new architecture is in place.

mercari

October 04, 2018
Tweet

More Decks by mercari

Other Decks in Technology

Transcript

  1. Improving scalability of the development team • Architecture that can

    handle the increasing number of engineers • Providing freedom for each team to choose their own technology stack
  2. Single PHP Server Te m ar Te m ar Box

    Te m ar G i Now Mercari Mercari Box Mercari Guide
  3. SSR GraphQL SPA REST API Simple HTTP server Mic r

    i s Te m ar Mic r i s Te m ar Box Mic r i s Te m ar G i Goal
  4. Monolithic Service Feture ・ ・ ・ Monolithic Service Feature ・

    ・ ・ Microservice Microservice Microservice Microservice Microservice Microservice
  5. Why? • This is a re-architecture, not a redesign •

    Limiting the scope of migration at first • We will start by taking on many small challenges and failures
  6. How we decided the order of migration • Difficulty •

    Clashes with other tasks and changes • Amount of traffic
  7. Web Gateway • Balancing for each service • Initially for

    both new and old architectures to co-exist • In the future, for Web Microservices
  8. • Mapping with path control • Scoped release • Session

    persistence Web Gateway mercari-web Service A Service B /hoge /moge /others CDN
  9. • Mapping with path control • Scoped release • Session

    persistence Web Gateway mercari-web Service A Service B /hoge /moge /others CDN /hoge=”Service A” /moge=”Service B”
  10. • Mapping with path control • Scoped release • Session

    persistence Web Gateway mercari-web Service A Service B /hoge /moge /others 0% 100% WI
  11. • Mapping with path control • Scoped release • Session

    persistence Web Gateway mercari-web Service A Service B /hoge /moge /others 10% 90% WI
  12. • Mapping with path control • Scoped release • Session

    persistence Web Gateway mercari-web Service A Service B /hoge /moge /others 100% 0% WI
  13. • Mapping with path control • Scoped release • Session

    persistence Web Gateway mercari-web Service A Service B /hoge /moge /others 10% 90% A B WI
  14. • Mapping with path control • Scoped release • Session

    persistence Web Gateway mercari-web Service A Service B /hoge /moge /others 10% 90% A B WI
  15. • Mapping with path control • Scoped release • Session

    persistence Web Gateway mercari-web Service A Service B /hoge /moge /others 10% 90% A B WI
  16. • Mapping with path control • Scoped release • Session

    persistence Web Gateway mercari-web Service A Service B /hoge /moge /others 10% 90% A B WI
  17. mercari-web mercari-api JSON over HTTPs SSR Offer service JSON over

    HTTPs gRPC Listing service gRPC New! Buying service New! Live service New! User service
  18. mercari-web mercari-api JSON over HTTPs SSR Offer service JSON over

    HTTPs gRPC Listing service gRPC New! Buying service New! Live service New! User service • We need to keep up to date with the specs for every new microservice • We need to write high-performance code
  19. mercari-web mercari-api JSON over HTTPs BFF Listing Service JSON over

    HTTPs gRPC Offer Service gRPC Our strategy SSR
  20. mercari-web mercari-api JSON over HTTPs BFF Listing Service JSON over

    HTTPs gRPC Offer Service gRPC Our strategy SSR Frontend Engineer Backend Engineer
  21. Backends for Frontends in our JP Web Re-architecture • Our

    definition of BFF: “a layer to aggregate backend microservices” • To improve the development experience for frontend engineers
  22. Session synchronization issues • Several microservices will exist in the

    same domain • Need to maintain consistency with the longin state of the Monolithic Service
  23. Microservice for managing session • Create a microservice to manage

    sessions • Maintaining session consistency and data preservation, etc. • Assume multiple microservices will use this
  24. Data transmission between Hokkaido and Tokyo • We use GKE

    in Tokyo region • The exisiting Monolithic Service will run from Hokkaido • We need to design the architecture with latency in mind
  25. • Making Storage to  store cache data • Minimize amount

    of back-and-forth data transmission in Japan mercari-web Session service New! Cache storage
  26. mercari-web Session service New! Cache storage • We chose gRPC

    via Node.js • Based on technical expertise of our members
  27. mercari-web Session service mercari-api Cache storage Firstly, check the Cache

    and DB at hand to check for existing session data SSR server
  28. mercari-web Session service mercari-api Cache storage If no session data

    can be found, check for the session in Monolithic Service SSR server
  29. mercari-web Session service mercari-api Cache storage With the session data,

    request authentication data to the Monolithic API SSR server
  30. • Use cache data if it exists, but if not,

    get from Hokkaido • No access to Tokyo from Hokkaido • This ensures security and consistency Simple is the best!
  31. Sowing the seeds of success • Implement a supreme architecture

    • Make it possible to develop at explosive speeds • And provide the ultimate developer experience
  32. Thank you :) Feel free to ask me any questions

    at the “Ask the speaker” booth