開発者の認知負荷軽減を目指して選んだCrossplane - Self-serviceの理想と現実

クラウドネイティブ会議2026
day2 5/15 Track A 17:40~
株式会社hacomono
有働 開
https://kaigi.cloudnativedays.jp/sessions/2895/?from=timetable&day=day2

現在hacomonoはアプリ量産によって事業拡大を狙っており、私のチームではKubernetesを利用したGitOpsベースのSelf-service基盤を構築することでアプリ開発支援に挑戦しています。

しかしGitOpsで扱いづらいマネージドサービスの扱いに課題を感じていました。
そこでCrossplaneを採用し、あらゆるリソースをカスタムリソースに抽象化することでGitOpsで完結する基盤を目指しました。
これにより複数のIaCを使って数百行記述する必要のあったリソースが数~数十行のmanifestで扱えるようになりました。

一方、Crossplaneの運用負荷/学習コストが高いことや、抽象化に時間がかかること、抽象化による柔軟性の低下等の新たな課題も感じています。

本セッションではCrossplaneを採用するに至った背景や、実際に運用して感じたメリデメ、抽象化によって得られるものと失うもの等を実体験に基づいて共有します。
Kubernetesとマネージドサービスとの連携に課題を感じている方やCrossplaneの導入を検討している方等に知見を提供します。

Transcript

