メルペイのマイクロサービスの構築と運用 / CloudNative Days Tokyo2019

Slide 1

Slide 1 text

メルペイにおけるマイクロサービス構築と運用 CloudNative Days Tokyo 2019 Merpay SRE @tjun Junichiro Takagi https://speakerdeck.com/tjun/cloudnative-days-tokyo2019

Slide 2

Slide 2 text

「マイクロサービス、実際やってみてどう？」に答えたい今日テーマ 2

Slide 3

Slide 3 text

メルペイマイクロサービス概要メルペイマイクロサービス構築と運用課題と今後 01 02 03 3 Agenda おまけ: 実際に起きた問題を紹介 04

Slide 4

Slide 4 text

メルペイ概要年月非接触型サービス「」に対応年月複数回お買い物をあとからまとめて支払える「メルペイあと払い」開始年月サイトでも「メルペイ」が利用できるネット決済提供開始年月大手チェーンや中・小規模店舗で・バーコード決済に対応全国135万か所 iD コード払いあと払いネット決済

Slide 5

Slide 5 text

メルペイサービスマイクロサービスアーキテクチャ 40以上マイクロサービス 2019 3Qで 1444億円以上を取り扱うメルカリ決済基盤(US メルカリ事業も含む数字） 200万人以上利用者（メルペイ「電子マネー」登録を行ったユーザー累計。コード払い除く）

Slide 6

Slide 6 text

Why microservice?

Slide 7

Slide 7 text

Why microservices? メルペイ複数サービスを短期間で立ち上げるため Focus on single service 各マイクロサービス機能に集中して開発 Independent releases 独立した開発・リリースサイクル Team independence 組織を拡大しながら複数機能を同時に開発

Slide 8

Slide 8 text

マイクロサービスそ他メリット Resilience 障害が局所化することで可用性が高まる Scalability & Flexibility 独立したリソース管理が可能ストレージも独立

Slide 9

Slide 9 text

メルペイマイクロサービスでやっていないことマイクロサービス単位で自由な技術選択自由な技術選択例自由な言語、好きなデータベース Why? ● 共通ツール・ライブラリを利用することで、開発や運用度や品質を高めるため ● チーム間情報共有や人移動を可能にするため

Slide 10

Slide 10 text

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

Slide 11

Slide 11 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

Slide 12

Slide 12 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 共通 GKEクラスタ  3  1  2  個別 Project  レイヤーアーキテクチャ 

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

マイクロサービス on Google Kubernetes Engine すべてマイクロサービスが同じClusterに乗っている - Cluster自体 Platform Teamが構築・運用 - Namespace内を各チームが開発・運用 Google Kubernetes Engine Namespace: service-a Container A Container A Container A Namespace: service-b Container A Container A Container B

Slide 15

Slide 15 text

マイクロサービス on Google Cloud Platform ● 1つマイクロサービスが1つ GCP Projectを持つ ● 各 Project 中に Spanner や Pub/Sub などを作成 ● 権限設定したService Account を Kubernetes Secretに配置 ● Terraformで管理 CircleCI Project A Cloud Spanner Cloud Pub/Sub GitHub Terraform Code Project B Cloud Spanner Big Query

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

API Gateway ● Goで書かれたマイクロサービス ● リクエストを各マイクロサービスへルーティングする共通リクエスト処理をAPI Gateway と Cloud Load Balancerで実現 ● TLS termination ● DDoS protection ● Request buffering ● Authマイクロサービスを利用したAuthN/AuthZ

Slide 19

Slide 19 text

メルペイマイクロサービス構築

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

メルペイマイクロサービス開発で気をつけていること一貫性 ● データ一貫性 ● リトライと冪等性 ● リコンサイル信頼性 ● Go template projectやlibraryによる標準化 ● Production Readiness checklist ● DesignDoc ● 権限管理

Slide 22

Slide 22 text

Slide 23

Slide 23 text

マイクロサービスにおける一貫性分散システムにおけるデータ一貫性担保難しい ● 決済トランザクションが複数サービスをまたがる ● DBへ書き込みや外部サービスへ接続が分散している ● どこかで処理が失敗しても、全体として一貫性が必要冪等性 ● リトライしても二重に処理されず、正しく動く詳しくメルカリtech blog 記事を参照 - マイクロサービスにおける決済トランザクション管理 - メルペイにおけるお客さま残高管理手法

Slide 24

Slide 24 text

マイクロサービスにおける一貫性リコンサイル ● 本当にデータ整合性が取れているか？ ● 不整合を見つけて修正する必要があるメルペイで ● バッチ処理によるリコンサイル ● 非同期な結果イベント通知によるリコンサイルによって不整合チェックと修正を行っている

Slide 25

Slide 25 text

Slide 26

Slide 26 text

メルペイマイクロサービスとGo ほとんどサービスがGoで書かれている（一部Node.js）マイクロサービステンプレート ● Liveness/ReadinessProbe対応、Graceful シャットダウンなど Kubernetes上で動かすために必要な機能を持つ社内で開発した共通 Goライブラリ ● Logging, 分散Tracing, クライアントサイド LoadBalancingなどに対応

Slide 27

Slide 27 text

マイクロサービスレビュー DesignDoc 設計をアーキテクト、SRE、Security、関連マイクロサービスエンジニアがレビュー・議論する Production Readiness Checklist 本番リリース前に、Kubernetes yaml等で必要な設定がされているか、運用準備が十分かなどをチェックする例: Horizontal Pod AutoscalerやPod Disruption Budget 設定

Slide 28

Slide 28 text

メルペイにおけるマイクロサービス構築流れ

Slide 29

Slide 29 text

開発を加する共通仕組み Microservices platform 各チームがOwnershipを持ってサービスを構築・運用する ● microservice-starter-kitによるマイクロサービス初期化 ● Protocol Buffersによるサービスインターフェース定義共通化 ● GCP上リソース全てTerraformで管理 ● Kubernetes上リソースをYAMLで管理 ● 共通デプロイフロー Platformをメルカリ Microservices platform teamが構築・運用

Slide 30

Slide 30 text

マイクロサービス初期化 microservices-starter-kit という仕組みで自動化 ● GCP Project 作成+Application用Service Account 作成、開発者へ IAM権限付与 ● Kubernetes Namespace 作成+必要なRBAC&Secret 設定 GCP project for GKE Centralized cluster Namespace: Service A Service A RBAC: Team A

Slide 31

Slide 31 text

GCPリソース作成 ● Cloud Spanner, Pub/Sub, Cloud Storage等リソース ● すべてTerraformで作成・管理 CircleCI Cloud Spanner Cloud Pub/Sub GitHub Terraform Code Project B Cloud Spanner Big Query Project A

Slide 32

Slide 32 text

Kubernetesリソース単体デプロイ Manifest 単体をCircleCIからデプロイ - Job、Horizontal Pod Autoscalerなど YAML CircleCI Google Kubernetes Engine yaml GitHub Namespace: service-a Container A Container A Container A Namespace: service-b Container A Container A Container B

Slide 33

Slide 33 text

Microservicesアプリケーションデプロイ必要なYAMLとImageを指定してSpinnaker経由でデプロイ CI Google Kubernetes Engine yaml Namespace: service-a Container A Container A Container A Namespace: service-b Container A Container A Container B Cloud Build Container Registry code CI

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

マイクロサービス運用体制マイクロサービスで各チームが担当マイクロサービスを運用 ● 元から運用経験があるエンジニア多くない Google Kubernetes Engine Container A Container A Container A Cloud Spanner Project A Container A Container A Container B Cloud Spanner Project B Cloud Pub/Sub

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

監視体制 Datadogに集約してTimeboardやAPM、Monitor 機能を利用 Google Kubernetes Engine Container A Container A Container A Cloud Spanner Project A Go, gRPC, Docker, Kubernetes メトリクス GLB, Spanner, Pub/Sub, Stackdriver Logging 等メトリクス

Slide 41

Slide 41 text

ここまでまとめメルペイで ● 短期間でサービスリリースを実現するためマイクロサービスアーキテクチャを採用 ● 共通化された開発・運用 Platformがある ● Platform 上で、各チームがOwnershipを持って開発運用 ● 一貫性と信頼性を実現するため、各マイクロサービスアプリケーション上や開発運用プロセスでさまざまな仕組みを作っている

Slide 42

Slide 42 text

メルペイマイクロサービス課題と今後

Slide 43

Slide 43 text

開発・運用で出てきた課題一部マイクロサービスがモノリス化する ● 機能をどマイクロサービスに実装するか、判断が難しいことがある ● 1つマイクロサービスにさまざまなビジネスロジックが集まってしまう QAが難しい ● どマイクロサービスどバージョン組み合わせなか ● リリース以前開発環境どこかが壊れている状態だった運用と開発リソース調整 ● 開発が落ち着いてきたけど運用が続くサービスもあれ、これから開発が活発になるサービスもある

Slide 44

Slide 44 text

メルペイマイクロサービス今後リリースを振り返って ● サービス信頼性を高めて運用負荷を下げる改善中今後に向けて ● さらに広く使われるメルペイを目指して、引き続きさまざま機能を企画・開発しています ● バックエンド、SREなど各職種で採用してます！ Go、Microservice、Kubernetes、GCPやりたい人ご連絡ください

Slide 45

Slide 45 text

残り時間で、開発中に発生したさまざまなトラブルを紹介します

Slide 46

Slide 46 text

[1] Deploy時にリクエスト一部がエラーになる深刻度: ★

Slide 47

Slide 47 text

[1] Deploy時にリクエスト一部がエラーまずやること ● Graceful Shutdown ● Readiness/Liveness 適切な設定上記をやらないと、 ● 消えていくPodが正しくリクエストを処理しない ● 準備ができていないPodへリクエストが届く

Slide 48

Slide 48 text

[1] Deploy時にエラーが出るまだ、Kubernetesで必ず起きる問題や、gRPCだから起きる問題が残っていた ● containers.lifecycle.preStop に sleepを入れる ● terminationGracePeriodSeconds を設定する ● strategy.rollingUpdate.maxSurge を 100%にしない等設定を入れて、RollingUpdateをなめらかに行う

Slide 49

Slide 49 text

[2] Ingress 再作成に失敗する深刻度: ★★★

Slide 50

Slide 50 text

[2] Ingress 再作成に失敗前提 ● メルペイで、Ingress-GCEを利用起きたこと ● 開発環境 Ingressを作り直したところ ○ External-IPが当たらない ○ Backend-serviceが作られない ○ 設定を少し変えると作成されることもある … ○ ログに何も出ていない

Slide 51

Slide 51 text

[2] Ingress 再作成に失敗原因 ● GKE v1.10.6 （に含まれるIngress-GCE）バグだった対策 $ kubectl apply -f merpay-ingress1.yaml $ kubectl apply -f merpay-ingress2.yaml $ kubectl apply -f merpay-ingress3.yaml -> OK $ kubectl apply -f merpay-ingress4.yaml

Slide 52

Slide 52 text

[3] Ingressを追加したら、元からあったIngressが壊れた深刻度: ★★★★★

Slide 53

Slide 53 text

[3] Ingress を追加したら既存 Ingressが壊れた起きたこと ● 新しい用途 Ingressを追加したら、前から使っていたIngress （触ってない）方でリクエストが全てエラー ● 設定したい証明書と違う証明書が設定されている対応 ● いろんな設定とログを調べたが全く分からず、新しいIngressを消すと問題が解消した ● Ingress-controller ログが見られない…

Slide 54

Slide 54 text

[3] Ingress を追加したら既存 Ingressが壊れた原因 ● 2つ Ingress 設定を元に同じ HTTPS proxy を交互に更新していた ● Namespace名+Ingress名先頭55文字で区別しているため、長くて似た名前で作っていたIngressがぶつかっていた ● 実ドキュメントに書いてある ○ The total length of the namespace and name of an Ingress must not exceed 55 characters.

Slide 55

Slide 55 text

[3] Ingress を追加したら既存 Ingressが壊れた対策 ● Ingress 名前を短くした ● 長い名前 Ingressを作れないようなLintを追加した

Slide 56

Slide 56 text

[4] Podが減っていく深刻度: ★★★★★

Slide 57

Slide 57 text

[4] Podが減っていく… 起きたこと（イメージ） ● 5つあったず Podが3つになっている ● 他 2つ起動できずにRestartを繰り返している ● 他 3つがRestartして起動できなくなるも時間問題… 調査 ● エラーが曖昧なもしか出せず、原因調査が難航 ● 今動いているもを止めたくないで、ログを増やしたPodをデプロイすることもできない

Slide 58

Slide 58 text

[4] Podが減っていく… 原因 ● 起動時処理に必要な GCP APIが意図せずdisableされていた ● Terraform Diffで出ていたが、レビューでそ影響に気づけていなかった対策 ● Terraform 設定を修正して各サービスを更新

Slide 59

Slide 59 text

[5] Spannerへ Latencyがときどき大きくなる深刻度: ★★★★

Slide 60

Slide 60 text

[5] Spannerへリクエストレイテンシがときどき大きくなる前提 ● GKE上 Go アプリケーションからCloud Spanner へ読み書きを行う起きたこと ● アプリケーションを動かしていると、数100ms-数秒かかるときがときどき発生

Slide 61

Slide 61 text

[5] Spannerへリクエストレイテンシがときどき大きくなるさまざまな原因 ● クライアントライブラリgoogle-cloud-go 問題 ● Kubernetesクラスタ DNS 問題 ● アクセストークンリフレッシュ対策 ● クライアントライブラリ修正 ● DNSをアプリケーション側でキャッシュ ● アクセストークンをバックグラウンドで定期更新

Slide 62

Slide 62 text

[5] Spannerへリクエストレイテンシがときどき大きくなる詳細メルカリ Tech Blog メルペイで Spannerと戦い日々で紹介しています。

Slide 63

Slide 63 text

最後に宣伝 Google Kubernetes Engine と Cloud Spanner について 2019.07.31 Google Cloud Next Tokyo で発表します