プラットフォームの複雑性はどこに住むべきか - 認知負荷を吸収し、プロダクトをまたぐPR Preview基盤の設計事例
概要
AIエージェントがPull Requestの量と並行度を押し上げつつある今、各PRをend-to-endで検証できることは、あれば便利な追加機能ではなく、開発ループに組み込まれるべき要素になりつつあります。PR単位のプレビュー環境はそのための自然な解決策ですが、スケーラブルな形で、プロダクト開発者へ複雑性を漏らさずに構築することは容易ではありません。 私たちは、このプラットフォームをKubernetes Controllerとして開発・運用しています。複数のプロダクトチーム・リポジトリをまたいで動作する設計です。アプリケーションの複製、ルーティング、ライフサイクル管理といった横断的な責務は基盤側で吸収し、プロダクト開発チームは小さく見慣れたセットアップだけで済み、運用時も必要な情報に最適な形で触れられるようにしています。 プラットフォームエンジニアリングの仕事の核は「複雑さをどこに置くか」の意思決定にあります。このセッションでは、私たちがPRプレビュープラットフォームを開発する中で下してきた技術判断を辿り、プロダクト開発チームの認知負荷を吸収するプラットフォームを開発する上での学びを共有します。具体的には、次のような内容を扱います: - なぜマニフェスト生成ではなくControllerを書く選択にしたのか - どの責務をプラットフォーム側で吸収し、何をアプリケーション側に残したか - プロダクト開発チームがネットワークトポロジーの変更を意識せず複数のプロダクト間でのPRプレビューを連携させる仕組み - 開発者の認知負荷を吸収するDevExをどう実現するか うまくいった意思決定だけでなく、後から境界を引き直すことになった意思決定も取り上げることで、より学びの多い教訓を共有します。
PR PreviewCross-team境界設計認知負荷DevExKubernetesKubernetes ControllerService Mesh
スピーカー
enechainのPlatform Engineeringチームにて、プロダクトチームの開発・運用を支えるプラットフォームの構築と運用を担当。以前はCookpadにてサービスメッシュを構築・運用し、Envoyへのコントリビューションと合わせてEnvoyCon 2018で発表。その後Tetrateに移りEnvoyエコシステムの開発に従事。Finatextではプラットフォームチームとして開発生産性とセキュリティを中心に取り組み、その取り組みをPlatform Engineering Kaigi 2024で発表。詳しくは https://taiki.dev/