Upgrade to Pro — share decks privately, control downloads, hide ads and more …

「Chatwork」のEKS環境を支えるhelmfileを使用したマニフェスト管理術

 「Chatwork」のEKS環境を支えるhelmfileを使用したマニフェスト管理術

SRE NEXT2025 Day2 trackC 13:30-13:50にお話しさせていただいた資料です

Avatar for hanayo04

hanayo04

July 12, 2025
Tweet

More Decks by hanayo04

Other Decks in Technology

Transcript

  1. 桝谷 花世 ますたに はなよ 所属 | 株式会社kubell ( 旧Chatwork株式会社)     コミュニケーションプラットフォーム

                     ディビジョン     プロダクトユニット SREグループ 経歴 | 2018/4     SI企業に新卒で入社     様々なPJでインフラ領域を主に担当     2023/9     株式会社kubellに入社     主にKubernetes周辺技術やコスト管理を担当 Community | JAWS-UG SRE支部 運営 X (Twitter) | @hnchn87
  2. 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にて選定。 効率的に情報共有できる グループチャット 仕事の見える化ができる タスク管理 見落としがなくなる ファイル管理 いつでも会議ができる ビデオ/音声通話
  3. 4 SRE NEXT 2025 Day2 TrackC 「Chatwork」のEKS環境の特徴 環境数 3 環境

    test/stg/prod環境 の3つの環境が存在 クラスター数 5 個 manager用とapp用で 合計5個のクラスターを運用 Pod数 最大 1000 個以上 平日日中のピーク時 は数千のPodが起動 詳細は↓
  4. 5 SRE NEXT 2025 Day2 TrackC Kubernetesにおける開発チームとSREの分担 開発チーム アプリケーションの開発に集中 アプリケーション設定

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

    責任範囲で階層を分離 デプロイの自動化 手動作業を減らし、宣言的な管理で再現性を確保 point 1 point 2 point 3
  6. 7 SRE NEXT 2025 Day2 TrackC 「Chatwork 」のマニフェスト管理構造 helmfile(アプリケーション設定) サービス固有の設定や環境差分をhelmfileを使って定義

    helmfile(共通基盤) 複数のHelmリソースを統合管理しており、依存関係の管理も行う Helm Chart php, akka, mysql等、用途別に標準化されており、再利用可能なテンプレート Kubernetes マニフェスト 最終的にKubernetesに適用するマニフェストであり、全ての値が展開されているもの 開発チーム SREチーム SREチーム
  7. 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から変更したい値のみ記述
  8. 9 SRE NEXT 2025 Day2 TrackC Helm Chartのみの管理での課題 複数サービス×複数環境の場合のデプロイの複雑さ  デプロイする際のコマンド

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

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

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

    Chartを管理することができ、管理したい単位で一括デプロイが可能 解決策 1 デプロイ時に依存関係は何も考えなくてOK  依存関係もhelmfileに定義できるので、デプロイ時には考慮する必要がなく運用が楽 解決策 2 ただし 複数Chartを一括管理できても標準的なChartでは対応できないリソースも実運用の中では多数ある
  13. 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
  14. 15 SRE NEXT 2025 Day2 TrackC 「Chatwork」のマニフェスト管理構造 helmfile(アプリケーション設定) サービス固有の設定や環境差分をhelmfileを使って定義 helmfile(共通基盤)

    複数のHelmリソースを統合管理しており、依存関係の管理も行う Helm Chart php, akka, mysql等、用途別に標準化されており、再利用可能なテンプレート Kubernetes マニフェスト 最終的にKubernetesに適用するマニフェストであり、全ての値が展開されているもの 開発チーム SREチーム SREチーム 再掲
  15. 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で行っています
  16. 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
  17. 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に表示 動的生成することで学習効率・運用効率・レビュー品質の向上が可能
  18. 19 SRE NEXT 2025 Day2 TrackC 「Chatwork」のマニフェスト管理構造 helmfile(アプリケーション設定) サービス固有の設定や環境差分をhelmfileを使って定義 helmfile(共通基盤)

    複数のHelmリソースを統合管理しており、依存関係の管理も行う Helm Chart php, akka, mysql等、用途別に標準化されており、再利用可能なテンプレート Kubernetes マニフェスト 最終的にKubernetesに適用するマニフェストであり、全ての値が展開されているもの 開発チーム SREチーム SREチーム 動的生成
  19. 20 SRE NEXT 2025 Day2 TrackC まとめ 技術選定と役割分担 開発チーム: アプリケーション設定に集中

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

    Atlantisについてお話しする予定です! ぜひご参加ください!