メルペイにおけるマイクロサービス運用の苦労と改善 / 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
   

   View Slide

2. 自己紹介
   ● twitter: @tjun
   ● Merpay SREチーム
   ○ Engineering Manager & Tech Lead
   ● 2018年4月メルペイ入社
   ● 昨年のCloudNative Days Tokyo 2019でも発表
   「メルペイのマイクロサービスの構築と運用」
   昨年の資料
   https://speakerdeck.com/tjun/cloudnative-days-tokyo2019
   

   View Slide

3. マイクロサービスの運用をしてきた
   技術面・組織面の経験を共有したい
   今日のテーマ
   3
   

   View Slide

4. メルペイのマイクロサービスの現状
   メルペイのマイクロサービスの運用
   開発運用における課題と改善
   01
   02
   03
   4
   Agenda
   まとめ
   04
   

   View Slide

5. メルペイのマイクロサービスの現状
   

   View Slide

6. メルペイの
   サービス規模
   マイクロサービスアーキテクチャ
   60以上のマイクロサービス
   6,259億円を取り扱うメルカリの
   決済基盤 ※FY2020.6 通期
   700万人以上の利用者
   ※メルペイ「電子マネー」の登録を行ったユーザーと、「メルペイコード払
   い」、「ネット決済」、「メルペイあと払い」等の利用者の合計（重複を除く）
   2020年6月時点
   

   View Slide

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

   レイヤーアーキテクチャ

   

   View Slide

8. Google Kubernetes Engine
   Kubernetes
   マイクロサービスの実行基盤・オーケストレーション
   - 自己修復性のあるReplication Controller
   - ServiceによるLoad Balancing
   - DeploymentによるRollout/Rollback
   - Horizontal Pod Autoscalerによるスケールアウト
   - Kubernetes 自体の拡張性やエコシステム
   サービス開発に集中し、安定して運用するために
   Managedな Kubernetesを利用
   

   View Slide

9. 開発を加速する共通の仕組み
   Microservices platform
   各チームがOwnershipを持ってサービスを構築・運用するための基盤
   ● Kubernetesクラスタとネットワーク
   ● microservice-starter-kitによるマイクロサービスの初期化
   ● GCP上のリソースは全てTerraformで管理
   ● Kubernetes上のリソースをYAMLで管理
   ● Spinnakerを用いたデプロイ
   PlatformをメルカリのMicroservices Platform Teamが構築・運用
   

   View Slide

10. マイクロサービスの階層構造
    アプリ、加盟店等のパートナー様
    全てのリクエストが を通る
    共通処理とルーティング
    サービス クライアントからのリクエストとレスポンスの責任を持つ
    裏側にある複数のマイクロサービスのアグリゲーション
    サービス 機能のロジックを実現する
    Backend
    Service
    API Gateway
    API
    Service
    Client
    

    View Slide

11. メルペイのマイクロサービスの例
    iD決済を実現する流れ
    API-Gateway NFC-api NFC-service
    payment-
    service
    リクエストの認証と
    ルーティング
    clientへ返すための
    responseの作成
    NFC決済を実現する
    ための処理
    共通の決済処理
    

    View Slide

12. 開発運用組織とマイクロサービス
    各機能を実現する
    Product開発チーム
    ● バックエンドエンジニア
    ● フロントエンドエンジニア
    ● iOS/Androidエンジニア
    ● QAエンジニア
    ● デザイナー
    ● PM
    共通基盤とサービス全体を見る
    Platform寄りのチーム
    ● SRE
    ● アーキテクトチーム
    ● Microservices Platformチーム
    ● ソリューションチーム
    ● Data platformチーム
    ● Machine Learningチーム
    

    View Slide

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
    

    View Slide

14. メルペイのマイクロサービスの運用
    

    View Slide

15. マイクロサービスの運用は大変
    マイクロサービスの数が増えるだけ運用する要素が増える
    ● 各マイクロサービスのアプリケーション
    ● 各マイクロサービスが利用するリソース（データベース等）
    ● マイクロサービス間の通信
    ● 接続する外部のシステム
    運用の手間を減らす仕組み
    ● マイクロサービスの構成をできるだけ揃える
    ● Kubernetes によるオートスケールや自己修復
    ● Managedなクラウドサービス
    それでもさまざまなところで問題は起きる
    

    View Slide

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

    

    View Slide

17. マイクロサービス運用で気をつけていること
    SLOを設定する
    ● サービスが正常な状態を各マイクロサービスで定義する
    ● アラートをしたり問題を修正したりする判断の基準
    Observability
    ● Metrics: 問題が起きたときに調査する&問題が起きる前に気づく
    ● 分散Tracing: どのマイクロサービスの処理で時間がかかるか
    ● Log
    

    View Slide

18. SLO（Service Level Objective）
    運用を考えると出てくる疑問
    ● 自分たちのサービスは今正常なのか？
    ● 自分たちのサービスは遅い？一部のお客さまに対してだけ遅い？
    ● CPU使用率が一瞬上がっていたが、問題ないのか？
    SLOとは
    ● Availability、Latencyなどシステムの信頼性の目標値
    ○ 例: API Xでは 99.99%のリクエストが 5xx以外を返す
    ● SLOを定義することで、自分たちのサービスが正常なのか、Alertする
    か、修正すべきかの判断ができる
    

    View Slide

