$30 off During Our Annual Pro Sale. View Details »

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

tjun
September 08, 2020

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

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

tjun

September 08, 2020
Tweet

More Decks by tjun

Other Decks in Technology

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

    View Slide

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

    View Slide

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

    View Slide

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

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

    View Slide

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

    開発における課題2
    マイクロサービスの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
    開発における課題2
    マイクロサービスのQAが難しい
    header:
    service-b-pr-x

    View Slide

  32. 運用における課題

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  39. 組織における課題

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  43. 組織における課題2
    情報共有のための取り組みの例
    毎週のチーム横断ミーティング
    ● 各チームの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. 46

    View Slide