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

by zawa_zawa0210

Slide 1

Slide 1 text

プラットフォームエンジニアリングを普及と実践し続けて見えてきた利点とリスク開発生産性カンファレンス2024

Slide 2

Slide 2 text

このセッションについて開発生産性を向上させるアプローチPlatform Engineeringについて、動向と実践の両面から学べる２部制のセッションです。

Slide 3

Slide 3 text

前半：自己紹介 ● Platform Engineering Meetup　運営 ○ 「Real World Platform Engeening」共著 ● 株式会社野村総合研究所(NRI)　エキスパート ○ 生産性向上プラットフォームブランド ○ コンテナ、CI/CD、生成AIを扱う開発領域のプロダクトを担当井沢　祐介

Slide 4

Slide 4 text

前半：Platform Engineeringの動向 ● Platform Engineeringとは ○ 生まれた背景 ○ 構成要素 ● Platform Engineeringの普及 ○ コミュニティ動向 ○ ベンダ動向

Slide 5

Slide 5 text

Platform Engeneeringとは DevOpsの実践において、開発者の生産性を高めるためのアプローチ。 1. 開発者の認知負荷を下げる機能がセルフサービスで利用できる 2. アプリケーションの迅速な開発とデリバリーを可能にする。 3. プラットフォーム自体もプロダクトとして、継続的に改善・発展されるプラットフォーム　v1 抽象化された機能実際の実装抽象化された機能実際の実装プラットフォーム v2 プラットフォームチームプロダクトチームアプリケーション

Slide 6

Slide 6 text

Platform Engineeringが生まれた背景学習関連(Germane) 認知負荷内在的(Intrinsic) 認知負荷認知負荷(Cognitive Load)について外在的(Extraneous) 認知負荷情報を認識するまでの負荷　・不要なノイズ　・テキストや音声といったフォーマット対応情報を理解する負荷　・学習対象の難易度そのもの情報を長期化する負荷　・分割し、順序、関連性を持たせる

Slide 7

Slide 7 text

Platform Engineeringが生まれた背景オンプレミス＋仮想マシン時代は、認知負荷が比較的低く課題にならなかった学習関連(Germane) 認知負荷内在的(Intrinsic) 認知負荷ネットワーク仮想化技術サーバインフラ/ミドルウェアの設計ミドルウェアアプリケーションの設計ライブラリプログラミング言語公式ドキュメント OSS 外在的(Extraneous) 認知負荷

Slide 8

Slide 8 text

Platform Engineeringが生まれた背景 CloudNativeな構成へシフト、インプット情報も多様化し認知負荷が増大学習関連(Germane) 認知負荷内在的(Intrinsic) 認知負荷ネットワーク仮想化技術サーバインフラ/ミドルウェアの設計ミドルウェアアプリケーションの設計ライブラリプログラミング言語公式ドキュメント OSS 配信動画フォークされたOSS 大量生産された解説ブログチャットAI クラウドコンテナ CI/CD クラウド設計 CI/CD設計コンテナ設計外在的(Extraneous) 認知負荷

Slide 9

Slide 9 text

Platform Engineeringが生まれた背景あなたのチームは、スーパーマン頼りになっていませんか？学習関連(Germane) 認知負荷内在的(Intrinsic) 認知負荷ネットワーク仮想化技術サーバインフラ/ミドルウェアの設計ミドルウェアアプリケーションの設計ライブラリプログラミング言語クラウドコンテナ CI/CD クラウド設計 CI/CD設計コンテナ設計アプリケーション以外の一切合切をやってくれる＝その人がいないと開発が止まる外在的(Extraneous) 認知負荷

Slide 10

Slide 10 text

認知負荷を軽減するためのPlatformの構想 https://tag-app-delivery.cncf.io/whitepapers/platforms/　参考プロダクトであること…チームにより継続的に改善が行われるドキュメントがあること...設定例など、ユーザのニーズに応じたものを認知負荷の削減...抽象化して機能を提供する UXを考えること...ポータル/API/GUI/IDE/CLIなど最適な提供方法を考えるセルフサービスであること...依頼を受けて人が動く運用を避けるオプションであること...必要な機能を一部のみ使用可能デフォルトで安全であること...組織のルールに基づくことを保証する

