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

メルペイにおけるマイクロサービス運用の苦労と改善 / CloudNative Days To...

tjun
September 08, 2020

メルペイにおけるマイクロサービス運用の苦労と改善 / CloudNative Days Tokyo2020

2020.09.08 に CloudNative Days Tokyo2020 で発表した内容です。
メルペイの1年半におけるマイクロサービス運用の経験と苦労した事例について紹介しました。

tjun

September 08, 2020
Tweet

More Decks by tjun

Other Decks in Technology

Transcript

  1. 自己紹介 • twitter: @tjun • Merpay SREチーム ◦ Engineering Manager

    & Tech Lead • 2018年4月メルペイ入社 • 昨年のCloudNative Days Tokyo 2019でも発表 「メルペイのマイクロサービスの構築と運用」 昨年の資料 https://speakerdeck.com/tjun/cloudnative-days-tokyo2019
  2. 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 アーキテクチャ Google Cloud Platform
 3
 1
 2
 マイクロサービス
 on Kubernetes
 レイヤーアーキテクチャ

  3. Google Kubernetes Engine Kubernetes マイクロサービスの実行基盤・オーケストレーション - 自己修復性のあるReplication Controller - ServiceによるLoad

    Balancing - DeploymentによるRollout/Rollback - Horizontal Pod Autoscalerによるスケールアウト - Kubernetes 自体の拡張性やエコシステム サービス開発に集中し、安定して運用するために Managedな Kubernetesを利用
  4. 開発運用組織とマイクロサービス 各機能を実現する Product開発チーム • バックエンドエンジニア • フロントエンドエンジニア • iOS/Androidエンジニア •

    QAエンジニア • デザイナー • PM 共通基盤とサービス全体を見る Platform寄りのチーム • SRE • アーキテクトチーム • Microservices Platformチーム • ソリューションチーム • Data platformチーム • Machine Learningチーム
  5. メルペイのEngineering組織 Product D Product C Product B Product A Product

    Engineering PM PM PM PM TL ... TL ... TL EM EM EM EM EM TL SRE Backend 1 Backend 2 iOS Frontend EM Android
  6. マイクロサービスの運用は大変 マイクロサービスの数が増えるだけ運用する要素が増える • 各マイクロサービスのアプリケーション • 各マイクロサービスが利用するリソース(データベース等) • マイクロサービス間の通信 • 接続する外部のシステム

    運用の手間を減らす仕組み • マイクロサービスの構成をできるだけ揃える • Kubernetes によるオートスケールや自己修復 • Managedなクラウドサービス それでもさまざまなところで問題は起きる
  7. SLO(Service Level Objective) 運用を考えると出てくる疑問 • 自分たちのサービスは今正常なのか? • 自分たちのサービスは遅い?一部のお客さまに対してだけ遅い? • CPU使用率が一瞬上がっていたが、問題ないのか?

    SLOとは • Availability、Latencyなどシステムの信頼性の目標値 ◦ 例: API Xでは 99.99%のリクエストが 5xx以外を返す • SLOを定義することで、自分たちのサービスが正常なのか、Alertする か、修正すべきかの判断ができる
  8. 監視体制 メトリクス、Trace、LogをDatadogに集約 Google Kubernetes Engine Container A Container A Container

    A Cloud Spanner Project A Go, gRPC, Docker, Kubernetes の メトリクス, ログ, Trace Cloud Spanner, Pub/Sub, Load Balancer等の メトリクス
  9. マイクロサービス開発運用で出てきた課題 開発における課題 • マイクロサービス開発者の負荷が高い • マイクロサービスのQAが難しい 運用における課題 • 障害の起きた箇所の特定が難しい •

    サービス全体の信頼性の実現が難しい • インフラコストの増加 組織の課題 • 組織の流動性が低い • マイクロサービス間の情報共有
  10. 開発における課題1 マイクロサービス開発者の負荷の増加 マイクロサービス開発者の担当範囲(開発関連) • 金融ドメインのサービス設計と開発 ◦ さまざまな社内のbest practiceを反映 • 利用するGCP

    resourceをTerraformで作成 • Kubernetes のYAMLを書いて、必要なDeployment, CronJobなどを 設定 • Spinnakerを使ってApplicationやJobのデプロイ • DatadogでDashboardとMonitorを作成
  11. マイクロサービス開発者の担当範囲(運用関連) • DatadogでDashboardとMonitorを作成 • 担当マイクロサービスのアラート対応 ◦ メトリクス、ログ、トレースをマイクロサービス横断して確認 ◦ 不整合データの対応 ◦

    Incident Reportの作成 • 継続的なサービスの改善 加えて、運用するマイクロサービスが増えたり複雑化することによって、負 荷が高まっている 開発における課題1 マイクロサービス開発者の負荷の増加
  12. マイクロサービス開発運用の生産性を高める仕組み Microservices Platform • マイクロサービスの作成・開発・運用が簡単に行える仕組みを提供 • CI/CDまわりの改善など開発者の生産性を向上している ArchitectやSRE, Solution teamによる共通課題の解決

    • テストの自動化やQAの並列化 • 開発・運用のためのツールの提供 • 運用改善の支援、SREがProjectに入って支援できる仕組みづくり • GCP(おもにCloud Spanner)まわりの情報提供 開発における課題1 マイクロサービス開発者の負荷の増加
  13. コストの可視化と削減 BigQueryに入れたコストのデータを可視化・分析 • Google Cloudのサービス単位 (Cloud Spanner, Cloud Storage...) •

    マイクロサービス単位 大きなコストがかかっていたBackupや Logging の設定を全マイクロサービスで修正 運用における課題3 インフラコストの増加
  14. 組織における課題1 マイクロサービスと組織の流動性 Ownershipと金融ドメイン • マイクロサービスは開発した人がOwnershipを持って運用する • 金融ドメインの処理やパートナーのシステムとの連携など、 マイクロサービス毎にドメイン知識が必要 流動性は不要? •

    組織としては、安定運用しながら新規案件のサービスに開発者を増や したい • エンジニア個人としては、同じサービスの運用を続けていると 運用疲れしたり飽きてきたりすることもある
  15. 組織における課題2 情報共有のための取り組みの例 毎週のチーム横断ミーティング • 各チームのTech Leadを中心に、お願いや困っていることなどの 情報を共有する会を実施 ドキュメントの整備 • Microservices

    PlatformチームがPlatformに関するドキュメントを 整備して提供 横断施策のトラッキング • 各チームで実施して欲しい対応は、PullRequestの自動作成など 行いつつ、最終的にはSpreadSheetで管理してSREがtrackingする
  16. 組織とマイクロサービス 各機能を実現する Product開発チーム • バックエンドエンジニア • フロントエンドエンジニア • iOS/Androidエンジニア •

    QAエンジニア • デザイナー • PM マイクロサービス共通の課題を解決し、組織とシステムをスケール するためには、横串の組織との連携が必要 共通基盤とサービス全体を 見るPlatform寄りの横串チーム • SRE • アーキテクトチーム • Microservices Platformチーム • ソリューションチーム • Data platformチーム • MLチーム
  17. 46