メルペイにおけるマイクロサービス運用の苦労と改善 / CloudNative Days Tokyo2020

2020.09.08 に CloudNative Days Tokyo2020 で発表した内容です。
メルペイの1年半におけるマイクロサービス運用の経験と苦労した事例について紹介しました。

Transcript

1. メルペイにおける マイクロサービス運用の苦労と改善 CloudNative Days Tokyo 2020 Merpay SRE @tjun Junichiro Takagi https://speakerdeck.com/tjun/cloudnative-days-tokyo2020
2. 自己紹介 • twitter: @tjun • Merpay SREチーム ◦ Engineering Manager & Tech Lead • 2018年4月メルペイ入社 • 昨年のCloudNative Days Tokyo 2019でも発表 「メルペイのマイクロサービスの構築と運用」 昨年の資料 https://speakerdeck.com/tjun/cloudnative-days-tokyo2019
3. マイクロサービスの運用をしてきた 技術面・組織面の経験を共有したい 今日のテーマ 3
4. メルペイのマイクロサービスの現状 メルペイのマイクロサービスの運用 開発運用における課題と改善 01 02 03 4 Agenda まとめ 04
5. メルペイのマイクロサービスの現状
6. メルペイの サービス規模 マイクロサービスアーキテクチャ 60以上のマイクロサービス 6,259億円を取り扱うメルカリの 決済基盤 ※FY2020.6 通期 700万人以上の利用者 ※メルペイ「電子マネー」の登録を行ったユーザーと、「メルペイコード払 い」、「ネット決済」、「メルペイあと払い」等の利用者の合計（重複を除く） 2020年6月時点
7. API Gateway Authority API Service X API Service Y Google Cloud Load Balancer Service A Service B Google Kubernetes Engine Service C Web Service Z Cloud Spanner Project A Cloud Spanner Cloud Pub/Sub Project B Project GKE Project C Cloud Spanner アーキテクチャ Google Cloud Platform
 3
 1
 2
 マイクロサービス
 on Kubernetes
 レイヤーアーキテクチャ

8. Google Kubernetes Engine Kubernetes マイクロサービスの実行基盤・オーケストレーション - 自己修復性のあるReplication Controller - ServiceによるLoad Balancing - DeploymentによるRollout/Rollback - Horizontal Pod Autoscalerによるスケールアウト - Kubernetes 自体の拡張性やエコシステム サービス開発に集中し、安定して運用するために Managedな Kubernetesを利用
9. 開発を加速する共通の仕組み Microservices platform 各チームがOwnershipを持ってサービスを構築・運用するための基盤 • Kubernetesクラスタとネットワーク • microservice-starter-kitによるマイクロサービスの初期化 • GCP上のリソースは全てTerraformで管理 • Kubernetes上のリソースをYAMLで管理 • Spinnakerを用いたデプロイ PlatformをメルカリのMicroservices Platform Teamが構築・運用
10. マイクロサービスの階層構造 アプリ、加盟店等のパートナー様 全てのリクエストが を通る 共通処理とルーティング サービス クライアントからのリクエストとレスポンスの責任を持つ 裏側にある複数のマイクロサービスのアグリゲーション サービス 機能のロジックを実現する Backend Service API Gateway API Service Client
11. メルペイのマイクロサービスの例 iD決済を実現する流れ API-Gateway NFC-api NFC-service payment- service リクエストの認証と ルーティング clientへ返すための responseの作成 NFC決済を実現する ための処理 共通の決済処理
12. 開発運用組織とマイクロサービス 各機能を実現する Product開発チーム • バックエンドエンジニア • フロントエンドエンジニア • iOS/Androidエンジニア • QAエンジニア • デザイナー • PM 共通基盤とサービス全体を見る Platform寄りのチーム • SRE • アーキテクトチーム • Microservices Platformチーム • ソリューションチーム • Data platformチーム • Machine Learningチーム
13. メルペイのEngineering組織 Product D Product C Product B Product A Product Engineering PM PM PM PM TL ... TL ... TL EM EM EM EM EM TL SRE Backend 1 Backend 2 iOS Frontend EM Android
14. メルペイのマイクロサービスの運用
15. マイクロサービスの運用は大変 マイクロサービスの数が増えるだけ運用する要素が増える • 各マイクロサービスのアプリケーション • 各マイクロサービスが利用するリソース（データベース等） • マイクロサービス間の通信 • 接続する外部のシステム 運用の手間を減らす仕組み • マイクロサービスの構成をできるだけ揃える • Kubernetes によるオートスケールや自己修復 • Managedなクラウドサービス それでもさまざまなところで問題は起きる
16. マイクロサービスの運用体制 マイクロサービスでは各チームが担当マイクロサービスを運用 Google Kubernetes Engine Container A Container A Service A Cloud Spanner Project A Container A Container A Service B Cloud Spanner Project B Cloud Pub/Sub teamA
 teamB

