クラウドネイティブ会議Day1_AI時代の開発スピードに追いつけ！ Argo CD ApplicationSetと挑む、PR単位の検証環境/Cloud Native Conference Day 1: Keeping Pace with Development Speeds in the AI Era! Building a Pull Request-Level Testing Environment with Argo CD ApplicationSet

Transcript

1. AI時代の開発スピードに追いつけ！ Argo CD ApplicationSetと挑む、PR単位の検証環境 2026.05.14
2. 2 2023/12- フリー株式会社 - 新規プロダクトの構築改善・支援 - 開発環境改善 今井 妃華 SRE Himeka Imai
4. freeeは「スモールビジネスを、世界の主役に。」をミッションに掲げ、 統合型経営プラットフォームを開発‧提供し、 だれもが⾃由に⾃然体で経営できる環境をつくっていきます。 起業やビジネスを育てていくことを、もっと魅⼒的で気軽な⾏為に。 個⼈事業や中⼩企業などのスモールビジネスに携わるすべての⼈が、 じぶんらしく⾃信をもって経営できるように。 ⼤胆にスピード感をもってアイデアを具現化できるスモールビジネスは、 今までにない多様な価値観や⽣き⽅、 新しいイノベーションを⽣み出す起爆剤だと私たちは考えています。 スモールビジネスが⼤企業を刺激し、社会をさらにオモシロク、 世の中全体をより良くする流れを後押ししていきます。 Mission スモールビジネスを、世界の主役に。
5. 　 電⼦稟議 経費精算 債権債務 管理 ⼈事労務 電⼦契約 固定資産 請求管理 会計 ⼯数管理 販売管理 会計‧⼈事労務‧販売管理を核とした 統合型経営プラットフォーム
6. 6 SEQチームとDXチームの紹介 「開発生産性」を「Platform（基盤）」で向上させるチーム Developer eXperience(DX) DXの観点 主なトピック - EKS向けCI/CD基盤 - 開発環境整備 - 新規プロダクト構築の効率化 Software Engineer in Quality (SEQ) SEQの観点 主なトピック - 自動テスト基盤 - 品質のオブザーバビリティ - テスト容易性の向上
7. 7 はじめに freeeの開 発 環 境の現 状と 課題 Preview環境のコンセプト Preview環境を広げる 05 成 果 06 Preview環境の実装 まとめと今後の課題 07 本セッションのアジェンダ 01 02 03 04
8. 8 フリーの開発環境 の現状と課題
9. 9 フリーの技術スタック
10. 10 組織・プロダクト規模 組織の規模拡大とともに、開発組織の人数も一貫して増えている 引用元： https://speakerdeck.com/freee/10fen-dewakarufreee-enziniaxiang-kehui-she-shuo-ming-zi-liao?slide=25
11. 11 AIコーディングの普及と PR数増加 • 1年単位で見たPR量が前年の1.25倍 -> 1.61倍と加速度的に増えている • デプロイ時に使うCIのCommit数も右肩上がりに増加 ◦ デプロイもPRも増えている状況 去年の今頃
12. 　 電⼦稟議 経費精算 債権債務 管理 ⼈事労務 電⼦契約 固定資産 請求管理 会計 ⼯数管理 販売管理 会計‧⼈事労務‧販売管理を核とした 統合型経営プラットフォーム 統合を実現するためのマイクロサービスが多数存在
13. 13 基盤が会計を参照していたり、依存するマイクロサービスのリストもない 依存関係が複雑 freee会計 基盤A 人事労務 販売 etc... 基盤B 基盤C 人事労務 販売 etc... 人事労務 販売 etc... マイクロサー ビス マイクロサー ビス マイクロサー ビス群
14. 14 依存マイクロサービスを構築する大変さ • 把握の難しさ ◦ あるプロダクトの依存サービスの一覧を探すところからスタート ◦ Podが動く状態になるまでに必要な依存環境とは別に特定の機能でのみ使 う環境なども存在 ▪ ターゲットのサービスを構築した後一通り実際に触ることでしか依存を把 握できなかった • 依存サービスを立てるために様々なチームに頭出しする必要がある点も大変 な点だった。 ◦ この手間があったため5年以上検証環境の数は増えることがなかった....
15. 15 https://www.wantedly.com/companies/wantedly/ post_articles/313884 Preview環境の先行事例（一部） https://zenn.dev/ubie_dev/articles/8c34b0862 6aa88
16. 16 Preview環境の 全体像
17. 17 Preview環境の全体像 PR A環境 PRX環境... 共通環境 Headerによる ルーティング App Repo PR Infra Repo PR PRX環境... PR X環境... Infra main Branch Github Actions
18. 18 「開発者に使ってもらう Preview環境」 実現のための「こだわり」 1. 開発者が行う Stepの最小化 2. 小さなチームに確実に届け切る Preview環境のコンセプトとこだわり
19. 19 実は以前同じような仕組み（ e2e-infra）を作って失敗し、撤退している • 夢のような基盤 ◦ E2EテストをPR毎に環境を作って自動実行してくれる！ ◦ staging環境でのE2Eテストの失敗・修正を未然に防げる！ ➡ 2年ぐらい投資したが使われず廃棄 なぜか？ • 開発者のペインをきちんと深掘りせずに、SRE/QAの課題感から始めた • 使ってもらうための開発者体験の向上よりも、安定性や機能実装を優先してしまった • いきなり大きなチームからはじめた • 開発チームへのEnablingが不十分だった なぜ使ってもらうことにこだわったか プロダクトマネジメント・ Platform Engineeringの典型的アンチパターン
20. 20 1. 開発者が行う Stepの最小化 2. 小さなチームに確実に届け切る Preview環境のこだわり
21. 21 要素をふたつに分解 - PRへの情報の集約 - 手順の簡略化と拡張性の両立 開発者が行う Stepの最小化
22. 22 - Previewにアクセスする方法 - ArgoCD Application - Infra RepoへのPR 情報の集約 PRコメントに集約
23. 23 - 基本的には ApplicationにLabelを貼る手順を追加して待つだけ - デバックや拡張時は簡単に確認・修正 - 特殊なケースでも大幅に手順を増やさない 手順の簡略化と拡張性の両立 リソース群 InfraPR App　PR 自動化部分 普段のPRにLabelを 貼るだけ
24. 24 - URLにするとマイクロサービス間のリダイレクトの部分に手を加えないといけない課題があっ た - そのためHeaderルーティングにし、Chrome拡張機能でheaderを簡単に追加できるようにし た - 現在どのPR・Commitを見ているか拡張機能によって表示されるので「本当にみたい変更が 加えられた環境か？」をエンジニアが確認しやすいメリット Headerルーティングを行うための独自拡張機能
25. 25 要素をふたつに分解 - PRへの情報の集約 - 手順の簡略化と拡張性の両立 開発者が行う Stepの最小化
26. 26 1. 開発者が行う Stepの最小化 2. 小さなチームに確実に届け切る Preview環境のこだわり
27. 27 条件は三つ 1. 他のプロダクトとの依存関係が比較的少ないこと 2. ほぼ単一チームで開発を行っていること 3. 同期処理が処理の大部分を担っていること 届け切る「小さなチーム」の選定
28. 28 条件は三つ 1. 他のプロダクトとの依存関係が比較的少ないこと -> 構築時間を最小化するため 2. ほぼ単一チームで開発を行っていること 3. 同期処理が処理の大部分を担っていること 届け切る「小さなチーム」の選定
29. 29 条件は三つ 1. 他のプロダクトとの依存関係が比較的少ないこと -> 構築時間を最小化するため 2. ほぼ単一チームで開発を行っていること -> FBループを確実に回すため 3. 同期処理が処理の大部分を担っていること 届け切る「小さなチーム」の選定
30. 30 条件は三つ 1. 他のプロダクトとの依存関係が比較的少ないこと -> 構築時間を最小化するため 2. ほぼ単一チームで開発を行っていること -> FBループを確実に回すため 3. 同期処理が処理の大部分を担っていること -> 検証する環境をできるだけシンプルに保つため 届け切る「小さなチーム」の選定
31. 31 2月下旬のパイロット利用開始から確実に利用され続けていることがわかる 日毎のPreview利用集計
32. 32 ユーザーの Slackでの声
33. 33 開発者のアイデアも生かしつつ開発 「これは本当に最新か？」を 検証したいという開発者の 要望 から生まれたCommit Hash併記
34. 34 Preview環境を広 げる
35. 35 フリーの全開発者向け配信で共有
36. 36 配信でのSlackの反応（抜粋）
37. 37 横展開を素早くするために Skill化 • 開発と同時に横展開のためのSkillを作成し、それを更新していく形でメンテナ ンスしている ◦ Skillを作ることで大まかな実装手順を同時並行で作れるというメリットもあ る。 • CI部分はプロダクト毎にデプロイフローが少し違うこともあり、かっちり共通化 することが難しい部分であったため自由度を持たせた実装にし、細かい部分を Skillで作っていく形式にした
38. 38 freee会計への前倒し導入 • パイロットプロダクトで継続して利用できる状態になり、これを全エンジニアの集会で共有したと ころ、会計側エンジニアの協力もあり、freee会計での前倒し導入が実現 • 課題であった検証環境の逼迫が一番深刻なプロダクトの一つに届けられ、実際にデザイナーと のレビュー依頼で早速利用があった。 会計の機能開発ででデザイナー へのレビューを依頼した時の Slackのコミュニケーション
39. 39 成果
40. 40 2月下旬のパイロット利用開始から確実に利用され続けていることがわかる 日毎のPreview利用集計（再）
41. 41 Preview環境を利用すると特に250行以下の比較的小規模のコード変更ではPR滞留時間に 有意な減少があった。 Preview利用の効果
42. 42 freee会計への前倒し導入 • パイロットプロダクトで継続して利用できる状態になり、これを全エンジニアの 集会で共有したところ、会計側エンジニアの協力もあり、freee会計での前倒し 導入が実現 • 課題であった検証環境の逼迫が一番深刻なプロダクトの一つに届けられ、実 際にデザイナーとのレビュー依頼で早速利用があった。 会計の機能開発ででデザイナー へのレビューを依頼した時の Slackのコミュニケーション
43. 43 Preview環境の 実装
44. 44 環境生成部分に注目したフリーの Preview環境 PRA環境 PRX環境... App Repo PR Infra Repo PR PRX環境... PRX環境... Github Actions Infra repo のみを参照 固有の情報を 渡しPRを生成
45. 45 PullRequest Generator • Github等のSCMaaSのAPIを用いてリポジトリ内の未解決のPRを自動的に検出しApplication を作るGenerator ◦ PRの中からさらに、branch名・対象ブランチ名・PRタイトル名などを正規表現でフィルタリング することができる ◦ labelでもフィルタリングすることが可能 • アプリリポジトリのPRを参照することが多いが、フリーではインフラリポジトリのPRを参照するよう にしている ◦ Good：インフラのPR毎の改変の自由度が高い ◦ Bad： インフラPRのライフサイクル管理、統制する場所が多い ※SCMaaSプロバイダーはGithubを前提に話します
46. 46 生成部分に着目した、よくある Preview環境 PR A環境 PRX環境... App Repo PR PRX環境... PR X環境... Infra main Branch App Repoを 参照して生成 設定はこちらを 参照
47. 47 環境生成部分に注目したフリーの Preview環境 PRA環境 PRX環境... App Repo PR Infra Repo PR PRX環境... PRX環境... Github Actions Infra repo のみを参照 固有の情報を 渡しPRを生成
48. 48 - インフラリポジトリとアプリケーションリポジトリにまたがるので、それぞれのリポジトリの関連CI の責務を以下のように整理している Github Actionsでのライフサイクル管理 インフラCI アプリCI • インフラ側PRのライフサイクル 管理 ◦ Merge阻止 ◦ 3日たったPRをClose • 常設環境のImage更新 ◦ 日時でProductionのものに することで、本番と条件を近 づける • PR固有の情報管理 ◦ Headerの値 ◦ PR固有の環境変数書き 換え ▪ redis®等 • アプリPRと連動したライフサ イクル管理 ◦ インフラリポジトリへのPR のOpen・Close
49. 49 Preview環境と永続化層の接続 PR A環境 PRX環境... 共通環境 Headerによる ルーティング PRX環境... PR X環境...
50. 50 • 全てのPRによって作られる環境が単一のWorkerインスタンスとジョブキュー を共有している状況だった。 ◦ PR 間でのジョブの奪い合いが発生 ◦ 参照Workerの競合 ◦ テスト干渉・環境の再現がしづらくデバッグが困難 • resqueueの既存Integration環境のだし分けには、DB番号で分けている実 装もnamespaceで分けている実装も存在する ◦ 既存のWoekerのQueueの出し方によって実装が変わることやPreview環 境だけのロジックを作ることは避けたかった WorkerのQueueを共通KVSで集約する問題点
51. 51 PRのライフサイクルに閉じるなら Podにすればいいじゃない！ PR A環境 PRX環境... 共通環境 Headerによる ルーティング PRX環境... PR X環境...
52. 52 • フリーにおけるredisの利用のされ方は主に二つ ◦ DBのキャッシュ ◦ worker用のQueue • データの特性を考える ◦ 前者は最悪データがなくなっても良い ◦ 後者はむしろライフサイクルに合わせてなくなって欲しい WorkerのQueueとして使われる KVSの利用方法 KVSのデータの中身は環境内に閉じて存在する！ 独立したPodとしてRedis®を立てることで解決
53. 53 今後の課題と まとめ
54. 54 - 単一DBだけのシンプルな構造であればその都度DBを作り直せば解決する - Redisの場合はこの条件を満たした - サービス間でのデータの依存関係があるケースがありそのケースにおいて存在し得ない挙動を するリスクがある DBの整合性問題 PR A環境 PRX環境... PRX環境... PR X環境... ? ?
55. 55 PR後、Preview 環境が使えるまでのリードタイム問題 • PR毎にDocker Imageを作るため、Docker buildの時間が環境使えるまでのボトルネック • 今後DBを実践運用していく時にもDB Migrationの時間がボトルネックの一つになることが 予想 • 解決策としてDocker Build時間の最適化をする必要があるがまだ着手できず
56. 56 オブザーバビリティの確保 • 全てのPreview環境にオブザーバビリティを素朴に導入するとコストが高くなってしまうリス クがある ◦ Preview環境ではArgoCDのLog監視ツールやCLIによるデバックしかサポートしていな い • 可観測性の確保はレビューやデバックにおいても重要な観点になりうるため、Preview環境 に的したコストが低いオブザーバビリティツールを導入したい
57. 57 まとめ • AIによるPR数向上により、検証環境の不足が深刻化していたが、ArgoCDや GithubActionsなどのCI /CD基盤を駆使することで簡単にPreview環境を作ることができた • 社内プラットフォームであっても、小さな１プロダクトに向けて改善サイクルを回すといった開 発のプラクティスをうまく利用することで、使われるプラットフォームに早く近づける ◦ そのために「確実に機能を届け切るにはどうすればいいか」という視点が重要 ▪ 要件のメリハリが大事 • DBのデータ整合性、オブザーバビリティなど解かなければならない課題はたくさん
58. 58 参考文献 Preview環境先行事例 • https://www.wantedly.com/companies/wantedly/post_articles/313884 • https://zenn.dev/ubie_dev/articles/8c34b08626aa88 • https://techblog.zozo.com/entry/zozotown-android-vrt • https://tech-blog.rakus.co.jp/entry/20260115/argocd • https://tech-blog.monotaro.com/entry/2025/04/22/090000 • https://tech.assured.jp/entry/2025/06/19/100000 • https://techblog.tg-inet.co.jp/entry/2026/03/04/095136 • その他参考文献 • https://istio.io/latest/docs/ops/best-practices/traffic-management/#split-virtual-services Slack絵文字 しかまつ 様 https://note.com/shikamatsu/n/nd217dc0617db
59. スモールビジネスを、世界の主役に。