Slide 11

Slide 11 text

個人的な経験からのPlatformの優先度プロダクトであることドキュメントがあること認知負荷の削減 UXを考えることセルフサービスであることオプションであることデフォルトで安全であることスケール　・社内標準になったら耐えられるかプロダクトマーケットフィット　・開発者の課題を解決するか　・最小限の開発で試行できるかユーザ体験の向上　・利用することで逆に　　認知負荷は増えないか

Slide 12

Slide 12 text

Platform Engineeringによる認知負荷の削減学習関連(Germane) 認知負荷内在的(Intrinsic) 認知負荷 Platformの各要素が開発者の認知負荷削減に寄与見るべき情報をあらかじめ整理　・ドキュメントやポータル理解が必要な情報を削減　・抽象化された機能の提供機能間の関連性も示す　・推奨構成(Golden Path)を　　プロジェクトテンプレートで提供外在的(Extraneous) 認知負荷

Slide 13

Slide 13 text

抽象化した機能の提供 Platform Engineeringの提供機能　Cloud Native版 https://tag-app-delivery.cncf.io/whitepapers/platforms/ より和訳プロダクトチームプラットフォームチームインターフェース提供機能ドキュメント GUI (ポータル) プロジェクトテンプレート APIとCLI 環境とリソースの提供インフラリソースデータ保管メッセージング ID管理と認証 CI/CD サービス連携成果物管理セキュリティ可観測性

Slide 14

Slide 14 text

Platform Engineeringの提供機能　NRI aslead事例

Slide 15

Slide 15 text

前半：Platform Engineeringの動向 ● Platform Engineeringとは ○ 生まれた背景 ○ 構成要素 ● Platform Engineeringの普及 ○ コミュニティ動向 ○ ベンダ動向

Slide 16

Slide 16 text

海外コミュニティ動向 2021年より活動が現れ、2022年に本格化 2021年 1月　世界で28箇所でコミュニティ活動が開始 2022年 2月　専門組織PlatformEngineering.orgが設立 2022年 6月～　カンファレンスPlatformCon2022が開催 (以降、毎年開催) https://platformengineering.org/about　より

Slide 17

Slide 17 text

Platform Con 2024 https://platformcon.com/talks　より集計トーク説明文のワードクラウド集計

Slide 18

Slide 18 text

国内コミュニティ動向 2023年 3月　日本コミュニティ Platform Engineering Meetupが開始 #4 FUKUOKA #3 NAGOYA #8 KANSAI TOKYO

Slide 19

Slide 19 text

プラットフォーム提供ベンダ動向 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

Slide 20

Slide 20 text

一般ユーザ動向 2023年末より日本でも少し認知はされ始めたが、普及はまだまだこれから https://trends.google.co.jp/trends/explore?date=today%205-y&q=Platform%20Engineering&hl=ja　より

Slide 21

Slide 21 text

Platform Engineering Kaigi 2024の初開催参加申し込みはこちら↓↓

Slide 22

Slide 22 text

Google Cloud 00 [後半パート] Platform Engineering の利点とリスクを事例を交えながらお話しします 22 リクルートにおける横断データプロダクトの事例紹介 Platform Engineering は組織にどのような変化をもたらしたか Platform Engineering におけるリスクと対応

Slide 23

Slide 23 text

© Recruit Co., Ltd. All Rights Reserved 23 Speaker 　菅沼孝二社会人歴 8 年目所属　　　　　株式会社リクルート　データ推進室最近の出来事二児の父（共働き運用開始で大変、継続的改善を心がける）好きなサービス Kubernetes Engine, Cloud Logging, IAM 肩書　　　　　プロダクトテックリード 2016 年 - 新卒メディア・ゲーム・広告関連事業会社広告データ収集基盤開発・広告効果モデリング 2017 年 - 中途株式会社リクルートライフスタイルデータ分析・ML モデリング・実装 / データプラットフォーム開発・ SRE 2021 年 - （統合）株式会社リクルートデータプラットフォーム開発・ SRE

