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

by endo

Slide 1

Slide 1 text

サービスカタログに基づくTerraform/K8s コードの自動生成 Platform Engineering Desk 遠藤雅彰

Slide 2

Slide 2 text

自己紹介写真をここに配置遠藤　雅彰株式会社enechain Platform Engineering Desk プリンシパルエンジニア略歴 2022年 - 現在株式会社enechain 2020年 - freee株式会社 2 2016年 - 株式会社メルカリ 2012年 - グリー株式会社 2008年 - Speee株式会社 2004年 - ガイオテクノロジー株式会社

Slide 3

Slide 3 text

3 会社紹介 - 株式会社enechain さらっと紹介する感じ。 hiyosiさんの時のやつを使えばよさそう。そもそも会社のこと話ししてok? 3

Slide 4

Slide 4 text

展開しているサービス ● enechainでは創業から６年の間に様々なサービスを展開してきました ● サービスが拡大していく中でいくつかの大きな課題が発生していました 4

Slide 5

Slide 5 text

5 Platformチームで発生していた課題 5

Slide 6

Slide 6 text

プロジェクト背景と課題 Platformチームで発生していた課題創業当初のスピード感で事業を拡大していった結果、manifestやterraformが独自形式で作られてしまいメンテナンスコストが徐々に高くなった新しく推奨構成を作っても独自形式を対応させるコストが発生するため、更新が進まない新規プロジェクトを作成する際に古いコードを参考にしてmanifestが作られることも多く、問題が拡大した

Slide 7

Slide 7 text

Platformチームがイメージしていた理想の運用セルフサービス運用 SRE/Platformチームがボトルネックにならず、プロダクト開発者がセルフサービスでインフラの運用ができる構成変更の適用構成変更などのアップデートが全プロダクトに適用できるチーム間連携サービスを誰がメンテナンスしているのかを把握してチーム間連携ができている依存関係の理解サービス間の依存関係を理解してインフラ構築ができている 7

Slide 8

Slide 8 text

理想と現実のギャップ manifestやterraformのガバナンス構成変更の一括反映の仕組みが存在しない manifestの理解と作成スキルプロダクト開発者に全部理解してもらうのは厳しい、プロダクトの開発に集中できなくなる担当チーム管理シート適切に管理出来ておらず、時間経過によってメンテナが曖昧になってしまっているサービスマップの作成依存関係が増えるたびに手作業でなんとかしないといけない抜本的にアプローチを変える必要があった 8

Slide 9

Slide 9 text

9 問題の解決に向けて 9

Slide 10

Slide 10 text

Internal Developer Platform（IDP）の検討 IDPとは開発者が自律的に開発・デプロイできる環境を提供する社内向けプラットフォーム Templateを用いて開発者がセルフサービスで環境構築やデプロイが可能になるよう設計する標準化と自動化の実現標準化と自動化により、開発のスピードと品質を向上させ、運用負荷を軽減サービスカタログの活用各サービスのオーナー情報、リポジトリ、ステータス、依存関係などを一元表示することができる → 今回の課題解決に良さそう 10

Slide 11

Slide 11 text

IDP導入に向けてプロジェクト化テンプレートによる自動生成構成変更時には再生成により全プロジェクトへの反映を可能とし、ガバナンスを効かせる標準化の策定をするテンプレートで生成しやすいように可能な限り統一するサービスカタログを導入するプロダクトの実態の可視化と運用改善を目指す → 導入を目指して Instant Universeプロジェクト発足 11

Slide 12

Slide 12 text

実装フェーズと移行計画フェーズ1（Instant Universe V1）新規プロダクトでテンプレートを使用する標準化の策定を行いプロジェクト個別の設定を制限する generatorでプロジェクト全体のボイラープレートを生成するフェーズ2（Instant Universe V2）既存プロダクトのサービスカタログへの移行開発者がTemplateを選んで生成できるようにする CIを整備してGit Opsで運用できるようにする実行計画フローフェーズ 1 テンプレート導入・標準化の実施実施計画 STEP 1 新規プロダクトに導入フェーズ 2 カタログモデル・自動化の実装実施計画 STEP 2 既存プロダクトの移行を実施 12

Slide 13

Slide 13 text

Instant Universe V1 V1 2024/05 リリース標準化の定義予測可能な設定と一貫性のある構成を実現簡易的なシェルスクリプトでのテンプレート生成開発効率と一貫性の向上を実現新規作成時は最新のテンプレートから生成常に最新の標準に準拠した環境構築を保証詳しくは弊社のブログで紹介しているので気になる方はQRコードの記事参照 13

Slide 14

Slide 14 text

1 4 計画の見直し 14

Slide 15

Slide 15 text

Backstageの台頭検討事項フェーズ2の開発途中でBackstageが台頭してきた方針を転換すべきか、このまま進めるべきか検討をした社内で既に導入済みのDatadogもサービスカタログを提供してきたので合わせて検討することにした 2つのツールを比較し、再検討することにした 15

