プラットフォームエンジニアリングを 普及と実践し続けて見えてきた利点とリスク

開発生産性カンファレンス2024で発表した資料です。

Transcript

1. プラットフォームエンジニアリングを 普及と実践し続けて見えてきた利点とリスク 開発生産性カンファレンス2024
2. このセッションについて 開発生産性を向上させるアプローチPlatform Engineeringについて、 動向と実践の両面から学べる２部制のセッションです。
3. 前半：自己紹介 • Platform Engineering Meetup　運営 ◦ 「Real World Platform Engeening」共著 • 株式会社野村総合研究所(NRI)　エキスパート ◦ 生産性向上プラットフォームブランド ◦ コンテナ、CI/CD、生成AIを扱う 開発領域のプロダクトを担当 井沢　祐介
4. 前半：Platform Engineeringの動向 • Platform Engineeringとは ◦ 生まれた背景 ◦ 構成要素 • Platform Engineeringの普及 ◦ コミュニティ動向 ◦ ベンダ動向
5. Platform Engeneeringとは DevOpsの実践において、開発者の生産性を高めるためのアプローチ。 1. 開発者の認知負荷を下げる機能がセルフサービスで利用できる 2. アプリケーションの迅速な開発とデリバリーを可能にする。 3. プラットフォーム自体もプロダクトとして、継続的に改善・発展される プラットフォーム　v1 抽象化された機能 実際の実装 抽象化された機能 実際の実装 プラットフォーム v2 プラットフォーム チーム プロダクトチーム アプリケーション
6. Platform Engineeringが生まれた背景 学習関連(Germane) 認知負荷 内在的(Intrinsic) 認知負荷 認知負荷(Cognitive Load)について 外在的(Extraneous) 認知負荷 情報を認識するまでの負荷 　・不要なノイズ 　・テキストや音声といったフォーマット対応 情報を理解する負荷 　・学習対象の難易度そのもの 情報を長期化する負荷 　・分割し、順序、関連性を持たせる
7. Platform Engineeringが生まれた背景 オンプレミス＋仮想マシン時代は、認知負荷が比較的低く課題にならなかった 学習関連(Germane) 認知負荷 内在的(Intrinsic) 認知負荷 ネットワーク 仮想化技術 サーバ インフラ/ミドルウェアの設計 ミドルウェア アプリケーションの設計 ライブラリ プログラミング言語 公式ドキュメント OSS 外在的(Extraneous) 認知負荷
8. Platform Engineeringが生まれた背景 CloudNativeな構成へシフト、インプット情報も多様化し認知負荷が増大 学習関連(Germane) 認知負荷 内在的(Intrinsic) 認知負荷 ネットワーク 仮想化技術 サーバ インフラ/ミドルウェアの設計 ミドルウェア アプリケーションの設計 ライブラリ プログラミング言語 公式ドキュメント OSS 配信動画 フォークされたOSS 大量生産された解説ブログ チャットAI クラウド コンテナ CI/CD クラウド設計 CI/CD設計 コンテナ設計 外在的(Extraneous) 認知負荷
9. Platform Engineeringが生まれた背景 あなたのチームは、スーパーマン頼りになっていませんか？ 学習関連(Germane) 認知負荷 内在的(Intrinsic) 認知負荷 ネットワーク 仮想化技術 サーバ インフラ/ミドルウェアの設計 ミドルウェア アプリケーションの設計 ライブラリ プログラミング言語 クラウド コンテナ CI/CD クラウド設計 CI/CD設計 コンテナ設計 アプリケーション以外の一切合切をやってくれる ＝その人がいないと開発が止まる 外在的(Extraneous) 認知負荷
10. 認知負荷を軽減するためのPlatformの構想 https://tag-app-delivery.cncf.io/whitepapers/platforms/　参考 プロダクトであること…チームにより継続的に改善が行われる ドキュメントがあること...設定例など、ユーザのニーズに応じたものを 認知負荷の削減...抽象化して機能を提供する UXを考えること...ポータル/API/GUI/IDE/CLIなど最適な提供方法を考える セルフサービスであること...依頼を受けて人が動く運用を避ける オプションであること...必要な機能を一部のみ使用可能 デフォルトで安全であること...組織のルールに基づくことを保証する
11. 個人的な経験からのPlatformの優先度 プロダクトであること ドキュメントがあること 認知負荷の削減 UXを考えること セルフサービスであること オプションであること デフォルトで安全であること スケール 　・社内標準になったら耐えられるか プロダクトマーケットフィット 　・開発者の課題を解決するか 　・最小限の開発で試行できるか ユーザ体験の向上 　・利用することで逆に 　　認知負荷は増えないか
12. Platform Engineeringによる認知負荷の削減 学習関連(Germane) 認知負荷 内在的(Intrinsic) 認知負荷 Platformの各要素が開発者の認知負荷削減に寄与 見るべき情報をあらかじめ整理 　・ドキュメントやポータル 理解が必要な情報を削減 　・抽象化された機能の提供 機能間の関連性も示す 　・推奨構成(Golden Path)を 　　プロジェクトテンプレートで提供 外在的(Extraneous) 認知負荷
13. 抽象化した機能の提供 Platform Engineeringの提供機能　Cloud Native版 https://tag-app-delivery.cncf.io/whitepapers/platforms/ より和訳 プロダクトチーム プラットフォームチーム インター フェース 提供 機能 ドキュメント GUI (ポータル) プロジェクトテンプレート APIとCLI 環境とリソースの提供 インフラリソース データ保管 メッセージング ID管理と認証 CI/CD サービス連携 成果物管理 セキュリティ 可観測性
14. Platform Engineeringの提供機能　NRI aslead事例
15. 前半：Platform Engineeringの動向 • Platform Engineeringとは ◦ 生まれた背景 ◦ 構成要素 • Platform Engineeringの普及 ◦ コミュニティ動向 ◦ ベンダ動向
16. 海外コミュニティ動向 2021年より活動が現れ、2022年に本格化 2021年 1月　世界で28箇所でコミュニティ活動が開始 2022年 2月　専門組織PlatformEngineering.orgが設立 2022年 6月～　カンファレンスPlatformCon2022が開催 (以降、毎年開催) https://platformengineering.org/about　より
17. Platform Con 2024 https://platformcon.com/talks　より集計 トーク説明文のワードクラウド集計
18. 国内コミュニティ動向 2023年 3月　日本コミュニティ Platform Engineering Meetupが開始 #4 FUKUOKA #3 NAGOYA #8 KANSAI TOKYO
19. プラットフォーム提供ベンダ動向 2024年より各ベンダでも国内発信が活発になってきている • Google Cloud　「道を照らす: プラットフォーム エンジニアリング、 　　　　　　　　ゴールデンパス、セルフサービスのパワー」 • AWS　　　　　「プラットフォームエンジニアリングって何？」 • Azure　　　　 「プラットフォーム エンジニアリングとは」 • Red hat　　　　「プラットフォーム エンジニアリングとは」 https://cloud.google.com/blog/ja/products/application-development/how-to-become-a-platform-engineer/ https://pages.awscloud.com/eib-what-is-platform-engineering-240229-reg.html https://learn.microsoft.com/ja-jp/platform-engineering/what-is-platform-engineering https://www.redhat.com/ja/topics/devops/platform-engineering
20. 一般ユーザ動向 2023年末より日本でも少し認知はされ始めたが、普及はまだまだこれから https://trends.google.co.jp/trends/explore?date=today%205-y&q=Platform%20Engineering&hl=ja　より
21. Platform Engineering Kaigi 2024の初開催 参加申し込みは こちら↓↓
22. Google Cloud 00 [後半パート] Platform Engineering の利点とリスク を事例を交えながらお話しします 22 リクルートにおける横断データプロダクトの事例紹介 Platform Engineering は組織にどのような変化をもたらしたか Platform Engineering におけるリスクと対応
23. © Recruit Co., Ltd. All Rights Reserved 23 Speaker 　 菅沼孝二 社会人歴 8 年目 所属　　　　　株式会社リクルート　データ推進室 最近の出来事 二児の父（共働き運用開始で大変、継続的改善を心がける） 好きなサービス Kubernetes Engine, Cloud Logging, IAM 肩書　　　　　プロダクト テックリード 2016 年 - 新卒 メディア・ゲーム・広告関連事業会社 広告データ収集基盤開発・広告効果モデリング 2017 年 - 中途 株式会社リクルートライフスタイル データ分析・ML モデリング・実装 / データ プラットフォーム開発・ SRE 2021 年 - （統合） 株式会社リクルート データ プラットフォーム開発・ SRE
24. © Recruit Co., Ltd. All Rights Reserved 24 01 Contents 02 03 04 リクルートにおける　　　　　　　　　　横断データ プロダクトの事例紹介 Platform Engineering は組織にどのような変 化をもたらしたか Platform Engineering におけるリスク要因と 対応 おわりに
25. © Recruit Co., Ltd. All Rights Reserved 25 Key Takeaways 文化/マインドを変化させる仕組みを生み出せる Platform Engineering はプロダクト進化の硬直リスクを孕んでいる Platform Engineering は開発生産性に寄与する文化/マインドに変 化をもたらす 単に開発生産性を向上させるだけではない 持続的な進化の実現に向けて運営設計する 運営方式を誤ると進化を阻害する結果に繋がる ❶ ❷
26. Google Cloud 01 リクルートにおける 横断データプロダクトの事例紹介 26 担当プロダクトの役割・位置付け 担当プロダクトにおける各種指標
27. © Recruit Co., Ltd. All Rights Reserved 27 ETL / Delivery エンドユーザー データ収集 データ処理 / 配信 事業 DB API Platform Job Platform Streaming Platform Notebook Platform 事業サーバー データ管理 … エンドユーザー 事業 DB 事業サーバー BI ツール Ingestion Real-time Data Ingestion Platform Batch Data Ingestion Platform Data Management Platform Data Engineering (ETL / Delivery) に特化した Internal Developer Platform を運営 担当プロダクト範囲
28. © Recruit Co., Ltd. All Rights Reserved 28 担当プロダクト上の チーム / プロセス / 技術 に関連するメトリクス Our Platform Overview 300+ developers / users 250+ projects 4,500+ containers on API Platform all 2,000+ workflows on Job Platform all 5± maintainers 6,000+ developers’s releases per year (contains automatic releases) 400+ maintainer’s releases per year ※ 2024/03 時点
29. © Recruit Co., Ltd. All Rights Reserved 本セッションではプロダクト詳細は割愛します Platform Engineering Meetup #6 にて詳しく説明しているのでこちらの資料をご参照ください https://speakerdeck.com/recruitengineers/platformengineeringmeetup_suganuma
30. Google Cloud Platform team のマインド変化 Developer team のマインド変化 30 02 Platform Engineering は組織にどのような変化をもたらしたか
31. © Recruit Co., Ltd. All Rights Reserved 31 Platform team のマインド変化 Platform as a Software から Platform as a Product へ 多様な価値提供から 持続的な価値提供へ 01 02 重要な課題を解決できる最小のセルフサービス化 （Thinnest Vaible Platform） ツール・プロセス・チームの全スコープで戦略的に運営する
32. © Recruit Co., Ltd. All Rights Reserved 32 プロダクトとして運営する • 事業戦略・横断組織戦略に基づいた優 先度で期初開発計画を策定 • 随時ユーザーサポートやユーザー フィードバックの収集/分析 • 期初計画の消化ではなくユーザーへの アウトカムを最大化するため、期中に開 発計画を柔軟に修正 • これらを繰り返し、継続的に改善 [引用] thematic https://getthematic.com/insights/feedback-loops-for-customer-experience/
33. © Recruit Co., Ltd. All Rights Reserved 33 持続的に価値提供できる仕組みを設計する • 担当している Platform が解決すべき問題や 開発すべき技術にフォーカスする ◦ そうでない問題解決は別 Team や Developer 側に委譲 ◦ マネージドサービスを積極採用 • SLO / Error budget に基づいた運用により、 頻繁かつチャレンジングな変更を継続 • 必要十分なドキュメンテーション整備と継続的 なアップデートにより属人性排除 Reference: What is a Thinnest Viable Platform (TVP)? — Team Topologies
34. © Recruit Co., Ltd. All Rights Reserved 34 Developer team のマインド変化 委託気質な開発から 自律的な開発へ 顧客志向から パートナー志向へ 01 02 Platform team と相互扶助的に改善を積み重ねる Developer team がアプリケーション品質のオーナーシップを持つ
35. © Recruit Co., Ltd. All Rights Reserved 35 Developer team の オーナーシップの確立 • Developer team によるアプリ ケーション運用 • Developer team 内でのトラブル シューティング / 改善 • Developer team 内でのコード品 質担保（レビュー） [引用] Atlassian https://www.atlassian.com/ja/devops Developer team が 自律的に DevOps を実践できる環境を提供
36. © Recruit Co., Ltd. All Rights Reserved 36 Platform team と Developer team の 相互扶助的な改善 • Developer team からの継続的 なフィードバック • Platform team / Developer team の協業による性能改善 • Platform team / Developer team の協業による技術的負債 の解消
37. © Recruit Co., Ltd. All Rights Reserved 37 Platform Engineering による主な変化と考察 委託気質な開発から 自律的な開発へ 顧客志向から パートナー志向へ Platform as a Software から Platform as a Product へ 多様な価値提供から 持続的な価値提供へ Platform team のマインド変化 Developer team のマインド変化 決して Platform の導入によってすぐに変化できた訳ではない 地道な対話と改善を積み重ねた結果、文化として定着した
38. Google Cloud Developer team への利用強制 Developer team 要望への盲信 過度なサービス品質の提供 03 Platform Engineering における リスク要因と対応 38
39. © Recruit Co., Ltd. All Rights Reserved 39 Platform Engineering におけるリスク要因 Developer team への利用強制 Developer team 要望への盲信 過度なプロダクト品質の提供 01 02 03
40. © Recruit Co., Ltd. All Rights Reserved 40 Developer team への利用強制 • 使われている理由が強制によるもの なのか、良いプロダクトであるからな のか、評価しづらくなる • 「使われない」理由を獲得できなくな る • 結果として使いづらいプロダクトに繋 がりうる • プラットフォームの利用を強制するの ではなく、利用を提案する ◦ 導入判断は Developer 側 • プラットフォームの利用が最適である と意思決定してもらえるものを目指 す ◦ 内部ニーズの変化と外部ツー ルの変化に常に追従 起きうる事象 対応 / 考え方
41. © Recruit Co., Ltd. All Rights Reserved 41 具体事例: 「使われない」理由のフィードバック プラットフォームへの機能改善要望が実現するまでのリードタイムを長くする構造上の要因がある • 全体への効果見立てで開発優先度を設計するため、特定チーム固有の要望に対応しづらい • 変更影響が大きく、ダイナミックな打ち手が取りにくい • 組織跨ぎによるコミュニケーションリードタイムが生じる 要望 発生 要望整理 打ち手検討 Developer team Platform team やるやら 議論 要望の解像 度を上げる 打ち手検討 （全体影響考慮） 開発計画 開発 受け入れ テスト 組織跨ぎによるコミュニケーション リードタイム発生 特定チーム固有の要望に 対応しづらい 変更影響が大きい場合は、ダイナ ミックな打ち手が取れない 利用 開始 Platform team としては、その設計・構築を一部支援しつつ、 その協業の中で得られる汎化可能な知見や機能を Platform に反映するなどの打ち手を検討しています。 これらの課題に対して、Developer team では固有の要件・ニーズ ・開発効率を満たすための「独自基盤」を設計・構築する方針が採 用されました。
42. © Recruit Co., Ltd. All Rights Reserved 42 Developer team 要望への盲信 • ユーザーの機能要望に全て応えて いくことで、運用保守コストが高いプ ロダクトになったり、一貫性がなく複 雑性が増して変更容易性が下がっ てしまう • ユーザー自身が自分の本当に有用 な機能を認識できていないケースも ありうる • 担当プロダクトが果たすべき役割に 基づいて、重要な課題を解決できる 最小の機能を提供する ◦ Thinnest Viable Platform • 受動的なフィードバックによる課題整 理だけでなく、能動的な課題探索も 取り入れる ◦ 積極的な利用者への関与 起きうる事象 対応 / 考え方
43. © Recruit Co., Ltd. All Rights Reserved XaaS 43 具体事例: 能動的な課題探索と改修提案 Applications Platform team A team B team C Self-service / XaaS を中心とする価値提供を取りつつ、 対話的 / Collaborating な価値提供の選択肢も取る ※一部抜粋（一部黒塗） （例）各アプリケーションの リソース利用率可視化と最適値の提案 Collaboration Platform team Developer team … …
44. © Recruit Co., Ltd. All Rights Reserved 44 過度なプロダクト品質の提供 • 依頼をなんでも対応してしまうと運営 体制のキャパシティを超えて、継続 的な改善に取り組む余裕がなくなる • 変更失敗の許容範囲が小さくなり、 継続的な改善 / 素早い改善が難しく なる • 責任境界モデルを定義し、問題発生 時に Platform team が対応すること / 対応しないことをサービスレベルに 明文化する ◦ ソフトな境界設定 • 適切な SLI/SLO を定義し、エラーバ ジェットに基づいた積極的な変更を 心がける 起きうる事象 対応 / 考え方
45. © Recruit Co., Ltd. All Rights Reserved 具体事例: 責任分解モデル・SLO 運用 チーム間の責任境界や SLO 定義/稼働状況などもドキュメントに公開 適度なプロダクト品質の下で、効率的な開発を維持する ※一部抜粋 ※一部抜粋
46. Google Cloud 04 おわりに 46
47. © Recruit Co., Ltd. All Rights Reserved 47 Key Takeaways 文化/マインドを変化させる仕組みを生み出せる Platform Engineering はプロダクト進化の硬直リスクを孕んでいる Platform Engineering は開発生産性に寄与する文化/マインドに変 化をもたらす 単に開発生産性を向上させるだけではない 持続的な進化の実現に向けて運営設計する 運営方式を誤ると進化を阻害する結果に繋がる ❶ ❷
48. © Recruit Co., Ltd. All Rights Reserved 48 今取り組みを進めている新たな挑戦 Software delivery performance, 　 Operational performance から Productivity & 　 Organizational performanceへ 高い生産力を維持したまま、さらに生産効率の高い組織へ変革する
49. © Recruit Co., Ltd. All Rights Reserved 49 Developer team による Self-service にコスト改善できる仕組みを構築 • Developer team 毎の従量課金設計/請求 • Developer team へのコストダッシュボード 提供 • Platform によるコスト最適化の自動提案 / 自動反映 • etc. Cost Dashboard の一部抜粋（黒塗） この例ではプロジェクト毎にコスト分析できる
50. Google Cloud 　　【宣伝】8/2 15:00 - 15:30 Google Cloud Next Tokyo ‘24 にて チームメンバーより IDP における FinOps の取り組みを紹介 https://cloudonair.withgoogle.com/events/next-tokyo-24?talk=d2-inf-02
51. © Recruit Co., Ltd. All Rights Reserved ご清聴ありがとうございました！ 51