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

Slide 1

Slide 1 text

Kubernetesの上に作る、統一されたマイクロサービス運用体験 tkuchiki 株式会社メルペイ SRE

Slide 2

Slide 2 text

Taku Kuchiki / @tkuchiki 株式会社メルペイ SRE Cloud Spanner 周りの業務に従事しており、 spanner-autoscaler という OSS のメンテナをしています。

Slide 3

Slide 3 text

Agenda 01 メルペイのマイクロサービスの運用 02 Kubernetesカスタムコントローラーを活用したCloud Spanner のオートスケール 03 SREマネージドコンテナイメージを使用した Cloud Spanner のバックアップ 04 運用の仕組みをKubernetes上に統一するメリット 05 まとめ

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

マイクロサービス運用における課題マイクロサービスではスケーラブルな組織を作るために各チームで開発から運用まで行う ● チームごとに運用を任せてバラバラな仕組みを作ってしまうことで発生する問題 ○ ツール開発コストの増大 ○ 共通の運用ルールを適用できない ○ SREがフォローできない ● 共通のプラットフォーム上でマイクロサービスを運用することで解決

Slide 6

Slide 6 text

メルペイのサービス規模 60+ 1,000+ Microservices Kubernetes Pods

Slide 7

Slide 7 text

メルペイのマイクロサービス基盤開発者がオーナーシップを持ってサービスを構築・運用するためのプラットフォーム ● メルカリのMicroservices Platform Teamが構築・運用 ○ TerraformでGCPリソースを管理(IaC) ○ Kubernetes上のリソースをYAMLで管理(CaD) ■ CI経由でのkubectl apply ■ Spinnakerでデプロイ IaC = Infrastructure as Code, CaD = Conﬁguration as Data

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

メルペイSREの役割マイクロサービスプラットフォーム上での運用サポート ● マイクロサービス共通のインフラの運用 ● 運用にもCaDのような仕組みを提供 ○ 本セッションでは2つの事例を紹介 CaD = Conﬁguration as Data

Slide 10

Slide 10 text

Kubernetesカスタムコントローラーを活用したCloud Spannerのオートスケール

Slide 11

Slide 11 text

Cloud Spanner GCPのフルマネージドリレーショナル・データベース ● ダウンタイムなしでNodeを増減可能 ● メルペイの標準的なデータベースとして利用 https://cloud.google.com/spanner

Slide 12

Slide 12 text

Nodeを増減させる運用フロー Developer Pull Request Cloud Spanner +/- Nodes terraform apply on CI

Slide 13

Slide 13 text

Nodeを増減させる運用フロー Developer Pull Request Cloud Spanner +/- Nodes terraform apply on CI Wait for CI Wait for CI

Slide 14

Slide 14 text

Cloud Spannerの運用における課題 Cloud SpannerのCPU使用率高騰によりレイテンシが増加してもNode追加に時間がかかる ● どのくらいNodeを追加する必要があるのか判断 ● Pull Requestの作成 ● コードレビューとCI待ち CPU使用率に応じてオートスケールさせたい

Slide 15

Slide 15 text

オートスケールの検討 GCPプロダクトを組み合わせる ● Cloud Scheduler ● Cloud Functions ● Cloud Monitoring

Slide 16

Slide 16 text

オートスケールの検討この場合、2つの運用方法が考えられる ● 各マイクロサービスで運用 ○ GCPプロジェクトごとに稼働する ● 1GCPプロジェクトで稼働し、複数のGCPプロジェクトのSpannerを管理する ○ 中央集権的にSREが運用

Slide 17

Slide 17 text

オートスケールの検討 GCPプロダクトの組み合わせでもやりたいことは実現できるが... ● 各マイクロサービスで運用 ○ 開発者が運用するものが増える ● 中央集権的な運用 ○ SREの負担が大きい ○ 開発者のオーナーシップを損なう

Slide 18

Slide 18 text

オートスケールの検討 Kubernetesリソースとして管理できれば既存の運用フローに乗せられる ● リソースのレビュー・デプロイをマイクロサービスのチーム内で完結できる Kubernetesカスタムコントローラーを実装

Slide 19

Slide 19 text

Kubernetesカスタムコントローラー ● ユーザが独自に定義したリソース=カスタムリソースに対する処理を行うコントローラー ● Reconciliation loopにより、宣言した状態と実際の状態を比較し、あるべき状態に同期し続ける

Slide 20

Slide 20 text

Reconciliation loop https://learning.oreilly.com/library/view/managing-kubernetes/9781492033905/ch03.html#ﬁg0301

Slide 21

Slide 21 text

Reconciliation loop ● 現在のNode数をあるべきNode数に同期する、と考えると相性が良さそう ● HPAに似ている HPA = Horizontal Pod Autoscaler

Slide 22

Slide 22 text

spanner-autoscaler ● https://github.com/mercari/spanner-autoscaler ● HPAのようにCloud SpannerのNodeをオートスケールする Kubernetesカスタムコントローラー ● 2020年6月リリース HPA = Horizontal Pod Autoscaler

Slide 23

Slide 23 text

spanner-autoscalerを活用した運用 SRE Developer Manage Kubernetesカスタムリソース SpannerAutoscaler カスタムリソース kubectl apply spanner-autoscaler Cloud Spanner Scale-up/down Autoscale conﬁguration Focus on controller management Only manage YAML