Slide 16

Slide 16 text

Datadog vs Backstage Datadog 運用監視に特化したサービスカタログ既存サービスの「監視・運用・パフォーマンス管理」が主目的リアルタイム性、自動検出、統合監視が強み開発者ポータル機能(テンプレート、ドキュメント、ワークフロー)は提供しない Backstage 開発者ポータルとしてのサービスカタログ「サービス管理+開発者エクスペリエンス向上」が主目的プロジェクト生成、ドキュメント、ツール統合、カスタマイズが強みリアルタイム監視機能は外部ツール連携に依存 16

Slide 17

Slide 17 text

改めて整理した自分たちがほしかったものプロダクト開発者がセルフサービスでインフラの運用ができる SRE/Platformチームがボトルネックにならずに新規プロダクトが作成できる構成変更などのアップデートが全てに適用できるサービスを誰がメンテナンスしているのかわかるサービス間の依存関係がわかる 17

Slide 18

Slide 18 text

内製ツールとDatadogの併用の方向に決定 Datadogの利点サービスカタログやプロダクト担当者は Datadogでも管理できる Datadogは実際のAPIリクエストからサービスマップを表示してくれる DatadogにてPagerDurty相当のアラート対応が可能 Datadogに足りない機能へのアプローチ足りないところ（Scaffolderなど）は内製ツールに持たせる Datadogのサービスカタログへの登録は内製ツールで行う内製ツールと Datadogの併用内製ツール Scaffolder テンプレート ★ 自動化機能テンプレートからカタログ登録 Datadog サービスマップカタログ管理 ★ アラート機能 GitOpsとDatadogの連携による運用 18

Slide 19

Slide 19 text

何故Backstageを使わなかったのか少ないメンバーでの運用が難しかったドキュメント管理も今のNotionとGitHubからWebで見るのでも困っていない既にDatadogを活用していたこともあり、Datadogとの連携の方が新しいツールを覚えなくて良い API情報もprotobufにてIDEで見れるので困っていない →　今のところ社内のニーズにマッチしなかった 19

Slide 20

Slide 20 text

Backstageの運用は以下がネックだったフロントエンド + バックエンド + データベースの3層構成の運用が必要セキュリティアップデートが必要なのでビルド＆デプロイを定期的に行わないといけない PlatformチームにReactを使えるメンバーが少ないため学習コストが高かった GitHubのtokenやKubernetesのtokenなどの管理も考える必要がある依存関係など、プロダクト側でメンテナンスが必要なところは放置される可能性がある 20

Slide 21

Slide 21 text

2 1 内製ツール、pedcliの開発

Slide 22

Slide 22 text

内製ツールpedcliの概要コマンド pedcli 統一コマンドラインインターフェースサブコマンド呼び出しサブコマンド init プロジェクト初期化入力: 設定出力: 初期データテンプレート依存関係の設定カタログファイルの初期構成生成 edit パラメータ編集&バリデーション入力: YAML/JSON 出力: 検証済設定 YAML編集設定バリデーション generate 自動コード生成と最適化入力: Template, Parameter 出力: ソースコード/PR テンプレート変換 PR自動生成 docs ドキュメント自動生成入力: Parameter 出力: マークダウン/HTML API文書生成依存関係図表自動作成 22

Slide 23

Slide 23 text

pedcliの運用フローローカル開発フェーズ CI/CD自動化フェーズ 1 initコマンド新規プロジェクト作成 2 editコマンドパラメータをカスタマイズ 3 docsコマンドドキュメント生成・プレビュー 4 GitHubにpush 変更をリポジトリに反映 5 CI自動実行 generateコマンドで PR作成 6 PRレビュー＆マージメインブランチへ反映ローカル開発ではカタログファイルのYAMLの操作がメイン作業実際にTemplateから生成するのはGitHub Actionsを使って行う 23

Slide 24

Slide 24 text

プロダクトカタログ設計 Backstageのサービスカタログを元にして設計、自動生成対象はentitiesに登録サービスカタログと混乱してしまうのでプロダクトカタログという名前に決定 24

Slide 25

Slide 25 text

Entityの設計 Entityはプロダクトが必要とするリソースの種類を表す概念。自動生成するtemplateとも紐づいており、YAMLではパラメータやPR作成先の設定なども管理する 25

Slide 26

Slide 26 text

プロダクトカタログからの生成物生成される成果物は、プレフィックスによって運用方法を明確に区別する自動生成ファイル gen_プレフィックスが付いているものは自動生成される例: gen_deployment.yamlファイル, gen_service.yamlファイル gen_がついているファイルはすべて再生成の対象になるため、ユーザー側で更新しない運用にする手動運用ファイルプレフィックスなしのファイルは標準テンプレートでサポートできない部分に対して手作業で運用例: deployment.tamlファイル, service.yamlファイルプレフィックスなしのファイルは自動生成の対象外であり、ユーザーの運用に任せる 26

