enechainの内製セルフサービスプラットフォーム

Transcript

1. enechainの内製セルフサービスプラットフォーム スキーマ駆動カタログからK8sマニフェストとTerraformコードを⽣成する プラットフォーム開発部 Platform Engineering Desk 宇佐美 友也
2. ⾃⼰紹介 株式会社enechain 役割: ソフトウェアエンジニア (Platform Engineering Desk) 名前: 宇佐美 友也 (うさみ ともや) 興味のある技術: SPIFFE/SPIRE , K8s, AuthN/AuthZ 趣味: ランニング‧料理 2
3. 会社紹介 3
4. 展開しているサービス トレーディング 需給管理 リスク管理 / ETRM マーケットデータ 卸電⼒のオンライントレーディング SaaS 型の需給管理システム。需要 ⽇本の電⼒市場に特化した ETRM。 電⼒価格‧燃料価格などの市況デー プラットフォーム。現物から先物ま 想定‧JEPX への発注‧計画提出を 需給ポジションと収益リスクを可視 タを集約したデータプラットフォー でリアルタイムに取引でき、即時約 統合。2026年秋リリース予定。 化。 ム。 定で⾃動約定。 決済 ソリューション 環境価値 ⼈材育成 電⼒取引の決済ソリューション。 ⽇本気候取引所。環境価値を取引す 企業の脱炭素経営に必要な知識を学 取引先の与信リスクに対応。 るマーケットプレイスとデータ提 ぶ、GX ⼈材育成 e ラーニング。 供。 4
5. サービスを⽀えるプラットフォーム Artifact Registry app repo GitHub Actions CI/CD Argo CD terraform apply infra repo Google Cloud VPC（Shared VPC） Managed services GKE クラスタ Managed services Observability Cloud Armor Pub/Sub namespace（プロダクト単位） Cloud Logging Memorystore 実⾏基盤 Datadog product-a External HTTP(S) LB BigQuery product-b product-c Cloud SQL Cloud Storage Secret Manager 5
6. インフラの規模感 Google Cloud Projects Kubernetes / GKE Clusters Nodes Namespaces Deployments 約200 約200 6+2 〜20 約90 プロダクト × 環境 / ⽤途で 6 オートスケーラー プロダクト × 1クラスター 環境 検証⽤ 2 で変動 種別(app / job) あたり 6
7. Platform Engineering Desk メンバーの推移 2024/06 (発⾜) 専任 2025/01 2025/08 2025/11 Now 5名 9名 10 名 7名 0 社員 兼務 業務委託 (3-shake さん) 計 3名 7
8. Platform Engineering Desk 役割： インフラの管理と、⾼速デリバリーのための仕組み提供 今⽇の話 インフラの管理 ⾼速デリバリーのための仕組み Google Cloud, GKE, … Golden Pathの提供 CI/CD PR Preview Platform 今⽇の話 Kubecon NA / Platform Engineering Day 2026 ! K8s cluster addons more 8
9. セルフサービス プラットフォーム 9
10. 開発者の認知負荷 プロダクトが 増える → 使う技術が 増える → → ベストプラク ティスが分か らない → 基盤チームに 問い合わせが 集中 Golden Pathを 作る → enechain もよくある道をたどってきた • 2 つのフェーズを経てカタログ(Product Catalog)からの⾃動⽣成プロセスへ移⾏ 10
11. 2つのフェーズ 「テンプレートを配る」から「カタログから⽣成する」に PHASE 1 PHASE 2 generator でボイラープレート⽣成 カタログから golden path を⽣成 ‧標準構成をテンプレート化 ‧ 構成要素をカタログのエンティティとして定義 ‧シェルスクリプトから⽣成 ‧ エンティティ + パラメータから⽣成 ‧ CI が⽣成して PR まで作る ⾏き詰まったところ ‧ ガードレールを整備 ‧⽣成後に独⾃進化し、メンテコストが増える ‧ 推奨構成を反映して回るコストが⾼い ‧ 古いコードから fork され、drift が広がる めざす状態 セルフサービス / ガバナンスが効く / 推奨構成のアップデートに追従できる 11
12. カタログからのGolden Path⽣成イメージ Pull Invoke Product Catalog CI/CD Compiler GitHub Actions Argo CD Repository Templates Golden Path Push Deployment Kustomize patch YAML Terraform HCL Documents Create PRs Kubernetes Google Cloud 標準構成に沿った設定が⾃動的に⽣成され、効率的に開発〜デプロイを進めるこ とができる 1 2
13. セットアップの範囲 products/<name>.yaml ↓ GCP → インフラ⼀式 → K8s → ArgoCD へ登録 プロジェクト作成 マニフェスト カタログから⽣成 プロダクト固有の カスタマイズ ⼿で書く デプロイまでに必要なリソース‧マニフェスト⼀式をカタログから⽣成 13
14. カタログの構成要素 部品を⽤意する側と、組み合わせる側 Entity Product プラットフォームが提供する部品 プロダクトの構成をプロダクトチームが宣⾔ schema 実装が受け取れるパラメーターを スキーマとして宣⾔し、可変要素を公開する ‧どの Entity を使うかのリスト ‧各 Entity に渡すパラメーターの値 template ‧K8s マニフェストや Terraform コードのひな形 ‧受け取ったパラメーターを埋める Product は Entity が公開した範囲でのみカスタマイズできる 14
15. カタログの例 15
16. Schema駆動 Compiler は個別の Entity を知らない Product 使う Entity と パラメーターの値 → Compiler (CLI) → ⽣成物 Entity validate: schemaで検証 K8s マニフェスト schema宣⾔ generate: templateに流し込む Terraform コード template Entity を⾜しても、Compiler の変更不要 追加‧変更はカタログ(Entity)側だけで完結しツールの再ビルドは不要 16
17. Schemaの例 17
18. Templateの例 (Kubernetesマニフェスト) 18
19. Templateの例 (Terraformコード) 19
20. 拡張が容易 書くもの スキーマ定義 受け取るパラメーターを宣⾔する 書かなくていいもの + Go テンプレート — コンパイラの実装 埋める先のひな形を書く 必要な知識は Go の template と、パラメーターの定義だけ 他チームからの Entity 追加も、同じ⼿順でできる Platform Engineering Deskが唯⼀の拡張⼝である必要がない 20
21. カタログとパラメーターの考え⽅は Backstage 由来 踏襲したもの 変えたもの ‧カタログのエンティティという単位 ‧Web ポータルのフォームではなくCLIベース ‧受け取れる値をスキーマで宣⾔する形 ‧scaffolderに渡すパラメータをgitで管理 (設定値の再⼊⼒無しで再⽣成可能) ‧Entity の追加‧変更はカタログ側の変更だけ （プラグイン実装と再ビルドが不要） 継続的な「再作成」を重要視 Phase 1 の drift は⽣成が⼀度きりであることから来ていたので、同じ特性を持つBackstageをそのまま取り⼊れなかった 21
22. 継続的に再⽣成できる scaffold 型 再⽣成型 template → render → push catalog → generate → diff → PR ⽣成した時点で関係が切れる カタログを直して何度でも⽣成 以降の改善は既存プロダクトに届かない テンプレートの改善が全プロダクトに届く 個別に届ける場合もdriftしていると⼤変 カタログがSSoTなので⽣成物はいつでも作り直しができる 22
23. 所有権の明確化 overlays/prod/ ├─ gen_deployment.yaml ⽣成物 — 再⽣成で完全に作り直し ├─ gen_service.yaml ⽣成物 — ⼿で触らない ├─ kustomization.yaml エントリーポイント — ⽣成と⼿書きの両⽅を束ねる └─ patch-args.yaml ⼿書き — 再⽣成に巻き込まれない 機械⽣成 共有 ⼿書き ファイル名で変更可能な範囲がわかる 再⽣成を成り⽴たせる⼯夫の詳細については⻑くなるので別の機会に 23
24. 利⽤実態 約50 +約20 約30 2026 年の新規 約20 (8⽉時点) はじめからカタログ管理で作られた それ以前の既存 約30 Phase 1 の構成のまま 〜2025 年 2026 年（現在） これまで以上のスピードでプロダクトが追加されている 24
25. カタログのその他機能 (ドキュメント⽣成) 25
26. 現在取り組んでいる課題 PR の依存関係とマージ順序 ⽣成されるリソースに依存があり、適⽤できる順序が決まっている どの PR から⼊れるかの判断は、⼈が持ったまま 依存グラフから順序を判断する仕組みを検討中 Schemaの破壊的変更の反映 再⽣成があるので、壊れることは merge 前に分かる ただし直す作業は Product の数だけ残る AI による⼀括マイグレーションを検討∕Entityのバージョン管理も検討 26
27. 運⽤の⼯夫 27
28. 開発メンバー 2024/06 (発⾜) 専任 2025/01 2025/08 2025/11 Now 2名 2名 1名 0 社員 兼務 業務委託 (3-shake さん) 28
29. レビューがボトルネック AI 活⽤で 開発が速くなった → PR の量が増えた → ‧Catalog 追加 ‧Entity (template) 追加 ‧Compilerの機能拡張 レビューが 追いつかない レビュアーを増やせない理由 ‧マージにはチームメンバー1⼈からのレビューが必要 ‧開発メンバー以外には、変更の妥当性を判断しにくい 29
30. 変更種別ごとのレビュー⽅式 Entity(template) risk ラベル low / medium / high PR Catalog ⼈間レビュー レビュースキルが補助 → AI レビュー + CI → ⾃動マージ 変更内容の妥当性 再⽣成で差分が出るか 4.1h 中央値 ‧risk/high ‧差分あり → マージ 12h CODEOWNER の承認 中央値 同じ分け⽅を compiler のリポジトリにも導⼊している レビュアーの数は増やせないので、1 件を通すまでの⼯数を下げる 30
31. レビュースキルの整備と精度の改善 チェック項⽬を整備 回帰テスト付きの改善ループ 過去のカタログ PRの指摘を 定期的に過去PRの指摘事項 ＋ ⼈間による追加指摘を洗い出し レビューチェック項⽬として整備 レビューチェック項⽬の鮮度を保つ 過去 PR で再レビューし妥当性評価 ⼈間の最初のレビューまで open → merge 19.4h → 1.6h 44h → 12h 前後⽐較で因果は⽰せないが、⼀番効果のあったのは「レビュー着⼿までの時間」。そこを減らすための仕組みではある。 31
32. 最終的なインフラ構築のリードタイム Phase 1 以前 2 週間 ⼿動でインフラを作り、⼈がレビューする いま → 1⽇ カタログに書いて PR を出す 今後のAI活⽤や効率化でさらに速くできる⾒込み 32
33. 事業成⻑を妨げない、スピーディーな プロダクト⽴ち上げのゴールデンパスを提供する 33
35. 3 5