Slide 1

Slide 1 text

「Chatwork」のEKS環境を支える helmfileを使用したマニフェスト管理術 株式会社kubell (旧Chatwork株式会社) コミュニケーションプラットフォームディビジョン プロダクトユニット SREグループ エンジニアリングマネージャー 桝谷 花世 2025年07月12日

Slide 2

Slide 2 text

桝谷 花世 ますたに はなよ 所属 | 株式会社kubell ( 旧Chatwork株式会社)     コミュニケーションプラットフォーム                  ディビジョン     プロダクトユニット SREグループ 経歴 | 2018/4     SI企業に新卒で入社     様々なPJでインフラ領域を主に担当     2023/9     株式会社kubellに入社     主にKubernetes周辺技術やコスト管理を担当 Community | JAWS-UG SRE支部 運営 X (Twitter) | @hnchn87

Slide 3

Slide 3 text

3 SRE NEXT 2025 Day2 TrackC 「Chatwork」とは ※※Nielsen NetView 及びNielsen Mobile NetView Customized Report 2024年4月度調べ月次利用者(MAU:Monthly Active User)調査。 調査対象はChatwork、Microsoft Teams、Slack、LINE WORKS、Skypeを含む41サービスを株式会社kubellにて選定。 効率的に情報共有できる グループチャット 仕事の見える化ができる タスク管理 見落としがなくなる ファイル管理 いつでも会議ができる ビデオ/音声通話

Slide 4

Slide 4 text

4 SRE NEXT 2025 Day2 TrackC 「Chatwork」のEKS環境の特徴 環境数 3 環境 test/stg/prod環境 の3つの環境が存在 クラスター数 5 個 manager用とapp用で 合計5個のクラスターを運用 Pod数 最大 1000 個以上 平日日中のピーク時 は数千のPodが起動 詳細は↓

Slide 5

Slide 5 text

5 SRE NEXT 2025 Day2 TrackC Kubernetesにおける開発チームとSREの分担 開発チーム アプリケーションの開発に集中 アプリケーション設定 環境固有の値設定(CPU・メモリ等) デプロイ設定管理 test/stg/prod環境の差分 サービス固有の設定 スケーリング・ヘルスチェック等 SREチーム プラットフォーム提供・運用 共通基盤の提供 再利用可能なテンプレート開発 クラスタ運用管理 監視・ログ・セキュリティ基盤 CI/CD基盤構築 ArgoCD・GitOps この役割分担を実現するためのマニフェスト管理方法について本日はお話ししていきます

Slide 6

Slide 6 text

6 SRE NEXT 2025 Day2 TrackC マニフェスト管理方法を設計する上でのポイント DRY原則の徹底 階層的な構造化 共通部分をテンプレート化し、環境差分のみを管理 責任範囲で階層を分離 デプロイの自動化 手動作業を減らし、宣言的な管理で再現性を確保 point 1 point 2 point 3

Slide 7

Slide 7 text

7 SRE NEXT 2025 Day2 TrackC 「Chatwork 」のマニフェスト管理構造 helmfile(アプリケーション設定) サービス固有の設定や環境差分をhelmfileを使って定義 helmfile(共通基盤) 複数のHelmリソースを統合管理しており、依存関係の管理も行う Helm Chart php, akka, mysql等、用途別に標準化されており、再利用可能なテンプレート Kubernetes マニフェスト 最終的にKubernetesに適用するマニフェストであり、全ての値が展開されているもの 開発チーム SREチーム SREチーム

Slide 8

Slide 8 text

8 SRE NEXT 2025 Day2 TrackC Helm Chartの基本概念 # templates/deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: {{ include "myapp.fullname" . }} spec: replicas: {{ .Values.replicaCount }} template: spec: containers: - name: {{ .Chart.Name }} image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}" resources: limits: memory: {{ .Values.resources.memory }} cpu: {{ .Values.resources.cpu }} Helm Chartとは  Kubernetesのパッケージマネージャー  Go templateを使ってKubernetesマニフェストを効率的に管理可能 # values.yaml(default) replicaCount: 1 image: repository: chatwork/web tag: "1.0.0" resources: memory: "256Mi" cpu: "100m" # prod-values.yaml replicaCount: 10 resources: memory: "1Gi" cpu: "500m" defaultから変更したい値のみ記述

