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

私はkokukumaです ● 名前 ○ 狩野達也 ● Github ○ kokukuma ● Twitter ○ @kokukuma ● 仕事 ○ Mercari Backend チーム / マイクロサービス開発

目次 ● マイクロサービス化の現状 ● 問題点と今後 ● まとめ

マイクロサービス化の現状

● メルカリのAPIはPHPを主体とした、大きなアプリケーション ● 切り崩してマイクロサービス化を進めています 　メルカリがマイクロサービスに舵を切った大きな理由は、組織をどんどん拡大していくという目標です。 現時点でのメルカリのエンジニア数は 300人ですが、我々はその 3倍の、1000人規模のエンジニアリング 組織を目指しています。 　そして今まで以上のスピードとパフォーマンスを保ってプロダクトを開発し、お客様によりよりサービスを 提供していくことを目指しています。 「Microservices Platform at Mercari」in Mercari Tech Conf 2018 マイクロサービス化

● 本に書いてあった説明 ○ 『マイクロサービスアーキテクチャの目標は、それぞれ責任を持って 1つの機能をこなす一連の小さ なアプリケーションを構築し、個々のマイクロサービスに自律性、独立性、自己完結性を与えること です』プロダクションレディマイクロサービス ○ 『満たすべき特徴は、疎結合、高凝縮、単一目的』 Microservice Architecture at Medium ○ ● わかりやすいなと思った説明 ○ 開発・運用をスケールアウト出来るようにするためにやる ■ 自分が関わる対象範囲を小さくする ■ その範囲を、全部自分のものにする ■ 他の人の範囲を、API経由で利用する ○ 『Google map を使ったwebサービス』をイメージしてサービスを分割する マイクロサービスとは

こんな感じで分割するのがいい ● 特徴 ○ 開発プロセスが独立している ○ 組織が独立している ○ コード/データが分離されている ○ ● こんな事は起きない ○ リリースするとき、Google mapの人に連絡しな いといけない ○ サービス開発してたら、 GitHubが壊れた ○ GitHubとGoogle mapで同じDBみてる コード/データ、開発プロセス、運用プロセス、組織、それぞれが各サー ビスにおいて独立している

前進してます、マイクロサービス化 ● プラットフォームチームが、共通機能の準備 ○ 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数サービスくらい。

● サービスについて ○ 基本的には、GCP(東京)に置かれている。 ○ marcariのDBに繋ぐ必要のあるサービスは、 SAKURA(石狩)に置かれる。 ○ 現状、Client(APIの種類)と、DBは変更されていない。 マイクロサービス化の現状①

● チームについて ○ １サービスに、バックエンドエンジニアが一人か二人。 ○ QAやClient、SREは含まれていない。まだフィーチャーチームにはなってない。 ○ 物理的な距離は近い。 マイクロサービス化の現状②

● 開発プロセス・運用プロセスについて ○ 開発、デプロイは、ほぼ各サービスで独立している。 ○ QAやリリースは、API単位で実行している状況。 ○ 運用プロセスは実質まで未経験。準備はしているという感じ。 マイクロサービス化の現状③

マイクロサービス化の現状④ ● コード/データについて ○ コードは、基本的に、各チームで持っている。 ○ 共通してつかうpackageはある（DatadogやSentryの処理とか） ○ mercariのDBに関しては、一つのテーブルには一つオーナー。

マイクロサービス化の現状⑤ ● サービスの数ふえすぎてしまう問題 ○ 1つのAPIで、10~20テーブルを利用する。 ○ 最初からすべてを正しく分割すると、サービス数多すぎて運用できない。 ○ 「mercari DBにつなぐためのサービス」 を作って対処。

● mercariのDBに対するCRUDを提供 ○ 運用可能な範囲のサービス数で、 Listingサービスのマイクロサービス化を進める ○ 他のサービスでの資産を使うため、 Goで書かれている。 ○ あくまで、マイクロサービス化の 一時的対処として行っている。 Legacy db serviceとは gRPCでリクエストを受ける。クエリ を直接受け取らない。 クエリ組み立てて、MySQLに 投げる。結果を組み立てて返 す。 特定のテーブルのみアクセ ス出来るようにする。

● 分散モノリスを助長する危険性がある ○ テーブルやロジックが誰のものか考えずに使えてしまう ○ テーブル呼んでるところや、ロジックがいろんなサービスに分散してしまう ○ ● 一時的なものにするために.... ○ アクセスできるサービス /テーブルを制限 ■ オーナーが未定のテーブルのみアクセス許可 ■ 使いたいと言ってるサービスが、そのテーブルのオーナーぽかったら。。 ■ ○ シンプルなCRUDのみ提供 ■ トランザクション、Join、Subqueryは提供しない。 ■ 複雑なことしたくなるロジックは、オーナーが持ったほうがいい ■ そういうロジックが散るのは危ない。別途サービスを作ろう。 Legacy db serviceの怖さと対応

