Tweet
Tweet

Slide 1

Slide 1 text

メルペイにおける マイクロサービス運用の苦労と改善 CloudNative Days Tokyo 2020 Merpay SRE @tjun Junichiro Takagi https://speakerdeck.com/tjun/cloudnative-days-tokyo2020

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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
 レイヤーアーキテクチャ


Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

メルペイの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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

マイクロサービスの運用体制 マイクロサービスでは各チームが担当マイクロサービスを運用 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


Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

監視体制 メトリクス、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等の メトリクス

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

開発における課題

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

運用における課題

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

組織における課題

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

46