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

by hacomono Inc.

Embed

Start on current slide

Slide 1

Slide 1 text

Last Update 2022.03.16 開発者認知負荷軽減を目指して選んだ Crossplane Self-service 理想と現実クラウドネイティブ会議 2026 Platform Engineering Track

Slide 2

Slide 2 text

2 目次 1. 導入 2. Crossplane概要 3. hacomonoで採用事例 4. 運用して感じた良さ 5. 運用して感じた難しさ 6. 運用上工夫 7. まとめ

Slide 3

Slide 3 text

section 1 導入

Slide 4

Slide 4 text

4 自己紹介有働開(Kai Udo) ● 社歴 ○ 2020/4 ~ 2024/6 某製業 ○ 2024/7 ~ 株式会社hacomono 現在: 共通基盤グループ所属 ● GitHub: u-kai, X: @u_kai1012 ● CloudNative会議初参加です！よろしくお願いいたします！

Slide 5

Slide 5 text

5 本日話すこと・話さないこと話すこと ● Crossplaneでできること概要 ● 我々がCrossplaneを選定した理由 ● 我々 Crossplane活用方法 ● Crossplaneを活用して感じられたメリットや難しさ、工夫点など話さないこと ● Crossplane 具体挙動 a. https://speakerdeck.com/hacomono/platform-engineering-with-crossplane-resource-abstraction-simpliﬁed b. https://techblog.hacomono.jp/entry/2025/12/11/000000 ● Crossplane以外具体的な技術選定について a. https://techblog.hacomono.jp/entry/2025/10/14/110000 b. https://ﬁndy-tools.io/products/aws-eks/208/840 ● Crossplane 網羅的な活用方法

Slide 6

Slide 6 text

section 2 Crossplane概要

Slide 7

Slide 7 text

7 Crossplane概要 ● CNCF プロジェクトで去年 11月Graduated Stageに🎉 ● Upbound社が提供している商用版も(本日 OSS版話) ● 名前通り横断的(Cross)なControl planeが実現可能出典: https://www.crossplane.io/

Slide 8

Slide 8 text

8 Crossplaneで達成できること概要 1~あらゆるリソースを Kubernetesリソースに !~ あらゆるリソースが Kubernetesリソースとして管理できるように !

Slide 9

Slide 9 text

9 Crossplaneで達成できること概要 2~Composite Resource 実装が可能 ~ K8s リソースをまとめた独自カスタムリソース ※を実装可能あらゆるリソース組み合わせを抽象化して提供可能に！ ※ 正確に XRと呼れていますが、わかりやすさを考慮して本資料でカスタムリソースと表記しています。

Slide 10

Slide 10 text

section 3 hacomonoで採用事例

Slide 11

Slide 11 text

11 hacomonoについて hacomonoというWellness業界向けSaaSを提供中

Slide 12

Slide 12 text

12 hacomono これから ~マルチプロダクト戦略について ~ 各プロダクト独立して開発してマイクロサービス恩恵を受けたいこれからマルチプロダクトにも注力して事業拡大を狙う

Slide 13

Slide 13 text

13 プロダクト量産に向けてプロダクト量産を実現するに ... a. 中央チームが全プロダクトインフラを構築する b. インフラ人材をプロダクト毎にアサインして都度インフラを構築する c. プロダクト開発者自身でインフラ構築をできるように仕組み化する etc…

Slide 14

Slide 14 text

14 中央チームによるインフラ構築アプローチ ● ガバナンス担保が可能 ● プロダクト開発者がプロダクト開発に集中できる ● プロダクト数に比例して運用コストが増えがち ● 中央チームがボトルネックになりうる

Slide 15

Slide 15 text

15 プロダクト毎にインフラ人員をアサインしてプロダクト毎にインフラ構築するアプローチ ● プロダクト開発者と密にやり取りしてインフラ構築できる ● 柔軟なインフラ構築が可能 ● プロダクト数に比例してインフラ人員が必要になる ● 構成がバラバラになりうる

