Upgrade to Pro — share decks privately, control downloads, hide ads and more …

メルペイのマイクロサービスとCloud Native / CloudNative Days K...

tjun
November 28, 2019

メルペイのマイクロサービスとCloud Native / CloudNative Days Kansai2019

CloudNative Days Kansai 2019のキーノートの資料です

tjun

November 28, 2019
Tweet

More Decks by tjun

Other Decks in Technology

Transcript

  1. メルペイ マイクロサービスとCloud Native CloudNative Days Kansai 2019 Merpay SRE @tjun

    Junichiro Takagi https://speakerdeck.com/tjun/cloudnative-days-kansai2019
  2. メルペイ サービス規模 マイクロサービスアーキテクチャ 40以上 マイクロサービス 2019 3Qで 1444億円以上を取り扱う メルカリ 決済基盤

    (US メルカリ事業も含む数字) 500万人以上 利用者 (メルペイ「電子マネー」 登録を行ったユーザーと、「メルペイコード払い」、「ネット決済」、 「メルペイスマート払い」等 利用者 合計(重複を除く)2019年10月時点)
  3. Why Cloud Native? メルペイ 複数 サービスを短期間で立ち上げるため Focus on single service

    各マイクロサービス 機能に集中して開発 Independent releases 独立した開発・リリース サイクル Team independence 組織を拡大しながら 複数 機能を同時に開発
  4. Why Cloud Native? Automation オートスケールや自動修 復によるシステム 安定 稼働 Scalability &

    Flexibility 独立したリソース管理が可能 ストレージも独立 Managed インフラ構築を高 化し運 用負荷を下げる
  5. メルペイ マイクロサービスで やっていないこと マイクロサービス単位で 自由な技術選択 自由な技術選択 例: 自由な言語、好きなデータベース Why? •

    共通 ツール・ライブラリを利用することで、開発や運用 度や品質を高めるため • チーム間 情報共有や人 移動を可能にするため
  6. アーキテクチャ 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 Cloud Storage
  7. 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
 レイヤーアーキテクチャ
 Project C Cloud Spanner Cloud Storage
  8. Google Kubernetes Engine Kubernetes マイクロサービス 実行基盤・オーケストレーション - 自己修復性 あるReplication Controller

    - ServiceによるLoad Balancing - DeploymentによるRollout/Rollback - Horizontal Pod Autoscalerによるスケールアウト - Kubernetes 自体 拡張性やエコシステム 早く構築し、安定して運用するためにGKEを利用
  9. マイクロサービス 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
  10. マイクロサービス 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
  11. マイクロサービス 階層構 Client アプリ、加盟店等 パートナー様 API Gateway 全て リクエストがAPI Gatewayを通る

    共通処理とルーティング API サービス クライアントから リクエストとレスポンス 責任を持つ 裏側にある複数 マイクロサービス アグリゲーション Backend サービス 機能 ロジックを実現する Backend Service API Gateway API Service Client
  12. メルペイ マイクロサービス 例 iD決済を実現する流れ API-Gateway NFC-api NFC-service payment- service リクエスト

    認証と ルーティング clientへ返すため response 作成 NFC決済を実現する ため 処理 共通 決済処理
  13. メルペイ マイクロサービス開発で 気をつけていること 一貫性 • データ 一貫性 • リトライと冪等性 •

    リコンサイル 信頼性 • DesignDoc • Production Readiness checklist • 権限管理 • Go template projectやlibraryによ る標準化
  14. マイクロサービスにおける一貫性 分散システムにおけるデータ 一貫性 担保 難しい • 決済トランザクションが複数サービスをまたがる • DBへ 書き込みや外部サービスへ

    接続が分散している • どこかで処理が失敗しても、全体として一貫性が必要 冪等性 • リトライしても二重に処理されず、正しく動く 詳しく メルカリtech blog 記事を参照 - マイクロサービスにおける決済トランザクション管理 - メルペイにおけるお客さま残高 管理手法
  15. マイクロサービス 運用 大変 マイクロサービス 数が増えるだけ運用する要素が増える • 各マイクロサービス アプリケーション • 各マイクロサービスが利用するリソース(データベース等)

    • マイクロサービス間 通信 運用 手間を減らす仕組み • マイクロサービス 構成をできるだけ揃える • Kubernetes によるオートスケールや自己修復 • Managedなクラウドサービス それでもさまざまなところで問題 起きる
  16. マイクロサービス 運用体制 マイクロサービスで 各チームが担当マイクロサービスを運用 • 元から運用経験があるエンジニア かりで ない 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
  17. マイクロサービス運用で気をつけていること SLOを設定する • サービスが正常な状態を各サービスで定義する • アラートをしたり問題を修正したりする判断 基準 Observability • Metrics:

    問題が起きたときに調査する&問題が起きる前に気づく • 分散Tracing: リクエスト どこで時間がかかっているか • Logging: 各マイクロサービス ログを横断的に見られる仕組み
  18. SLO(Service Level Objective) 運用を考えると出てくる疑問例 • 自分たち サービス 今正常な か? •

    自分たち サービス 遅い?一部 お客さまに対してだけ遅い? • CPU使用率が一瞬上がっていたが、問題ない か? SLO • 可用性、レイテンシなどシステム 信頼性 目標値 • SLOを定義することで、自分たち サービスが正常な か、Alertする か、何を修正・改善するか 判断ができる 例: あるAPI で 最低でも99.99% リクエストが 5xx以外を返す
  19. Observability Microservicesで 、1リクエストが複数 マイクロサービスを経由 する • どこでどれだけ時間がかかっている か • なぜ時間がかかっている

    か、どんなエラーが出ている か • 各マイクロサービス SLOを満たしている か Metrics, Trace, Logをサービス横断して見られるようにする ことで、問題 特定がスムーズにできる
  20. 開発・運用で出てきた課題 一部 マイクロサービスがモノリス化する • 機能をど マイクロサービスに実装するか、判断が難しいことがある • 1つ マイクロサービスにさまざまなビジネスロジックが集まってしまう QAが難しい

    • ど マイクロサービス ど バージョン 組み合わせな か • リリース以前 開発環境 どこかが壊れている状態だった 運用と開発 リソース 調整 • 開発が落ち着いてきたけど運用が続くサービスもあれ 、これから 開発が活発になるサービスもある
  21. メルペイ リリースと運用をやってきて 思うこと Cloud Native で重要な 技術セットで ない 組織体制や開発・運用 スタイルも含めた

    Culture Microservices, Ownership, 自動化, SLO...など考え方を 組織に浸透させて仕組みを作っていく が重要&大変
  22. 33