Platform Engineering as a Product: Criteria for Improvement and Multi-Tenant Design

Transcript

1. プロダクトとして考えるPlatform Engineering　 改善の判断基準とマルチテナント設計 Kumo Ishikawa / CyberAgent
2. 自己紹介 Kumo Ishikawa（石川 雲） CyberAgent Service Reliability Group(SRG)所属 • 担当サービス Ameba Platform, ドットマネー, ピグ • 得意領域 Platform Engineering, CI/CD, Security • 登壇歴 • Cloud Native Kaigi 2026 • SRE NEXT 2025 • Platform Engineering Kaigi 2025 • Kubernetes Meetup Novice 数回 Kubestronaut (2024) CyberAgent Next Expert of Platform Engineering(2025)
3. MAIN THEME Ameba Platformの事例をもとに、 「プロダクト」としてのPlatformを育てる判断を整理する Platformを作った後に出てくる「三つの問い」に焦点を当てる 1. 使われる状態をどう作るか 2. 使われ出したら次に何を改善すべきか 3. 何を共有し、何を分離するか この発表で話すこと
4. この発表で話すこと  Platform Engineering や IDP の作り方は、すでに多く語られているため ※ 詳しく扱わないこと • Platform Engineering の入門全体 • IDP ツール比較  次のような課題をお持ちの方が対象者 • Platform Engineering / IDP に取り組んでいる / 運用し始めている人 • Platform を作った後の改善優先順位や判断根拠に悩んでいる人 • Golden Path などの定着や、複数チーム支える責務境界に課題がある人 • マルチテナント設計で、共有と分離の判断に悩んでいる人
5. プロダクトとしてのPlatformとは何か
6. Platformは進む
7. その各フェーズで、異なるズレが出る
8. ズレにどう向き合うか Q1. 使われる状態作り A1. 摩擦を見つけ、導線に変え る • 迷いはどこにあるか • 手作業や認知負荷はどこにあるか Q2. 改善優先度の判断 A2. 改善シグナルを見極める • どの課題が繰り返し起きているか • 何を今改善し、何をまず観測するか Q3. 共有と分離の境界 A3. 守るべき領域を見極める • 共有できる領域はどこか • 守るべき領域はどこか この向き合い方を、この発表では 「Platformをプロダクトとして扱う」 と呼ぶ
9. Platformをプロダクトとして扱うとは 開発者向けの共通基盤を、 利用者価値・継続改善・責務境界 を持つ対象として捉え、 組織全体の変更能力を高めるために、 何を提供し、何を委ねるか を継続的に選ぶこと。
10. 見方の変化 Platformをプロダクトとして扱うと、観点は次のように変わる 観点 共通基盤として見る プロダクトとして見る 利用者 依頼者 ユーザー 成果 機能を作った 課題が解けた 問い合わせ サポートコスト 改善シグナル 標準化 ルールを決める 選ばれる導線を作る 要望 受ける / 断る 目的を見て再利用可能な形に変換する 責務 Platformが全部持つ / 持たない どこまで責務を持つか設計する
11. プロダクトとしてのAmeba Platformが 実際にどんな文脈で生まれ 何を提供してきたのかを説明します
12. Ameba Platformの紹介
13. 2024年9月: Ameba 20周年 Amebaについて
14. Ameba Platformについて 全てのAmebaサービスを支える開発者プラットフォーム Developer Platform for All Ameba Services Amebaサービスのインフラ基盤 + 開発者プラットフォーム 最終の目標: 歩み 2019年 PoC開始 2020年 サービス移管開始 2026年 25サービス以上がAmeba Platform上へ移管 • Amebaサービスの共通実行基盤 • 開発・デプロイ・運用の共通経路 • ログ、監視、セキュリティの共通前提 • 複数サービスを継続的に移管・運用するための基盤 役割 歩み
15. Amebaの当時の課題 2019年当時、Amebaのサービス群で起きていたこと 複雑なシステム構造 新しく担当したサービスを理解するまでのリードタイムが長くなる 起きていたこと 開発・運用への影響 チームごとに選定された様々な技術 サービスごとに開発・運用の前提を覚え直す CI/CDや運用方法がサービスごとに違う リリースや障害対応のやり方が揃わない 監視・ログ・権限管理が分散している 状況把握や調査に時間がかかる 運用における責任範囲が不明瞭 誰がどこまで見るべきか曖昧になる 長期的な運用において、認知負荷が高く、継続性も弱かった
16. Ameba Platformが提供したもの サービス側で個別に考えていたこと Platform側が提供したこと 代表例 アプリケーションをどう動かすか 共通の実行環境を提供する Kubernetes / KubeVela / OAM 変更をどう届けるか 管理されたデプロイ経路を提供する GitHub Actions / Argo CD 状態をどう把握するか ログ・監視の見方を共通化する 統一ログフロー / Datadog 安全性をどう担保するか 基本的なガードレールを提供する SecurityContext / Secrets Manager 誰がどこまで見るか 所有者・権限・運用範囲を扱いやす くする 権限管理 / Owner / 運用設計
17. Amebaで発生した3つのズレ Platformが提供した領域 発生したズレ 対応している問い 共通の実行環境・ デプロイ経路 移行前に戸惑う、既存運用とぶつ かる Q1: 使われる状態をどう作るか ログ・監視・CI/CD・ セキュリティ 日々の利用で改善候補が増える Q2: 改善判断をどう持つか 権限・所有者・ 運用範囲 利用拡大で責務境界が曖昧になる Q3: 何を共有し、何を分離するか
18. 使われる状態をどう作るか
19. Ameba Platformへ移行する背景 移行対象 • オンプレの Kubernetes App / VM • 別 AWS Account 上の ECS / Lambda / EC2 • 周辺システムやバッチ処理 移行方法 • App本体は EKS App に集約 • モノリスはマイクロサービスへ分割しながら移行 • 周辺システムは、可能なものは Kubernetes へ移行 • Glue など移行しないものは、そのまま利用する 移行体制 • 通常は App側 2〜3人 + Platform側 1人 • VM起点の場合は、コンテナ化・マイクロサービス化が先に必要 • その場合、移行体制も大きくなる
20. 移行で向き合った2つの摩擦 移行では、主に2つの摩擦が現れた 既存の運用を変える • 慣れない設定とマニフェスト • 変えないといけない従来のリリース体制 移行後の運用責任を理解する • 障害・設定・改善の責任境界を把握しづらい • コミュニケーションコストがかかる 刷新と移行を並行する • 移行自体の作業コストがかかる • 新旧体制並行時の認知負荷 02. 標準経路との摩擦 既存の実現方法を変える必要がある • ユーザが技術選定や運用パターンを変えたく ない 目的と実現方法が密結合している • コストや負荷低減の目的が特定技術とセット 個別要望による共通性の崩壊 • 標準経路から外れた運用が増加 既存機能に気づけず、利用チーム側で回避策を 考えてしまう この章では、この2つの摩擦をどうPlatform側で対応したのかを見る 01. 移行・初期利用の摩擦
21. 移行で向き合った2つの摩擦 移行では、主に2つの摩擦が現れた 既存の運用を変える • 慣れない設定とマニフェスト • 変えないといけない従来のリリース体制 移行後の運用責任を理解する • 障害・設定・改善の責任境界を把握しづらい • コミュニケーションコストがかかる 刷新と移行を並行する • 移行自体の作業コストがかかる • 新旧体制並行時の認知負荷 02. 標準経路との摩擦 既存の実現方法を変える必要がある • ユーザが技術選定や運用パターンを変えたく ない 目的と実現方法が密結合している • コストや負荷低減の目的が特定技術とセット 個別要望による共通性の崩壊 • 標準経路から外れた運用が増加 既存機能に気づけず、利用チーム側で回避策を 考えてしまう この章では、この2つの摩擦をどうPlatform側で対応したのかを見る 01. 移行・初期利用の摩擦
22. 移行で向き合った2つの摩擦 移行では、主に2つの摩擦が現れた 既存の運用を変える • 慣れない設定とマニフェスト • 変えないといけない従来のリリース体制 移行後の運用責任を理解する • 障害・設定・改善の責任境界を把握しづらい • コミュニケーションコストがかかる 刷新と移行を並行する • 移行自体の作業コストがかかる • 新旧体制並行時の認知負荷 02. 標準経路との摩擦 既存の実現方法を変える必要がある • ユーザが技術選定や運用パターンを変えたく ない 目的と実現方法が密結合している • コストや負荷低減の目的が特定技術とセット 個別要望による共通性の崩壊 • 標準経路から外れた運用が増加 既存機能に気づけず、利用チーム側で回避策を 考えてしまう この章では、この2つの摩擦をどうPlatform側で対応したのかを見る 01. 移行・初期利用の摩擦
23. 摩擦1: 移行・初期利用の摩擦 利用チームがPlatformの細部を理解しなくても、正しい経路に乗れる状態が必要だった 判断: 利用チームに正しく覚えてもらうのではなく、 正しく使える導線をPlatform側で作る 起きていたこと (課題) 多様なマイクロサービスの一括管理 • 複数種類のアプリケーションに対応したい • アプリケーション単位で管理したい ログ管理場所の分散 • 全ログ同一箇所集約による弊害の解消 • 用途に応じた転送先・保存先の分岐 移行作業負荷の分散 • 9種類のマニフェスト作成 • 複数リポジトリの修正 Platform側で対応したこと Kubernetes App抽象化 • KubeVelaによるアプリ単位の管理 • Kubernetesの複雑さを隠蔽 ログ転送フローの整備 • 用途に応じた転送先の柔軟な変更 • 標準的なログ管理経路の提供 作業の導線化 • CLIによるマニフェスト自動生成 • Runbookの整備・最新化 • 1サービスへの専任者設置
24. 移行・初期利用の摩擦の解消: 導線をGolden Pathにする 迷わず進める • 移行手順が分かる • 必要な設定が分かる • 確認場所が分かる 安全に進める • 書き間違いを減らす • 変更漏れを減らす • 環境差分の漏れを減らす 運用までつながる • デプロイ経路につながる • ログ・監視の見方につながる • 移行後の運用責任につながる Golden Pathは、共通経路に価値到達までの導線 を与えるもの 移行手順、抽象化、CLI、Runbook、ドキュメント、ログ・監視の見方までを包含
25. 事例: 要件を満たす導線を作る 利用チームの不安 • マイグレーションフローをどう 移設するか分からない • マルチライン開発ができないと 思い、回避策を検討していた Platform側の判断 • Argo Workflow でマイグレー ションフローを実現できると判 断 • GitHub連携の Istio Operator 機能でマルチライン開発の要件 を満たせると判断 • 利用チームが使えるように、ド キュメント・RBAC・運用導線 を整備 提供した価値 • 要件を満たす実現方法を提示 • 既存機能を使える状態に整備 • 利用チームがPlatformの内部 構造を理解しなくても進められ る状態にした
26. 摩擦2: 標準経路との摩擦 移行が進むと、既存のやり方や個別要望が、Ameba Platformの標準経路とぶつかる 判断: ユーザの要望ではなく、達成したい目的を見る 表面上の要望 例: AWS Lambdaを使いたい • Lambdaを使いたい • たまに実行するBatchを実行した い 標準経路では • LambdaはPlatform管理用のみ 本当に達成したい目的 • コストを下げたい • バッチ処理を効率よく動かしたい • 運用負荷を下げたい Platform側の確認 • Lambdaでなければ目的を満たせない のか • すでにコンテナ化されている処理を活 かせないか • 標準経路から外したとき、運用負荷は 増えないか • その選択は他サービスにも再利用でき るか
27. 達成したい目的を共通経路に返す このケースでの判断 すでにコンテナ化されているなら、EKS上のCronJobで実現する Platform側から説明したこと • Lambdaよりも、既存の実行基盤に乗せたCronJobの方がコスト を下げやすい • 既存のCI/CD、ログ、監視、権限管理につながる • 個別運用を増やさず、移行後の運用責任も揃えられる トレードオフ ▼ Lambdaを使う自由度は下がる ▲ コスト削減の目的は満たせる ▲ 運用経路と責務境界は揃う ▲ 長期的な運用負荷を増やしにくい この判断で守ったこと • 要望を否定するのではなく、目的を満たす共通経路を示す
28. 判断構造 標準経路との摩擦に向き合うとき、2つの視点を同時に持つ →利用チームの目的を満たしながら、Platformとして維持できる導線に返す ユーザー体験 • 目的を満たせるか • 移行や運用の負担が下がるか • 利用チームが納得できるか Platformの方向性 • 共通の実行基盤に乗るか • CI/CD、ログ、監視、権限とつながるか • 他のサービスにも再利用できるか • 長期的な運用負荷を増やさないか
29. 使われる状態をどう作るか 利用者が価値に到達するまでの摩擦を見つけ Platform側で提供する範囲を決め 始めやすく、続けやすい導線を作る
30. 使われ出したら次に何を改善すべきか
31. 使われる経路になる 既存サービスの移行により、Platformは「作った基盤」から「日々使われる経路」へと進化 します。すると、様々な課題が出てきます。 この章で見ること： 改善候補をどう見立て、何を先に改善するか • CI/CDが遅い • ログが探しづらい • アラート対応が属人化する • セキュリティ検知のノイズが多い
32. 改善サイクルを回す 改善サイクル 改善シグナルの入力 •Platformチャンネルで繰り返し出る声 •半期ごとのPlatform討論会 •日々の問い合わせ •インシデントや障害対応 •日々の手作業・属人対応 •サービス移行の詰まり •セキュリティ検知のノイズ •改善や移行に必要な作業量
33. 改善シグナルを判断軸で読み替える 改善シグナルの入力 • Platformチャンネルの声 • 半期ごとのPlatform討論会 • 日々の問い合わせ • インシデントや障害対応 • 日々の手作業・属人対応 • サービス移行の詰まり • セキュリティ検知のノイズ • 改善や移行に必要な作業量  問い直すこと • 誰の体験にどれほど影響するか • 運用負荷は増えているか • セキュリティリスクは高いか • 他サービスにも展開可能か • 実現・移行コストは見合うか  共通の判断軸 • ユーザー価値 • 運用負荷 • セキュリティリスク • 再利用性 • 実現コスト そのうち、Ameba Platformが重視している判断軸 ユーザ価値 / 運用負荷 / セキュリティリスク
34. どう改善するかを判断します 今すぐ改善 影響範囲が広く、利用者体験や運 用負荷に直結する 段階的に改善 リスクは高いが、一気に入れると 運用できない まず観測 課題の実態や影響範囲がまだ見え ていない 後でやる 課題はあるが、緊急度や影響範囲 がまだ小さい 継続利用 課題はあるが、置き換えコストや 影響が大きい やらない Platformの方向性と合わない、ま たは長期的な運用負荷が増える Ameba Platformが重視している判断軸: ユーザ価値 / 運用負荷 / セキュリティリスク
35. 判断例1: 今すぐ改善する CI/CDの待ち時間 開発効率とリリース体験のボトルネック 判断: 今すぐ改善する 改善シグナル • Terraform実行時間が増える • Image PushからDeployまで時 間がかかる • Argo CD / FluxCDの同期が遅 れる • UIが重くなる • Post Release処理が詰まる 判断軸 ユーザ価値 • 開発者の待ち時間に直結する • リリース体験に影響する 運用負荷 • 複数サービスに広く効く • Platform拡大時の運用可能性に 関わる 改善の方向 • 差分ModuleのみTerraform Apply • ImageUpdateAutomation • Argo CD / FluxCDのシャー ディング • KubeVela Application Workflow • Controller / Repo Server / API Serverのスケール
36. 判断例2: 段階的に改善する Falcoによるランタイムセキュリティ 段階的な導入によるリスクと運用負荷のバランス 判断: 段階的に改善する 改善シグナル • 未対応のイメージ脆弱性 • コンテナ内部からの攻撃リスク • コンテナランタイム監視の不足 判断軸 • セキュリティリスク低減 • 運用負荷が一定にあるが、許容 可能 進め方 (Step) 01. Audit Log監視 まずは低リスクなログから開始 02. ノイズ削減 運用に耐える精度まで調整 03. アラート運用 本番環境でのアラート開始 04. 範囲拡大 必要に応じSystemCall監視へ
37. 判断例2: 段階的に改善する Falcoによるランタイムセキュリティ 段階的な導入によるリスクと運用負荷のバランス 判断: 段階的に改善する 改善シグナル • 未対応のイメージ脆弱性 • コンテナ内部からの攻撃リスク • コンテナランタイム監視の不足 判断軸 • セキュリティリスク低減 • 運用負荷が一定にあるが、許容 可能 「今すぐ改善する」への引 上げ条件は？ • セキュリティ要件が非常に厳 しい場合 • コンテナランタイム監視が半 期以内にすぐに構築しないと いけない場合
38. 判断例3: 継続利用 KubeVela(K8sApp抽象化)の継続利用 判断: 継続利用 改善シグナル • 主要開発元の開発停滞 • CUEテンプレートの難しさ • 保守負担の増加 • 社内でメンテナンスし続ける不 安 判断軸 運用負荷が高い • 代替可能なプロダクトがない • 置き換えによる移行コストは高 い • 既存Platformへの影響は大きい か ユーザ価値 • 利用チームへの影響は大きい • 今後は置き換えた方が良い 扱い • 継続利用する • リスクを観測する • 必要なら将来的なコントリ ビュートや代替検討を行う
39. 判断例3: 継続利用 KubeVela(K8sApp抽象化)の継続利用 判断: 継続利用 改善シグナル • 主要開発元の開発停滞 • CUEテンプレートの難しさ • 保守負担の増加 • 社内でメンテナンスし続ける不 安 判断軸 運用負荷が高い • 代替可能なプロダクトがない • 置き換えによる移行コストは高 い • 既存Platformへの影響は大きい か ユーザ価値 • 利用チームへの影響は大きい • 今後は置き換えた方が良い 「段階的に置き換える」へ の引き上げ条件は？ • 代替可能なプロダクトがGA • 移行コストが比較的に低い • 利用チームへの影響は少ない
40. 使われ出したら次に何を改善すべきか 利用者の声と運用シグナルを課題として捉え直し 自分たちのPlatformが重視する判断軸で 何をいつやるかを選ぶ
41. 何を共有し、何を分離するか マルチテナント設計をどう判断するか
42. Platformにおける共有 共有することで得られるPlatformの価値 • 実行基盤を共通化、経路の共通化（CI/CD・ログ・監視） • 運用改善を複数サービスへ波及させ、全体の改善を加速 • 開発者体験を高い水準で揃えやすく、品質を底上げ 課題 利用が広がるほど、同じ前提で扱えないサービスが出てくる 次に問われること どこまで共有し、どこから分離するか
43. 完全共有と完全分離のどちらにも限界がある
44. どうする？ Platformのレバレッジは共有から生まれる だから、まず共有できる領域を基本にする その上で、守るべき領域だけを分離する
45. 守るべき領域だけを分離する 共有できる領域 Non-Protected • 共通運用 • 共通基盤 • 共通経路 • 多くのサービスに効く改善 → Platformの改善を広く返すため、まず共有する 分離すべき領域 Protected •高いセキュリティ要件 •強い権限境界 •被害範囲の限定 •他テナントへの影響を抑える → 守るべきものがある場合だけ、境界を強める 分離するかどうかは、テナント単位ではなく、何を守る必要があるかで決める
46. Ameba Platformで起きたこと 初期設計: 完全共有を目指す • 1 Product = 1 Namespace • Owner Tagで責任範囲を管理 • みんなで一緒に面倒を見る 限界: 移行による変化 • 開発者は自分のサービスしか見ない • Developer権限では不足 / Adminの増加 • Viewer機能が使われない • セキュリティ要件の多様化 • 組織を跨ぐサービスの混在 課題: 完全共有が維持できなくなる 運用フェーズの変化に伴い、設計思想のアップデートが必要に
47. 設計思想のアップデート 分離観点の検討 • 責任範囲 • 接続性 • データ分離 初期段階の戦略 • 保護対象テナントだけを守る • 後から共通の仕組みを作る
48. Platform Engineering Kaigi 2025 https://www.cnia.io/pek2025/sessions/be2991cc-3d65-480d-8a5c-aafc00c84dc1/ 具体的な話はこちらへ
49. 事例: テナントの分離設計 移行対象の要件 • テナント間のアクセス範囲と全ての運用操作を隔離したい • テナント間のAWS通信とPod通信を制御したい 判断 • テナントのAWSリソース・Kubernetesリソース・開発資産全てを守るべき領域として指定 ◦ AWS ABAC設計、厳格なK8s RBAC設計、NetworkPolicy、Datadog/Github/ArgoCD RBAC設計 ◦ 入り口を認証プロバイダのRoleに一本線してUX体験を重視 • AWS通信など一部未達だったが、運用でカバー ◦ AWS内部ネットワークは共有、Pod -> RDSの通信制御は隔離できていない ◦ RDSはパスワードで分離管理のため、カバーできていると判断
50. 事例: RDSを守るために分離する 既存の分離とマルチテナント設計 • Namespace / IAM Role / RBAC は独立 • AWS内部ネットワークは共有、Pod -> RDSの通信制御は隔離できていない • RDSはパスワードで分離管理 新しい移行対象の要件 • セキュリティ要件が高く • パスワードが漏れた場合の影響を抑えたい • RDSへの到達自体をより強く制御したい 判断 • RDSを守るべき領域として指定 ◦ RDS自体を IAM Auth に切り替える ◦ 接続できる主体を IAM Role で制御する • 結果として、全テナントのRDS分離設計を見直した
51. 何を共有し、何を分離するか 共有を基本にしながら、守るべき領域だけを分離し 責務境界を管理可能な形にする
52. まとめ
53. Platform進化の各フェーズのズレと問い
54. 三つの問いとその答え Q1 使われる状態を どう作るか A1 始めやすく続けやすい 導線を作り、価値到達 までの摩擦を減らす Q2 次に何を改善すべ きか A2 改善シグナルを判断軸 で読み替えて、軸を元 に改善判断を決める Q3 何を共有し、 何を分離するか A3 守るべきものから 境界を設計する
55. ありがとうございました