組織規模に応じたPlatform Engineeringの実践

Platform Engineering Kaigi 2025 #PEK2025

Makoto Shiga
株式会社hacomono
Senior Platform Engineer

株式会社hacomono所属のSenior Platform Engineer。
入社時から基盤チームとして様々な角度からプロダクトチームへの基盤提供やEnabling活動に従事。

https://www.cnia.io/pek2025/sessions/90bded05-896a-4725-ba1e-903e39a22c68/

Transcript

1. Last Update 2022.03.16 組織規模に応じた Platform Engineeringの実践 Platform Engineering Kaigi 2025 株式会社 hacomono
2. section 00 目次
3. 3 目次 1. Introduction 2. Platform Engineeringについて（簡単に） 3. 組織規模に応じたPlatform Engineeringの実践 3.1. モジュラーモノリス導入 3.2. k8s導入
4. section 01 Introduction
5. 5 自己紹介 • 志賀 誠（まこたす） • 株式会社hacomono ◦ 2022/8 ~ ◦ プラットフォーム部所属 • x: Maco_Tasu • GitHub: MacoTasu
6. 6 株式会社 hacomonoについて
7. 7 株式会社 hacomono / プラットフォーム部について • プラットフォーム部 ◦ hacomonoインフラグループ（4名） ▪ hacomono本体のインフラの開発運用 ◦ マルチプロダクト基盤グループ（2名） ▪ マルチプロダクト基盤の開発運用
8. 8 本セッションの内容 • 内容 ◦ 弊社のプラットフォームチームの取り組み / 成果（成功 / 失敗） ◦ 技術的な話は少なめです • 対象者 ◦ これからPlatform Engineeringを実践しようとしている組織 ◦ Kubernetesの採用を検討している組織
9. section 02 Platform Engineeringについて（簡単に）
10. 10 DevOps Dev Ops サイロ化 • DevOpsは、顧客/ビジネスへ迅速に価値を届けることを目標とした文化の 醸成 Dev Ops 従来 DevOps You build it, you run it
11. 11 Platform Engineeringとは • DevOpsから派生した考え。開発者体験の向上、認知負荷の軽減を目的 とした取り組み Dev Ops DevOps You build it, you run it Platform Engineering で手助け • セルフサービス化 • IDP etc…
12. 12 Platform Engineeringとは ~ 4つのチームと 3つのインタラクション ~ チーム名 役割 ストリームアラインド 組織の主要なビジネス領域や提供価値（ワークストリーム）に沿って編 成され、顧客に直接的な価値を届けることに責任を持つ プラットフォーム 自律的にサービスを開発・運用できるようにするための内部プラット フォームを提供する イネーブリング 特定の専門知識を持ち、ストリームアラインドチームが新しい技術やス キルを習得するのを支援をする コンプリケイテッド サブシステム 専門的な知識が必要なサブシステムを専門に担当する
13. 13 Platform Engineeringとは ~ 4つのチームと 3つのインタラクション ~ 名称 内容 コラボレーション 両チームが密接に連携し、特定の課題解決や新しい機能開発のために 協力して作業する ファシリテーション ストリームアラインドチームに対して、特定の技術やプラットフォームの 利用方法について指導や支援を行う X-as-a-Service ストリームアラインドチームがセルフサービスで利用できるプラットフォー ム（ツール、API、ドキュメントなど）を「製品」として提供する
14. section 03 組織規模に応じた Platform Engineeringの実践 ※株式会社hacomonoの例
15. section 03-1 実例1: モジュラーモノリス導入
16. 16 背景と当時の状況 • 2022年8月頃の組織図
17. 17 背景と当時の状況 • 人数増加 x モノリス • コミュニケーションコストの増加 ◦ → 誰が何を知っているのか / 正しい仕様が把握できない ◦ → 意思決定までに時間がかかる etc… • CI/CDの長時間化 ◦ → 顧客へ価値を届ける時間が増える ◦ → 開発速度の低下へ直結する etc.. • 成長機会の損失 ◦ → 新規技術を入れにくい
18. 18 背景と当時の状況 • モノリス x 人数増加 • コミュニケーションコストの増加 ◦ → 誰が何を知っているのか / 正しい仕様が把握できない ◦ → 意思決定までに時間がかかる etc… • CI/CDの長時間化 ◦ → 顧客へ価値を届ける時間が増える ◦ → 開発速度の低下へ直結する etc.. • 成長機会の損失 ◦ → モノリス側を気にするため新規技術を入れにくい つらい
19. 19 背景と当時の状況 • Platform Engineeringの考えで、チームファースト思考 がある ◦ 少数のチームが信頼性が高くワークする ◦ 境界を明確にする
20. 20 背景と当時の状況 • Platform Engineering ◦ セルフサービス、IDPはあくまで実現手段の1つ ◦ 目的 = 開発者の認知負荷を下げること • 当時の課題への温度感 ◦ 組織成長の課題に対して、アサインは自分のみ ◦ 課題に対してマイクロサービス化どうだろうか...? みたいなオーダー
21. 21 マイクロサービス or モジュラーモノリス 観点 マイクロサービス モジュラーモノリス 🚀 開発速度 チームが独立して動けるため、大規模開発では高速。 ただし初期の環境構築は遅い。 初期開発は非常に高速。しかし、コードベースが大きくなると速度が 低下する可能性がある。 🔧 複雑性 分散システム特有の問題（通信、データ整合性）を考慮する必要 がある。 シンプル。単一のアプリケーション内で完結するため、管理しやすい。 💪 スケーラビリティ 特定のサービスだけを独立してスケール可能で、リソース効率が 良い。 アプリケーション全体でのスケーリングとなり、リソース効率は劣る。 🧩 柔軟性 高い。サービスごとに最適な技術（言語、 DB）を選択できる。 低い。アプリケーション全体で技術スタックが統一されるため、制約が 多い。 🛡 障害耐性 高い。一部のサービスの障害が、システム全体に波及しにくい。 低い。一部のモジュールの障害が、アプリケーション全体の停止につ ながる可能性がある。 💰 コスト 運用・管理コスト（インフラ、監視ツールなど）が高い。 開発・運用コストは低い。 👥 チーム体制 大規模・分散チームに適している。チームの自律性を促進する （コンウェイの法則）。 小〜中規模チームに適している。密なコミュニケーションが前提とな る。 🔄 デプロイ サービスごとに独立して迅速にデプロイ可能。 CI/CDが複雑にな る。 アプリケーション全体を一度にデプロイする必要がある。デプロイの 頻度は低くなりがち。 🗃 データ管理 サービスごとにDBが分散し、データの一貫性を保つのが難しい （結果整合性）。 単一のDBでトランザクション管理が容易。データの一貫性を保ちや すい。 📊 テスト サービスをまたがる統合テストが複雑で難しい。 単一アプリケーション内のテストなので比較的容易。 🛣 将来の移行 サービス間の境界を後から変更するのは困難。 モジュールをマイクロサービスとして切り出すための良い出発点とな る。 generated by Gemini
22. 22 マイクロサービス or モジュラーモノリス 観点 マイクロサービス モジュラーモノリス 🚀 開発速度 チームが独立して動けるため、大規模開発では高速。 ただし初期の環境構築は遅い。 初期開発は非常に高速。しかし、コードベースが大きくなると速度が 低下する可能性がある。 🔧 複雑性 分散システム特有の問題（通信、データ整合性）を考慮する必要 がある。 シンプル。単一のアプリケーション内で完結するため、管理しやす い。 💰 コスト 運用・管理コスト（インフラ、監視ツールなど）が高い。 開発・運用コストは低い。 👥 チーム体制 大規模・分散チームに適している。チームの自律性を促進する（コ ンウェイの法則）。 小〜中規模チームに適している。密なコミュニケーションが前提とな る。 🔄 デプロイ サービスごとに独立して迅速にデプロイ可能。 CI/CDが複雑にな る。 アプリケーション全体を一度にデプロイする必要がある。デプロイの 頻度は低くなりがち。 📊 テスト サービスをまたがる統合テストが複雑で難しい。 単一アプリケーション内のテストなので比較的容易。 generated by Gemini
23. 23 マイクロサービス or モジュラーモノリス 観点 マイクロサービス モジュラーモノリス 🔧 複雑性 分散システム特有の問題（通信、データ整合 性）を考慮する必要がある。 シンプル。単一のアプリケーション内で完結す るため、管理しやすい。 🗃 データ管理 サービスごとにDBが分散し、データの一貫性 を保つのが難しい（結果整合性）。 単一のDBでトランザクション管理が容易。 データの一貫性を保ちやすい。 🛣 将来の移行 サービス間の境界を後から変更するのは困 難。 モジュールをマイクロサービスとして切り出す ための良い出発点となる。 generated by Gemini
24. 24 マイクロサービス or モジュラーモノリス 高 高
25. 25 マイクロサービス or モジュラーモノリス • 組織・技術の成熟度 ◦ 基盤チーム（プラットフォーム） ▪ マイクロサービス /モジュラーモノリスの経験 ◦ プロダクトチーム（ストリームアラインド） ▪ 分散システムの経験 ◦ 共通事項 ▪ リソース観点 • 事業の方向の確実性 ◦ どんなドメインを扱っていくか可視化されている ◦ 既に確立したコアとなるドメインがある
26. 26 マイクロサービス or モジュラーモノリス 名称 状態 モジュラーモノリス （出発点） 実現する技術/リソースも不安がある。 ドメインも枯れ切っていない。 => 技術もモジュールの切り方も不安定 筋の良いモジュラーモノリス 技術/リソースはあるが、ドメインがまだ不安定 => 技術で論理的分離ができるが、モジュールの粒度が不安定 堅実なモジュラーモノリス ドメインは枯れ切っているが、技術 /リソースが不安定 => モジュールの粒度は適切だが、モジュール /マイクロサービスの 実現に不安が残る マイクロサービス 技術/リソースも確かで、ドメインも見えている => 最短ルートでマイクロサービス化へ
27. 27 マイクロサービス or モジュラーモノリス 高 高 hacomono
28. 28 モジュラーモノリスを実現する技術 • モジュラーモノリスで始めるチームファーストの実現 hacomono application modules module A module B module .. team A team B team … • 境界分離 ◦ packwerk（コード分離） ◦ protobuf（API定義） ◦ arproxy（table分離） ◦ github codeowner（責任分離） • 詳細は こちら
29. 29 ~ モジュラーモノリス ~ • インタラクションモード変遷 序盤 (モジュール1個目 ) 中盤 (モジュール 2 ~ 4個) 現在 （モジュール20個） ストリームア ラインド プラットフォー ム 兼 ストリームアラ インド プラットフォー ム ストリームア ラインド プラットフォー ム セルフコラボレーション？ サポート機能の開発 コラボレーション サポート機能の不足している部分の 開発およびドキュメント化 ファシリテーション ドキュメントの案内 サポート機能利用方法の説明
30. 30 ~ モジュラーモノリス ~ • インタラクションモード変遷 序盤 (モジュール1個目 ) 中盤 (モジュール 2 ~ 4個) 現在 （モジュール20個） ストリームア ラインド プラットフォー ム 兼 ストリームアラ インド プラットフォー ム ストリームア ラインド プラットフォー ム セルフコラボレーション？ コラボレーション ファシリテーション 導入から2年...
31. 31 結果　 • 認知負荷軽減ができたケース ◦ 新規機能系のモジュールは好感触なフィードバック ▪ 特に基盤系（メール、webhookなど） ◦ AI Coding活用でもコンテキストが絞られるため、少ないtokenで効果 的に扱える • 要因 ◦ 既存機能に依存しないものが多い ◦ 基盤系は機能が明確なため、I/Fを定義しやすい
32. 32 結果 • 認知負荷軽減ができなかったケース ◦ 既存機能に紐づく機能のモジュール化 • 要因 ◦ 特に既存コア機能のモジュール化が進んでいなかったため、本体側 とのやり取りで無理がある場合がある ◦ ドメインが固まっていないため切り出し単位が難しい • 成果 ◦ Fail Fastで切り出したドメインの見直しが進むきっかけになった ▪ モジュラーモノリスなので切り直しも容易
33. 33 結果 • 反省 ◦ 開発基盤チームのDevOps意識の不足 ▪ 継続的な会話が足りてなかった • 改善 ◦ #pj_modular_monolith ▪ 目的意識の共有 / 当事者化 ▪ リアルタイムコミュニケーション
35. section 03-2 実例2: 現在の取り組み ~ k8s導入 ~
36. 36 背景
37. 37 背景 • 速いフロー実現を阻害する8つの要因 障害のポイント 組織設計の選択に夜混乱 チームが引っ張りだこ 数年ごとの苦痛な組織変遷 ブロックされているフロー 不測の事態の多発 モチベーションの低いチーム コンウェイの法則への対抗 チームにとって大きすぎるソフトウェア
38. 38 背景 • 速いフロー実現を阻害する8つの要因 障害のポイント 組織設計の選択に夜混乱 チームが引っ張りだこ 数年ごとの苦痛な組織変遷 ブロックされているフロー 不測の事態の多発 モチベーションの低いチーム コンウェイの法則への対抗 チームにとって大きすぎるソフトウェア
39. 39 背景
40. 40 背景 • 残っている課題 ◦ プロダクト毎のCI/CD基盤構築、運用保守 ▪ プロダクト数に合わせて人数も増えたら困らないけど...😢 ◦ ファシリテーションコストの増加 ▪ ドキュメントが整備されていても、新規にプラットフォームサービス を使うチームには一定発生するコスト これはセルフサービス化（ k8s）に取り組む機運か ...? 🤔
41. 41 k8s ちょっと待って 🖐！！ k8sってなんか大変なんでしょ？ 😢
42. 42 EKS（k8s） • k8sは学習コストがかかる？ ◦ No 󰻶 ▪ エコシステムが多いための学習コストが高い • Argo CD, Istio, Crossplane etc… • k8sは運用が大変？ ◦ 多分No 󰻶 ▪ EKS Auto Mode (2024/12)登場。 色々マネージド化された • control plane（etcdなど） • リソース（Karpenter, load balancing）
43. 43 k8s導入の判断 ✏ 課題 ⏱ 2年の自信 🚩 タイミング プロダクト数増加による基盤コ スト増 モジュラーモノリスを経て、マイ クロサービス化が見えてきた ECS/Serverless運用経験から 失敗しても戻れる自信 AI発展によるガードレールの重 要性 EKS AutoModeの誕生 チーム拡大による余力 k8sを用いたセルフサービス化の実現に取り組み始めた 💪
44. 44 k8s基盤での取り組みについて • 🕸 Istioを用いたservice meshの実現 ◦ プロダクト毎にnamespace / virtual serviceを付与 • 🐙 Argo CDによるGitOpsの実現 ◦ CI/CDの仕組み及び利用体験の統一 • ✈ Crossplane活用 ◦ プロダクトに紐づくAWSリソース管理も移譲できるようにする • 📕 IDPとしてのBackstage ◦ 検討中
45. 45 k8s基盤での取り組みについて • 🕸 Istioを用いたservice meshの実現 ◦ プロダクト毎にnamespace / virtual serviceを付与 • 🐙 Argo CDによるGitOpsの実現 ◦ CI/CDの仕組みの及び利用体験の統一 • ✈ Crossplane活用 ◦ プロダクトに紐づくAWSリソース管理も移譲できるようにする • 📕 IDPとしてのBackstage ◦ 検討中 挑戦中🔥
47. https://www.hacomono.jp/
48. 48 質疑応答🙋 ※このあと弊社ブースでも質問できます。