サービスカタログに基づくTerraform/K8sコードの自動生成

2025年アーキテクチャカンファレンスにて発表した資料になります

Transcript

1. サービスカタログに基づくTerraform/K8s コードの自動生成 Platform Engineering Desk 遠藤 雅彰
2. 自己紹介 写真をここに配置 遠藤　雅彰 株式会社enechain Platform Engineering Desk プリンシパルエンジニア 略歴 2022年 - 現在 株式会社enechain 2020年 - freee株式会社 2 2016年 - 株式会社メルカリ 2012年 - グリー株式会社 2008年 - Speee株式会社 2004年 - ガイオテクノロジー株式会社
3. 3 会社紹介 - 株式会社enechain さらっと紹介する感じ。 hiyosiさんの時のやつを使えばよさそう。そもそも会社のこと話ししてok? 3
4. 展開しているサービス • enechainでは創業から６年の間に様々なサービスを展開してきました • サービスが拡大していく中でいくつかの大きな課題が発生していました 4
5. 5 Platformチームで発生し ていた課題 5
6. プロジェクト背景と課題 Platformチームで発生していた課題 創業当初のスピード感で事業を拡大していった結果、manifestやterraformが独自 形式で作られてしまいメンテナンスコストが徐々に高くなった 新しく推奨構成を作っても独自形式を対応させるコストが発生するため、更新が 進まない 新規プロジェクトを作成する際に古いコードを参考にしてmanifestが作られること も多く、問題が拡大した
7. Platformチームがイメージしていた理想の運用 セルフサービス運用 SRE/Platformチームがボトルネックにならず、 プロダクト開発者がセルフサービスでインフラの 運用ができる 構成変更の適用 構成変更などのアップデートが全プロダクトに適 用できる チーム間連携 サービスを誰がメンテナンスしているのかを把 握してチーム間連携ができている 依存関係の理解 サービス間の依存関係を理解してインフラ構築 ができている 7
8. 理想と現実のギャップ manifestやterraformのガバナンス 構成変更の一括反映の仕組みが存在しない manifestの理解と作成スキル プロダクト開発者に全部理解してもらうのは厳し い、プロダクトの開発に集中できなくなる 担当チーム管理シート 適切に管理出来ておらず、時間経過によっ てメンテナが曖昧になってしまっている サービスマップの作成 依存関係が増えるたびに手作業でなんとかし ないといけない 抜本的にアプローチを変える必要があった 8
9. 9 問題の解決に向けて 9
10. Internal Developer Platform（IDP）の検討 IDPとは 開発者が自律的に開発・デプロイできる環境を提供する社内向けプラットフォーム Templateを用いて開発者がセルフサービスで環境構築やデプロイが可能になるよう設計する 標準化と自動化の実現 標準化と自動化により、開発のスピードと品質を向上させ、運用負荷を軽減 サービスカタログの活用 各サービスのオーナー情報、リポジトリ、ステータス、依存関係などを一元表示することができる → 今回の課題解決に良さそう 10
11. IDP導入に向けてプロジェクト化 テンプレートによる自動生成 構成変更時には再生成により全プロジェクトへの反映を可能とし、ガバナンスを効かせる 標準化の策定をする テンプレートで生成しやすいように可能な限り統一する サービスカタログを導入する プロダクトの実態の可視化と運用改善を目指す → 導入を目指して Instant Universeプロジェクト発足 11
12. 実装フェーズと移行計画 フェーズ1（Instant Universe V1） 新規プロダクトでテンプレートを使用する 標準化の策定を行い プロジェクト個別の設定を制限す る generatorでプロジェクト全体のボイラープレートを生成す る フェーズ2（Instant Universe V2） 既存プロダクトのサービスカタログへの移行 開発者がTemplateを選んで生成できるようにする CIを整備してGit Opsで運用できるようにする 実行計画フロー フェーズ 1 テンプレート導入・標準化の実施 実施計画 STEP 1 新規プロダクトに導入 フェーズ 2 カタログモデル・自動化の実装 実施計画 STEP 2 既存プロダクトの移行を実施 12
13. Instant Universe V1 V1 2024/05 リリース 標準化の定義 予測可能な設定と一貫性のある構成を実現 簡易的なシェルスクリプトでのテンプレート生成 開発効率と一貫性の向上を実現 新規作成時は最新のテンプレートから生成 常に最新の標準に準拠した環境構築を保証 詳しくは弊社のブログで紹介しているので気になる方はQRコードの記事参照 13
14. 1 4 計画の見直し 14
15. Backstageの台頭 検討事項 フェーズ2の開発途中でBackstageが台頭してきた 方針を転換すべきか、このまま進めるべきか検討をした 社内で既に導入済みのDatadogもサービスカタログを提供してきたので合わせて 検討することにした 2つのツールを比較し、再検討することにした 15
16. Datadog vs Backstage Datadog 運用監視に特化したサービスカタログ 既存サービスの「監視・運用・パフォーマンス 管理」が主目的 リアルタイム性、自動検出、統合監視が強み 開発者ポータル機能(テンプレート、ドキュメ ント、ワークフロー)は提供しない Backstage 開発者ポータルとしてのサービスカタログ 「サービス管理+開発者エクスペリエンス向 上」が主目的 プロジェクト生成、ドキュメント、ツール統 合、カスタマイズが強み リアルタイム監視機能は外部ツール連携に 依存 16
17. 改めて整理した自分たちがほしかったもの プロダクト開発者がセルフサービスでインフラの運用ができる SRE/Platformチームがボトルネックにならずに新規プロダクトが作成できる 構成変更などのアップデートが全てに適用できる サービスを誰がメンテナンスしているのかわかる サービス間の依存関係がわかる 17
18. 内製ツールとDatadogの併用の方向に決定 Datadogの利点 サービスカタログやプロダクト担当者は Datadogでも管理 できる Datadogは実際のAPIリクエストからサービスマップを表 示してくれる DatadogにてPagerDurty相当のアラート対応が可能 Datadogに足りない機能へのアプローチ 足りないところ（Scaffolderなど）は内製ツールに持たせ る Datadogのサービスカタログへの登録は内製ツールで 行う 内製ツールと Datadogの併用 内製ツール Scaffolder テンプレート ★ 自動化機能 テンプレートからカタログ登録 Datadog サービスマップ カタログ管理 ★ アラート機能 GitOpsとDatadogの連携による運用 18
19. 何故Backstageを使わなかったのか 少ないメンバーでの運用が難しかった ドキュメント管理も今のNotionとGitHubからWebで見るのでも困っていない 既にDatadogを活用していたこともあり、Datadogとの連携の方が新しいツールを覚 えなくて良い API情報もprotobufにてIDEで見れるので困っていない →　今のところ社内のニーズにマッチしなかった 19
20. Backstageの運用は以下がネックだった フロントエンド + バックエンド + データベースの3層構成の運用が必要 セキュリティアップデートが必要なのでビルド＆デプロイを定期的に行わないといけな い PlatformチームにReactを使えるメンバーが少ないため学習コストが高かった GitHubのtokenやKubernetesのtokenなどの管理も考える必要がある 依存関係など、プロダクト側でメンテナンスが必要なところは放置される可能性が ある 20
21. 2 1 内製ツール、pedcliの開 発
22. 内製ツールpedcliの概要 コマンド pedcli 統一コマンドラインインターフェース サブコマンド呼び出し サブコマンド init プロジェクト初期化 入力: 設定 出力: 初期データ テンプレート依存関係の設定 カタログファイルの初期構成生成 edit パラメータ編集&バリデーション 入力: YAML/JSON 出力: 検証済設定 YAML編集 設定バリデーション generate 自動コード生成と最適化 入力: Template, Parameter 出力: ソースコード/PR テンプレート変換 PR自動生成 docs ドキュメント自動生成 入力: Parameter 出力: マークダウン/HTML API文書生成 依存関係図表自動作成 22
23. pedcliの運用フロー ローカル開発フェーズ CI/CD自動化フェーズ 1 initコマンド 新規プロジェクト作成 2 editコマンド パラメータをカスタマ イズ 3 docsコマンド ドキュメント生成・プ レビュー 4 GitHubにpush 変更をリポジトリに反映 5 CI自動実行 generateコマンドで PR作成 6 PRレビュー＆ マージ メインブランチへ反映 ローカル開発ではカタログファイルのYAMLの操作がメイン作業 実際にTemplateから生成するのはGitHub Actionsを使って行う 23
24. プロダクトカタログ設計 Backstageのサービスカタログを元にして設計、自動生成対象はentitiesに登録 サービスカタログと混乱してしまうのでプロダクトカタログという名前に決定 24
25. Entityの設計 Entityはプロダクトが必要とするリソースの種類を表す概念。自動生成するtemplateとも紐 づいており、YAMLではパラメータやPR作成先の設定なども管理する 25
26. プロダクトカタログからの生成物 生成される成果物は、プレフィックスによって運用方法を明確に区別する 自動生成ファイル gen_プレフィックスが付いているものは 自動生成 される 例: gen_deployment.yamlファイル, gen_service.yamlファイル gen_がついているファイルは すべて再生成 の対象になるため、ユーザー側で更新しない運用にする 手動運用ファイル プレフィックスなしのファイルは標準テンプレートでサポートできない部分に対して 手作業で運用 例: deployment.tamlファイル, service.yamlファイル プレフィックスなしのファイルは 自動生成の対象外 であり、ユーザーの運用に任せる 26
27. プロダクトカタログを使ってもらうための工夫 YAMLファイルを運用してみたところいくつかの課題があった YAMLファイルの入力漏れなどレビューのコストがかかる Templateの定義を見ないと設定が難しい バリデーション機能がないと間違い探しが難しい → pedcliに専用エディタとドキュメント生成機能があると楽できそうなので作成 することにした 今の設定を確認する時に探しにくい 27
28. インラインエディタの作成 テンプレートの定義に沿ってバリデーションやenumをselectできるエディタを作成エ ラー発生時（右の図）も何がエラーなのかわかりやすくした 28
29. ドキュメントの生成 enechain / services-dependencies.md Enechain Services Services Dependencies This document outlines the dependencies between various Enechain services: • eSquare: Depends on eAuth for authentication • eCloud: Depends on eAuth for authentication • eBilling: Depends on eAuth for authentication • eAuth: Core authentication service Dependency Graph 設定したプロダクトカタログからはメタデータや依存関係のグラフを自動生成 生成物はGitHub上で下記のように見ることができる 29
30. 3 0 プロダクトへの導入
31. 既存プロダクトの移行手順 1. 移行用スクリプト or AIで移行を行う 移行スクリプト 標準構成に準拠していてシンプルなもの （Terraformなど） AIで移行 プロダクト固有の設定があり複雑度が高いもの （Kubernetes manifestsなど） 2. スクリプトで移行の場合 スクリプト実行後、手順4に進む 3. AIでの移行の場合 AIでの移行は専用のpromptを提供する 標準化で対応できないケースもサポートする 4. CI上とArgoCDやTerraformで差分確認後に適用 CI上とArgoCD/Terraformで差分が問題ないことを確認したら適用する 31
32. スクリプトによるTerraformの移行 Terraformはスクリプトにて.tfファイルをパースしてコード上でマッピングを行う 下記の例では正社員と契約社員を分けたいためコメントを拾って分離している 32
33. AIによるmanifest移行の流れ 1 Phase 1: catalog 入力 既存マニフェスト(v1) 出力 プロダクトカタログ 2 Phase 2: generate 入力 プロダクトカタログ 出力 v2マニフェスト ※移行作業時はCI/CDで生成 3 Phase 3: diff 入力 v1マニフェスト & v2マニフェスト 出力 差分レポート 4 Phase 4: overlay 入力 差分レポート 出力 kustomize patches 5 Phase 5: verify 入力 v1マニフェスト & v2マニフェスト+patches 出力 kustomize build結果 判定: 差分の検証 差分がない結果 (想定される差分だけ )になればPRを作成 enechainではmanifest管理に Kustomizeを使っているので 固有の設定はパッチを作成 33
34. AIによるmanifest移行用のprompt promptにはテンプレートのスキーマ定義を埋め込みコメントでRequire/Mustを入れる パラメータのフォーマットはコメントにて指示している 34
35. AIによるmanifest移行用のprompt manifestから取得する値とEntityやパラメータのマッピングは人がMarkdown内に記述 標準化されていない設定の指示もできる限りここに記載するとスムーズに移行できる 35
36. ClaudeCodeでのmanifest移行 AIはClaudeCodeを使い、promptを生成するコマンド（migration-tool）を使って移行を実施 する。引数から環境ごとにカスタマイズされたpromptを出力する 36
37. ClaudeCodeでのmanifest移行 promptに従ってYAMLファイルのマイグレーションが実施される。指示の通りに CloudeCodeがリソースファイルとentityとのマッピングを作成してくれる 37
38. ClaudeCodeでのmanifest移行 38 生成物はプレビューに出力されるようにしているのでそこで目視確認する owner（TODOのところ）などコード化されてないところは手作業で編集する
39. ClaudeCodeでのmanifest移行 標準化対象外の設定はprefix無し（手動運用）のpatchとしてClaudeCodeが作成 39
40. AIによる自動生成の結果 実行結果として想定通り下記のようなmanifestが出力され、移行を完了できた kustomization.yamlは予約名なのでprefixを付与していない運用にした products application backend overlays dev configs gen_backend.env gen_deployment-patch.yaml gen_hpa.yaml gen_label-transformer.yaml gen_service-patch.yaml kustomization.yaml google workload_identity overlays dev gen_workload-identities.yaml kustomization.yaml 40
41. AIで移行してみた感想 移行作業は目論見通り無事完了 標準化されているものに関しては30分程度でスムーズに移行できた AIがかなり強力で、条件を列挙していけばかなりの精度で移行ができた 標準化されていないプロダクトでは調査や修正などで4時間程度かかった 41
42. 4 2 振り返り 42
43. IDPを導入してみての学び 最初に標準化とテンプレート化を行った結果、ある程度スムーズにV2移行で きたので事前にやっておいてよかった 今の規模だとGit Ops中心の運用でも十分なことがわかった Backstageの管理に時間を取られずに移行に集中できたのは結果的に良 かったと思う 自社の運用ではDatadogのサービスカタログの方が良さそうという社内FBも もらえた Templateを用意するのが思ったよりコストがかかった 43
44. 振り返ってみて 1ヶ月目 基盤構築フェーズ CLIの開発 CI/CDの整備 2ヶ月目 環境整備フェーズ テンプレート作成 3ヶ月目 移行フェーズ テンプレートの完成 移行手順整備 約三ヶ月で Instant Universe V2を開発から移行まで完了できたのは良かった Templateの作成と移行の準備に時間はかかったが初期コスト分は回収できそう 移行作業 44 Kubernetes manifestの移行が一番大変で Terraformは移行しやすい
45. 今後の展望 全プロダクトに導入し社内FBをもらいながら改善を続ける AIと連携させてより簡単にカタログ操作や変更 などをできるようにしていく 内製にこだわるのではなく、今後もしenechainに適しているツールが出てきたら移 行も検討する Datadogと連携を強化しAIやセキュリティ 検知機能などの管理や設定もIDPで可視 化して大事な設定漏れがないようにしていく 新規機能を必要な時にすぐ導入 できるように全ての機能をEntity化していく 45