Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
DMMプラットフォーム ゼロから始めるKubernetes運用 課題と改善
Search
pospome
July 31, 2022
Technology
0
3.5k
DMMプラットフォーム ゼロから始めるKubernetes運用 課題と改善
"Cloud Operator Days Tokyo 2022" の登壇資料です。
pospome
July 31, 2022
Tweet
Share
More Decks by pospome
See All by pospome
技術好きなエンジニアが "リーダーへの進化" によって得たものと失ったもの
pospome
5
1.3k
DMMプラットフォームにおけるTiDBの導入から運用まで
pospome
8
4k
DMMプラットフォームがTiDB Cloudを採用した背景
pospome
10
5.7k
DDDはなぜ難しいのか / 良いコードの定義と設計能力の壁
pospome
41
18k
マイクロサービス環境におけるDB戦略 in DMMプラットフォーム
pospome
12
4.2k
組織全体で開発生産性に取り組むために 専門チームを作った話
pospome
2
1.9k
DMMプラットフォームにおける GKE を利用した プラットフォームエンジニアリングへの 取り組み
pospome
1
760
DMMプラットフォームにおけるコード品質を改善する取り組みの理想と現実
pospome
3
2.7k
(再アップロード)Microservices & APIs
pospome
0
160
Other Decks in Technology
See All in Technology
Redefine_Possible
upsider_tech
0
220
PHPでアクターモデルを活用したSagaパターンの実践法 / php-saga-pattern-with-actor-model
ytake
0
990
Cline、めっちゃ便利、お金が飛ぶ💸
iwamot
19
18k
Explainable Software Engineering in the Public Sector
avandeursen
0
340
問題解決に役立つ数理工学
recruitengineers
PRO
6
970
チームの性質によって変わる ADR との向き合い方と、生成 AI 時代のこれから / How to deal with ADR depends on the characteristics of the team
mh4gf
4
320
20250326_管理ツールの権限管理で改善したこと
sasata299
1
290
Keynote - KCD Brazil - Platform Engineering on K8s (portuguese)
salaboy
0
120
ウェブアクセシビリティとは
lycorptech_jp
PRO
0
230
技術好きなエンジニアが _リーダーへの進化_ によって得たものと失ったもの / The Gains and Losses of a Tech-Enthusiast Engineer’s “Evolution into Leadership”
kaminashi
0
200
空が堕ち、大地が割れ、海が涸れた日~もしも愛用しているフレームワークが開発停止したら?~ #phperkaigi 2025
77web
2
980
ペアプログラミングにQAが加わった!職能を超えたモブプログラミングの事例と学び
tonionagauzzi
1
130
Featured
See All Featured
Faster Mobile Websites
deanohume
306
31k
Mobile First: as difficult as doing things right
swwweet
223
9.5k
Product Roadmaps are Hard
iamctodd
PRO
52
11k
Why Our Code Smells
bkeepers
PRO
336
57k
Done Done
chrislema
183
16k
Reflections from 52 weeks, 52 projects
jeffersonlam
349
20k
Agile that works and the tools we love
rasmusluckow
328
21k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
160
15k
jQuery: Nuts, Bolts and Bling
dougneiner
63
7.7k
What’s in a name? Adding method to the madness
productmarketing
PRO
22
3.4k
KATA
mclloyd
29
14k
How to Think Like a Performance Engineer
csswizardry
22
1.5k
Transcript
DMMプラットフォーム ゼロから始めるk8s運用 課題と改善
スピーカー 名前:pospome(ぽすぽめ) 所属:DMM Twitter:https://twitter.com/pospome 職種:サーバサイド & SRE見習い
ゼロから始めるk8s運用 課題と改善 k8sを運用して直面した課題 1. 引き継いだGKEクラスター 2. SREチームのエンジニアが足りない 3. SREチームにk8sの知見が足りない 4. k8s利用者の学習コストが高い
DMMプラットフォームの概要 扱う領域:会員、決済、不正対策、認証認可など エンジニア数:100名以上 開発チーム:16チーム マイクロサービス数:約40サービス ピーク時のリクエスト数:14,000RPS
マイクロサービスアーキテクトグループ SREチーム k8sクラスターを運用している。 DMMプラットフォームのインフラ周りのエコシステムを構築 し、組織全体の開発効率とセキュリティレベルを向上させる ミッションを持つチームである。
DMMプラットフォーム ざっくりシステムアーキテクチャ GKEクラスター API Gateway (golang) Client Microservices オンプレ Microservices
GKEクラスターについて • DMMプラットフォームにて共通利用する。 • オンプレ上のアプリケーションの移行先である。
ゼロから始めるk8s運用 課題と改善 1. 引き継いだGKEクラスター 2. SREチームのエンジニアが足りない 3. SREチームにk8sの知見が足りない 4. k8s利用者の学習コストが高い
ゼロから始めるk8s運用 課題と改善 1. 引き継いだGKEクラスター 2. SREチームのエンジニアが足りない 3. SREチームにk8sの知見が足りない 4. k8s利用者の学習コストが高い
課題:引き継いだGKEクラスター 運用に必要な仕組みが整っていなかった。 • Alert/Monitoring • クラスターアップグレード • その他いろいろ
安定運用できる仕組みを整える 主に以下を実施した。 1. Datadog による Metrics, Monitor, SLO の整備 2.
クラスターのアップグレードルールの定義 3. GKEやアプリケーションの各種設定の導入 4. 運用定例の実施
組織としてk8sをどのように活かすか 専任のチームがないと運用するのは難しい。 専任のチームを作り、マルチテナント & エコシステム活用に よって組織全体の開発効率を向上させる戦略を取る必要 がある。 Cloud Run, ECSの下位互換にならないように・・・。
ゼロから始めるk8s運用 課題と改善 1. 引き継いだGKEクラスター 2. SREチームのエンジニアが足りない 3. SREチームにk8sの知見が足りない 4. k8s利用者の学習コストが高い
課題:SREチームのエンジニアが足りない 当時の立ち上げたばかりのSREチームはエンジニアが1名 + pospome の2名体制だった。 シンプルにエンジニアが足りない。
SREチームが開発で意識していること • 一元管理 • 自動化 • スケールする仕組みづくり
“スケールする仕組みづくり”は最も重要である GKEの利用者や稼働するアプリケーション数に比例して SREチームのエンジニア数を増やさなくて良いようにする。
仕組み:k8sマニフェストをモノレポで管理する アプリケーションごとに ディレクトリを用意し、 コードオーナーを設定する。 利用者が自分で管理し、 更新することができる。
仕組み:マニフェストファイルの新規作成 GitHub Actions WorkFlow から 新規アプリケーションの マニフェストファイルを作成できる。 SREの承認なしで利用者が作成できる。
仕組み:マニフェストファイルに対するCI 適切なマニフェストファイルであることをCIでチェックしてい る。 最低限のガードレールは必要になる。 e.g. ポッドの CPU, Memory の request/limit
の指定がある かどうか。
仕組み:CDパイプライン CDパイプラインとしてSpinnakerを採用している。 利用者が自分でデプロイできる。
仕組み:RBACによる権限管理 1アプリケーション = 1Namespace の構成にしている。 Namespace単位のRBACは利用者自身で管理してもらう。 チームの都合に合わせて権限管理できる。
SREチームが開発で意識していること 仕組み 一元管理 自動化 スケールする マニフェストファイル 管理 o - o
マニフェストファイル CI - o o マニフェストファイル 作成 - o o CDパイプライン o - o RBAC - - o
スケールする仕組みづくりの実現方法 利用者にオーナーシップを持たせることで、利用者自身で 安全に作業が完結しするような仕組みを目指す。
スケールする仕組みづくりの実現方法 マニフェストファイル、Namespace、RBACなどあらゆるリ ソースをアプリケーション単位で管理している。 SREチームが開発した仕組みが組織体制の変更による影 響を受けないようにしている。
利用者のオーナーシップ vs SREによる管理 どこまでオーナーシップを持たせるのかが重要である。 オーナーシップと安全性を天秤にかける。
ゼロから始めるk8s運用 課題と改善 1. 引き継いだGKEクラスター 2. SREチームのエンジニアが足りない 3. SREチームにk8sの知見が足りない 4. k8s利用者の学習コストが高い
課題:SREチームにk8sの知見が足りない GKEの構築・運用経験に乏しく、知識と経験が足りなかっ た。
課題:SREチームにk8sの知見が足りない 事故りながら知見を得た。 • 特定のノードのLoad Averageが極端に高い → Deschedulerの導入 • Egress がドロップする
→Cloud NATの設定変更
課題:SREチームにk8sの知見が足りない 問題を最小限に抑える必要がある。 • 監視(Datadog Monitor)による異変の検知 • 運用定例によるメトリクス確認 • サンプルアプリケーションの開発・運用
課題:SREチームにk8sの知見が足りない オンプレからGKEへの移行ということもあり、ゆっくりとアプ リケーションが増えていったので、仕組みづくりや知見獲得 に時間をかけることができた。
ゼロから始めるk8s運用 課題と改善 1. 引き継いだGKEクラスター 2. SREチームのエンジニアが足りない 3. SREチームにk8sの知見が足りない 4. k8s利用者の学習コストが高い
課題:k8s利用者の学習コストが高い 開発チームにはk8sやCDパイプラインなどのエコシステム を理解してもらう必要がある。 SREのサポートなしで開発チームが自立してエコシステムを 理解できるのが理想である(スケールする仕組み)。
課題:k8s利用者の学習コストが高い 利用者の学習コストを下げる仕組み。 • 利用者ドキュメント • サンプルアプリケーションの提供 • テックリードミーティングやSlackでの情報共有
まとめ ゼロから始める場合、人が少なかったり、知見がなかったり するが、人が揃うまで待つわけにはいかないので、スモー ルスタートで始めてみるのが良いと思う。
おわり ご清聴ありがとうございました