Merpay SRE @tjun の Microservice基盤

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

3 Merpayのアーキテクチャ 01 今日の目次 02 ● Microservice アーキテクチャ Microservicesの構築 ● 構成管理 ● CI/CD Copyright © Merpay, Inc. All Rights Reserved. 03 Microservicesの運用 ● 運用の仕組みづくり ● 運用体制

MerpayのMicroserviceアーキテクチャ

メルペイのアーキテクチャ概要 Clients Merpay API Gateway API ServiceA ServiceA ServiceA API

メルペイのアーキテクチャのポイント Clients Merpay API Gateway API ServiceA ServiceA ServiceA API 1. Microservices 2. GKE(Google Kubernetes Engine) 3. API Gateway

Microservices ● Scaleする組織＆サービスに耐えられるアーキテクチャ ● 機能やデータをサービスごとに分離できる ○ コードが分かれている（当たり前） ○ チームが分かれている ○ データベースが分かれている ○ Kubernetesのnamespaceが分かれている ○ GCPのprojectが分かれている サービスの安定性・安全性を実現するために重要

MerpayのMicroservices ● ほとんどはGoで書かれている ○ Go microservice templateのようなコードがある ● gRPCでやりとり ○ protoファイルで定義を決めて共有できる ○ 多言語対応が比較的カンタン ● APIレイヤを分離することで、各サービスはサービスの機能に専念 できる ○ クライアントを意識するのはAPIレイヤの仕事

GKE(Google Kubernetes Engine) ● Microserviceのための機能 ○ Namespace ○ Secret ○ RBAC ○ Managed Istio(まだ使ってない) ● 運用が楽になるための機能 ○ Managed kubernetes ○ Update/Rollback ○ Load balance & Autoscale ○ Auto repair

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

Merpay API Gateway (+GLB) ● RequestのRouting + Protocol transform（後述） ● 共通のEndpoint処理 ○ DDoS Protection(GLB) ○ SSL 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がサービスの信頼性の指標になる

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

メルペイのアーキテクチャのポイント Clients Merpay API Gateway API ServiceA ServiceA ServiceA API 1. Microservices 2. GKE(Google Kubernetes Engine) 3. API Gateway

Microservices Platformの構築

Microservice Platform team @mercari ● Microservices Platform = GCP, GKEとその周りの仕組み ○ MerpayのサービスはMicroservicesPlatform上に構築 ● Merpay SREはPlatform側の改善にも参加する

CI/CD ● CI ○ GitHubのPRベースの開発 ○ CircleCIまたは CloudBuildでCI ○ GoogleDockerRegistryにImageをPush ● CD ○ SpinnakerでKubernetesのnamespaceに対してdeploy ○ 開発者自身がdeployを行える ○ Canary releaseなどの機能も今後利用していく

Bootstrap & Ops with Terraform ● 新たなserviceを作るとき `./script/new` コマンドで ○ GCP Project ○ Kubernetes namespace ○ Sentry/Pagerduty などを作成し、紐付けするPullRequestを自動生成するstarter-kitがあ る ● Databaseの追加やIAMの追加などインフラに対する変更をTerraformの コードで管理・レビューできる

GCP project for GKE Centralized cluster Namespace: Service A Namespace: Service B IAM: SRE IAM: Team A Service A Service B RBAC: Team A RBAC: Team B Bootstrap Bootstrap IAM: Team B

Platform Security ● EndPointをAPI Gatewayに集約 ● Serviceごとにコードやデータを分離 ● 権限を持つチームメンバをコードで管理&Review ● GCP, Kubernetes, SpinnakerなどのAudit Loggingとその監視 ● 各レイヤでのセキュリティ対策や監視 ○ Deploy, Container Image ○ Kubernetes Cluster, Pod ○ GCP(Database, Network)

Microservicesの運用準備

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

運用の仕組みの共通化 ● Microserviceでは各サービスのチームがOwnerとなって運用を進め ていく。技術選定も自由。 ● とはいえ、SREや他のチームのメンバーがサポートするためには共 通化が必要 ● ルールの共通化: SLO(Service Level Objective)を決めよう ● ツールの共通化: StackDriver, Datadog, Sentry, Pagerduty

運用の仕組みの共通化 ● SLO: サービスが信頼できる状態かどうか判断するための指標 ○ 例: Gatewayで測定して、あるAPIのRequestの成功率が99.99% ○ 指標がないと、何を直すのか、いつ緊急対応するのかの判断ができない ● ツールの共通化 ○ ログ: StackDriver & BigQuery, メトリクス: Datadog, エラー通知: Sentry, 当番通 知: Pagerduty ○ Microservice starter-kitで自動で各サービスのTeamやProjectなどが生成され る

まとめ

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