Merpay SRE @komattaka の Microservice基盤とMonitoring

2 自己紹介 Copyright © Merpay, Inc. All Rights Reserved. @komattaka SRE Team at Merpay

3 Merpayにおけるアーキテクチャと組織 01 今日の目次 02 ● アーキテクチャと組織 ● 開発者を支える取り組み ● SREの取り組み Monitoring ● Monitoring基盤のコンセプト ● Metrics Driven ● AlertとTicket Copyright © Merpay, Inc. All Rights Reserved.

Architecture @Merpay

メルペイのアーキテクチャ概要 Clients (API) Merpay API Gateway API microservice A microservice B microservice C API Mercari App Clients (Browser) CDN

アーキテクチャのポイント Merpay API Gateway API microservice A microservice B microservice C API Clients (API) Mercari App Clients (Browser) CDN 1. 基本的に4階層構造を取る 2. Microservices 3. GKE(Google Kubernetes Engine) 4. API Gateway

Microservicesアーキテクチャと組織 ● Scaleするサービス&組織に耐えられるアーキテクチャ ● 機能やデータをサービスごとに分離し、それぞれがOwnershipをもっ て開発を進められる ○ コードが分かれている ○ チームが分かれている ○ データベースが分かれている ○ Kubernetesのnamespaceが分かれている ○ GCPのprojectが分かれている サービスと組織の安定性・安全性・迅速な成長を 実現するために重要

namespace Merpay Architecture and Org. Structure API Kubernetes Engine namespace API namespace microservice C namespace microservice B namespace microservice A namespace Merpay API Gateway ● repository ● team Cloud Spanner ● repository ● team Cloud Pub/Sub Cloud SQL Stackdriver Monitoring Logging BigQuery Cloud Load Balancing … + + Project for Centralized GKE Cluster

As Developer Architecture

gRPC / Service Definition ● protocol buffersによるサービス定義を行う ● 中央管理しているサービス定義のリポジトリとCIが連携し 言語毎のClientを作成するようにしている

gRPC / Common function ● mercari-echo-jp ○ Monitoring server for liveness/readiness probe ○ error reporting ○ dockerfile ○ CI Settings ○ … ● これをMicroservice共通の実装として、各チームがforkし Microserviceを実装していく 初期実装の敷居を低くしつつ、 安定化のための機能を自ずと持つようにしている

Merpay API Gateway Clients Merpay API Gateway API ServiceA ServiceA ServiceA API CDN

API GatewayのProtocol Transform 3rd Party Merpay API Gateway API API Browser App gRPC HTTP + Protobuf HTTP + JSON RESTful API

Merpay API Gateway (+GLB) ● RequestのRouting + Protocol transform ● 共通のEndpoint処理 ○ DDoS Protection(GLB) ○ TLS Termination(GLB) ○ Authentication ○ Buffering ● Observability ○ Logging & Tracing 参考: 「API GatewayによるMicroservices化」 by deeeet

API Gatewayの特徴 ● メルカリのAPI Gatewayとcoreは同じ ○ もともとcoreがGoのpkgとして実装されている ○ coreの上にMerpayのロジックを載せている ● API Gateway自体もGKE上に動いている ● ObservabilityはMicroserviceでは重要 ○ ErrorRateやLatancyがサービスの信頼性の指標になる

As SRE Architecture

Infrastructure as Code ● Terraformを用いたInfrastructure as Codeを徹底している ○ Git管理しCI連携しているため、5W1Hのトレーサビリティが担保できるので監査 が楽 ● GCP Folder、IAMにより手作業による変更を防いでいる

Infrastructure as Code ● 中央管理のリポジトリで全てのMicroservice用のProjectの管理を行 う ● ディレクトリ:Microserviceを1:1対応させる ○ CODEOWNERを適切に設定することができるので、 チーム内でのReview/Approveを加速させることが出来る terraform/ ├──microservice-A ├──microservice-B … Cloud Spanner Cloud Pub/Sub Cloud SQL Project: microservie-A Project: microservie-B