Slide 24

Slide 24 text

Slide 25

Slide 25 text

© Recruit Co., Ltd. All Rights Reserved 25 Key Takeaways 文化/マインドを変化させる仕組みを生み出せる Platform Engineering はプロダクト進化の硬直リスクを孕んでいる Platform Engineering は開発生産性に寄与する文化/マインドに変化をもたらす単に開発生産性を向上させるだけではない持続的な進化の実現に向けて運営設計する運営方式を誤ると進化を阻害する結果に繋がる ❶ ❷

Slide 26

Slide 26 text

Google Cloud 01 リクルートにおける横断データプロダクトの事例紹介 26 担当プロダクトの役割・位置付け担当プロダクトにおける各種指標

Slide 27

Slide 27 text

© 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 を運営担当プロダクト範囲

Slide 28

Slide 28 text

© 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 時点

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Google Cloud Platform team のマインド変化 Developer team のマインド変化 30 02 Platform Engineering は組織にどのような変化をもたらしたか

Slide 31

Slide 31 text

© Recruit Co., Ltd. All Rights Reserved 31 Platform team のマインド変化 Platform as a Software から Platform as a Product へ多様な価値提供から持続的な価値提供へ 01 02 重要な課題を解決できる最小のセルフサービス化（Thinnest Vaible Platform）ツール・プロセス・チームの全スコープで戦略的に運営する

Slide 32

Slide 32 text

© Recruit Co., Ltd. All Rights Reserved 32 プロダクトとして運営する ● 事業戦略・横断組織戦略に基づいた優先度で期初開発計画を策定 ● 随時ユーザーサポートやユーザーフィードバックの収集/分析 ● 期初計画の消化ではなくユーザーへのアウトカムを最大化するため、期中に開発計画を柔軟に修正 ● これらを繰り返し、継続的に改善 [引用] thematic https://getthematic.com/insights/feedback-loops-for-customer-experience/

Slide 33

Slide 33 text

© Recruit Co., Ltd. All Rights Reserved 33 持続的に価値提供できる仕組みを設計する ● 担当している Platform が解決すべき問題や開発すべき技術にフォーカスする ○ そうでない問題解決は別 Team や Developer 側に委譲 ○ マネージドサービスを積極採用 ● SLO / Error budget に基づいた運用により、頻繁かつチャレンジングな変更を継続 ● 必要十分なドキュメンテーション整備と継続的なアップデートにより属人性排除 Reference: What is a Thinnest Viable Platform (TVP)? — Team Topologies

Slide 34

Slide 34 text

Slide 35

Slide 35 text

© 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 を実践できる環境を提供

Slide 36

Slide 36 text

© Recruit Co., Ltd. All Rights Reserved 36 Platform team と Developer team の相互扶助的な改善 ● Developer team からの継続的なフィードバック ● Platform team / Developer team の協業による性能改善 ● Platform team / Developer team の協業による技術的負債の解消

Slide 37

Slide 37 text

© Recruit Co., Ltd. All Rights Reserved 37 Platform Engineering による主な変化と考察委託気質な開発から自律的な開発へ顧客志向からパートナー志向へ Platform as a Software から Platform as a Product へ多様な価値提供から持続的な価値提供へ Platform team のマインド変化 Developer team のマインド変化決して Platform の導入によってすぐに変化できた訳ではない地道な対話と改善を積み重ねた結果、文化として定着した

Slide 38

Slide 38 text

Google Cloud Developer team への利用強制 Developer team 要望への盲信過度なサービス品質の提供 03 Platform Engineering におけるリスク要因と対応 38

Slide 39

Slide 39 text

Slide 40

Slide 40 text