Slide 9

Slide 9 text

9 SRE NEXT 2025 Day2 TrackC Helm Chartのみの管理での課題 複数サービス×複数環境の場合のデプロイの複雑さ  デプロイする際のコマンド  helm install myapp ./mychart --values prod-values.yaml  これを複数サービス×複数環境分実行する必要がある 課題 1 依存関係の管理の複雑さ  DBが起動した後にAppを起動する等依存関係がある場合の管理が大変 課題 2 この課題をhelmfileを使用することで解決します!

Slide 10

Slide 10 text

10 SRE NEXT 2025 Day2 TrackC helmfileの基本概念 # リポジトリ定義 repositories: - name: chatwork url: https://chatwork.github.io/charts # 環境定義 environments: development: values: - env/dev.yaml production: values: - env/prod.yaml … helmfileとは  Helmの宣言的管理ツール helmfileの基本構造 … # リリース定義(複数のHelm Chart) releases: - name: mysql namespace: chatwork chart: chatwork/mysql version: 1.6.10 values: - mysql/{{ .Environment.Name }}.yaml - name: web namespace: chatwork chart: chatwork/php version: 1.4.2 needs: - mysql values: - web/common.yaml - web/{{ .Environment.Name }}.yaml

Slide 11

Slide 11 text

11 SRE NEXT 2025 Day2 TrackC Helm Chartのみの管理での課題 複数サービス×複数環境の場合のデプロイの複雑さ  デプロイする際のコマンド  helm install myapp ./mychart --values prod-values.yaml  これを複数サービス×複数環境分実行する必要がある 課題 1 依存関係の管理の複雑さ  DBが起動した後にAppを起動する等依存関係がある場合の管理が大変 課題 2

Slide 12

Slide 12 text

12 SRE NEXT 2025 Day2 TrackC Helm Chartのみの管理での課題の解決策 管理したい単位で一括でデプロイ可能  helmfileで複数のHelm Chartを管理することができ、管理したい単位で一括デプロイが可能 解決策 1 依存関係の管理の複雑さ  DBが起動した後にAppを起動する等依存関係がある場合の管理が大変 課題 2

Slide 13

Slide 13 text

13 SRE NEXT 2025 Day2 TrackC Helm Chartのみの管理での課題 管理したい単位で一括でデプロイ可能  helmfileで複数のHelm Chartを管理することができ、管理したい単位で一括デプロイが可能 解決策 1 デプロイ時に依存関係は何も考えなくてOK  依存関係もhelmfileに定義できるので、デプロイ時には考慮する必要がなく運用が楽 解決策 2 ただし 複数Chartを一括管理できても標準的なChartでは対応できないリソースも実運用の中では多数ある

Slide 14

Slide 14 text

14 SRE NEXT 2025 Day2 TrackC raw Chartの基本概念 raw Chartとは  任意のKubernetesリソースを定義できる汎用的なHelm Chartです。標準的なHelm Chartが特定の用 途に特化しているのに対し、raw Chartは「何でも定義できる」万能のChart # helmfile.yaml repositories: - name: chatwork url: https://chatwork.github.io/charts releases: - name: custom-resources namespace: default chart: chatwork/raw version: 0.2.6 values: - values/custom-config.yaml # values/aws-secrets/common.yaml resources: - apiVersion: mumoshu.github.io/v1alpha1 kind: AWSSecret metadata: name: {{ .Values.appName }}-secret spec: stringDataFrom: secretsManagerSecretRef: secretId: "kubernetes/{{ .Values.stage }}/{{ .Values.appName }}" # values/aws-secrets/production.yaml appName: chatwork stage: production

Slide 15

Slide 15 text

15 SRE NEXT 2025 Day2 TrackC 「Chatwork」のマニフェスト管理構造 helmfile(アプリケーション設定) サービス固有の設定や環境差分をhelmfileを使って定義 helmfile(共通基盤) 複数のHelmリソースを統合管理しており、依存関係の管理も行う Helm Chart php, akka, mysql等、用途別に標準化されており、再利用可能なテンプレート Kubernetes マニフェスト 最終的にKubernetesに適用するマニフェストであり、全ての値が展開されているもの 開発チーム SREチーム SREチーム 再掲

