MTC2018 - Web Application as a Microservice

92cdcff298e89e2fcd2fb705155c2d4b?s=47 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.

92cdcff298e89e2fcd2fb705155c2d4b?s=128

mercari

October 04, 2018
Tweet

Transcript

  1. Web Application as a Microservice Sota Sugiura Tech Lead (Backend)

  2. Tech Lead Backend Sota Sugiura

  3. Web Application as a Microservice

  4. https://www.mercari.com/jp/

  5. JP Web Re-architect

  6. Improve scalability of the development team Goals A flexible architecture

    that is resilient to change 1 2
  7. Flexible architecture that is resilient to change • Keeping up

    to date with trends • Scrap and Build
  8. None
  9. 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
  10. Single PHP Server Te m ar Te m ar Box

    Te m ar G i Now Mercari Mercari Box Mercari Guide
  11. 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
  12. How to Carry Out the Re-architecture

  13. 1 Monolithic Service to 4 Microservices

  14. Wait, can you migrate all features from a Monolithic Service

    at once? :P
  15. 1 Monolithic Service to with 4 Microservices

  16. Monolithic Service Feture ・ ・ ・ Monolithic Service Feature ・

    ・ ・ Microservice Microservice Microservice Microservice Microservice Microservice
  17. 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
  18. Limiting the migration scope

  19. Monolithic Service Feature ・ ・ ・ /jp/*

  20. Monolithic Service Feature ・ ・ ・ Microservice Microservice /jp/* /jp/top

  21. How we decided the order of migration • Difficulty •

    Clashes with other tasks and changes • Amount of traffic
  22. Challenges

  23. Challenges Monolithic Service + Microservices 1 2 Separating Frontend and

    Backend 3 Session synchronization
  24. GraphQL SSR mercari-web mercari-api Web Gateway Session service CDN

  25. GraphQL SSR mercari-web mercari-api Web Gateway Session service CDN 1

    2 3
  26. GraphQL SSR mercari-web mercari-api Web Gateway Session service CDN 1

    2 3
  27. Web Gateway • Balancing for each service • Initially for

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

    persistence Web Gateway mercari-web Service A Service B /hoge /moge /others CDN
  29. • 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”
  30. • Mapping with path control • Scoped release • Session

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

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

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

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

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

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

    persistence Web Gateway mercari-web Service A Service B /hoge /moge /others 10% 90% A B WI
  37. GraphQL SSR mercari-web mercari-api Web Gateway Session service CDN 1

    2 3
  38. How is frontend affected by the backend migration to Microservices?

  39. mercari-web mercari-api JSON over HTTPs

  40. mercari-web mercari-api JSON over HTTPs SSR JSON over HTTPs New!

  41. mercari-web mercari-api JSON over HTTPs SSR Offer service JSON over

    HTTPs gRPC New!
  42. mercari-web mercari-api JSON over HTTPs SSR Offer service JSON over

    HTTPs gRPC Listing service gRPC New!
  43. 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
  44. 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
  45. mercari-web mercari-api JSON over HTTPs BFF Listing Service JSON over

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

    HTTPs gRPC Offer Service gRPC Our strategy SSR Frontend Engineer Backend Engineer
  47. 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
  48. What to implement as BFF • GraphQL - works well

    with SPAs • a
  49. GraphQL SSR mercari-web mercari-api Web Gateway Session service CDN 1

    2 3
  50. Session synchronization issues • Several microservices will exist in the

    same domain • Need to maintain consistency with the longin state of the Monolithic Service
  51. mercari-web Logged-out user SSR server

  52. mercari-web POST /login SSR server Logged-out user

  53. mercari-web Logged-in user Success! SSR server

  54. mercari-web Logged-in user GET / SSR server

  55. mercari-web Should show page for logged in users SSR server

    Logged-in user
  56. Microservice for managing session • Create a microservice to manage

    sessions • Maintaining session consistency and data preservation, etc. • Assume multiple microservices will use this
  57. How we will manage synchronization

  58. mercari-web Session service Request Call to get session every time

    Response Session data SSR server
  59. mercari-web Session service Request Call to get session every time

    Response Session data SSR server
  60. https://gist.github.com/jboner/2841832 Latency Numbers Every Programmer Should Know

  61. mercari-web Session service Q. What’s the distance here? SSR server

  62. About 800km ※だいたいです

  63. 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
  64. • Making Storage to  store cache data • Minimize amount

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

    via Node.js • Based on technical expertise of our members
  66. mercari-web Session service mercari-api Cache storage SSR server

  67. mercari-web Session service mercari-api Cache storage Firstly, check the Cache

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

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

    request authentication data to the Monolithic API SSR server
  70. mercari-web Session service mercari-api Cache storage Save session data SSR

    server
  71. • 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!
  72. Conclusion

  73. Sowing the seeds of success • Implement a supreme architecture

    • Make it possible to develop at explosive speeds • And provide the ultimate developer experience
  74. So many challenges! • Tech stack • Re-architecture • Evolving

    and scaling our development structure
  75. Al or One All for the ultimate Web

  76. Thank you :) Feel free to ask me any questions

    at the “Ask the speaker” booth
  77. None