Kubernetes環境周りの責任範囲をいい機会なので考える / Taking the Opportunity to Clarify Kubernetes Responsibilities

[ログラス×みてね] Platform Engineeringを支えるKubernetes活用実例
https://mixi.connpass.com/event/382719/

Transcript

1. ©MIXI 1 Kubernetes環境周りの責任範囲を いい機会なので考える 2026/02/19 [ログラス×みてね] Platform Engineeringを⽀えるKubernetes活⽤実例 @kohbis
2. 2 ©MIXI ABOUT ME Kohei SUGIMOTO 株式会社MIXI • 2022/04 ~ 『家族アルバム みてね』SRE X / @kohbis
3. 3 ©MIXI （本題の前に）前提 『家族アルバム みてね』（以下『みてね』） ではSREグループが インフラやプラットフォームも対応 • アプリケーション開発は複数のストリームアラインドなドメインチーム • 横断的な組織としてプラットフォーム部があり、そのなかにSREグループがある SREグループがEKSクラスタを管理 • Argo CDによるGitOps • Helm ChartによるYAML管理    過去のアウトプットは 「みてね EKS」や「みてね K8s」で ドメインA ドメインB ドメインC チームα チームβ チームγ プラットフォーム部 CRE Security SRE
4. 4 ©MIXI 本⽇お話しすること 『みてね』におけるKubernetes（Amazon EKS）環境周りの責任範囲を いい機会なので考えてみた話 • 『みてね』のKubernetes運⽤で、責任範囲はどう機能しているのだろう？ • SREチームが持つ範囲とドメインチームが触る範囲はどこで分かれるのだろう？ • 責任範囲を成り⽴たせる要素はなんだろう？ • そもそも「責任範囲」とはなんだろう？ 「Kubernetes活⽤実例」と銘打たれたイベントで 「⾃組織」で「Kubernetes環境」を「プラットフォーム」たらしめるものは何か 整理する（いいのか？いいよね？） ※ このスライドではKubernetesとEKSを適宜使い分けますがご容赦ください
5. 5 ©MIXI なぜ「考えよう」と思ったのか 『みてね』ではEKS環境に対して複数チームから変更が⾏われている 現時点※1では設定ミスなどによる⼤きな問題は起きていない それは「いまの構成がある程度適切に動いている」からだと思っている （もちろんたまたまの可能性もある） しかし「なぜか」がわからなければ、次のアクションにつながらない なのでこのタイミングで⾔語化‧明確化したい 現在地の把握、再現性の確保、今後の改善へとつなげたい（ここが重要） ※1 2026/02時点
6. 6 ©MIXI そもそも「責任範囲」ってなんだろう？（1/2） なんとなく定義してみる • 「責任範囲」＝ 誰が何を「変更する‧できる」かの境界 • 「変更する‧できる」＝ その結果（パフォーマンスやコストなど）に向き合う なんとなくKubernetes環境で想像してみる • SREチーム 基盤（クラスタや共通コンポーネント）管理、ガードレール設置 • ドメインチーム ワークロード（Deploymentなど）の設定 とりあえずRACI（後述）で棚卸ししてみるとよさそう？
7. 7 ©MIXI そもそも「責任範囲」ってなんだろう？（2/2）〜RACI〜 RACIチャート（マトリクス） • プロジェクトにおける役割と責任を定義、明確化する • 明確なコミュニケーションの確立、意思決定の改善、タスクや成果物への説明責任の確保 R （Responsible） 実⾏責任者 実際にタスクを⾏うひと A （Accountable） 説明責任者 最終的な意思決定者 （原則1⼈‧チーム） C （Consulted） 相談先 双⽅の対話が必要 I （Informed） 報告先 進捗の⼀⽅向共有 ※ https://www.atlassian.com/work-management/project-management/raci-chart
8. 8 ©MIXI 「Platform」ってなんだろう？（1/3） （CNCF Platforms WGの⽤語集 ※1 より）Platformは以下の要素の集合体 Capabilities • ユーザーが得られる具体的な機能やその成果 （例）実⾏環境、CI/CD、認証認可、オブザーバビリティ Documentation • ユーザーが迷わずに使い始めるために必要な知識や例 （例）オンボーディング、利⽤ガイド、設定の例、Runbook Tools • ユーザーがCapabilitiesを利⽤‧管理するための操作⽅法 （例）Webポータル、API、CLI、テンプレート、プロトコル定義 ※1 https://tag-app-delivery.cncf.io/wgs/platforms/glossary/#platform
9. 9 ©MIXI 「Platform」ってなんだろう？（2/3） Platformは単なるインフラではなく、ユーザー（開発者）への「体験」を提供する （CNCF Platforms White Paper ※1 より） Platform（チーム）は、Capabilitiesを統合する「⼀貫した体験のレイヤー」 体験の提供⽅法（インターフェース）には、WebポータルやAPI、CLIのほかに • Golden Path Template（Project Template + Documents） • Standard（標準） も含まれる ※1 https://tag-app-delivery.cncf.io/whitepapers/platforms/
10. 10 ©MIXI 「Platform」ってなんだろう？（3/3） Platformを提供するチームは、何を提供するのか？ （CNCF Blog “What is platform engineering?” ※1 より） A platform engineering team acts as an “internal provider,” offering a layer of abstraction that allows developers to operate more independently and efficiently. • “internal provider” … 内部サービスとして提供 • “layer of abstraction” … 抽象化されたレイヤー • “independently” … 開発者がより⾃律的に操作できる • “efficiently” … 開発者がより効率的に操作できる ※1 https://www.cncf.io/blog/2025/11/19/what-is-platform-engineering/
11. 11 ©MIXI values.yaml では以下を設定可能（⼀部例） • metadata.name , resources.requests/limits • Deploymentのスケールや、CronJobのスケジュールに関わる設定 『みてね』におけるインターフェース（1/3） values.yaml Helm Chart Input（Interface） 開発者が操作 Template（Engine） SREが管理＆隠蔽 Output K8sリソース ※1 変更 ※1 The Kubernetes Icons Set https://github.com/kubernetes/community/blob/master/icons/README.md 抽象化
12. 12 ©MIXI 『みてね』におけるインターフェース（2/3） values.yamlのイメージ（⾮同期ジョブ、CronJob） workers: hoge-worker: ….. maxReplicas: 100 fuga-worker: ….. requests: cpu: 500m memory: 1000Mi ….. ※ The Kubernetes Icons Set https://github.com/kubernetes/community/blob/master/icons/README.md {{- range $name, $value := $.Values.workers }} --- apiVersion: apps/v1 kind: Deployment metadata: name: {{ $name }} spec: ….. {{- end }} cronjobs: hoge-job: ….. schedule: "0 1 * * *" fuga-job: ….. schedule: "0 1 * * *" concurrencyPolicy ….. {{- range $name, $v := .Values.cronjobs }} --- apiVersion: batch/v1 kind: CronJob metadata: name: mitene-cron-{{ $name }} spec: schedule: {{ $v.schedule | quote }} concurrencyPolicy: {{ $v.concurrencyPolicy | quote }} …… {{- end }}
13. 13 ©MIXI 『みてね』におけるインターフェース（3/3） 責任範囲は「何を持つか」より「何を変更できるか」で切るとよさそう？ ドメイン開発の領域 valuesの変更 + その結果 SREの領域 基盤 + ガードレール values.yaml 「インターフェース（values.yaml）で触れる範囲」=「ドメイン開発の責任範囲」 と呼ぶことができそう （注‧「責任」は変更の結果に向き合うことであり「担当する‧しない」ではない）
14. 14 ©MIXI 責任範囲の整理（1/5） 『みてね』のKubernetes環境周りにおけるSREが管理する範囲 • EKSクラスタ • アップグレードなど • EKSに関連するAWSリソース • EC2、VPC、IAMなど • 共通コンポーネント • Ingress、モニタリング、Argo CDなど • values.yamlがインターフェースとして成り⽴つための抽象化 • 具体的にはHelm Chartのカスタマイズなど • 責任範囲は横断的 • より専⾨的な知識 • ⾃動化や共通化などによる最適化の必要性
15. 15 ©MIXI 責任範囲の整理（2/5） 『みてね』のKubernetes環境周りにおけるドメイン開発チームが触る範囲 • values.yaml（= インターフェース）に対する変更 • values.yaml内の調整可能な項⽬のみ • リソース（cpu/memory） • スケール（replicas, thresholds, concurrency policy） • 責任範囲はアプリケーション（ドメイン）に限定される • SREが抽象化したYAML構造に関する知識は必要 • Helm Chart⾃体への知識は（基本的に）不要 Platformとしては、これを満たすようなインターフェース設計
16. 16 ©MIXI 責任範囲の整理（3/5） RACIマトリクスへの割り当て（こんな感じ？） タスク / 領域 SRE ドメイン開発 備考 EKSアップグレード R / A I Kubernetes基盤の根幹 共通コンポーネント管理 R / A I 監視やIngressなど Namespace / RBAC R / A C / I 権限設計 Helm Chart管理（抽象化） R / A C / I インターフェース設計‧構築 Values変更 C / I R / A アプリ挙動に直結 ※ R（Responsible）/ A（Accountable）/ C（Consulted）/ I（Informed）
17. 17 ©MIXI 責任範囲の整理（4/5） 責任範囲の分界を成⽴させるために必要なものは何か？ 「組織」に着⽬すると • 責任範囲の明確化や宣⾔（オーナー、窓⼝、エスカレーションなど） 「変更」に着⽬すると • GitHubにおけるレビュー設定（CODEOWNERSやブランチ保護など） • CIによる⾃動レビュー 「運⽤」で着⽬すると • 権限の分離（Namespace, RBACなど） • リソースの制限（requests/limits, LimitRange, ResourceQuotaなど） 「知識」に着⽬すると • ドキュメントやRunbookの整備 どれかだけではなく多層のガードレール
18. 18 ©MIXI 責任範囲の整理（5/5） いま未定義‧あいまいな部分（定義するべきかも含めてあいまいなものもある） • インターフェースでどこまで設定可能にするか？ • valuesで設定できるのはDeployment, CronJob作成と そのリソース、スケール設定など • 『みてね』では基本同じアプリケーションへのcommitなので Namespaceなどで分割するケースにはあてはまらない（ほんとに？） • レビューにどこまでコストをかけるか？ • いまは基本SREがレビュー＆⼀部セルフサービス化 • テストやポリシー設定をどこまで（どこから）⼊れるか？ • コスト監視は？ • AWSなどの監視はSREグループがしている • 複雑な要素から変更に伴う変化をどう抽出するか？ • ほかインシデントレスポンス、イレギュラー対応など
19. ©MIXI 19 まとめ
20. 20 ©MIXI まとめ Platformは、Capabilities + Documentation + Toolsの集合体 インターフェースを「責任範囲」を分界点として考えてみた • 『みてね』では values.yaml をインターフェースとすると SREとドメイン開発の責任分界点として成り⽴っていそう 「何を持つか」ではなく「何を変更できるか」から責任範囲を捉えてみた • ドメイン開発は、values.yamlを変更してアプリケーション挙動を制御する • SREは、共通部分を変更してPlatformの安定性と抽象化の品質を保つ 「責任範囲」を考えることで 現在地の把握、再現性の確保、今後の改善につなげていきたい（再掲）
21. ©MIXI 21 ありがとうございました