19. Observability
    Microservicesでは、リクエストが複数のマイクロサービスを経由する
    ● どこで、どれだけ時間がかかっているのか
    ● なぜ時間がかかっているのか、どんなエラーが出ているのか
    ● 各マイクロサービスは SLOを満たしているのか
    メトリクス, Trace, Logをサービス横断して見られるようにすることで、問題の
    特定がスムーズにできる
    

    View Slide

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等の
    メトリクス
    

    View Slide

21. ここまでのまとめ
    メルペイでは
    ● マイクロサービスアーキテクチャを採用
    ● Microservices開発運用のためのPlatformがある
    ● Platformの上で、各チームがOwnershipを持って開発運用
    ● SLOとObservabilityを意識して運用
    

    View Slide

22. メルペイのマイクロサービス運用の
    苦労と改善
    

    View Slide

23. リリースから1年半でのサービスの変化
    マイクロサービスの増加
    ● マイクロサービス数は約30→60へ増加
    ● 既存のマイクロサービスも機能が増えた
    ● エンジニアはそれほど増えていない
    システムの複雑化
    ● マイクロサービス間の連携増加
    ● メルカリとの連携
    ● 外部パートナーのシステムとの連携
    

    View Slide

24. マイクロサービス開発運用で出てきた課題
    開発における課題
    ● マイクロサービス開発者の負荷が高い
    ● マイクロサービスのQAが難しい
    運用における課題
    ● 障害の起きた箇所の特定が難しい
    ● サービス全体の信頼性の実現が難しい
    ● インフラコストの増加
    組織の課題
    ● 組織の流動性が低い
    ● マイクロサービス間の情報共有
    

    View Slide

25. 開発における課題
    

    View Slide

26. 開発における課題１
    マイクロサービス開発者の負荷の増加
    マイクロサービス開発者の担当範囲（開発関連）
    ● 金融ドメインのサービス設計と開発
    ○ さまざまな社内のbest practiceを反映
    ● 利用するGCP resourceをTerraformで作成
    ● Kubernetes のYAMLを書いて、必要なDeployment, CronJobなどを
    設定
    ● Spinnakerを使ってApplicationやJobのデプロイ
    ● DatadogでDashboardとMonitorを作成
    

    View Slide

27. マイクロサービス開発者の担当範囲（運用関連）
    ● DatadogでDashboardとMonitorを作成
    ● 担当マイクロサービスのアラート対応
    ○ メトリクス、ログ、トレースをマイクロサービス横断して確認
    ○ 不整合データの対応
    ○ Incident Reportの作成
    ● 継続的なサービスの改善
    加えて、運用するマイクロサービスが増えたり複雑化することによって、負
    荷が高まっている
    開発における課題１
    マイクロサービス開発者の負荷の増加
    

    View Slide

28. マイクロサービス開発運用の生産性を高める仕組み
    Microservices Platform
    ● マイクロサービスの作成・開発・運用が簡単に行える仕組みを提供
    ● CI/CDまわりの改善など開発者の生産性を向上している
    ArchitectやSRE, Solution teamによる共通課題の解決
    ● テストの自動化やQAの並列化
    ● 開発・運用のためのツールの提供
    ● 運用改善の支援、SREがProjectに入って支援できる仕組みづくり
    ● GCP(おもにCloud Spanner)まわりの情報提供
    開発における課題１
    マイクロサービス開発者の負荷の増加
    

    View Slide

29. QA: 品質保証のために、リリース前にさまざまな試験を行うプロセス
    メルペイにおけるQA
    ● QAのための専用環境: 本番環境に近い環境
    ● 新規リリース前のサービスをデプロイしてQAを実施
    Service A
    master
    Service B
    featureX
    サービスBの機能X
    のQAをしたい

    開発における課題２
    マイクロサービスのQAが難しい
    

    View Slide

30. 課題: 複数の機能を同時にQAできない
    ● ServiceBで同時期に大きな機能を開発・QAを実施したい
    ● ServiceA→ServiceBの向き先を動的に切り替えられない
    ● 時間を決めて、この時間は機能XのQA、という運用
    Service A
    master
    Service B
    featureX
    Service B
    featureY
    サービスBの機能Xと
    YのQAをしたい

    開発における課題２
    マイクロサービスのQAが難しい
    

    View Slide

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
    

    View Slide

32. 運用における課題
    

    View Slide

33. 運用における課題１
    障害の起きた箇所の特定が難しい
    複数のマイクロサービスが連動して機能を提供
    ● 表に近いマイクロサービスでエラー率があがった際に、
    実際は裏側のサービスが原因ということがよくある
    ● 多くのサービスが依存するサービスで問題が起きると、
    さまざまな箇所でエラーが増える
    ● インフラの問題で複数サービスに影響が出ることもある
    Service A Service B Service C
    LB
    

    View Slide