Slide 24

Slide 24 text

ここまでのまとめ ● Cloud SpannerのNodeを増減させる運用フローに課題があり、オートスケールの必要性を実感 ● KubernetesカスタムコントローラーのReconciliation loopの仕組みに着目 ● HPAのようにCloud SpannerをオートスケールするKubernetesカスタムコントローラーを実装

Slide 25

Slide 25 text

cloudspannerecosystem/autoscaler ● https://github.com/cloudspannerecosystem/autoscaler ● GCPプロダクトを組み合わせてオートスケール ● 2020年9月頃リリース ● CPUタスク優先度高以外のメトリクスでスケーリング可能 https://cloud.google.com/architecture/autoscaling-cloud-spanner

Slide 26

Slide 26 text

cloudspannerecosystem/autoscaler https://raw.githubusercontent.com/cloudspannerecosystem/autoscaler/master/resources/architecture-per-project.png

Slide 27

Slide 27 text

cloudspannerecosystem/autoscaler 以下の理由により採用せず ● GCPプロダクトを組み合わせる実装で挙げた問題が同様に発生しそう ● Kubernetesリソースとしてオートスケールの設定を管理できる方が運用体験が良い

Slide 28

Slide 28 text

SREマネージドコンテナイメージを利用した Cloud Spannerのバックアップ

Slide 29

Slide 29 text

Cloud Spannerのバックアップ Cloud Spannerにバックアップを自動で定期的に実行する機能はない ● Cloud SchedulerからAPIリクエストを送ることで定期的に実行可能 ● 2つのバックアップ方法パフォーマンス影響ポータビリティ保持期間バックアップなしインスタンスに紐づき移動不可最長1年間エクスポート低任意のストレージ上で保管削除するまで

Slide 30

Slide 30 text

Cloud Spannerのバックアップ Cloud Scheduler単体でもバックアップの取得はできるが... ● エクスポートジョブ失敗時にSlack通知したい ● エクスポートジョブの実行時間を計測したいツールの実装を検討

Slide 31

Slide 31 text

ツールを実装するときの選択肢 ● App Engin Cronサービス ● Cloud Scheduler + Cloud Functions ● Cloud Scheduler + Cloud Run

Slide 32

Slide 32 text

運用後に発生した問題 ● 開発者はApp Engineを操作する権限を持たないのでSREが設定 ● 設定を更新したい場合もSREに依頼

Slide 33

Slide 33 text

運用後に発生した問題 SRE App Engine App Engine . . . Developer Deploy . . . Bottleneck Heavy workload Request . . .

Slide 34

Slide 34 text

運用後に発生した問題の改善 App Engineのデプロイパイプラインを構築することで問題を解決できそうではあるが... ● バックアップのためだけに仕組みを追加するのは大変 ● 管理するものが分散する

Slide 35

Slide 35 text

運用後に発生した問題の改善 Spinnaker PipelineをYAMLで作成する仕組みがある ● Kubernetes CronJobで実行すれば、Pipelineの構築とJobの設定を YAMLで完結できる ● アプリケーションと同じように管理できる https://speakerdeck.com/keisukeyamashita/spinnakerdeshi-jian-surumaikurosabisufalse-an-quan-naririsuhurotobesutopurakuteisu?slide=57

Slide 36

Slide 36 text

運用後に発生した問題の改善 Kubernetes CronJobで実行するためにはコンテナイメージが必要 ● マイクロサービスごとにイメージを作成 ○ 専用のDockerﬁleを作成してイメージをビルド ● SREが作成したイメージを各マイクロサービスで使用

Slide 37

Slide 37 text

SREマネージドなイメージを使用した運用 Container Registry Developer Manage Kubernetes CronJob Run CD Pipeline Deploy Use Image SRE YAML Fetch Focus on image management Only manage YAML

Slide 38

Slide 38 text

ここまでのまとめ ● Cloud Spannerのバックアップを開発者がオーナーシップを持って設定できなかった ○ SREの負荷も高かった ● 開発者自身で設定できるように環境を整備 ● 開発者のオーナーシップを損なわず、SREの負荷を軽減

Slide 39

Slide 39 text

運用の仕組みをKubernetes上に統一するメリット

Slide 40

Slide 40 text

仕組みをKubernetes上に統一するメリット YAMLを書いてリソースをデプロイするだけという手軽さ ● 開発者が管理するのはYAMLだけ ● ツールごとにキャッチアップすべきことが少ないので運用の負担が減る

Slide 41

Slide 41 text

仕組みをKubernetes上に統一するメリット設定作業がチーム内で完結するためオーナーシップを損なわない ● 運用の仕組みを設計する上で重要 ● スケーラブルな組織をつくるためには必要不可欠

Slide 42

Slide 42 text

まとめ

Slide 43

Slide 43 text

本セッションのまとめ ● 運用体験向上のために運用にCaDの仕組みを取り入れた事例を紹介 ● 運用の仕組みをKubernetes上に統一することで以下を実現 ○ YAMLを書いてデプロイするだけの手軽さ ○ 開発者のオーナーシップを損なわない運用環境 CaD = Conﬁguration as Data

Slide 44

Slide 44 text

No content