Legacy db service、必要？ ● Legacy db ができた背景 ○ API単位でマイクロサービス化を進めたために、一気に数 10サービスリリースする必要が出てきた ● もし、 ○ データ側からサービスを一つづつ作っていったら、 legacy dbはいらなかったかも。 ● ただ、 ○ そのサービスを使うように mercari APIを修正する必要がある ○ 時間もかかるし、手間もかかる。

問題点と今後

問題だと思っていること ● サービスのQAが上手く回っていない ○ QA環境が安定していない ○ 開発者が低コストでQA環境を準備できない ○ QA環境の状態がわからない

● Gateway ○ マイクロサービスに行くか、既存の mercari APIに行くかが別れている ○ API毎に制御 ○ ● Mercari API側 ○ 複数あって開発者が自由に利用できる ○ 特定のsubdomainにアクセスする ○ ● マイクロサービス側 ○ 複数デプロイすることは現状してない ○ 開発者が自分のサービスをデプロイする 現状のQA環境

● 状況 ○ 定期的に動かなくなる ■ 独立してデプロイする ■ 独立したQAはしてない ■ リクエストも少なく発見が遅れる ○ 他のQAが進まなくなる ● 対策 ○ デプロイの制限 ○ 動く状況を保つ ○ 複製出来るようにする QA環境が安定しない問題

開発者が低コストでQA環境を準備できない ● サービスを複製する必要がある ○ リクエストごとに、サービスの versionを選 択する機能はない ○ ● 複製はコストが高い ○ 各サービスは別チーム ○ 下流のサービスほど、高くなる

QA環境の状態がわからない ● 全体を把握する人間はいない ○ 各サービスでは、自分のサービスのことし か知らない。 ○ 特定のリクエストがどのサービスを通るか は知らない。 ○ ● QA環境の状態がわからない ○ どのsubdomainで、何をテストできるかが わかりにくい

● 全体的に動く状態を保つ ○ 数個の環境をルール決めて運用する。動かなくなったら、検知出来るようにする。 ○ てっとり早いが、スケールはしない。 ○ ● サービス毎に動く状態を保つ ○ 各サービスの独立性を上げて、動く状態を保つ。 ○ スケールする。文化による対応、浸透するまでに時間がかかる。 ○ ● QA環境を複製できるようにする ○ QA環境を用途に応じて、環境を低コストで複製できるようにする。 ○ ある程度スケールする。 対策の種類

● 対策内容 ○ 1つ以上の固定された環境を持つ。 ○ 正常系のリクエストを投げ続け、通らな かったらアラート。 ● メリット・デメリット ○ 低コストで実施出来るメリット ○ スケールしないデメリット ■ 全サービスで統一したルールを守る 必要がある。 ■ APIが増えたときに、リクエストの追 加が発生。 ■ 動かなくなる可能性を下げる力は働 かない ○ 運用コストが大きくなるデメリット 全体的に動く状態を保つ

● 対策内容 ○ 各サービスそれぞれが、機能を提供出来 ていることを保証する ○ QA環境に、本番に近い品質を求める ■ unit test・サービス内のe2e test ■ デプロイ後のintegration test ■ 後方互換性の検証 ■ 問題があったときのアラート ○ ● メリット・デメリット ○ サービスの独立性を推進するメリット。 ○ 対策が浸透するまで時間がかかるデメリッ ト。 サービス毎に動く状態を保つ

● 対策内容 ○ サービスメッシュを使う ■ 特定リクエストのみ特定サービスに 切り替える ■ 各サービスでは、デプロイだけ ■ QAを主導する人が、routeを選択 ○ ● メリット・デメリット ○ 問題を一番確実に解決出来るメリット。 ○ API単位のQAを根付かせてしまうデメリッ ト QA環境を複製できるようにする

● 思うこと ○ 最終的には、「サービス毎に動く状態保つ」方向に行かなければならない。 ○ どのみち、QA環境を分ける需要は発生する。 ○ Sakura側は事情が違いすぎて、サービスメッシュ導入難しい。 ○ どれがうまくいくかは、やってみないとわからないところある。 ○ ● 全部組み合わせる形でやってみたい ○ サービスメッシュ使って、特定サービスだけ QAできる状況を作る。 ○ Master環境は、リクエスト投げ続けて、動く状態を保つ。 ○ Sakura側は、各サービスの独立性をあげる。 で、どうするか？

● マイクロサービス化進んでます ● Legacy db serviceは慎重に。 ● QA環境の問題どうなるかは乞うご期待 まとめ

おまけ

これ自体はマイクロサービスではない ● 分割粒度が粗い ○ 単一目的を満たしてない ● 共通化されている部分がない ○ モニタリングやエラーレポートは共通のものを 利用する ● 同期的にしか動かない ○ サービスが中央集権