Slide 27

Slide 27 text

プロダクトカタログを使ってもらうための工夫 YAMLファイルを運用してみたところいくつかの課題があった YAMLファイルの入力漏れなどレビューのコストがかかる Templateの定義を見ないと設定が難しいバリデーション機能がないと間違い探しが難しい → pedcliに専用エディタとドキュメント生成機能があると楽できそうなので作成することにした今の設定を確認する時に探しにくい 27

Slide 28

Slide 28 text

インラインエディタの作成テンプレートの定義に沿ってバリデーションやenumをselectできるエディタを作成エラー発生時（右の図）も何がエラーなのかわかりやすくした 28

Slide 29

Slide 29 text

ドキュメントの生成 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

Slide 30

Slide 30 text

3 0 プロダクトへの導入

Slide 31

Slide 31 text

既存プロダクトの移行手順 1. 移行用スクリプト or AIで移行を行う移行スクリプト標準構成に準拠していてシンプルなもの（Terraformなど） AIで移行プロダクト固有の設定があり複雑度が高いもの（Kubernetes manifestsなど） 2. スクリプトで移行の場合スクリプト実行後、手順4に進む 3. AIでの移行の場合 AIでの移行は専用のpromptを提供する標準化で対応できないケースもサポートする 4. CI上とArgoCDやTerraformで差分確認後に適用 CI上とArgoCD/Terraformで差分が問題ないことを確認したら適用する 31

Slide 32

Slide 32 text

スクリプトによるTerraformの移行 Terraformはスクリプトにて.tfファイルをパースしてコード上でマッピングを行う下記の例では正社員と契約社員を分けたいためコメントを拾って分離している 32

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

AIによるmanifest移行用のprompt promptにはテンプレートのスキーマ定義を埋め込みコメントでRequire/Mustを入れるパラメータのフォーマットはコメントにて指示している 34

Slide 35

Slide 35 text

AIによるmanifest移行用のprompt manifestから取得する値とEntityやパラメータのマッピングは人がMarkdown内に記述標準化されていない設定の指示もできる限りここに記載するとスムーズに移行できる 35

Slide 36

Slide 36 text

ClaudeCodeでのmanifest移行 AIはClaudeCodeを使い、promptを生成するコマンド（migration-tool）を使って移行を実施する。引数から環境ごとにカスタマイズされたpromptを出力する 36

Slide 37

Slide 37 text

ClaudeCodeでのmanifest移行 promptに従ってYAMLファイルのマイグレーションが実施される。指示の通りに CloudeCodeがリソースファイルとentityとのマッピングを作成してくれる 37

Slide 38

Slide 38 text

ClaudeCodeでのmanifest移行 38 生成物はプレビューに出力されるようにしているのでそこで目視確認する owner（TODOのところ）などコード化されてないところは手作業で編集する

Slide 39

Slide 39 text

ClaudeCodeでのmanifest移行標準化対象外の設定はprefix無し（手動運用）のpatchとしてClaudeCodeが作成 39

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

AIで移行してみた感想移行作業は目論見通り無事完了標準化されているものに関しては30分程度でスムーズに移行できた AIがかなり強力で、条件を列挙していけばかなりの精度で移行ができた標準化されていないプロダクトでは調査や修正などで4時間程度かかった 41

Slide 42

Slide 42 text

4 2 振り返り 42

Slide 43

Slide 43 text

IDPを導入してみての学び最初に標準化とテンプレート化を行った結果、ある程度スムーズにV2移行できたので事前にやっておいてよかった今の規模だとGit Ops中心の運用でも十分なことがわかった Backstageの管理に時間を取られずに移行に集中できたのは結果的に良かったと思う自社の運用ではDatadogのサービスカタログの方が良さそうという社内FBももらえた Templateを用意するのが思ったよりコストがかかった 43

Slide 44

Slide 44 text

振り返ってみて 1ヶ月目基盤構築フェーズ CLIの開発 CI/CDの整備 2ヶ月目環境整備フェーズテンプレート作成 3ヶ月目移行フェーズテンプレートの完成移行手順整備約三ヶ月で Instant Universe V2を開発から移行まで完了できたのは良かった Templateの作成と移行の準備に時間はかかったが初期コスト分は回収できそう移行作業 44 Kubernetes manifestの移行が一番大変で Terraformは移行しやすい

Slide 45

Slide 45 text

今後の展望全プロダクトに導入し社内FBをもらいながら改善を続ける AIと連携させてより簡単にカタログ操作や変更などをできるようにしていく内製にこだわるのではなく、今後もしenechainに適しているツールが出てきたら移行も検討する Datadogと連携を強化しAIやセキュリティ検知機能などの管理や設定もIDPで可視化して大事な設定漏れがないようにしていく新規機能を必要な時にすぐ導入できるように全ての機能をEntity化していく 45

Slide 46

Slide 46 text

No content