Service A Infrastructure as Code Cloud SQL Developers SRE Pull Request Review Terraform plan tfnotifyを使ってGithub PR上でTerraform Plan結果を確認できるようにしている (OSSとして公開中: github.com/mercari/tfnotify)

Terraform Apply結果もGithub上で確認できる Service A Infrastructure as Code Cloud SQL Developers SRE Pull Request Approve / Merge Terraform apply

Microserviceはいっぱいある…

Service A Infrastructure as Code Cloud SQL Developers Service B Developers SRE Pull Request Cloud Spanner Cloud Pub/Sub Pull Request Review Service A Cloud SQL Developers Service B Developers Cloud Spanner Cloud Pub/Sub Pull Request Pull Request Bottleneck!? Terraform plan / apply

Service A Infrastructure as Code Cloud SQL Developers Service B Developers SRE Pull Request Cloud Spanner Cloud Pub/Sub Pull Request & Review / Approve Review Service A Cloud SQL Developers Service B Developers Cloud Spanner Cloud Pub/Sub Terraform plan / apply Pull Request CODEOWNER CODEOWNER Pull Request & Review / Approve CODEOWNERを適切に渡すことでSREがBottleneckになることを防ぐ

Monitoring

Concept Monitoring

Monitoringのコンセプト

Monitoring Chaos Map Infrastructure Monitoring ※ 順不同 スタック毎に得手不得手があるので 1つのツールで全てを担当することは正解ではない Application Performance Monitoring Application Bug Tracking Analyzation External Monitoring Notification/Call

Application Performance Monitoring Monitoring Chaos Map Analyzation External Monitoring Infrastructure Monitoring Application Bug Tracking Notification/Call ※ 順不同 弊社での活用例(検証中含む)

Metrics Driven Development Monitoring

Metrics Driven Development 適切なモニタリングを行うために、あらゆる事象を特徴の異なる3つの指標にグルーピングすること を推奨している 種類 例 特徴 Work Metrics ● Throughput ● Success ● Error ● Performance ユーザに一番分かりやすく、 CVなどに影響 → 閲覧が…できる/できない → 表示までの速度が…速い/遅い これが悪化したらすぐに直さないといけない Resource Metrics ● Utilization ● Saturation ● (Internal) Error ● Availability これが悪化するとWork Metricsに影響が出るもの の、すぐに影響する訳ではない これが悪化したらいつか直さないといけない Events ● CI/CDジョブの実行 ● CM、広告 Work / Resource両方のMetricsに影響が出る

Metrics Driven Development 3つの指標には相関関係がある 全ての人の行動(Events)はメトリクスに反映されるため、 常にモニタリングし改善を続けていくことが大事

SLI / SLO Determination 何をMonitoringするかはSLI/SLO(SLA)を定義することでハッキリする ● SLO(Service Level Objective): サービスレベル指標 ● SLI(Service Level Indicator): サービスレベル目標 ● SLA(Service Level Agreement): サービスレベル合意(品質保障) SLI/SLOの例: 1. Availability: 1時間測定し99.99%のリクエストが正常な結果 (Status: 200, 300系, 400 系) を返す 2. Latency: 1時間測定してBackendへの99%のリクエストが 150msec以内に返る 3. Quality: Sentryで10分測定して、想定外のエラー率が 0.1%以下である

Alert or Ticket さらに、Monitoringはすぐに対応しないといけないAlertと いつか対応すれば良いTicketに分離することができる。 実はWork MetricsとResource Metricsがそれぞれに対応する。 ● Work Metrics: Alert ● Resource Metrics: Ticket おさらい: ● Work Metrics: ユーザに目に見えるMetrics (e.g.アクセス出来る/出来ない) ● Resource Metrics: ユーザに目に見えないMetrics (e.g. CPU usage)

Best Practice Monitoring