17. マイクロサービス運用で気をつけていること SLOを設定する • サービスが正常な状態を各マイクロサービスで定義する • アラートをしたり問題を修正したりする判断の基準 Observability • Metrics: 問題が起きたときに調査する&問題が起きる前に気づく • 分散Tracing: どのマイクロサービスの処理で時間がかかるか • Log
18. SLO（Service Level Objective） 運用を考えると出てくる疑問 • 自分たちのサービスは今正常なのか？ • 自分たちのサービスは遅い？一部のお客さまに対してだけ遅い？ • CPU使用率が一瞬上がっていたが、問題ないのか？ SLOとは • Availability、Latencyなどシステムの信頼性の目標値 ◦ 例: API Xでは 99.99%のリクエストが 5xx以外を返す • SLOを定義することで、自分たちのサービスが正常なのか、Alertする か、修正すべきかの判断ができる
19. Observability Microservicesでは、リクエストが複数のマイクロサービスを経由する • どこで、どれだけ時間がかかっているのか • なぜ時間がかかっているのか、どんなエラーが出ているのか • 各マイクロサービスは SLOを満たしているのか メトリクス, Trace, Logをサービス横断して見られるようにすることで、問題の 特定がスムーズにできる
20. 監視体制 メトリクス、Trace、LogをDatadogに集約 Google Kubernetes Engine Container A Container A Container A Cloud Spanner Project A Go, gRPC, Docker, Kubernetes の メトリクス, ログ, Trace Cloud Spanner, Pub/Sub, Load Balancer等の メトリクス
21. ここまでのまとめ メルペイでは • マイクロサービスアーキテクチャを採用 • Microservices開発運用のためのPlatformがある • Platformの上で、各チームがOwnershipを持って開発運用 • SLOとObservabilityを意識して運用
22. メルペイのマイクロサービス運用の 苦労と改善
23. リリースから1年半でのサービスの変化 マイクロサービスの増加 • マイクロサービス数は約30→60へ増加 • 既存のマイクロサービスも機能が増えた • エンジニアはそれほど増えていない システムの複雑化 • マイクロサービス間の連携増加 • メルカリとの連携 • 外部パートナーのシステムとの連携
24. マイクロサービス開発運用で出てきた課題 開発における課題 • マイクロサービス開発者の負荷が高い • マイクロサービスのQAが難しい 運用における課題 • 障害の起きた箇所の特定が難しい • サービス全体の信頼性の実現が難しい • インフラコストの増加 組織の課題 • 組織の流動性が低い • マイクロサービス間の情報共有
25. 開発における課題
26. 開発における課題１ マイクロサービス開発者の負荷の増加 マイクロサービス開発者の担当範囲（開発関連） • 金融ドメインのサービス設計と開発 ◦ さまざまな社内のbest practiceを反映 • 利用するGCP resourceをTerraformで作成 • Kubernetes のYAMLを書いて、必要なDeployment, CronJobなどを 設定 • Spinnakerを使ってApplicationやJobのデプロイ • DatadogでDashboardとMonitorを作成
27. マイクロサービス開発者の担当範囲（運用関連） • DatadogでDashboardとMonitorを作成 • 担当マイクロサービスのアラート対応 ◦ メトリクス、ログ、トレースをマイクロサービス横断して確認 ◦ 不整合データの対応 ◦ Incident Reportの作成 • 継続的なサービスの改善 加えて、運用するマイクロサービスが増えたり複雑化することによって、負 荷が高まっている 開発における課題１ マイクロサービス開発者の負荷の増加
28. マイクロサービス開発運用の生産性を高める仕組み Microservices Platform • マイクロサービスの作成・開発・運用が簡単に行える仕組みを提供 • CI/CDまわりの改善など開発者の生産性を向上している ArchitectやSRE, Solution teamによる共通課題の解決 • テストの自動化やQAの並列化 • 開発・運用のためのツールの提供 • 運用改善の支援、SREがProjectに入って支援できる仕組みづくり • GCP(おもにCloud Spanner)まわりの情報提供 開発における課題１ マイクロサービス開発者の負荷の増加
29. QA: 品質保証のために、リリース前にさまざまな試験を行うプロセス メルペイにおけるQA • QAのための専用環境: 本番環境に近い環境 • 新規リリース前のサービスをデプロイしてQAを実施 Service A master Service B featureX サービスBの機能X のQAをしたい
 開発における課題２ マイクロサービスのQAが難しい
30. 課題: 複数の機能を同時にQAできない • ServiceBで同時期に大きな機能を開発・QAを実施したい • ServiceA→ServiceBの向き先を動的に切り替えられない • 時間を決めて、この時間は機能XのQA、という運用 Service A master Service B featureX Service B featureY サービスBの機能Xと YのQAをしたい
 開発における課題２ マイクロサービスのQAが難しい
