認知負荷を吸収し、プロダクトをまたぐPR Preview基盤の設計事例

Platform Engineering Kaigi 2026 https://www.cnia.io/pek2026/sessions/7f3b6910-d519-4640-8f54-d4d2caa00c5b/

Transcript

1. Platform Engineering Kaigi 2026 認知負荷を吸収し、 プロダクトをまたぐ PR Preview基盤の設計事例 Taiki Ono, Principal Software Engineer ―1
2. 導⼊ -2
3. PRプレビューとは • 解決したい問題 ◦ Pull Requestのレビュー量増加問題 ◦ フィードバックサイクルのシフトレフト ◦ 開発者の多様化 • ユーザージャーニー ◦ PR作成と同時にプレビュー作成 ◦ プレビュー毎の専⽤URLからアクセス ◦ PRマージでプレビュー削除 ―3
4. enechainでの現況 • あるプロダクトチームが先⾏して開発 ◦ 社内での価値検証が済んでいてプラットフォーム機能としてニーズが⾼かった • 全社で利⽤できるプラットフォーム機能として開発‧運⽤中 ◦ 2⽉に設計開始、3⽉末から導⼊開始 ◦ 社内の最も開発が活発なプロダクト‧最も複雑な構成のプロダクトでも導⼊済み ◦ 実際に社内で積極的に使われている ◦ 技術的な詳細はTech Blog記事へ ▪ https://techblog.enechain.com/entry/intro-prothea ―4
5. enechainのテクノロジースタック GKE Cluster Manifest Repo ArgoCD Product Namespace Frontend Browser BFF Backend API ―5
6. グランドデザイン -6
7. 解決策の⽅向性 • マニフェスト⽣成⽅式 ◦ プレビュー⽤のマニフェストファイルを⽣成してArgoCDなどでクラスタに適⽤ • クラスタ内で複製する⽅式 ◦ マニフェストファイルは変更せずクラスタ内で直接プレビューリソースを作成 どちらを選択するべきか？→ プラットフォームでなにを解決したいのか？ ―7
8. 認知負荷の分解 • 本質的な負荷 ◦ ドメインから由来する問題そのものの難しさ • ⾮本質的な負荷 ◦ やり⽅‧環境から来る負荷 • 価値を⽣む負荷 ◦ プロダクトを良くする思考 ―8
9. プラットフォームと複雑性 • 認知負荷は消えない、プラットフォームが吸収する • つまり、複雑性はプロダクト開発からプラットフォームへ移る • ここにトレードオフが存在する ◦ 認知負荷を吸収していくと、プラットフォームを複雑にする⼒が働く ―9
10. トレードオフを破る⼒学 • 認知負荷のコストも認知負荷削減のリターンもどちらも積み上がって効く ◦ プラットフォームの構築は⼤きな初期コストと⼩さな継続的コスト ◦ ⽣まれた余剰リソースを改善に投資するサイクルが回ると指数的に状況が変わり得る • ソフトウェアエンジニアリングのパワー ◦ 複雑な問題をシンプルに解ける可能性がある ◦ 認知負荷の低いプロダクト開発とシンプルなプラットフォーム これらを踏まえた上で⾃分たちの状況で意思決定することが⼤事 ― 10
11. 今回の我々の意思決定 • マニフェスト⽣成⽅式 ◦ プレビュー⽤のマニフェストファイルを⽣成してArgoCDなどでクラスタに適⽤ • ✅ クラスタ内で複製する⽅式 ◦ マニフェストファイルは変更せずクラスタ内で直接プレビューリソースを作成 ― 11
12. 設計 - 12
13. 概要 Dev Cluster GitHub Clone Manifest Repo prothea webhookserver controller Webhook Product Repo PR Create Watch Read Product Namespace Push Product Developer Preview Request Reconcile Preview Configuration Preview Environment ― 13
14. プレビューリソースの作成 Dev Cluster GitHub Clone Manifest Repo prothea webhookserver controller Webhook Product Repo PR Create Watch Read Product Namespace Push Product Developer Preview Request Reconcile Preview Configuration Preview Environment ― 14
15. ベースマニフェストを変更しない • Kubernetesのマニフェストは素の状態でも認知負荷が⾼め ◦ プラットフォームによる抽象化の過渡期なので開発者が認知する必要がある • さらにkustomizeなどでテンプレート化されていて複雑 • ここからプレビューリソース層を追加するかどうか ◦ プレビュー⽤の規約は業界標準ではなく社内独⾃ → 複数の概念を混ぜた状態は避ける 特に社内独⾃規約が混ざると複雑度が増しやすい ― 15
16. プレビュー環境の設定 Dev Cluster GitHub Clone Manifest Repo prothea webhookserver controller Webhook Product Repo PR Create Watch Read Product Namespace Push Product Developer Preview Request Reconcile Preview Configuration Preview Environment ― 16
17. 設定⽤カスタムリソース 設定は基本的な紐付け情報のみ プロダクトによる構成の違いを どう吸収しているか？ ― 17
18. プレビュー構成の導出 Dev Cluster GitHub Clone Manifest Repo prothea webhookserver controller Create / Read Webhook Product Repo PR Create Watch Read Derived Preview Configuration Product Namespace Push Product Developer Preview Request Reconcile Preview Configuration Preview Environment ― 18
19. 導出した結果を⾒せるリソース • 複製するアプリケーションの⼀覧 ◦ Deployment、Service、アプリのコンテナ名、取り除くPodラベルなど • プレビューへのアクセス経路 ◦ ドメイン名、Gateway / IngressとそのHTTPRoute ◦ プレビューURLの元 ◦ プレビュー⽤の共有インフラの設定 ◦ 詳細は後述 • 共有インフラのセットアップ結果 プロダクト開発者‧プラットフォーム運⽤者⽤の中間情報 ― 19
20. プラットフォームのインタフェース • なるべくプラットフォームでカバーする ◦ 🙅 ドキュメントやCLI⽣成を利⽤して細かい設定を開発者が書く‧確認する ◦ 🙅 プラットフォームがなにをする‧したのかがわからない ◦ 🙅 異常ケースではプラットフォームのログを読ませる • シンプルな規約に収める • 設定変更でなにが変わるのか‧なにが起きるのかを予⾒させる ◦ CIでのシフトレフト • ⽇常的に使わない部分は隠して段階的インタフェースを⽤意する ◦ 今回だとカスタムリソースとして⾒せる ― 20
21. 透過的ネットワーク - 21
22. プレビュー環境への⼊⼝ Dev Cluster GitHub Clone Manifest Repo prothea webhookserver controller Webhook Create Product Repo PR Watch Read Product Namespace Preview Request Push Product Developer Open URL Reconcile Preview Configuration Preview Environment ― 22
23. ベース環境とは独⽴したルーティング経路 Product Namespace Base Environment example.com Browser GKE Gateway / Ingress pr-123.example.com preview-gateway PR-123 Preview *.example.com PR-456 Preview pr-456.example.com ― 23
24. 特殊な構成もプラットフォームが吸収 Parent Product Namespace / GKE Gateway preview-gateway Preview Environment /sub Browser Sub Product Namespace preview-gateway Preview Environment ― 24
25. サービス間の通信 Default HTTPRoute Default HTTPRoute Base Backend API Base Core API Per-Preview HTTPRoute Per-Preview HTTPRoute Preview Backend API Preview Core API Inject preview-id header Gateway HTTP Request with preview-id header pr-123.example.com BFF Browser With GAMMA (Gateway API for Service Mesh) HTTP Request with preview-id header ― 25
26. 境界設計 - 26
27. アプリケーションとの境界設計 • プレビュー⽤のコンテナイメージのビルド ◦ 社内共通ビルドワークフロー向けのビルド後のフックを⽤意 • フロントエンドの向き先解決 ◦ セットアップ⼿順に含める (いい解決策が思いつかなかった) • Cross-Origin Resource Sharing対応 ◦ 後述 ― 27
28. Cross-Origin Resource Sharing • プレビュー環境ではドメイン名が変わることは本来プラットフォームの関⼼事 ◦ preview-gatewayでpreflightに応答したい ◦ アプリケーションには変更を⼊れないようにしたい • 合理的に引き受けられない場合はアプリケーション側に戻す選択もある ◦ credentialなリクエストでの任意ヘッダー許可がIstioでできない問題 ◦ アプリケーション側では1⾏の変更で済む ― 28
29. 開発者体験 - 29
30. より良い開発者体験 • ノイズにならないUIを作る ◦ 今回だとGitHub Deployments API • 開発者のミスをケアする ◦ 起動しないコンテナなど ◦ 異常系で丁寧にフィードバックを返す • ⼀段奥に調査⽤の情報を整理して置く ◦ 今回だとCRDとそのStatus ― 30
31. より良い開発者体験のために • 複雑性を引き受けられるプラットフォームの技術選定 ◦ 複雑なことをシンプルに実現する必要がある • Platform as Productの実践 ◦ 開発者の⾏動を観察‧計測‧分析する ▪ ◦ 「顧客はほしいものがわからない」原則 ドッグフーディング ― 31
32. 終わりに - 32
33. まとめ • 複雑性をどこに置くか？ ◦ トレードオフを考えた上で意思決定 • 認知負荷を吸収するプラットフォーム ◦ 必要な複雑性を引き受けられる技術選定 ▪ 時には境界を引き直す ◦ 既存の概念を混ぜない ◦ インタフェースに注⼒する ▪ Platform as Product ― 33