Kubernetesの上に作る、統一されたマイクロサービス運用体験 / The Experience of Operating Microservices Built and Unified Using Kubernetes

メルペイではKubernetes上で60以上のマイクロサービスが稼働しており、それらを開発者がオーナーシップを持って運用しています。
そのような環境で、SREチームはマイクロサービス開発者の運用体験向上にフォーカスし、普段のGitOpsの延長線上でKubernetesマニフェストを記述するだけで利用できる仕組みを提供しています。これにより、SREの手を借りることなくマイクロサービス開発者がオーナーとなって運用できるようになりました。
本セッションでは、マイクロサービス開発者の運用体験を向上するための取り組みとして、Kubernetes Custom Controllerを活用したパターンや、SREチームマネージドなコンテナイメージを利用するパターンなどを紹介します。
------
Merpay Tech Fest 2022は3日間のオンライン技術カンファレンスです。
IT企業で働くソフトウェアエンジニアおよびメルペイの技術スタックに興味がある方々を対象に2022年8月23日（火）から8月25日（木）までの3日間、開催します。 Merpay Tech Festは事業との関わりから技術への興味を深め、プロダクトやサービスを支えるエンジニアリングを知れるお祭りです。 セッションでは事業を支える組織・技術・課題などへの試行錯誤やアプローチを紹介予定です。お楽しみに！

■イベント関連情報
- 公式ウェブサイト：https://events.merpay.com/techfest-2022/
- 申し込みページ：https://mercari.connpass.com/event/249428/
- Twitterハッシュタグ： #MerpayTechFest
■リンク集
- メルカリ・メルペイイベント一覧：https://mercari.connpass.com/
- メルカリキャリアサイト：https://careers.mercari.com/
- メルカリエンジニアリングブログ：https://engineering.mercari.com/blog/
- メルカリエンジニア向けTwitterアカウント：https://twitter.com/mercaridevjp
- 株式会社メルペイ：https://jp.merpay.com/

Transcript