Slide 16

Slide 16 text

16 プロダクト開発者自身でインフラ構築できるようにするアプローチ ● プロダクト開発者自身で高なインフラ構築が可能 ● プロダクト数に比例して基盤チーム運用工数が増えにくい ● 仕組み中でガバナンス担保が可能 ● 仕組み作りが必要 ● 汎用的に構築することで個別最適化が難しくなる可能性

Slide 17

Slide 17 text

17 プロダクト開発者自身でインフラ構築できるようにするアプローチ ● プロダクト開発者自身で高なインフラ構築が可能 ● プロダクト数に比例して基盤チーム運用工数が増えにくい ● 基盤レイヤーによるガバナンス担保が可能 ● 仕組み作りが必要 ● 汎用的に構築することで個別最適化が難しくなる可能性 Self-service基盤構築を採用！

Slide 18

Slide 18 text

18 Self-service 基盤技術選定 K8s ✖ エコシステム ✖ GitOpsを採用必要なmanifestをGitにpushするだけで OKな状態を目指した ● 必要な機能を基盤に組み込みやすい ● GitOpsによって開発者認知負荷や運用工数を下げられる ● あらゆるリソースを一貫したK8s APIで管理/提供できる

Slide 19

Slide 19 text

19 K8s/GitOps で感じた課題以下ような課題が浮上 ● マネージドサービス扱いやK8sリソースと連携 ● プロダクションレディなK8sリソース定義 ● 基盤独自仕様や複雑さ ● 上記を全てAIで解決できるか？ Self-service利用者ペルソナを K8s/Terraformに慣れてない開発者と想定

Slide 20

Slide 20 text

20 マネージドサービス扱い ● マネージドサービス GitOpsで管理しづらいで別IaCを使う必要あり K8s✖GitOps マネージドサービス ✖IaC ✖ CDツール ● manifest + 別IaC 学習/管理が必要になる ● K8sリソースとマネージドサービス連携が必要なケース複雑... ● それぞれ別々仕組みでデプロイする必要がある

Slide 21

Slide 21 text

21 プロダクションレディな K8sリソース定義 ● セキュアで信頼性あるK8sリソースを定義するに十分な知識が必要 ● 様々なリソースを適切な設定で組み合わせる必要があり複雑 PDB? maxSurge?? securityContext? afﬁnity?antiAfﬁnity? HPA?それともKEDA? PSS??

Slide 22

Slide 22 text

22 基盤独自仕様や複雑さ ● 開発者基盤独自設定を適切に設定する必要がある ○ Account IDやデプロイするネットワークリソース IDなど ○ 付与が必須なラベルや属性など基盤管理者開発者 cost-center labelつけてください dev xxでprod yy AccountIDですこ前お願いした環境変数ですが、HOGE_HOGEに変更してほしいです。こリソース devに置きたい IDなんだっけ？？💦 調整必須細かい変更多いんだよな〜💦 ● 上記に変更があった場合基盤管理者と開発者で調整が必要になる

Slide 23

Slide 23 text

23 AIにインフラ構築全てを任せることできないか？ ● 知識を有してないと良いIaC 出力難しい ● 複雑なIaC レビュー難しく、認知負荷が高い ● リスクを考慮するとAIを100%信用する（まだ）簡単でない堅牢なコンテナをデプロイしたいって言ったらめっちゃ出てきた。。。なんじゃこれ。。。権限不足ならrootで動かすしょうがないよな？多分。。。堅牢なワークロードこちらです。ちなみに権限不足で動かなかったでrootで動かしてます。 💦

Slide 24

Slide 24 text

24 K8s を使ってプラットフォームエンジニアリングを実現する際考慮ポイント ● K8s 自体運用負荷 ○ 専門チームが頑張るしかない!? ● manifest を開発者に書いてもらう場合... ○ 開発者に生じる manifest 認知負荷 ○ ガバナンス担保が難しい ○ 基盤変更適用が難しい ● 他マネージドサービスと連携する場合... ○ K8sと連携が難しい ○ マネージドサービス設定/管理が大変イケてる仕組みでも開発者負荷が高いと意味がない... 認知負荷や工数が大きい。。。なんとかせ。。。