© Recruit Co., Ltd. All Rights Reserved 40 Developer team への利用強制 ● 使われている理由が強制によるものなのか、良いプロダクトであるからなのか、評価しづらくなる ● 「使われない」理由を獲得できなくなる ● 結果として使いづらいプロダクトに繋がりうる ● プラットフォームの利用を強制するのではなく、利用を提案する ○ 導入判断は Developer 側 ● プラットフォームの利用が最適であると意思決定してもらえるものを目指す ○ 内部ニーズの変化と外部ツールの変化に常に追従起きうる事象対応 / 考え方

Slide 41

Slide 41 text

© Recruit Co., Ltd. All Rights Reserved 41 具体事例: 「使われない」理由のフィードバックプラットフォームへの機能改善要望が実現するまでのリードタイムを長くする構造上の要因がある ● 全体への効果見立てで開発優先度を設計するため、特定チーム固有の要望に対応しづらい ● 変更影響が大きく、ダイナミックな打ち手が取りにくい ● 組織跨ぎによるコミュニケーションリードタイムが生じる要望発生要望整理打ち手検討 Developer team Platform team やるやら議論要望の解像度を上げる打ち手検討（全体影響考慮）開発計画開発受け入れテスト組織跨ぎによるコミュニケーションリードタイム発生特定チーム固有の要望に対応しづらい変更影響が大きい場合は、ダイナミックな打ち手が取れない利用開始 Platform team としては、その設計・構築を一部支援しつつ、その協業の中で得られる汎化可能な知見や機能を Platform に反映するなどの打ち手を検討しています。これらの課題に対して、Developer team では固有の要件・ニーズ・開発効率を満たすための「独自基盤」を設計・構築する方針が採用されました。

Slide 42

Slide 42 text

© Recruit Co., Ltd. All Rights Reserved 42 Developer team 要望への盲信 ● ユーザーの機能要望に全て応えていくことで、運用保守コストが高いプロダクトになったり、一貫性がなく複雑性が増して変更容易性が下がってしまう ● ユーザー自身が自分の本当に有用な機能を認識できていないケースもありうる ● 担当プロダクトが果たすべき役割に基づいて、重要な課題を解決できる最小の機能を提供する ○ Thinnest Viable Platform ● 受動的なフィードバックによる課題整理だけでなく、能動的な課題探索も取り入れる ○ 積極的な利用者への関与起きうる事象対応 / 考え方

Slide 43

Slide 43 text

© 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 … …

Slide 44

Slide 44 text

© Recruit Co., Ltd. All Rights Reserved 44 過度なプロダクト品質の提供 ● 依頼をなんでも対応してしまうと運営体制のキャパシティを超えて、継続的な改善に取り組む余裕がなくなる ● 変更失敗の許容範囲が小さくなり、継続的な改善 / 素早い改善が難しくなる ● 責任境界モデルを定義し、問題発生時に Platform team が対応すること / 対応しないことをサービスレベルに明文化する ○ ソフトな境界設定 ● 適切な SLI/SLO を定義し、エラーバジェットに基づいた積極的な変更を心がける起きうる事象対応 / 考え方

Slide 45

Slide 45 text

Slide 46

Slide 46 text

Google Cloud 04 おわりに 46

Slide 47

Slide 47 text

© Recruit Co., Ltd. All Rights Reserved 47 Key Takeaways 文化/マインドを変化させる仕組みを生み出せる Platform Engineering はプロダクト進化の硬直リスクを孕んでいる Platform Engineering は開発生産性に寄与する文化/マインドに変化をもたらす単に開発生産性を向上させるだけではない持続的な進化の実現に向けて運営設計する運営方式を誤ると進化を阻害する結果に繋がる ❶ ❷

Slide 48

Slide 48 text

Slide 49

Slide 49 text

© Recruit Co., Ltd. All Rights Reserved 49 Developer team による Self-service にコスト改善できる仕組みを構築 ● Developer team 毎の従量課金設計/請求 ● Developer team へのコストダッシュボード提供 ● Platform によるコスト最適化の自動提案 / 自動反映 ● etc. Cost Dashboard の一部抜粋（黒塗）この例ではプロジェクト毎にコスト分析できる

Slide 50

Slide 50 text

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