kustomizeを使ったFeature環境の実現方法
参考になった
2
株式会社enechain / ashigirl96
メンバー / フロントエンドエンジニア
| ツールの利用規模 | ツールの利用開始時期 | 事業形態 |
|---|---|---|
| 10名以下 | 2025年1月 | B to B |
| ツールの利用規模 | 10名以下 |
|---|---|
| ツールの利用開始時期 | 2025年1月 |
| 事業形態 | B to B |
アーキテクチャ
アーキテクチャの意図・工夫
設計思想
GitOps原則の徹底
- すべての環境定義をGitで管理
- 変更履歴の完全な追跡可能性
- ロールバック容易性の確保
リソース効率の最適化
- Kubernetesリソースは環境ごとに独立
- 高コストなCloudリソース（DB、DWH）は共有
- 自動削除による無駄なリソース消費の防止
運用の自動化
- CI/CDパイプラインによる完全自動化
- 人的介入ポイントの最小化
- エラー発生時の自動リカバリ
ksubst-rs の活用
既存のkustomizeには PrefixSuffixTransformer などの機能が存在しましたが、ブランチ名の特殊文字処理や環境変数展開の柔軟性に課題がありました。そこで、これらの課題を解決するため、ksubst-rs という軽量なツールを独自開発する方針を採用しました。詳細な比較検討については後述の「比較したサービス」で説明します。
metadata:
name: ${FEATURE_NAME-}escan-app
spec:
domains:
- ${FEATURE_NAME.}dev.enechain.com
sync-waveによる実行順序制御
複数のFeature環境が同時にBigQueryのスキーママイグレーションを実行すると、BigQuery APIのレート制限（1ユーザー・1メソッドあたりの秒間リクエスト上限）に引っかかってエラーが発生していました。 そこで、Argo CDのsync-waveアノテーションを使って各Feature環境のマイグレーションJobに異なる値（0, 10, 20...）を割り当て、順番に実行されるよう制御することで、API呼び出しが分散されレート制限を回避できるようになりました。
annotations:
argocd.argoproj.io/sync-wave: "${BQ_MIGRATION_SYNC_WAVE}"
導入の背景・解決したかった問題
導入背景
ツール導入前の課題
enechainでeScanという電力取引向けのリスク管理システム（ETRM）を開発している中で、非エンジニアが機能の動作を早期に確認できず、不具合発見時の手戻りコストが膨大になるという大きなボトルネックに直面していました。エンジニア同士のコードレビューはGitHub上でできても、実際のアプリケーション画面を触れる環境がないと、UI/UXまわりの細かなフィードバックが難しいという状況でした。
また、実際に動作する環境での確認が開発後期まで待たされることで、仕様のすれ違いや不具合の発見が遅れ、手戻りコストが膨大になるケースが頻発していました。機能実装後にマージして初めて動作確認ができる環境では、mainブランチへマージ → テスト環境リリース → 不具合発見 → 再度修正…というフローが必要となり、開発の反復サイクルが遅くなることで生産性が大幅に低下する悪循環に陥っていました。
どのような状態を目指していたか
私たちが理想とした開発フローは、featureブランチごとに独立した環境が自動的に立ち上がり、Pull Requestレビュー担当者やPdM、QAエンジニアがいつでもアクセスできる状態でした。具体的には、開発者がfeatureブランチを作成してPull Requestを開くと、そのブランチ専用の環境が自動的に構築され、https://<branch-name>.dev.enechain.com のようなURLでアクセス可能になることを目指していました。
また、Pull Requestがマージまたはクローズされた後は、リソースの無駄な消費を避けるため、対応する環境が自動的に削除される仕組みも必要でした。これにより、管理者の負担を最小限に抑えながら、必要な時だけ環境を利用できる効率的な運用を実現したいと考えていました。
比較検討したサービス
主要検討対象：
- kustomizeのPrefixSuffixTransformer： 標準機能での環境分離
- Helm Charts： テンプレート機能を活用した動的環境生成
- 独自ツール開発（ksubst-rs）： 環境変数ベースのテンプレートエンジン構築
その他検討対象：
- 外部SaaS（Vercel Review Apps、Heroku Review Apps等）
- 独自スクリプトによる自動化
比較した軸
技術的親和性：
- 既存のkustomize/Argo CD構成との統合しやすさ
- GitOpsワークフローへの適合性
運用効率性：
- ブランチ名の特殊文字（
/、.など）への対応力 - 環境変数展開の柔軟性
- チーム内での学習コストの低さ
コスト・複雑性：
- 運用コストと複雑性のバランス
- 初期導入コストと長期的なメンテナンス性
選定理由
最終的にkustomize + Argo CDの拡張を選択した決め手は、実装の現実性と拡張性でした。kustomize自体には PrefixSuffixTransformer などの機能が存在しましたが、ブランチ名の特殊文字処理や環境変数展開の柔軟性に課題がありました。そこで、ksubst-rs という独自ツールを開発することで、これらの課題を解決できる見通しが立ったことが大きな決め手となりました。
ksubst-rs を使えば、YAMLテンプレート内のプレースホルダを環境変数に応じて柔軟に置き換えることができ、ブランチ名に含まれる特殊文字を自動的にエスケープしてリソース名やドメインに落とし込む処理も簡単に実装できました。この仕組みにより、既存のkustomizeの仕組みを活かしながら、Feature環境特有の要件に対応できることが確認できました。
導入の成果
改善したかった課題はどれくらい解決されたか
非エンジニア職との機能確認
- URLを共有するだけで即座に動作確認可能
- エンジニアとPdM/QAエンジニア間のフィードバックループが実現
開発後期での問題発覚
- 早期段階での仕様すり合わせが可能に
- 大規模な手戻りが大幅に減少
開発反復サイクル
- コミット後、数分で環境更新完了
- フィードバックループの高速化
どのような成果が得られたか
定量的成果（Four Keysメトリクスより）
- デプロイ頻度：週3回 → 週8回
- リードタイム：5日 → 2.5日
- 変更失敗率：15% → 5%
- 平均復旧時間：変化なし
定性的成果
- チーム間のコミュニケーション活性化
- 非エンジニアメンバーの開発プロセスへの参画度向上
- エンジニアの開発体験（DX）の大幅改善
導入時の苦労・悩み
導入時に最も苦労したのは、同一namespace内でのリソース名の衝突問題でした。当初はFeature環境ごとに新しいnamespaceを作成することを検討しましたが、権限管理やネットワークポリシーの設定が複雑になることから、Develop環境と同じnamespaceを使用する方針に転換しました。この決定により、リソース名をユニークにする仕組みの構築が必要となり、ksubst-rsの開発につながりました。
また、Argo CDの運用方法の見直しも必要でした。従来はアプリケーションごとにkustomizeのディレクトリを直接参照していましたが、Feature環境では動的に生成されたマニフェストを管理する必要があったため、output/ディレクトリ方式への移行が必要でした。この移行には、既存のCI/CDパイプラインの大幅な修正が伴いました。
DNS設定やSSL証明書の管理についても当初は懸念がありましたが、幸いにも既存のexternal-dnsとManagedCertificateの仕組みを活用することで、想定よりもスムーズに解決できました。
導入に向けた社内への説明
上長・チームへの説明
定量的メリット
- 手戻りによる工数削減：1機能あたり平均2-3日の短縮見込み
- リリースサイクルの短縮：平均リードタイムの20-30%改善
- Cloud リソースの共有によるコスト抑制
定性的メリット
- PdM/QAエンジニアの早期参画による品質向上
- エンジニアの心理的安全性の向上
- チーム全体のコミュニケーション改善
活用方法
エンジニア（週5-10回）
- 機能開発時：PRごとに自動で環境構築
- デバッグ時：実環境での動作確認
- レビュー時：レビュアーが実際に動作確認
PdM（週3-5回）
- 仕様確認：開発中の機能を随時チェック
- デモ準備：ステークホルダー向けのデモ環境として活用
- フィードバック：Slackで開発者に即座にフィードバック
QAエンジニア（日次）
- 早期テスト：開発完了前からテスト開始
- バグ報告：具体的な再現手順を環境URLと共に共有
- 回帰テスト：複数のFeature環境を並行してテスト
典型的な利用フロー
- エンジニアがfeatureブランチでPR作成
featureラベル付与で環境自動構築（約5分）- PdM/QAがURLにアクセスして動作確認
- PdM/QAが開発者にフィードバック
- 修正コミット → 自動再デプロイ（約3分）
- マージ後に環境自動削除
よく使う機能
環境管理機能
- 自動環境構築：PR作成時の
featureラベルトリガー - 自動環境更新：コミットプッシュによる自動再デプロイ
- 自動環境削除：PR close/mergeによる自動クリーンアップ
- URL生成：ブランチ名ベースの予測可能なURL体系
開発支援機能
- 環境変数管理：
ksubst-rsによる柔軟な設定注入 - リソース分離：namespace内での完全なリソース分離
- ログ集約：Argo CD UIからのログ確認
- デプロイ状況可視化：Argo CDダッシュボードでのステータス確認
ツールの良い点
完全自動化された環境ライフサイクル
- 人的介入なしでの環境構築・削除
- GitOpsによる宣言的な管理
既存システムとのシームレスな統合
- kustomize/Argo CDの資産を最大活用
- 学習コストの最小化
コスト最適化
- Cloudリソースの効率的な共有
- 不要環境の自動削除
開発体験の向上
- URLを共有するだけの簡単な利用方法
- 高速な環境構築（5分以内）
ツールの課題点
データベース共有による制約
- スキーマ変更時の競合リスク
- 対策：運用ルールの徹底が必要
BigQuery APIのレート制限
- 複数環境の同時マイグレーション時のエラー
- 対策：sync-waveでの実行制御が必須
初期セットアップの複雑さ
- ksubst-rs、Argo CD、external-dnsなどの設定
- 対策案：ドキュメント整備とセットアップスクリプトの提供
モニタリング体制の不足
- Feature環境のリソース使用状況の可視化
- 対策案：エラー通知の最適化とダッシュボード構築
ツールを検討されている方へ
導入前のチェックリスト
- kustomizeベースの環境管理をしているか
- Argo CDまたは類似のGitOpsツールを使用しているか
- Kubernetesクラスタのリソースに余裕があるか
- ワイルドカードDNSの設定が可能か
- チームにKubernetes/GitOpsの基礎知識があるか
段階的導入のススメ
Phase 1：最小構成でのPoC
- 1つのアプリケーションでテスト
- 手動でのマニフェスト作成
- 効果測定と課題洗い出し
Phase 2：自動化の導入
- CI/CDパイプラインの構築
- ksubst-rsなどのツール導入
- 運用ルールの策定
Phase 3：全面展開
- 全サービスへの適用
- モニタリング体制の確立
- 継続的な改善プロセス
今後の展望
開発者体験の継続的改善
- VS Code拡張機能の開発
- CLIツールによる環境管理
セキュリティ強化
- ゼロトラストネットワークの実装
- Feature環境へのアクセス制御強化
株式会社enechain / ashigirl96
メンバー / フロントエンドエンジニア
株式会社enechain / ashigirl96
メンバー / フロントエンドエンジニア
レビューしているツール
目次
- アーキテクチャ
- 導入の背景・解決したかった問題
- 活用方法