俺たちのmicroserviceはまだ始まったばかり

mercari.go #5

Transcript

1. 俺たちのmicroserviceは まだ始まったばかり kokukuma
2. 私はkokukumaです • 名前 ◦ 狩野達也 • Github ◦ kokukuma • Twitter ◦ @kokukuma • 仕事 ◦ Mercari Backend チーム / マイクロサービス開発
3. 目次 • マイクロサービス化の現状 • 問題点と今後 • まとめ
4. マイクロサービス化の現状
5. • メルカリのAPIはPHPを主体とした、大きなアプリケーション • 切り崩してマイクロサービス化を進めています 　メルカリがマイクロサービスに舵を切った大きな理由は、組織をどんどん拡大していくという目標です。 現時点でのメルカリのエンジニア数は 300人ですが、我々はその 3倍の、1000人規模のエンジニアリング 組織を目指しています。 　そして今まで以上のスピードとパフォーマンスを保ってプロダクトを開発し、お客様によりよりサービスを 提供していくことを目指しています。 「Microservices Platform at Mercari」in Mercari Tech Conf 2018 マイクロサービス化
6. • 本に書いてあった説明 ◦ 『マイクロサービスアーキテクチャの目標は、それぞれ責任を持って 1つの機能をこなす一連の小さ なアプリケーションを構築し、個々のマイクロサービスに自律性、独立性、自己完結性を与えること です』プロダクションレディマイクロサービス ◦ 『満たすべき特徴は、疎結合、高凝縮、単一目的』 Microservice Architecture at Medium ◦ • わかりやすいなと思った説明 ◦ 開発・運用をスケールアウト出来るようにするためにやる ▪ 自分が関わる対象範囲を小さくする ▪ その範囲を、全部自分のものにする ▪ 他の人の範囲を、API経由で利用する ◦ 『Google map を使ったwebサービス』をイメージしてサービスを分割する マイクロサービスとは
7. こんな感じで分割するのがいい • 特徴 ◦ 開発プロセスが独立している ◦ 組織が独立している ◦ コード/データが分離されている ◦ • こんな事は起きない ◦ リリースするとき、Google mapの人に連絡しな いといけない ◦ サービス開発してたら、 GitHubが壊れた ◦ GitHubとGoogle mapで同じDBみてる コード/データ、開発プロセス、運用プロセス、組織、それぞれが各サー ビスにおいて独立している
8. 前進してます、マイクロサービス化 • プラットフォームチームが、共通機能の準備 ◦ gatewayサービス、テンプレートサービス、プロダクションレディチェックリスト ◦ モニタリング、エラーレポーティング、 Oncall対応 ◦ 「Microservices Platform at Mercari」in Mercari Tech Conf 2018 ◦ • バックエンドチームが、既存機能のマイクロサービス化を実施 ◦ API単位で進められている。 ◦ Mercari APIの互換性を保ちつつ、既存ロジックを分割している。 Client側/DB側は変えない。 ◦ 「Listing Service: モノリスからマイクロサービスへ」 in Mercari Tech Conf 2018 ◦ • Listing serviceのリリースを実施中 ◦ Listing serviceは、一つのAPIを担当。 ◦ 依存するサービスを含めると 10数サービスくらい。
9. • サービスについて ◦ 基本的には、GCP(東京)に置かれている。 ◦ marcariのDBに繋ぐ必要のあるサービスは、 SAKURA(石狩)に置かれる。 ◦ 現状、Client(APIの種類)と、DBは変更されていない。 マイクロサービス化の現状①
10. • チームについて ◦ １サービスに、バックエンドエンジニアが一人か二人。 ◦ QAやClient、SREは含まれていない。まだフィーチャーチームにはなってない。 ◦ 物理的な距離は近い。 マイクロサービス化の現状②
11. • 開発プロセス・運用プロセスについて ◦ 開発、デプロイは、ほぼ各サービスで独立している。 ◦ QAやリリースは、API単位で実行している状況。 ◦ 運用プロセスは実質まで未経験。準備はしているという感じ。 マイクロサービス化の現状③
12. マイクロサービス化の現状④ • コード/データについて ◦ コードは、基本的に、各チームで持っている。 ◦ 共通してつかうpackageはある（DatadogやSentryの処理とか） ◦ mercariのDBに関しては、一つのテーブルには一つオーナー。
13. マイクロサービス化の現状⑤ • サービスの数ふえすぎてしまう問題 ◦ 1つのAPIで、10~20テーブルを利用する。 ◦ 最初からすべてを正しく分割すると、サービス数多すぎて運用できない。 ◦ 「mercari DBにつなぐためのサービス」 を作って対処。
14. • mercariのDBに対するCRUDを提供 ◦ 運用可能な範囲のサービス数で、 Listingサービスのマイクロサービス化を進める ◦ 他のサービスでの資産を使うため、 Goで書かれている。 ◦ あくまで、マイクロサービス化の 一時的対処として行っている。 Legacy db serviceとは gRPCでリクエストを受ける。クエリ を直接受け取らない。 クエリ組み立てて、MySQLに 投げる。結果を組み立てて返 す。 特定のテーブルのみアクセ ス出来るようにする。
15. • 分散モノリスを助長する危険性がある ◦ テーブルやロジックが誰のものか考えずに使えてしまう ◦ テーブル呼んでるところや、ロジックがいろんなサービスに分散してしまう ◦ • 一時的なものにするために.... ◦ アクセスできるサービス /テーブルを制限 ▪ オーナーが未定のテーブルのみアクセス許可 ▪ 使いたいと言ってるサービスが、そのテーブルのオーナーぽかったら。。 ▪ ◦ シンプルなCRUDのみ提供 ▪ トランザクション、Join、Subqueryは提供しない。 ▪ 複雑なことしたくなるロジックは、オーナーが持ったほうがいい ▪ そういうロジックが散るのは危ない。別途サービスを作ろう。 Legacy db serviceの怖さと対応
16. Legacy db service、必要？ • Legacy db ができた背景 ◦ API単位でマイクロサービス化を進めたために、一気に数 10サービスリリースする必要が出てきた • もし、 ◦ データ側からサービスを一つづつ作っていったら、 legacy dbはいらなかったかも。 • ただ、 ◦ そのサービスを使うように mercari APIを修正する必要がある ◦ 時間もかかるし、手間もかかる。
17. 問題点と今後
18. 問題だと思っていること • サービスのQAが上手く回っていない ◦ QA環境が安定していない ◦ 開発者が低コストでQA環境を準備できない ◦ QA環境の状態がわからない
19. • Gateway ◦ マイクロサービスに行くか、既存の mercari APIに行くかが別れている ◦ API毎に制御 ◦ • Mercari API側 ◦ 複数あって開発者が自由に利用できる ◦ 特定のsubdomainにアクセスする ◦ • マイクロサービス側 ◦ 複数デプロイすることは現状してない ◦ 開発者が自分のサービスをデプロイする 現状のQA環境
20. • 状況 ◦ 定期的に動かなくなる ▪ 独立してデプロイする ▪ 独立したQAはしてない ▪ リクエストも少なく発見が遅れる ◦ 他のQAが進まなくなる • 対策 ◦ デプロイの制限 ◦ 動く状況を保つ ◦ 複製出来るようにする QA環境が安定しない問題
21. 開発者が低コストでQA環境を準備できない • サービスを複製する必要がある ◦ リクエストごとに、サービスの versionを選 択する機能はない ◦ • 複製はコストが高い ◦ 各サービスは別チーム ◦ 下流のサービスほど、高くなる
22. QA環境の状態がわからない • 全体を把握する人間はいない ◦ 各サービスでは、自分のサービスのことし か知らない。 ◦ 特定のリクエストがどのサービスを通るか は知らない。 ◦ • QA環境の状態がわからない ◦ どのsubdomainで、何をテストできるかが わかりにくい
23. • 全体的に動く状態を保つ ◦ 数個の環境をルール決めて運用する。動かなくなったら、検知出来るようにする。 ◦ てっとり早いが、スケールはしない。 ◦ • サービス毎に動く状態を保つ ◦ 各サービスの独立性を上げて、動く状態を保つ。 ◦ スケールする。文化による対応、浸透するまでに時間がかかる。 ◦ • QA環境を複製できるようにする ◦ QA環境を用途に応じて、環境を低コストで複製できるようにする。 ◦ ある程度スケールする。 対策の種類
24. • 対策内容 ◦ 1つ以上の固定された環境を持つ。 ◦ 正常系のリクエストを投げ続け、通らな かったらアラート。 • メリット・デメリット ◦ 低コストで実施出来るメリット ◦ スケールしないデメリット ▪ 全サービスで統一したルールを守る 必要がある。 ▪ APIが増えたときに、リクエストの追 加が発生。 ▪ 動かなくなる可能性を下げる力は働 かない ◦ 運用コストが大きくなるデメリット 全体的に動く状態を保つ
25. • 対策内容 ◦ 各サービスそれぞれが、機能を提供出来 ていることを保証する ◦ QA環境に、本番に近い品質を求める ▪ unit test・サービス内のe2e test ▪ デプロイ後のintegration test ▪ 後方互換性の検証 ▪ 問題があったときのアラート ◦ • メリット・デメリット ◦ サービスの独立性を推進するメリット。 ◦ 対策が浸透するまで時間がかかるデメリッ ト。 サービス毎に動く状態を保つ
26. • 対策内容 ◦ サービスメッシュを使う ▪ 特定リクエストのみ特定サービスに 切り替える ▪ 各サービスでは、デプロイだけ ▪ QAを主導する人が、routeを選択 ◦ • メリット・デメリット ◦ 問題を一番確実に解決出来るメリット。 ◦ API単位のQAを根付かせてしまうデメリッ ト QA環境を複製できるようにする
27. • 思うこと ◦ 最終的には、「サービス毎に動く状態保つ」方向に行かなければならない。 ◦ どのみち、QA環境を分ける需要は発生する。 ◦ Sakura側は事情が違いすぎて、サービスメッシュ導入難しい。 ◦ どれがうまくいくかは、やってみないとわからないところある。 ◦ • 全部組み合わせる形でやってみたい ◦ サービスメッシュ使って、特定サービスだけ QAできる状況を作る。 ◦ Master環境は、リクエスト投げ続けて、動く状態を保つ。 ◦ Sakura側は、各サービスの独立性をあげる。 で、どうするか？
28. • マイクロサービス化進んでます • Legacy db serviceは慎重に。 • QA環境の問題どうなるかは乞うご期待 まとめ
29. おまけ
30. これ自体はマイクロサービスではない • 分割粒度が粗い ◦ 単一目的を満たしてない • 共通化されている部分がない ◦ モニタリングやエラーレポートは共通のものを 利用する • 同期的にしか動かない ◦ サービスが中央集権