【Mercari Tech Conf 2018 レポート】メルカリ Web の新アーキテクチャについてのセッション『Web Application as a Microservice』#mtc18

2018/10/04 に行われた『Mercari Tech Conf 2018』で発表されたメルカリ Web の新アーキテクチャについてのセッション『Web Application as a Microservice』のレポートです。

Mercari Tech Conf 2018

#イベント

#Microservice

黒澤大

2018.10.05

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

Web Application as a Microservice

Mercari Tech Conf 2018 - Web Application as a Microservice

メルカリWebはメルカリの成長を支える一角として開発され、約2年間メルカリと共に成長してきました。このメルカリWebをWebにまつわる技術の進化や拡大するフロントエンドチームといった変化に強くするためにJP Web Rearchitectチームが誕生しました。このトークではJP Web Rearchitectで実現する新たなアーキテクチャとその詳細、そしてそれを実現した先にある未来についてお話します。

スライド

Web 版メルカリ

組織の変化
技術的な変化

どちらの変化にも対応していきたい

JP Web Re-architect

メルカリ Web を改善する

変更に強い柔軟なアーキテクチャ

トレンドへの追従
Scrap and Build
最初に選択した技術
- TypeScript
- React
- Next.js
- GraphQL

開発チームのスケーラビリティの向上

エンジニアの増加に耐えうるアーキテクチャ
各チームの技術選定を自由に

モノリス

マイクロサービス

モノリス to マイクロサービス?

モノリスを全部一気に移行するのは現実的ではない
モノリス with マイクロサービス
- モノリスとマイクロサービスが共存する
- いずれは全てをマイクロサービスに移行する

Why?

リニューアルではなく Re-architect
小さいスコープで移行を行う
まずは小さいチャレンジと失敗を積み重ねる

必要最少コープの移動

ページ単位で 1 ページずつ移行していく

移行順の決め方

難易度
他改修とのバッティング
十分なトラフィックがあるか
- 十分なトラフィックがないと効果がわかりづらい

モノリス + マイクロサービス

Web Gateway

各サービスへのバランシングを行う
初期は新旧アーキテクチャ共存のため
将来は Web マイクロサービスのため

パスによる制御

公開範囲の制御

実現が難しそうでまだ WIP
一部だけマイクロサービスにトラフィックを流せるようにしたい

セッション

クライアントごとにトラフィックを流す先をセッションで制御する
- 違う所にトラフィックを流さないように
これもまだ WIP

フロントエンドとバックエンドの分離

バックエンドのマイクロサービス化はフロントエンドにどのような効果があるのか
- 日々増えるマイクロサービスの仕様の把握
- パフォーマンスを意識したコーディング

Backends For Frontends(BFF)

複数のマイクロサービスを束ねる層
フロントエンドとバックエンドの責務を BFF で分離する

BFF として何を実装するか
- SPA と相性のよい GraphQL を採用
- Apollo を使用

セッション同期問題

いくつかのマイクロサービスは同一ドメインに展開
モノリスとログイン状態の一貫性を保つ必要がある

セッションを管理するマイクロサービス

セッション管理を行うマイクロサービスを立てる
セッション整合性, データ保存などを隠蔽
他のマイクロサービスからも使うことを想定

どのように同期するか

毎回セッションがモノリスに存在するか問い合わせに行くか?

プログラマが知るべき様々なレイテンシ
- Latency Numbers Every Programmer Should Know
マイクロサービスのセッションサービスとモノリスとの距離は?
- 約800Km
東京と北海道間の通信
- GKE は東京リージョンを使用
- 既存のモノリスは北海道のさくら DC
- レイテンシを意識して設計を行う必要がある

レイテンシのどのように対応するか

ストレージを前段に
日本を縦断する回数を抑える
DB は Spanner か Datastore を検討している
Node.js + gRPC を使用
- メルカリでは Go + gPRC がよく使われているがチームとの相性を意識した

フロー

手元のキャッシュ, DB を見てセッションの有無を確かめる

手元にない場合, モノリスにセッション有無を問い合わせる

得たセッションから, モノリス API へ認証情報を問い合わせる

セッション情報を DB に保存

シンプルに保つ

手元にあれば使う, なければ取りに行く
北海道から東京のアクセスはしない
セキュリティ/整合性は担保する

まとめ

今は種まきの状態

まずは最高のアーキテクチャを実現する
爆発的なスピードで開発できる世界へ
最高の開発体験を実現する

多くのチャレンジ

技術スタック
アーキテクチャ刷新
開発体制の進化, スケール

全ては最高の Web のために

おわりに

現在めちゃくちゃマイクロサービス化を推進しているメルカリさんですが, どちらかといえばバックエンドにフォーカスしたマイクロサービスのお話が多い中, 今回はフロントエンド寄りのお話をしていただきました。Web 部分もマイクロサービスにしたいという需要はあると思うので貴重な知見をお話いただいて大変勉強になりました。