Slide 25

Slide 25 text

25 K8s を使ってプラットフォームエンジニアリングを実現する際考慮ポイント ● K8s 自体運用負荷 ○ 専門チームが頑張るしかない!? ● manifest を開発者に書いてもらう場合... ○ 開発者に生じる manifest 認知負荷 ○ ガバナンス担保が難しい ○ 基盤変更適用が難しい ● 他マネージドサービスと連携する場合... ○ K8sと連携が難しい ○ マネージドサービス設定/管理が大変イケてる仕組みでも開発者負荷が高いと意味がない... Crossplaneを採用!

Slide 26

Slide 26 text

26 Crossplaneで達成できること (再掲) Crossplaneによってマネージドサービス含むあらゆるリソースを K8sリソースで管理可能 & あらゆるK8sリソース組み合わせを抽象化して提供可能に！

Slide 27

Slide 27 text

27 Crossplane 採用 Crossplane 採用で ● マネージドサービス含めほぼ全てをGitOpsで管理可能！少ないmanifestと認知負荷であらゆるリソースを定義可能に！開発者自身で簡単かつ安全なインフラ構築ができるず！ ● プロダクションレディなリソースをカスタムリソースで提供可能！ ● 基盤独自仕様や複雑さカスタムリソース裏側に隠蔽可能！ ● 抽象化とガードレールでレビュー認知負荷を軽減可能！

Slide 28

Slide 28 text

28 Crossplaneを活用した実際 Self-service 基盤イメージ複数チームが利用中 & 利用予定

Slide 29

Slide 29 text

29 Self-service 基盤詳細 ● インフラコード基盤リソース/複数プロダクトをまとめたモノレポ ● プロダクト毎 AWSリソース分離 XR 裏側で達成 ● 開発者に Gitおよび限定されたAppProject 権限み解放 ● 一般的なプロダクト開発ニーズに焦点を当ててXRを構築 ● 許可されたリソースみを利用可能にしてガバナンス担保 ● 全AWSサービス/K8sリソースに対応しているわけでない ● 基盤を利用できるケースとできないケースでガイドラインを引いている

Slide 30

Slide 30 text

30 Crossplane 活用例 ~アプリケーションコンテナと S3 Bucket~ Crossplaneなし: manifest 150行,Terraform 100行を別々仕組みでデプロイ Crossplaneあり: manifest 数十行をGitにpushするだけでデプロイ

Slide 31

Slide 31 text

31 Self-service 基盤で達成できたこと ● 開発者みで必要な全リソースを構築できている 🎉! ● プロダクト数が増えても基盤運用者負荷が上がりづらい状態に 🎉!

Slide 32

Slide 32 text

section 4 運用して感じた良さ

Slide 33

Slide 33 text

33 提供機能変更が容易 ● Operator プログラム不要で抽象提供が可能 ● 抽象化によって (契約を破らない前提で)機能追加/修正が開発者と調整なしで実施可能プログラムなしで実装できる！ label 追加っと hapからkedaに変更っと 0スケールやcron ベーススケールが可能になったらしいいつか利用を検討しよう

Slide 34

Slide 34 text

34 開発者へ最小な権限付与 GitOpsと組み合わせによって開発者へ K8s/AWS権限付与を最小限に！

Slide 35

Slide 35 text

35 AIによる基盤運用者およびプロダクト開発者へ支援が可能 ● 開発者へ精度高い manifest作成支援が可能 ● 基盤管理者へ基盤開発や Crossplane ナレッジ収集など支援が可能コンテナデプロイしたい！新しいカスタムリソース定義して！ Crossplane ここどうなっている？

Slide 36

Slide 36 text