1. Kubernetesの上に作る、 統一されたマイクロサービス運用体験 tkuchiki 株式会社メルペイ SRE
2. Taku Kuchiki / @tkuchiki 株式会社メルペイ SRE Cloud Spanner 周りの業務に従事しており、 spanner-autoscaler という OSS のメンテナをしてい ます。
3. Agenda 01 メルペイのマイクロサービスの運用 02 Kubernetesカスタムコントローラーを活用したCloud Spanner のオートスケール 03 SREマネージドコンテナイメージを使用した Cloud Spanner のバックアップ 04 運用の仕組みをKubernetes上に統一するメリット 05 まとめ
4. メルペイのマイクロサービスの運用
5. マイクロサービス運用における課題 マイクロサービスではスケーラブルな組織を作るために各チームで開発から運用 まで行う • チームごとに運用を任せてバラバラな仕組みを作ってしまうことで発生する問 題 ◦ ツール開発コストの増大 ◦ 共通の運用ルールを適用できない ◦ SREがフォローできない • 共通のプラットフォーム上でマイクロサービスを運用することで解決
6. メルペイのサービス規模 60+ 1,000+ Microservices Kubernetes Pods
7. メルペイのマイクロサービス基盤 開発者がオーナーシップを持ってサービスを構築・運用するためのプラットフォー ム • メルカリのMicroservices Platform Teamが構築・運用 ◦ TerraformでGCPリソースを管理(IaC) ◦ Kubernetes上のリソースをYAMLで管理(CaD) ▪ CI経由でのkubectl apply ▪ Spinnakerでデプロイ IaC = Infrastructure as Code, CaD = Configuration as Data
8. Configuration as Data インフラをあるべき状態を宣言したデータとして管理 • KubernetesのYAMLなど • GCPのリソースをCaDで管理するKubernetesコントローラーもある ◦ Config Connector https://cloud.google.com/blog/ja/products/containers-kubernetes/understanding-configuration-as-data-in-kubernetes
9. メルペイSREの役割 マイクロサービスプラットフォーム上での運用サポート • マイクロサービス共通のインフラの運用 • 運用にもCaDのような仕組みを提供 ◦ 本セッションでは2つの事例を紹介 CaD = Configuration as Data
10. Kubernetesカスタムコントローラーを 活用したCloud Spannerのオートスケール
11. Cloud Spanner GCPのフルマネージドリレーショナル・データベース • ダウンタイムなしでNodeを増減可能 • メルペイの標準的なデータベースとして利用 https://cloud.google.com/spanner
12. Nodeを増減させる運用フロー Developer Pull Request Cloud Spanner +/- Nodes terraform apply on CI
13. Nodeを増減させる運用フロー Developer Pull Request Cloud Spanner +/- Nodes terraform apply on CI Wait for CI Wait for CI
14. Cloud Spannerの運用における課題 Cloud SpannerのCPU使用率高騰によりレイテンシが増加してもNode追加に 時間がかかる • どのくらいNodeを追加する必要があるのか判断 • Pull Requestの作成 • コードレビューとCI待ち CPU使用率に応じてオートスケールさせたい
15. オートスケールの検討 GCPプロダクトを組み合わせる • Cloud Scheduler • Cloud Functions • Cloud Monitoring
16. オートスケールの検討 この場合、2つの運用方法が考えられる • 各マイクロサービスで運用 ◦ GCPプロジェクトごとに稼働する • 1GCPプロジェクトで稼働し、複数のGCPプロジェクトのSpannerを管理する ◦ 中央集権的にSREが運用
17. オートスケールの検討 GCPプロダクトの組み合わせでもやりたいことは実現できるが... • 各マイクロサービスで運用 ◦ 開発者が運用するものが増える • 中央集権的な運用 ◦ SREの負担が大きい ◦ 開発者のオーナーシップを損なう
18. オートスケールの検討 Kubernetesリソースとして管理できれば既存の運用フローに乗せられる • リソースのレビュー・デプロイをマイクロサービスのチーム内で完結できる Kubernetesカスタムコントローラーを実装
19. Kubernetesカスタムコントローラー • ユーザが独自に定義したリソース=カスタムリソースに対する処理を行うコント ローラー • Reconciliation loopにより、宣言した状態と実際の状態を比較し、あるべ き状態に同期し続ける
20. Reconciliation loop https://learning.oreilly.com/library/view/managing-kubernetes/9781492033905/ch03.html#fig0301
21. Reconciliation loop • 現在のNode数をあるべきNode数に同期する、と考えると相性が良さそう • HPAに似ている HPA = Horizontal Pod Autoscaler
22. spanner-autoscaler • https://github.com/mercari/spanner-autoscaler • HPAのようにCloud SpannerのNodeをオートスケールする Kubernetesカスタムコントローラー • 2020年6月リリース HPA = Horizontal Pod Autoscaler
23. spanner-autoscalerを活用した運用 SRE Developer Manage Kubernetesカスタムリソース SpannerAutoscaler カスタムリソース kubectl apply spanner-autoscaler Cloud Spanner Scale-up/down Autoscale configuration Focus on controller management Only manage YAML
24. ここまでのまとめ • Cloud SpannerのNodeを増減させる運用フローに課題があり、オートス ケールの必要性を実感 • KubernetesカスタムコントローラーのReconciliation loopの仕組みに 着目 • HPAのようにCloud SpannerをオートスケールするKubernetesカスタム コントローラーを実装
25. cloudspannerecosystem/autoscaler • https://github.com/cloudspannerecosystem/autoscaler • GCPプロダクトを組み合わせてオートスケール • 2020年9月頃リリース • CPUタスク優先度高以外のメトリクスでスケーリング可能 https://cloud.google.com/architecture/autoscaling-cloud-spanner
26. cloudspannerecosystem/autoscaler https://raw.githubusercontent.com/cloudspannerecosystem/autoscaler/master/resources/architecture-per-project.png
27. cloudspannerecosystem/autoscaler 以下の理由により採用せず • GCPプロダクトを組み合わせる実装で挙げた問題が同様に発生しそう • Kubernetesリソースとしてオートスケールの設定を管理できる方が運用体 験が良い
28. SREマネージドコンテナイメージを利用した Cloud Spannerのバックアップ
29. Cloud Spannerのバックアップ Cloud Spannerにバックアップを自動で定期的に実行する機能はない • Cloud SchedulerからAPIリクエストを送ることで定期的に実行可能 • 2つのバックアップ方法 パフォーマンス影響 ポータビリティ 保持期間 バックアップ なし インスタンスに 紐づき移動不可 最長1年間 エクスポート 低 任意のストレージ上 で保管 削除するまで
30. Cloud Spannerのバックアップ Cloud Scheduler単体でもバックアップの取得はできるが... • エクスポートジョブ失敗時にSlack通知したい • エクスポートジョブの実行時間を計測したい ツールの実装を検討
31. ツールを実装するときの選択肢 • App Engin Cronサービス • Cloud Scheduler + Cloud Functions • Cloud Scheduler + Cloud Run
32. 運用後に発生した問題 • 開発者はApp Engineを操作する権限を持たないのでSREが設定 • 設定を更新したい場合もSREに依頼
33. 運用後に発生した問題 SRE App Engine App Engine . . . Developer Deploy . . . Bottleneck Heavy workload Request . . .
34. 運用後に発生した問題の改善 App Engineのデプロイパイプラインを構築することで問題を解決できそうではあ るが... • バックアップのためだけに仕組みを追加するのは大変 • 管理するものが分散する
35. 運用後に発生した問題の改善 Spinnaker PipelineをYAMLで作成する仕組みがある • Kubernetes CronJobで実行すれば、Pipelineの構築とJobの設定を YAMLで完結できる • アプリケーションと同じように管理できる https://speakerdeck.com/keisukeyamashita/spinnakerdeshi-jian-surumaikurosabisufalse-an-quan-naririsuhurotobesutopurakuteisu?slide=57
36. 運用後に発生した問題の改善 Kubernetes CronJobで実行するためにはコンテナイメージが必要 • マイクロサービスごとにイメージを作成 ◦ 専用のDockerfileを作成してイメージをビルド • SREが作成したイメージを各マイクロサービスで使用
37. SREマネージドなイメージを使用した運用 Container Registry Developer Manage Kubernetes CronJob Run CD Pipeline Deploy Use Image SRE YAML Fetch Focus on image management Only manage YAML
38. ここまでのまとめ • Cloud Spannerのバックアップを開発者がオーナーシップを持って設定で きなかった ◦ SREの負荷も高かった • 開発者自身で設定できるように環境を整備 • 開発者のオーナーシップを損なわず、SREの負荷を軽減
39. 運用の仕組みをKubernetes上に 統一するメリット
40. 仕組みをKubernetes上に統一するメリット YAMLを書いてリソースをデプロイするだけという手軽さ • 開発者が管理するのはYAMLだけ • ツールごとにキャッチアップすべきことが少ないので運用の負担が減る
41. 仕組みをKubernetes上に統一するメリット 設定作業がチーム内で完結するためオーナーシップを損なわない • 運用の仕組みを設計する上で重要 • スケーラブルな組織をつくるためには必要不可欠
42. まとめ
43. 本セッションのまとめ • 運用体験向上のために運用にCaDの仕組みを取り入れた事例を紹介 • 運用の仕組みをKubernetes上に統一することで以下を実現 ◦ YAMLを書いてデプロイするだけの手軽さ ◦ 開発者のオーナーシップを損なわない運用環境 CaD = Configuration as Data