Slide 16

Slide 16 text

16 SRE NEXT 2025 Day2 TrackC GitOps App helmfile EKS(app) EKS (manager) helmfile 1.Master merge 3.Push 2.Build 4.Update 5. Polling 7.Apply 開発者 6. Press the Sync button Service Pod Pod Pod Pod Pod Pod ver.1 ver.2 helmfileでのマニフェスト生成は ArgoCDで行っています

Slide 17

Slide 17 text

17 SRE NEXT 2025 Day2 TrackC ArgoCDを使ったhelmfileでのマニフェスト生成 ArgoCD では、標準的なKubernetesマニフェストだけでなく、独自の設定ファイルからマニフェスト を生成するプラグイン機能(ArgoCD Config Management Plugin)があります。 # プラグイン定義 argocd-server ConfigMap data: configManagementPlugins: | - name: helmfile-plugin init: command: ["helmfile", "repos"] generate: command: ["/bin/bash", "-c"] args: - | # 認証処理 export AWS_CREDENTIALS=$(get-credentials) # マニフェスト生成 helmfile --environment $TARGET_ENV template discover: fileName: "helmfile.yaml" # アプリケーションでの利用 apiVersion: argoproj.io/v1alpha1 kind: Application spec: source: repoURL: https://github.com/your-org/app-config path: ./ plugin: name: helmfile-plugin env: - name: TARGET_ENV value: production

Slide 18

Slide 18 text

18 SRE NEXT 2025 Day2 TrackC Kubernetesマニフェストを動的生成するメリット git-repo/  dev/   deployment.yaml # 3000行   service.yaml  # 500行   configmap.yaml # 1000行  staging/(同じ構成)  prod/(同じ構成) git-repo/  helmfile.yaml # 50行  values/   dev.yaml # 30行   staging.yaml # 30行   prod.yaml # 30行 マニフェストを管理 動的生成 デメリット 冗長なYAMLがリポジトリ上に存在 レビュー時に本質的な参考差分が確認できない メリット 冗長なYAMLがリポジトリ上に存在しない 実際の変更のみがPRに表示 動的生成することで学習効率・運用効率・レビュー品質の向上が可能

Slide 19

Slide 19 text

19 SRE NEXT 2025 Day2 TrackC 「Chatwork」のマニフェスト管理構造 helmfile(アプリケーション設定) サービス固有の設定や環境差分をhelmfileを使って定義 helmfile(共通基盤) 複数のHelmリソースを統合管理しており、依存関係の管理も行う Helm Chart php, akka, mysql等、用途別に標準化されており、再利用可能なテンプレート Kubernetes マニフェスト 最終的にKubernetesに適用するマニフェストであり、全ての値が展開されているもの 開発チーム SREチーム SREチーム 動的生成

Slide 20

Slide 20 text

20 SRE NEXT 2025 Day2 TrackC まとめ 技術選定と役割分担 開発チーム: アプリケーション設定に集中 SREチーム: 共通基盤とテンプレート提供 Helm: 再利用可能なテンプレート管理 helmfile: 複数環境・サービスの統合管理 4層アーキテクチャで実現 4層: アプリケーション設定(開発チーム) 3層: 共通基盤サービス(SREチーム) 2層: 共通テンプレート(SREチーム) 1層: Kubernetes Manifests(動的生成) 重要なポイント 1. 責務分離: 開発チームは必要な情報のみに集中 2. 動的生成: 学習効率・運用効率・レビュー効率向上 この後も終日弊社のブースにいるので質問等あればお気軽に話しかけにきてください!

Slide 21

Slide 21 text

21 SRE NEXT 2025 Day2 TrackC 参考(ブース場所)

Slide 22

Slide 22 text

22 SRE NEXT 2025 Day2 TrackC 最後に告知 申し込みはこちら 弊社SRE 山下がLT登壇します! Atlantisについてお話しする予定です! ぜひご参加ください!

Slide 23

Slide 23 text

kubellではSREを探しています 皆様のご応募お待ちしています! 働くをもっと楽しく、創造的に Join Our Team! ↑SREの求人情報はこちら↑

Slide 24

Slide 24 text

働くをもっと楽しく、創造的に