DMMプラットフォームゼロから始めるKubernetes運用課題と改善

by pospome

Slide 1

Slide 1 text

DMMプラットフォームゼロから始めるk8s運用課題と改善

Slide 2

Slide 2 text

スピーカー名前：pospome（ぽすぽめ）所属：DMM Twitter：https://twitter.com/pospome 職種：サーバサイド & SRE見習い

Slide 3

Slide 3 text

ゼロから始めるk8s運用　課題と改善 k8sを運用して直面した課題 1. 引き継いだGKEクラスター 2. SREチームのエンジニアが足りない 3. SREチームにk8sの知見が足りない 4. k8s利用者の学習コストが高い

Slide 4

Slide 4 text

DMMプラットフォームの概要扱う領域：会員、決済、不正対策、認証認可などエンジニア数：100名以上開発チーム：16チームマイクロサービス数：約40サービスピーク時のリクエスト数：14,000RPS

Slide 5

Slide 5 text

マイクロサービスアーキテクトグループ SREチーム k8sクラスターを運用している。 DMMプラットフォームのインフラ周りのエコシステムを構築し、組織全体の開発効率とセキュリティレベルを向上させるミッションを持つチームである。

Slide 6

Slide 6 text

DMMプラットフォームざっくりシステムアーキテクチャ GKEクラスター API Gateway (golang) Client Microservices オンプレ Microservices

Slide 7

Slide 7 text

GKEクラスターについて ● DMMプラットフォームにて共通利用する。 ● オンプレ上のアプリケーションの移行先である。

Slide 8

Slide 8 text

ゼロから始めるk8s運用　課題と改善 1. 引き継いだGKEクラスター 2. SREチームのエンジニアが足りない 3. SREチームにk8sの知見が足りない 4. k8s利用者の学習コストが高い

Slide 9

Slide 9 text

Slide 10

Slide 10 text

課題：引き継いだGKEクラスター運用に必要な仕組みが整っていなかった。 ● Alert/Monitoring ● クラスターアップグレード ● その他いろいろ

Slide 11

Slide 11 text

安定運用できる仕組みを整える主に以下を実施した。 1. Datadog による Metrics, Monitor, SLO の整備 2. クラスターのアップグレードルールの定義 3. GKEやアプリケーションの各種設定の導入 4. 運用定例の実施

Slide 12

Slide 12 text

組織としてk8sをどのように活かすか専任のチームがないと運用するのは難しい。専任のチームを作り、マルチテナント & エコシステム活用によって組織全体の開発効率を向上させる戦略を取る必要がある。 Cloud Run, ECSの下位互換にならないように・・・。

Slide 13

Slide 13 text

Slide 14

Slide 14 text

課題：SREチームのエンジニアが足りない当時の立ち上げたばかりのSREチームはエンジニアが1名 + pospome の2名体制だった。シンプルにエンジニアが足りない。

Slide 15

Slide 15 text

SREチームが開発で意識していること ● 一元管理 ● 自動化 ● スケールする仕組みづくり

Slide 16

Slide 16 text

“スケールする仕組みづくり”は最も重要である GKEの利用者や稼働するアプリケーション数に比例して SREチームのエンジニア数を増やさなくて良いようにする。

Slide 17

Slide 17 text

仕組み：k8sマニフェストをモノレポで管理するアプリケーションごとにディレクトリを用意し、コードオーナーを設定する。利用者が自分で管理し、更新することができる。

Slide 18

Slide 18 text

仕組み：マニフェストファイルの新規作成 GitHub Actions WorkFlow から新規アプリケーションのマニフェストファイルを作成できる。 SREの承認なしで利用者が作成できる。

Slide 19

Slide 19 text

仕組み：マニフェストファイルに対するCI 適切なマニフェストファイルであることをCIでチェックしている。最低限のガードレールは必要になる。 e.g. ポッドの CPU, Memory の request/limit の指定があるかどうか。

Slide 20

Slide 20 text

仕組み：CDパイプライン CDパイプラインとしてSpinnakerを採用している。利用者が自分でデプロイできる。

Slide 21

Slide 21 text

仕組み：RBACによる権限管理 1アプリケーション = 1Namespace の構成にしている。 Namespace単位のRBACは利用者自身で管理してもらう。チームの都合に合わせて権限管理できる。

Slide 22

Slide 22 text

SREチームが開発で意識していること仕組み一元管理自動化スケールするマニフェストファイル管理 o - o マニフェストファイル CI - o o マニフェストファイル作成 - o o CDパイプライン o - o RBAC - - o

Slide 23

Slide 23 text

スケールする仕組みづくりの実現方法利用者にオーナーシップを持たせることで、利用者自身で安全に作業が完結しするような仕組みを目指す。

Slide 24

Slide 24 text

スケールする仕組みづくりの実現方法マニフェストファイル、Namespace、RBACなどあらゆるリソースをアプリケーション単位で管理している。 SREチームが開発した仕組みが組織体制の変更による影響を受けないようにしている。

Slide 25

Slide 25 text

利用者のオーナーシップ vs SREによる管理どこまでオーナーシップを持たせるのかが重要である。オーナーシップと安全性を天秤にかける。

Slide 26

Slide 26 text

Slide 27

Slide 27 text

課題：SREチームにk8sの知見が足りない GKEの構築・運用経験に乏しく、知識と経験が足りなかった。

Slide 28

Slide 28 text

課題：SREチームにk8sの知見が足りない事故りながら知見を得た。 ● 特定のノードのLoad Averageが極端に高い → Deschedulerの導入 ● Egress がドロップする →Cloud NATの設定変更

Slide 29

Slide 29 text

課題：SREチームにk8sの知見が足りない問題を最小限に抑える必要がある。 ● 監視（Datadog Monitor）による異変の検知 ● 運用定例によるメトリクス確認 ● サンプルアプリケーションの開発・運用

Slide 30

Slide 30 text

課題：SREチームにk8sの知見が足りないオンプレからGKEへの移行ということもあり、ゆっくりとアプリケーションが増えていったので、仕組みづくりや知見獲得に時間をかけることができた。

Slide 31

Slide 31 text

Slide 32

Slide 32 text

課題：k8s利用者の学習コストが高い開発チームにはk8sやCDパイプラインなどのエコシステムを理解してもらう必要がある。 SREのサポートなしで開発チームが自立してエコシステムを理解できるのが理想である（スケールする仕組み）。

Slide 33

Slide 33 text

課題：k8s利用者の学習コストが高い利用者の学習コストを下げる仕組み。 ● 利用者ドキュメント ● サンプルアプリケーションの提供 ● テックリードミーティングやSlackでの情報共有

Slide 34

Slide 34 text

まとめゼロから始める場合、人が少なかったり、知見がなかったりするが、人が揃うまで待つわけにはいかないので、スモールスタートで始めてみるのが良いと思う。

Slide 35

Slide 35 text

おわりご清聴ありがとうございました