36 K8s を使ってプラットフォームエンジニアリングを実現する際考慮ポイント ● K8s 自体運用負荷 ○ 専門チームが頑張るしかない!? ● manifest を開発者に書いてもらう場合... ○ 開発者に生じる manifest 認知負荷 ○ ガバナンス担保が難しい ○ 基盤変更適用が難しい ● 他マネージドサービスと連携する場合... ○ K8sと連携が難しい ○ マネージドサービス設定/管理が大変イケてる仕組みでも開発者負荷が高いと意味がない... Crossplaneサイコーで？？

Slide 37

Slide 37 text

37 K8s を使ってプラットフォームエンジニアリングを実現する際考慮ポイント ● K8s 自体運用負荷 ○ 専門チームが頑張るしかない!? ● manifest を開発者に書いてもらう場合... ○ 開発者に生じる manifest 認知負荷 ○ ガバナンス担保が難しい ○ 基盤変更適用が難しい ● 他マネージドサービスと連携する場合... ○ K8sと連携が難しい ○ マネージドサービス設定/管理が大変イケてる仕組みでも開発者負荷が高いと意味がない... もちろん難しさもあります。

Slide 38

Slide 38 text

section 5 運用して感じた難しさ

Slide 39

Slide 39 text

39 Crossplane 認知/運用負荷高さ他IaC ツール CLIベース oneshot実行なで楽。。。複数コンポーネントへ理解/設定/運用が必要適切な権限設定マネージドリソース対応追加作業モニタリングバージョン管理インフラ起因エラーカスタムリソース追加作業適切なコンポーネント設定

Slide 40

Slide 40 text

40 他IaC ツールと比べてエコシステムが発展途上に感じる ● Terraform plan ような機能がない ● Testツールが最近出たかり ○ 商用版に前から存在する模様 (今後OSS版に追加されるかも!?※) ● カスタムリソース構成リソースをレンダリングする機能あるが... ○ 現在構成と差分がわからない ○ それが正しいか、稼働するかどうか動かさないとわからない運用管理に独自ツール作成やマインドチェンジが必要 ※: https://github.com/crossplane/crossplane/issues/6810

Slide 41

Slide 41 text

41 Crossplaneによるカスタムリソース提供落とし穴 ~実際に起きた設定ミス ~ カスタムリソース作成に十分な Crossplane/K8s/マネージドサービス知識と検証 /テストが必要失敗しても Runningし続けるカスタムリソース ... 設定ミスによる AWSサービスと差分で無限 Reconcile… 消したくても消えない永続層が無限 Reconcile... Crossplane バグで期待する更新がされない ... etc… 重い。。。

Slide 42

Slide 42 text

42 全てユースケースを CrossplaneによるSelf-serviceで対応する大変 ● Crossplaneで機能サポートを追加→運用コストがかかる多くをサポートする十分な運用体制構築 OR サポート外明示やサポート外に対する対策方針を固めるなどが必要 ● 能機能追加に追加する機能十分な知識と運用していく覚悟が必要 ● サポート外開発者責務で別IaC管理→インフラ管理一貫性が欠如 ○ Terraform module配布方が”オプションで組み合わせ可能 ”を達成しやすい...

Slide 43

Slide 43 text

43 Self-serviceや抽象化を用いても認知負荷を 0にする難しい現実: 基盤に慣れるまでやり取りが必要だった当初想定 : ドキュメントや AIを駆使すれほぼ自走できるずさらに認知負荷を減らすか基盤に慣れてもらうため施策が必要 ● 基盤固有ルールや思想と従来開発手法と乖離がある ● GitOps 思想やツール利用方法に慣れてない ● 抽象化されているといえmanifest 扱いに慣れてない

Slide 44

Slide 44 text

44 そ抽象進化可能か？抽象化によるリソース提供難しいそ抽象ニーズを満たせるか？そ抽象認知負荷を下げられているか？機能追加を進めたら抽象化前とほぼ変わらなくなった ... そもそも抽象化して提供すべきなか？