31. MicroservicesのQAの並列化 Headerを見てリクエストを対象のPodに投げ分ける仕組みを導入 • Custom Controller を使ってPull Requestごとにリソースを生成 • Istioを使ってVertualServiceでリクエストのターゲットを指定 Service A master Service B PullReq-X Service B PullReq-Y Virtual Service 開発における課題２ マイクロサービスのQAが難しい header: service-b-pr-x
32. 運用における課題
33. 運用における課題１ 障害の起きた箇所の特定が難しい 複数のマイクロサービスが連動して機能を提供 • 表に近いマイクロサービスでエラー率があがった際に、 実際は裏側のサービスが原因ということがよくある • 多くのサービスが依存するサービスで問題が起きると、 さまざまな箇所でエラーが増える • インフラの問題で複数サービスに影響が出ることもある Service A Service B Service C LB
34. チーム間のオンコール連携 • 共通のSlack アラートチャンネル • アラートがなったチームが確認、SREや関連チームが必要に応じてサ ポート マイクロサービス横断のObservability • となりのサービスのログやメトリクスを見られることが重要 • リクエストIDや分散Tracingで、リクエストを追跡 運用における課題１ 障害の起きた箇所の特定が難しい
35. さまざまなところで問題が起きる ➔ マイクロサービスのSLOが、お客さまから見たときの信頼性と 一致していない SLOが正しく運用できていない ➔ 最初にSLO定義しただけのチームもある 運用における課題２ サービス全体の信頼性の実現が難しい Service A Service B Service C LB
36. SLOを基準とした運用の仕組みを構築中 SLO を基準とした運用とは、SLOが行動につながる状態 • SLOとその達成が常に見える状態にある • 現状に合わせて継続的にSLOが更新される • SLOと監視基準が一致している SLO 監視 設定 達成度 を確認 サービス改善 SLOの見直し 運用における課題２ サービス全体の信頼性の実現が難しい
37. 上がり続けるインフラコスト マイクロサービスの増加 • 各マイクロサービスがDBなどの インフラリソースを作成 リクエストやデータ量の増加 • ストレージやログまわりの コストが増加 運用における課題３ インフラコストの増加
38. コストの可視化と削減 BigQueryに入れたコストのデータを可視化・分析 • Google Cloudのサービス単位 （Cloud Spanner, Cloud Storage...） • マイクロサービス単位 大きなコストがかかっていたBackupや Logging の設定を全マイクロサービスで修正 運用における課題３ インフラコストの増加
39. 組織における課題
40. 組織における課題１ マイクロサービスと組織の流動性 Ownershipと金融ドメイン • マイクロサービスは開発した人がOwnershipを持って運用する • 金融ドメインの処理やパートナーのシステムとの連携など、 マイクロサービス毎にドメイン知識が必要 流動性は不要？ • 組織としては、安定運用しながら新規案件のサービスに開発者を増や したい • エンジニア個人としては、同じサービスの運用を続けていると 運用疲れしたり飽きてきたりすることもある
41. マイクロサービス共通の技術スタック • 開発言語や利用するデータベースなどを揃えている • 運用に必要な技術・ツールも共通 エンジニア ローテーションプログラム • エンジニアが希望を出して、他Projectや他職種へ異動できる制度 組織における課題１ 組織の流動性を実現するための取り組み
42. 組織における課題２ マイクロサービス間の格差と情報共有 情報を伝えてアクションしてもらうのは難しい • 組織が拡大し情報が伝わりにくい • 開発が忙しいと、改善のためのタスクは後回しになりがち マイクロサービスでも差が出てくる • 1年以上前に作ったサービス、最近作ったサービス • 運用経験が豊富なチーム、運用をはじめたばかりのチーム • 前からいて他チームに話しかけやすい人、最近入社した人 COVID-19による在宅勤務で他チームと話す時間が減少
43. 組織における課題２ 情報共有のための取り組みの例 毎週のチーム横断ミーティング • 各チームのTech Leadを中心に、お願いや困っていることなどの 情報を共有する会を実施 ドキュメントの整備 • Microservices PlatformチームがPlatformに関するドキュメントを 整備して提供 横断施策のトラッキング • 各チームで実施して欲しい対応は、PullRequestの自動作成など 行いつつ、最終的にはSpreadSheetで管理してSREがtrackingする
44. 組織とマイクロサービス 各機能を実現する Product開発チーム • バックエンドエンジニア • フロントエンドエンジニア • iOS/Androidエンジニア • QAエンジニア • デザイナー • PM マイクロサービス共通の課題を解決し、組織とシステムをスケール するためには、横串の組織との連携が必要 共通基盤とサービス全体を 見るPlatform寄りの横串チーム • SRE • アーキテクトチーム • Microservices Platformチーム • ソリューションチーム • Data platformチーム • MLチーム
45. まとめ マイクロサービスアーキテクチャは難しい • マイクロサービスは組織とシステムを Scalableにするためのアプローチとして有 効だけど、すべてを解決するわけではない • マイクロサービスにすることで、新たな課題が出てくる 横串のチームとProject Engineerの連携が重要 • 共通の課題を解決するチームと、マイクロサービスを開発運用する チームの両方が重要 まだまだメルペイのマイクロサービスに課題はある