Argo CDとAtlantisで実現するインフラ管理のセルフサービス化──小規模SREチームで支えるプラットフォーム

https://www.cnia.io/pek2026/sessions/91c5eecd-3e0b-424b-bfd6-14733ae280d3/

Transcript

1. Argo CDとAtlantisで実現するインフラ管理のセルフサービス化 ──小規模SREチームで支えるプラットフォーム 2026/09/26 Platform Engineering Kaigi 2026 株式会社アンドパッド 開発本部 サービスプラットフォーム部 部長 角井 暖 © 2026 ANDPAD All Rights Reserved. 1
2. 自己紹介 角井 暖 / Dan Kadoi • • • • @cass7ius ERP パッケージベンダーで DevOps を経験し、 2019 年 8 月よりアンドパッドの SREに参画 コンテナ化プロジェクト、SRE/DBREチームの テックリードなどを経て、2026年より部長に 就任 SRE / DBRE / セキュリティの 3 チームを管掌 © 2026 ANDPAD All Rights Reserved. 2
3. この発表は「SREへの依頼をPull Requestに変えた話」 • 小規模なSREチームによる、インフラ管理のセルフサービス化の事例 • 変更の入口はPull Requestに一本化。適用はプラットフォームの仕事 • 前半：なぜGitOpsだったのか、依頼をPull Requestに変えるとは何か • 後半：入口 → 境界 → 検証 → 適用 の4段階で、どのように整備したか • 最後に、何がどれだけ変わったか • 気になった点、もっと詳しく聞きたい点はぜひブースへ © 2026 ANDPAD All Rights Reserved. 3
4. 前提と、起きていたこと 事業と組織、そしてマイクロサービス化のあと © 2026 ANDPAD All Rights Reserved. 4
5. ANDPADとは ※ ANDPADは現場の効率化から経営改善まで一元管理できる クラウド型建設プロジェクト管理サービスです クラウド上で最新の情報を共有 スマホで撮影した写真、 データを活用して、 チャットで共有された ・資料作成 資料や各現場の図面 ・検査報告書作成 データ 入力 写真 工程表 チャット 報告 受発注 検査 引合粗利 図面 データ 活用 ・帳票作成 ・データ資産... ※『建設業マネジメントクラウドサービス市場の動向とベンダシェア（ミックITリポート 2025年12月号）』（デロイト トーマツ ミック経済研究所調べ） © 2026 ANDPAD All Rights Reserved. 5
6. マルチプロダクト戦略を小規模なSREチームで支える • • フェーズも体制も異なるプロダクト開発チームが多数あり、横断的な関 心事を扱うチームが施策の展開や技術支援をしている SREは中央集中型の小規模チームで、Embedded SREはなし 開発チームA 開発チームB QA QA Frontend Backend Native App 開発チームC 開発チームD Frontend Frontend Frontend Backend Backend Backend Native App 横断的な関心事を扱うチーム （SRE, DBRE, CRE, セキュリティ, FinOps など） © 2026 ANDPAD All Rights Reserved. 6
7. マイクロサービスアーキテクチャの採用とその後 • • • • • もともとは、巨大なRailsアプリがひとつだけ 事業成長に伴って拡大する開発リソースをフル活用するため、マイクロ サービスアーキテクチャの採用を決定 2021年頃、マイクロサービスの共通実行基盤をEKSで構築。アプリのデ リバリー以外の関心事を抽象化 ◦ テレメトリ収集と計装、サービスディスカバリとL7負荷分散、外部 公開の手法などを、SREで機能提供 デリバリーは各チームの裁量に委ね、新規事業の立ち上げを加速 その結果、数年の時を経て3つの課題が顕在化 © 2026 ANDPAD All Rights Reserved. 7
8. 顕在化した3つの課題 1. デリバリーパイプラインのサイロ化 — 運用ナレッジがチーム内に閉じる 2. インフラ管理の自律性の低下 — 強い権限を要する作業がSREへの依頼に 3. システム構成の不透明化 — 命令的なデプロイと手作業の変更の蓄積 プロダクトが増えるほど掛け算で大きくなる 重なり合う問題として、まとめて手を打つ必要があった © 2026 ANDPAD All Rights Reserved. 8
9. どう解くことにしたか 考え方と、プラットフォームの全体像 © 2026 ANDPAD All Rights Reserved. 9
10. 3つの課題の根は、変更の経路がばらばらだったこと • • • • 課題1はチームごとの経路、課題2はSREへの依頼、課題3は手作業 決めたのは1本の標準経路 ◦ 入口はPull Request、適用はプラットフォーム その経路の型としてGitOpsを採用。あるべき状態をGitに宣言する OpenGitOpsの4原則（opengitops.dev） ◦ 宣言的：あるべき状態が宣言で表現されている ◦ バージョン管理され不変：履歴が残り、書き換えられない ◦ 自動的にpull：エージェントが自動で取得する ◦ 継続的にリコンサイル：実状態を観測し、寄せ続ける © 2026 ANDPAD All Rights Reserved. 10
11. 依頼をPull Requestに変え、セルフサービス化を促進 • • • • 依頼のかたち：チャットで相談 → SREが手で作業 → 記録は手順書の中 Pull Requestのかたち：宣言で表現、履歴はGit、適用はプラットフォー ム 開発チームとの接点は残して、強い権限ではなくレビューで安全性を担 保 SREは変更の代行者ではなく、安全に変更できるプラットフォームの提 供者 © 2026 ANDPAD All Rights Reserved. 11
12. プラットフォームの全体像 • 変更はPull Requestから入り、適用はプラットフォーム側が行う Argo CD sync Kubernetesクラスター 各Application クラスター内で pull インフラの設定を管理する GitHubリポジトリ群 あるべき状態をGitに宣言する Atlantis Pull Request上で plan / apply apply クラウド / SaaS AWS・監視・ID基盤 ほか © 2026 ANDPAD All Rights Reserved. 12
13. インフラの設定を管理するリポジトリ群 • • • • アプリ用モノレポ（開発チームが管理） ◦ マイクロサービスのApplicationの定義と、チーム固有のHelm Chart プラットフォーム用モノレポ（SREが管理） ◦ 基盤コンポーネントと、Argo CD自体の設定 （ApplicationSet・AppProject） ◦ 共通のCIワークフローと、クラスター全体に効くポリシー 共通Helm Chartリポジトリ（SREが提供し、各チームが参照） Terraformモノレポ（開発チームとSREが共同で管理） 「誰が何を変えられるか」は、まずリポジトリの分け方で決まる © 2026 ANDPAD All Rights Reserved. 13
14. Argo CDとは • • Gitのマニフェストをあるべき状態として読み取り、クラスター内から継 続的に同期するGitOpsツール CIに書き込み権限を渡さず、差分の自動適用はApplicationごとに宣言 Kubernetesクラスター pull merge 開発チーム アプリ用モノレポ Pull Requestを出す main = あるべき状態 Argo CD 差分を収束 各Application CI：検証のみ © 2026 ANDPAD All Rights Reserved. 14
15. Atlantisとは • • • TerraformのplanとapplyをPull Request上から実行するOSS 実行結果がPull Requestにコメントされ、コードレビューが容易に Pull Request経由の変更では、Gitの状態と実環境がずれにくい © 2026 ANDPAD All Rights Reserved. 15
16. Pull Requestが適用されるまでの4段階 • • 標準化した経路では、どの変更も4つの段階を同じ順で通る この段階を整備することで、課題がどう解決されるかを見ていく 段階 その段階で決めること 効いた課題 入口 どこに何を書くか 課題1 デリバリーパイプラインのサイロ化 境界 誰が何を変えられるか 課題2 インフラ管理の自律性の低下 検証 適用前に何を確かめるか 課題3 システム構成の不透明化 適用 誰が適用するか 課題2・課題3 © 2026 ANDPAD All Rights Reserved. 16
17. 書く場所と形を揃える 1つのモノレポに集め、ディレクトリの形を全チームで共通にする 課題1 デリバリーパイプラインのサイロ化を解消 入口 → 境界 → 検証 → 適用 © 2026 ANDPAD All Rights Reserved. 17
18. インフラの設定は、決まったリポジトリに集める • 変更の入口は、開発チームもSREも同じPull Request Pull Request 開発チーム アプリ用モノレポ プラットフォーム用モノレポ 共通Helm Chartリポジトリ SREチーム Terraformモノレポ © 2026 ANDPAD All Rights Reserved. 18
19. 【Kubernetes】1ディレクトリ = 1 Application clusters/<cluster>/<team>/<namespace>/<release>/ ├── helmfile.yaml # Helm Chart の参照とvaluesの重ね順 ├── values.yaml # 環境固有の設定値 ├── image.values.yaml # CI が更新するイメージタグ（コミット SHA） └── secrets.yaml # 暗号化された秘匿値 • • • 値はディレクトリ内で完結し、実行時に外から値を注入しない Helm Chartは同じリポジトリ内の charts/<team>/ を参照。外部の Chartはバージョンを固定 このディレクトリを見るだけで「何がどう出来上がるか」が分かる © 2026 ANDPAD All Rights Reserved. 19
20. 【Kubernetes】ApplicationSetで自動生成する generators: - git: repoURL: < アプリ用モノレポ > revision: main directories: - path: clusters/<cluster>/*/*/* • • • ディレクトリを追加すればApplicationも増える。1つずつ手で書く必要 なし チームによっては、設定ファイルを起点にするgeneratorも併用 テンプレートはプラットフォーム用モノレポにあり、全チーム共通 © 2026 ANDPAD All Rights Reserved. 20
21. 【Terraform】モノレポで構造を揃える <provider>/<product>/envs/<environment>/ <provider>/<product>/modules/... aws/modules/... • • • • # 1 つの実行単位 # プロダクト固有モジュール # 共通モジュール provider → プロダクト → 環境の3階層。stateとオーナーの単位を一致 1実行単位 = 1環境ディレクトリ。400件程度を1つのリポジトリで管理 ディレクトリパターンが揃っていれば、他所のコードを真似して書き始 められる 共通モジュールはSemVerで管理し、バージョンを指定して参照 © 2026 ANDPAD All Rights Reserved. 21
22. 【Terraform】atlantis.yamlで実行単位を宣言 projects: - name: <product>-<environment> dir: ./aws/<product>/envs/<environment> autoplan: when_modified: - "**/*.tf*" - "**/.terraform.lock.hcl" - "../../modules/**" # モジュール変更も plan対象 • • 実行単位の名前はパスから機械的に決まる命名規則。ファイル冒頭に明 文化 モジュールを変更すると、それを参照する実行単位も自動でplan対象に なる © 2026 ANDPAD All Rights Reserved. 22
23. 境界を宣言して権限を委譲する 触れる範囲を宣言で決め、その単位で権限を渡す 課題2 インフラ管理の自律性の低下を解消 入口 → 境界 → 検証 → 適用 © 2026 ANDPAD All Rights Reserved. 23
24. 【Kubernetes】AppProjectで触れる範囲を宣言する spec: destinations: [ < チームのnamespace> ] namespaceResourceWhitelist: - { group: apps, kind: Deployment } - { group: batch, kind: CronJob } roles: - name: developer policies: - p, proj:<team>:developer, applications, sync, <team>/*, allow - p, proj:<team>:developer, applications, action/*, <team>/*, allow # update は許可しない。マニフェストの変更は Pull Request から • • チーム名・IdPのグループ名・AppProject名を一致させ、境界を1つに統 一 強い権限を配るのではなく、扱えるリソース種別とNamespaceを宣言で 制限 © 2026 ANDPAD All Rights Reserved. 24
25. 【Terraform】オーナー定義とapply権限を委譲する • • state・CODEOWNERS・apply権限を、同じオーナー単位に揃える ◦ applyできる範囲は、AtlantisのExternal command機能で限定 ◦ 横断チームは委譲済み、開発チームはこれから AtlantisはECS on Fargateで実行し、強い権限は人ではなく実行基盤に © 2026 ANDPAD All Rights Reserved. 25
26. 適用前に差分を検証する 構造が同じなので、同じ検証をすべての変更にかける 課題3 システム構成の不透明化を解消 入口 → 境界 → 検証 → 適用 © 2026 ANDPAD All Rights Reserved. 26
27. 【Kubernetes】適用前にCIで差分を検証する • • • • • プロダクトのソースコードのリポジトリと、アプリ用モノレポは別々 イメージタグ更新のPull Requestは、共通ワークフローが自動で作成 プロダクト側のCIがモノレポに対して行うのは、Pull Requestの起票ま で ディレクトリ構造が全チーム共通なので、検証を一律にかけられる ◦ 変更のあったApplicationごとに、テンプレート展開・ポリシー・ス キーマを検証 テンプレートの展開結果だけで完結するので、CIにクラスターの認証情 報は不要 © 2026 ANDPAD All Rights Reserved. 27
28. 【Terraform】適用前にplanで差分を確認する • • • Atlantisが、Pull Request上にplanの結果をコメントとして記録 「何が変わるか」を、起票者とレビュー担当が同じ画面で確認してから apply 手作業による変更が減り、コードと実際の構成のずれも起きにくい状態 へ © 2026 ANDPAD All Rights Reserved. 28
29. 適用をプラットフォームに任せる 人ではなくArgo CDとAtlantisが適用する 課題2 自律性の低下と課題3 不透明化を、あわせて解消 入口 → 境界 → 検証 → 適用 © 2026 ANDPAD All Rights Reserved. 29
30. 【Kubernetes】適用はクラスター内のArgo CDが行う • • • • どのチームのApplicationも、クラスター内のArgo CDが適用する 適用に必要な権限はArgo CDが持つ。CIや開発チームに渡す必要がない 適用されるのはmainの内容だけ ◦ targetRevisionはテンプレート側で固定し、全チーム共通 本番は例外なくレビュー、開発環境は自動マージ。統制はこの1点に集約 © 2026 ANDPAD All Rights Reserved. 30
31. 【Terraform】applyはAtlantisの実行基盤が行う • • • applyを実行するのはSREのローカルではなく、Atlantisの実行基盤 起動はPull Request上のコメントによるイベント駆動 ◦ 誰がいつ適用したかがPull Requestに残る applyが成功し、インフラが期待どおりになってからマージ ◦ 期待と違えば修正をプッシュし、planからやり直す ◦ マージ後は、mainの内容と実環境が一致した状態 © 2026 ANDPAD All Rights Reserved. 31
32. GitOpsの4原則に照らすと、到達点は同じではない • • • Atlantisはイベント駆動のため、pullとリコンサイルは未達 Argo CDはドリフト検出が全Application、復帰はself-heal有効時 差は残るが、Pull Requestを通り、適用の主体が人でない点は共通 OpenGitOpsの4原則 Kubernetes（Argo CD） Terraform（Atlantis） 宣言的 ◦ ◦ バージョン管理され不変 ◦ ◦ 自動的にpull ◦ ✕ 継続的にリコンサイル △ ✕ © 2026 ANDPAD All Rights Reserved. 32
33. 結果 何がどれだけ変わったか © 2026 ANDPAD All Rights Reserved. 33
34. 現場で起きた反応 • • • • SREが手動で管理していた設定も、徐々にimportしIaC化 変更の依頼者が自分でPull Requestを起票する流れが定着 「プラットフォームに移行して運用が楽になった」という声が、他チー ムの動機づけに SREへの依頼待ちが減り、レビューで設計の意図を共有する時間へ © 2026 ANDPAD All Rights Reserved. 34
35. たくさんの変更が、Gitを通って流れるようになった • • • 最初のApplicationが稼働した2025年1月を基準にしている 開発チームが触る2つのモノレポで、Pull Requestが伸び続けている SREの規模を変えないまま、多くの変更がGitを通って流れた © 2026 ANDPAD All Rights Reserved. 35
36. 載るものは増えても、SREの範囲は増えない • • • • アプリ用モノレポでのデプロイに移行したサービスは、全体の1/3程度 Argo CDのApplicationは、2025年初めの十数件から150件程度に Terraformの実行単位は、2024年末の数十件から400件程度に 委譲が進むほど、SREの管理範囲が増えても変更量の増加は小さい © 2026 ANDPAD All Rights Reserved. 36
37. まとめ 課題・考え方・仕組み・結果 © 2026 ANDPAD All Rights Reserved. 37
38. まとめ • • • • • 課題：マイクロサービス化のあと、サイロ化・自律性の低下・不透明化 が重なった 考え方：変更の経路を標準化し、SREへの依頼をPull Requestに変更 ◦ 強い権限は人ではなく基盤に置き、レビューで安全性を担保する 仕組み：入口・境界・検証・適用の4段階を、Argo CDとAtlantisで揃え た 結果：開発チームが触るモノレポのPull Requestは4倍以上に ◦ SREの規模を変えないまま、変更のスループットを安全に増やせた 残課題は2つ ◦ 既存の仕組みからプラットフォームへの移行は、まだ道半ば ◦ Terraform側のドリフト検出は未整備 © 2026 ANDPAD All Rights Reserved. 38
39. We are hiring! https://engineer.andpad.co.jp/ 技術スタックや募集ポジションを 掲載してます！ © 2026 ANDPAD All Rights Reserved. 39
40. Appendix © 2026 ANDPAD All Rights Reserved. 40
41. プラットフォームの全体像 • • 変更の入口は開発チームもSREも同じPull Request 本番環境のリソースを直接変更できる強い権限は人に配らない Pull Request アプリ用モノレポ 開発チームが管理するk8sマニフェスト 開発チーム プラットフォーム用モノレポ SREが管理するk8sマニフェスト Argo CD sync クラスター内で pull Kubernetesクラスター 各Application 共通Helm Chartリポジトリ SREが提供し、各チームが参照 SREチーム Terraform モノレポ 各チームが管理するインフラ、SaaS設定 Atlantis Pull Request上で plan / apply apply クラウド / SaaS AWS・監視・ID基盤 ほか © 2026 ANDPAD All Rights Reserved. 41