Stack x SLI/SLO x Alert or Ticket Application Performance Monitoring Analyzation External Monitoring Infrastructure Monitoring Application Bug Tracking Notification/Call Work Metrics =Alert Resource Metrics =Ticket ●Server up time ●process stuck ●cluster failure ●cpu usage ●mem usage ●disk usage Work Metrics =Alert Resource Metrics =Ticket ●error rate ●99th % duration ●cpu usage ●mem usage ●queue length Work Metrics =Alert Resource Metrics =Ticket ●error rate ●unknown error ●well-known error Work Metrics =Alert Resource Metrics =Ticket ●error rate ●99th % duration ●cert expiration ●rendering time まずはMonitoringできるMetricsを一覧し、Work / Resourceに分類する

Stack x SLI/SLO x Alert or Ticket Application Performance Monitoring Analyzation External Monitoring Infrastructure Monitoring Application Bug Tracking Notification/Call Work Metrics =Alert Resource Metrics =Ticket ●Server up time ●process stuck ●cluster failure ●cpu usage ●mem usage ●disk usage Work Metrics =Alert Resource Metrics =Ticket ●error rate ●99th % duration ●cpu usage ●mem usage ●queue length Work Metrics =Alert Resource Metrics =Ticket ●error rate ●unknown error ●well-known error Work Metrics =Alert Resource Metrics =Ticket ●error rate ●99th % duration ●cert expiration ●rendering time ●cache hit rate 次にSLO損失に繋がるMetricsをピックアップする

Stack x SLI/SLO x Alert or Ticket Application Performance Monitoring Analyzation External Monitoring Infrastructure Monitoring Application Bug Tracking Notification/Call Work Metrics =Alert Resource Metrics =Ticket ●Server up time ●process stuck ●cluster failure ●cpu usage ●mem usage ●disk usage Work Metrics =Alert Resource Metrics =Ticket ●error rate ●99th % duration ●cpu usage ●mem usage ●queue length Work Metrics =Alert Resource Metrics =Ticket ●error rate ●unknown error ●well-known error Work Metrics =Alert Resource Metrics =Ticket ●error rate ●99th % duration ●cert expiration ●rendering time ●cache hit rate SLO損失=電話を検討する Engineer

Stack x SLI/SLO x Alert or Ticket Application Performance Monitoring Analyzation External Monitoring Infrastructure Monitoring Application Bug Tracking Notification/Call Work Metrics =Alert Resource Metrics =Ticket ●Server up time ●process stuck ●cluster failure ●cpu usage ●mem usage ●disk usage Work Metrics =Alert Resource Metrics =Ticket ●error rate ●99th % duration ●cpu usage ●mem usage ●queue length Work Metrics =Alert Resource Metrics =Ticket ●error rate ●unknown error ●well-known error Work Metrics =Alert Resource Metrics =Ticket ●error rate ●99th % duration ●cert expiration ●rendering time ●cache hit rate Resource Metricsの悪化は放っておくとSLO損失に繋がるのでTicket管理する

運用体制イメージ サービスに関する問題 ● Error ● Latency ● DB ● 問い合わせ Service Alert PlatformやInfraの問題 ● kubernetes ● Gateway ● GCPまわり Platform Alert Service Team SRE ● Sinmetal(GCP Hero) ● Google Support Microservice Platform Team GCP

DataDog APM Monitoring

DataDog APM / Service Map https://www.datadoghq.com/blog/service-map/より

DataDog APM / Trace https://www.datadoghq.com/blog/service-map/より

まとめ

まとめ MerpayのSREは ● Microservice Platformを使ったサービス運用を行うチームです ● Microservice Platform自体の改善にも参加しています ● 安定化にもコミットしています GCPやりたい人、KubernetesやMicroserviceやりたい人、DB, Network, Securityなどが 得意な人、ぜひ一緒にやりましょう！！ Merpay 採用ページの SiteReliability までお願いします We are hiring!!!

https://jp.merpay.com/