1. Last Update 2022.03.16 開発者 認知負荷軽減を目指して選んだ Crossplane Self-service 理想と現実 クラウドネイティブ会議 2026 Platform Engineering Track
2. 2 目次 1. 導入 2. Crossplane概要 3. hacomonoで 採用事例 4. 運用して感じた良さ 5. 運用して感じた難しさ 6. 運用上 工夫 7. まとめ
3. section 1 導入
4. 4 自己紹介 有働 開(Kai Udo) • 社歴 ◦ 2020/4 ~ 2024/6 某製 業 ◦ 2024/7 ~ 株式会社hacomono 現在: 共通基盤グループ所属 • GitHub: u-kai, X: @u_kai1012 • CloudNative会議初参加です！ よろしくお願いいたします！
5. 5 本日話すこと・話さないこと 話すこと • Crossplaneでできること 概要 • 我々がCrossplaneを選定した理由 • 我々 Crossplane活用方法 • Crossplaneを活用して感じられたメリットや難しさ、工夫点など 話さないこと • Crossplane 具体挙動 a. https://speakerdeck.com/hacomono/platform-engineering-with-crossplane-resource-abstraction-simplified b. https://techblog.hacomono.jp/entry/2025/12/11/000000 • Crossplane以外 具体的な技術選定について a. https://techblog.hacomono.jp/entry/2025/10/14/110000 b. https://findy-tools.io/products/aws-eks/208/840 • Crossplane 網羅的な活用方法
6. section 2 Crossplane概要
7. 7 Crossplane概要 • CNCF プロジェクトで去年 11月Graduated Stageに🎉 • Upbound社が提供している商用版も(本日 OSS版 話) • 名前 通り横断的(Cross)なControl planeが実現可能 出典: https://www.crossplane.io/
8. 8 Crossplaneで達成できること 概要 1~あらゆるリソースを Kubernetesリソースに !~ あらゆるリソースが Kubernetesリソースとして管理できるように !
9. 9 Crossplaneで達成できること 概要 2~Composite Resource 実装が可能 ~ K8s リソースをまとめた独自カスタムリソース ※を実装可能 あらゆるリソース 組み合わせを抽象化して提供可能に！ ※ 正確に XRと呼 れていますが、わかりやすさを考慮して本資料で カスタムリソースと表記しています。
10. section 3 hacomonoで 採用事例
11. 11 hacomonoについて hacomonoというWellness業界向けSaaSを提供中
12. 12 hacomono これから ~マルチプロダクト戦略について ~ 各プロダクト 独立して開発してマイクロサービス 恩恵を受けたい これから マルチプロダクトにも注力して事業拡大を狙う
13. 13 プロダクト量産に向けて プロダクト 量産を実現するに ... a. 中央チームが全プロダクト インフラを構築する b. インフラ人材をプロダクト毎にアサインして都度インフラを構築する c. プロダクト開発者自身でインフラ構築をできるように仕組み化する etc…
14. 14 中央チームによるインフラ構築 アプローチ • ガバナンス 担保が可能 • プロダクト開発者がプロダクト開発に集中できる • プロダクト数に比例して運用コストが増えがち • 中央チームがボトルネックになりうる
15. 15 プロダクト毎にインフラ人員をアサインしてプロダクト毎にインフラ構築するアプローチ • プロダクト開発者と密にやり取りしてインフラ構築できる • 柔軟なインフラ構築が可能 • プロダクト数に比例してインフラ人員が必要になる • 構成がバラバラになりうる
16. 16 プロダクト開発者自身でインフラ構築できるようにするアプローチ • プロダクト開発者自身で高 なインフラ構築が可能 • プロダクト数に比例して基盤チーム 運用工数が増えにくい • 仕組み 中でガバナンス担保が可能 • 仕組み作りが必要 • 汎用的に構築することで個別最適化が難しくなる可能性
17. 17 プロダクト開発者自身でインフラ構築できるようにするアプローチ • プロダクト開発者自身で高 なインフラ構築が可能 • プロダクト数に比例して基盤チーム 運用工数が増えにくい • 基盤レイヤーによるガバナンス担保が可能 • 仕組み作りが必要 • 汎用的に構築することで個別最適化が難しくなる可能性 Self-service基盤構築を採用！
18. 18 Self-service 基盤 技術選定 K8s ✖ エコシステム ✖ GitOpsを採用 必要なmanifestをGitにpushするだけで OKな状態を目指した • 必要な機能を基盤に組み込みやすい • GitOpsによって開発者 認知負荷や運用工数を下げられる • あらゆるリソースを一貫したK8s APIで管理/提供できる
19. 19 K8s/GitOps で感じた課題 以下 ような課題が浮上 • マネージドサービス 扱いやK8sリソースと 連携 • プロダクションレディなK8sリソース 定義 • 基盤独自 仕様や複雑さ • 上記を全てAIで解決できるか？ Self-service利用者 ペルソナを K8s/Terraformに慣れてない開発者と想定
20. 20 マネージドサービス 扱い • マネージドサービス GitOpsで管理しづらい で別IaCを使う必要あり K8s✖GitOps マネージドサービス ✖IaC ✖ CDツール • manifest + 別IaC 学習/管理が必要になる • K8sリソースとマネージドサービス 連携が必要なケース 複雑... • それぞれ別々 仕組みでデプロイする必要がある
21. 21 プロダクションレディな K8sリソース 定義 • セキュアで信頼性 あるK8sリソースを定義するに 十分な知識が必要 • 様々なリソースを適切な設定で組み合わせる必要があり複雑 PDB? maxSurge?? securityContext? affinity?antiAffinity? HPA?それともKEDA? PSS??
22. 22 基盤独自 仕様や複雑さ • 開発者 基盤独自 設定を適切に設定する必要がある ◦ Account IDやデプロイするネットワークリソース IDなど ◦ 付与が必須なラベルや属性など 基盤管理者 開発者 cost-center labelつけてください dev xxでprod yy AccountIDで す こ 前お願いした環境変数です が、HOGE_HOGEに変更してほ しいです。 こ リソース devに置きたい IDなんだっけ？？💦 調整必須 細かい変更多いんだ よな〜💦 • 上記に変更があった場合 基盤管理者と開発者で調整が必要になる
23. 23 AIにインフラ構築 全てを任せること できないか？ • 知識を有してないと良いIaC 出力 難しい • 複雑なIaC レビュー 難しく、認知負荷が高い • リスクを考慮するとAIを100%信用する （まだ）簡単で ない 堅牢なコンテナをデプロイしたいって 言ったらめっちゃ出てきた。。。なん じゃこれ。。。 権限不足ならrootで動かす しょう がないよな？多分。。。 堅牢なワークロード こちらで す。 ちなみに権限不足で動かな かった でrootで動かしてま す。 💦
24. 24 K8s を使ってプラットフォームエンジニアリングを実現する際 考慮ポイント • K8s 自体 運用負荷 ◦ 専門チームが頑張るしかない!? • manifest を開発者に書いてもらう場合... ◦ 開発者に生じる manifest 認知負荷 ◦ ガバナンス担保が難しい ◦ 基盤変更 適用が難しい • 他 マネージドサービスと連携する場合... ◦ K8sと 連携が難しい ◦ マネージドサービス 設定/管理が大変 イケてる仕組みでも開発者 負荷が高いと意味がない... 認知負荷や工数が大きい。。。 なんとかせ 。。。
25. 25 K8s を使ってプラットフォームエンジニアリングを実現する際 考慮ポイント • K8s 自体 運用負荷 ◦ 専門チームが頑張るしかない!? • manifest を開発者に書いてもらう場合... ◦ 開発者に生じる manifest 認知負荷 ◦ ガバナンス担保が難しい ◦ 基盤変更 適用が難しい • 他 マネージドサービスと連携する場合... ◦ K8sと 連携が難しい ◦ マネージドサービス 設定/管理が大変 イケてる仕組みでも開発者 負荷が高いと意味がない... Crossplaneを採用!
26. 26 Crossplaneで達成できること (再掲) Crossplaneによって マネージドサービス含むあらゆるリソースを K8sリソースで管理可能 & あらゆるK8sリソース 組み合わせを抽象化して提供可能に！
27. 27 Crossplane 採用 Crossplane 採用で • マネージドサービス含めほぼ全てをGitOpsで管理可能！ 少ないmanifestと認知負荷であらゆるリソースを定義可能に！ 開発者自身で簡単かつ安全なインフラ構築ができる ず！ • プロダクションレディなリソースをカスタムリソースで提供可能！ • 基盤独自 仕様や複雑さ カスタムリソース 裏側に隠蔽可能！ • 抽象化とガードレールでレビュー 認知負荷を軽減可能！
28. 28 Crossplaneを活用した実際 Self-service 基盤イメージ 複数チームが利用中 & 利用予定
29. 29 Self-service 基盤詳細 • インフラコード 基盤リソース/複数プロダクトをまとめたモノレポ • プロダクト毎 AWSリソース分離 XR 裏側で達成 • 開発者に Gitおよび限定されたAppProject 権限 み解放 • 一般的なプロダクト開発 ニーズに焦点を当ててXRを構築 • 許可されたリソース みを利用可能にしてガバナンス担保 • 全AWSサービス/K8sリソースに対応しているわけで ない • 基盤を利用できるケースとできないケースでガイドラインを引いている
30. 30 Crossplane 活用例 ~アプリケーションコンテナと S3 Bucket~ Crossplaneなし: manifest 150行,Terraform 100行を別々 仕組みでデプロイ Crossplaneあり: manifest 数十行をGitにpushするだけでデプロイ
31. 31 Self-service 基盤で達成できたこと • 開発者 みで必要な全リソースを構築できている 🎉! • プロダクト数が増えても基盤運用者 負荷が上がりづらい状態に 🎉!
32. section 4 運用して感じた良さ
33. 33 提供機能 変更が容易 • Operator プログラム不要で抽象 提供が可能 • 抽象化によって (契約を破らない前提で)機能追加/修正が開発者と 調整なしで実施可能 プログラムなしで実装 できる！ label 追加っと hapからkedaに変更っ と 0スケールやcron ベース スケールが 可能になったらしい いつか利用を検討し よう
34. 34 開発者へ 最小な権限付与 GitOpsと 組み合わせによって開発者へ K8s/AWS権限付与を最小限に！
35. 35 AIによる基盤運用者およびプロダクト開発者へ 支援が可能 • 開発者へ 精度 高い manifest作成支援が可能 • 基盤管理者へ 基盤開発や Crossplane ナレッジ収集など支援が可能 コンテナデプロイしたい！ 新しいカスタムリソース定 義して！ Crossplane ここどう なっている？
36. 36 K8s を使ってプラットフォームエンジニアリングを実現する際 考慮ポイント • K8s 自体 運用負荷 ◦ 専門チームが頑張るしかない!? • manifest を開発者に書いてもらう場合... ◦ 開発者に生じる manifest 認知負荷 ◦ ガバナンス担保が難しい ◦ 基盤変更 適用が難しい • 他 マネージドサービスと連携する場合... ◦ K8sと 連携が難しい ◦ マネージドサービス 設定/管理が大変 イケてる仕組みでも開発者 負荷が高いと意味がない... Crossplaneサイコーで ？？
37. 37 K8s を使ってプラットフォームエンジニアリングを実現する際 考慮ポイント • K8s 自体 運用負荷 ◦ 専門チームが頑張るしかない!? • manifest を開発者に書いてもらう場合... ◦ 開発者に生じる manifest 認知負荷 ◦ ガバナンス担保が難しい ◦ 基盤変更 適用が難しい • 他 マネージドサービスと連携する場合... ◦ K8sと 連携が難しい ◦ マネージドサービス 設定/管理が大変 イケてる仕組みでも開発者 負荷が高いと意味がない... もちろん難しさもあります。
38. section 5 運用して感じた難しさ
39. 39 Crossplane 認知/運用負荷 高さ 他IaC ツール CLIベース oneshot実行な で楽。。。 複数コンポーネント へ 理解/設定/運用が必要 適切な権限設定 マネージドリソース対応追加 作業 モニタリング バージョン管理 インフラ起因 エラー カスタムリソース 追加作業 適切なコンポーネント 設定
40. 40 他IaC ツールと比べ てエコシステムが 発展途上 に感じる • Terraform plan ような機能がない • Testツールが最近出た かり ◦ 商用版に 前から存在する模様 (今後OSS版に追加されるかも!?※) • カスタムリソース 構成リソースをレンダリングする機能 あるが... ◦ 現在 構成と 差分がわからない ◦ それが正しいか、稼働するかどうか 動かさないとわからない 運用管理に 独自ツール 作成やマインドチェンジが必要 ※: https://github.com/crossplane/crossplane/issues/6810
41. 41 Crossplaneによるカスタムリソース提供 落とし穴 ~実際に起きた設定ミス ~ カスタムリソース作成に 十分な Crossplane/K8s/マネージドサービス 知識と検証 /テストが必要 失敗しても Runningし続けるカスタムリソース ... 設定ミスによる AWSサービスと 差分で無限 Reconcile… 消したくても消えない永続層が無限 Reconcile... Crossplane バグで期待する更新がされない ... etc… 重い。。。
42. 42 全て ユースケースを CrossplaneによるSelf-serviceで対応する 大変 • Crossplaneで機能 サポートを追加→運用コストがかかる 多くをサポートする十分な運用体制 構築 OR サポート外 明示やサポート外に対する対策方針を固める などが必要 • 能機能追加に 追加する機能 十分な知識と運用していく覚悟が必要 • サポート外 開発者責務で別IaC管理→インフラ管理 一貫性が欠如 ◦ Terraform module配布 方が”オプションで組み合わせ可能 ”を達成しやすい...
43. 43 Self-serviceや抽象化を用いても認知負荷を 0にする 難しい 現実: 基盤に慣れるまで やり取りが必要だった 当初 想定 : ドキュメントや AIを駆使すれ ほぼ自走できる ず さらに認知負荷を減らすか基盤に慣れてもらうため 施策が必要 • 基盤固有 ルールや思想と従来 開発手法と 乖離がある • GitOps 思想やツール 利用方法に慣れてない • 抽象化されていると いえmanifest 扱いに慣れてない
44. 44 そ 抽象 進化可能か？ 抽象化によるリソース提供 難しい そ 抽象 ニーズを満たせる か？ そ 抽象 認知負荷を下げられているか？ 機能追加を進めたら抽象化前とほぼ変わらなくなった ... そもそも抽象化して提供すべきな か？
45. section 6 運用上 工夫
46. 46 Crossplaneを利用して Self-service提供する上で 工夫 ~Crossplane完全理解 ~ コードやドキュメントリーディングによる Crossplane 完全理解を実施 • カスタムリソースを正確に提供するために！ • 正確なトラブルシューティングやモニタリング設定をするために！ • AI活用で精度 高いアウトプットを得るために！ おすすめ ドキュメントやコード • https://docs.crossplane.io/latest/whats-crossplane/ • internal/controller/apiextensions/definition/reconciler.go • internal/controller/apiextensions/composite/reconciler.go • internal/controller/apiextensions/composite/composition_functions.go
47. 47 Crossplaneを利用して Self-service提供する上で 工夫 ~シナリオテスト 実装と実施 ~ シナリオテスト 実装と実施による設定ミス 撲滅 • 実際に動かすことでわかる設定ミスを炙り出せる • 実装に対して仕様通りであることに自信を持てる • 変更に対して問題ないことに自信を持てる • AIへフィードバックを与えることができる
48. 48 Crossplaneを利用して Self-service提供する上で 工夫 ~ADRによる意思決定 ~ ADRを用いて意思決定し、そ 結果を保存 • 提供する抽象や機能が適切かどうかトレードオフ含めADRへ • 設計や判断がチーム内でブラッシュアップされるように！ • 過去 ADRが継続的な機能改善 指針に役に立つ！ • ADRを元にAIが実装してくれるように！ • 設計背景や思想まで考慮してAIが回答してくれるように！
49. 49 Crossplaneを利用して Self-service提供する上で 工夫 ~そ 他~ • 独自ツール 開発によるカスタムリソース開発効率化 • K8s Event モニタリング強化によって設定ミスを気付ける状態へ • 永続層 K8sリソース み削除するように設定し、無限Reconcileを防止 • 開発者 心理的ハードルを下げるため Skills整備 • dev環境かつ担当範囲であれ approveなしでmerge可能にし、いち早く基盤 に慣れてもらうように などなど
50. 50 Crossplaneを活用した Self-serviceで未だに悩んでいること • 個別最適な要求をどこまで受けるべきか？ • どうしたらすぐに基盤に慣れてくれるか？認知負荷を減らせるか？ • 重いシナリオテスト ... • 実永続リソース Clean up処理... などなど... 悩みながらも日々 改善活動を実施中！
51. section 7 まとめ
52. 52 開発者 認知負荷軽減を目指して選んだ Crossplane • 全てをGitOpsでまとめることができた👌 • 抽象化により複雑さを隠蔽できた👌 • 結果、プロダクト開発者だけでインフラ構築ができている👌 • プロダクションレディな設定になっていることが担保できている👌 • プロダクト数に比例しない運用負荷を実現できている👌
53. 53 Self-service 理想と現実 • Crossplane 良いこと かりで なく、難しく運用負荷もかかる😢 • Crossplaneだけで全て ユースケースに対応する 大変😢 • 開発者が基盤に慣れるまで ハードルが存在する🤔 • 抽象を提供するとこと自体が難しい😢 • 日々 運用改善が重要😬
54. 54 今後 展望 • 基盤利用にいち早く慣れてもらう仕組み 整備 ◦ オンボーディング 実施 ◦ Getting Started 整備 • 対応ユースケースを広げて基盤利用をさらに加 させる • 利用者から フィードバックをもとに継続的改善 • Crossplane 新CLI 検証/評価 ◦ シナリオテストを薄くしたい... • 上記を達成するため 運用体制強化
55. https://www.hacomono.jp/