Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Speaker Deck
PRO
Sign in
Sign up for free
microservices and monitoring @Merpay
Komazaki
October 31, 2018
Technology
7
930
microservices and monitoring @Merpay
Komazaki
October 31, 2018
Tweet
Share
More Decks by Komazaki
See All by Komazaki
HashiCorp Vault on GKE @HashiCorp Meetup 10/23/2019
komattaka
5
1.2k
Monitoring and SLI/SLO driven development @Merpay
komattaka
2
1.3k
Other Decks in Technology
See All in Technology
Pentesting Password Reset Functionality
anugrahsr
0
180
2023年は何する宣言
shigeruoda
0
240
Startup Studio Sereal / Culture Deck
sereal
0
610
Hasuraの本番運用に向けて
nori3tsu
0
270
SmartHRからOktaへのSCIM連携で作り出すHRドリブンのアカウント管理
jousysmiler
1
110
日本ディープラーニング協会主催 NeurIPS 2022 技術報告会講演資料
tdailab
0
930
マネーフォワードクラウドを支える事業者基盤
machisuke
0
220
EMになって最初の失敗談 - コミュニケーション編 -
fukuiretu
1
330
re:Inventで発表があったIoT事例の紹介と考察
kizawa2020
0
120
日経電子版だけじゃない! 日経の新規Webメディアの開発 - NIKKEI Tech Talk #3
sztm
0
110
経営統合をきっかけに会社をエンジニアリングした話 / btconjp-2023
carta_engineering
0
100
【NGK2023S】 ノードエディタ形式の画像処理ツール「Image-Processing-Node-Editor」
kazuhitotakahashi
0
210
Featured
See All Featured
The Invisible Side of Design
smashingmag
292
48k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
349
27k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
224
50k
JazzCon 2018 Closing Keynote - Leadership for the Reluctant Leader
reverentgeek
175
9.1k
A Philosophy of Restraint
colly
193
15k
How STYLIGHT went responsive
nonsquared
89
4.2k
5 minutes of I Can Smell Your CMS
philhawksworth
198
18k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
32
6.7k
Writing Fast Ruby
sferik
613
58k
Making Projects Easy
brettharned
102
4.8k
Designing for Performance
lara
600
65k
GraphQLの誤解/rethinking-graphql
sonatard
39
7.8k
Transcript
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/