Slide 45

Slide 45 text

section 6 運用上工夫

Slide 46

Slide 46 text

46 Crossplaneを利用して Self-service提供する上で工夫 ~Crossplane完全理解 ~ コードやドキュメントリーディングによる Crossplane 完全理解を実施 ● カスタムリソースを正確に提供するために！ ● 正確なトラブルシューティングやモニタリング設定をするために！ ● AI活用で精度高いアウトプットを得るために！おすすめドキュメントやコード ● https://docs.crossplane.io/latest/whats-crossplane/ ● internal/controller/apiextensions/deﬁnition/reconciler.go ● internal/controller/apiextensions/composite/reconciler.go ● internal/controller/apiextensions/composite/composition_functions.go

Slide 47

Slide 47 text

47 Crossplaneを利用して Self-service提供する上で工夫 ~シナリオテスト実装と実施 ~ シナリオテスト実装と実施による設定ミス撲滅 ● 実際に動かすことでわかる設定ミスを炙り出せる ● 実装に対して仕様通りであることに自信を持てる ● 変更に対して問題ないことに自信を持てる ● AIへフィードバックを与えることができる

Slide 48

Slide 48 text

48 Crossplaneを利用して Self-service提供する上で工夫 ~ADRによる意思決定 ~ ADRを用いて意思決定し、そ結果を保存 ● 提供する抽象や機能が適切かどうかトレードオフ含めADRへ ● 設計や判断がチーム内でブラッシュアップされるように！ ● 過去 ADRが継続的な機能改善指針に役に立つ！ ● ADRを元にAIが実装してくれるように！ ● 設計背景や思想まで考慮してAIが回答してくれるように！

Slide 49

Slide 49 text

49 Crossplaneを利用して Self-service提供する上で工夫 ~そ他~ ● 独自ツール開発によるカスタムリソース開発効率化 ● K8s Event モニタリング強化によって設定ミスを気付ける状態へ ● 永続層 K8sリソースみ削除するように設定し、無限Reconcileを防止 ● 開発者心理的ハードルを下げるため Skills整備 ● dev環境かつ担当範囲であれ approveなしでmerge可能にし、いち早く基盤に慣れてもらうようになどなど

Slide 50

Slide 50 text

50 Crossplaneを活用した Self-serviceで未だに悩んでいること ● 個別最適な要求をどこまで受けるべきか？ ● どうしたらすぐに基盤に慣れてくれるか？認知負荷を減らせるか？ ● 重いシナリオテスト ... ● 実永続リソース Clean up処理... などなど... 悩みながらも日々改善活動を実施中！

Slide 51

Slide 51 text

section 7 まとめ

Slide 52

Slide 52 text

52 開発者認知負荷軽減を目指して選んだ Crossplane ● 全てをGitOpsでまとめることができた👌 ● 抽象化により複雑さを隠蔽できた👌 ● 結果、プロダクト開発者だけでインフラ構築ができている👌 ● プロダクションレディな設定になっていることが担保できている👌 ● プロダクト数に比例しない運用負荷を実現できている👌

Slide 53

Slide 53 text

53 Self-service 理想と現実 ● Crossplane 良いことかりでなく、難しく運用負荷もかかる😢 ● Crossplaneだけで全てユースケースに対応する大変😢 ● 開発者が基盤に慣れるまでハードルが存在する🤔 ● 抽象を提供するとこと自体が難しい😢 ● 日々運用改善が重要😬

Slide 54

Slide 54 text

54 今後展望 ● 基盤利用にいち早く慣れてもらう仕組み整備 ○ オンボーディング実施 ○ Getting Started 整備 ● 対応ユースケースを広げて基盤利用をさらに加させる ● 利用者からフィードバックをもとに継続的改善 ● Crossplane 新CLI 検証/評価 ○ シナリオテストを薄くしたい... ● 上記を達成するため運用体制強化

Slide 55

Slide 55 text

https://www.hacomono.jp/