34. チーム間のオンコール連携
    ● 共通のSlack アラートチャンネル
    ● アラートがなったチームが確認、SREや関連チームが必要に応じてサ
    ポート
    マイクロサービス横断のObservability
    ● となりのサービスのログやメトリクスを見られることが重要
    ● リクエストIDや分散Tracingで、リクエストを追跡
    運用における課題１
    障害の起きた箇所の特定が難しい
    

    View Slide

35. さまざまなところで問題が起きる
    ➔ マイクロサービスのSLOが、お客さまから見たときの信頼性と
    一致していない
    SLOが正しく運用できていない
    ➔ 最初にSLO定義しただけのチームもある
    運用における課題２
    サービス全体の信頼性の実現が難しい
    Service A Service B Service C
    LB
    

    View Slide

36. SLOを基準とした運用の仕組みを構築中
    SLO を基準とした運用とは、SLOが行動につながる状態
    ● SLOとその達成が常に見える状態にある
    ● 現状に合わせて継続的にSLOが更新される
    ● SLOと監視基準が一致している
    SLO
    監視
    設定
    達成度
    を確認
    サービス改善
    SLOの見直し
    運用における課題２
    サービス全体の信頼性の実現が難しい
    

    View Slide

37. 上がり続けるインフラコスト
    マイクロサービスの増加
    ● 各マイクロサービスがDBなどの
    インフラリソースを作成
    リクエストやデータ量の増加
    ● ストレージやログまわりの
    コストが増加
    運用における課題３
    インフラコストの増加
    

    View Slide

38. コストの可視化と削減
    BigQueryに入れたコストのデータを可視化・分析
    ● Google Cloudのサービス単位
    （Cloud Spanner, Cloud Storage...）
    ● マイクロサービス単位
    大きなコストがかかっていたBackupや Logging
    の設定を全マイクロサービスで修正
    運用における課題３
    インフラコストの増加
    

    View Slide

39. 組織における課題
    

    View Slide

40. 組織における課題１
    マイクロサービスと組織の流動性
    Ownershipと金融ドメイン
    ● マイクロサービスは開発した人がOwnershipを持って運用する
    ● 金融ドメインの処理やパートナーのシステムとの連携など、
    マイクロサービス毎にドメイン知識が必要
    流動性は不要？
    ● 組織としては、安定運用しながら新規案件のサービスに開発者を増や
    したい
    ● エンジニア個人としては、同じサービスの運用を続けていると
    運用疲れしたり飽きてきたりすることもある
    

    View Slide

41. マイクロサービス共通の技術スタック
    ● 開発言語や利用するデータベースなどを揃えている
    ● 運用に必要な技術・ツールも共通
    エンジニア ローテーションプログラム
    ● エンジニアが希望を出して、他Projectや他職種へ異動できる制度
    組織における課題１
    組織の流動性を実現するための取り組み
    

    View Slide

42. 組織における課題２
    マイクロサービス間の格差と情報共有
    情報を伝えてアクションしてもらうのは難しい
    ● 組織が拡大し情報が伝わりにくい
    ● 開発が忙しいと、改善のためのタスクは後回しになりがち
    マイクロサービスでも差が出てくる
    ● 1年以上前に作ったサービス、最近作ったサービス
    ● 運用経験が豊富なチーム、運用をはじめたばかりのチーム
    ● 前からいて他チームに話しかけやすい人、最近入社した人
    COVID-19による在宅勤務で他チームと話す時間が減少
    

    View Slide

43. 組織における課題２
    情報共有のための取り組みの例
    毎週のチーム横断ミーティング
    ● 各チームのTech Leadを中心に、お願いや困っていることなどの
    情報を共有する会を実施
    ドキュメントの整備
    ● Microservices PlatformチームがPlatformに関するドキュメントを
    整備して提供
    横断施策のトラッキング
    ● 各チームで実施して欲しい対応は、PullRequestの自動作成など
    行いつつ、最終的にはSpreadSheetで管理してSREがtrackingする
    

    View Slide

44. 組織とマイクロサービス
    各機能を実現する
    Product開発チーム
    ● バックエンドエンジニア
    ● フロントエンドエンジニア
    ● iOS/Androidエンジニア
    ● QAエンジニア
    ● デザイナー
    ● PM
    マイクロサービス共通の課題を解決し、組織とシステムをスケール
    するためには、横串の組織との連携が必要
    共通基盤とサービス全体を
    見るPlatform寄りの横串チーム
    ● SRE
    ● アーキテクトチーム
    ● Microservices Platformチーム
    ● ソリューションチーム
    ● Data platformチーム
    ● MLチーム
    

    View Slide

45. まとめ
    マイクロサービスアーキテクチャは難しい
    ● マイクロサービスは組織とシステムを
    Scalableにするためのアプローチとして有
    効だけど、すべてを解決するわけではない
    ● マイクロサービスにすることで、新たな課題が出てくる
    横串のチームとProject Engineerの連携が重要
    ● 共通の課題を解決するチームと、マイクロサービスを開発運用する
    チームの両方が重要
    まだまだメルペイのマイクロサービスに課題はある
    

    View Slide

46. View Slide