$30 off During Our Annual Pro Sale. View Details »

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

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

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

zawa_zawa0210

June 29, 2024
Tweet

Other Decks in Programming

Transcript

  1. 前半:自己紹介 • Platform Engineering Meetup 運営 ◦ 「Real World Platform Engeening」共著

    • 株式会社野村総合研究所(NRI) エキスパート ◦ 生産性向上プラットフォームブランド ◦ コンテナ、CI/CD、生成AIを扱う 開発領域のプロダクトを担当 井沢 祐介
  2. 前半:Platform Engineeringの動向 • Platform Engineeringとは ◦ 生まれた背景 ◦ 構成要素 •

    Platform Engineeringの普及 ◦ コミュニティ動向 ◦ ベンダ動向
  3. Platform Engineeringが生まれた背景 学習関連(Germane) 認知負荷 内在的(Intrinsic) 認知負荷 認知負荷(Cognitive Load)について 外在的(Extraneous) 認知負荷

    情報を認識するまでの負荷  ・不要なノイズ  ・テキストや音声といったフォーマット対応 情報を理解する負荷  ・学習対象の難易度そのもの 情報を長期化する負荷  ・分割し、順序、関連性を持たせる
  4. Platform Engineeringが生まれた背景 オンプレミス+仮想マシン時代は、認知負荷が比較的低く課題にならなかった 学習関連(Germane) 認知負荷 内在的(Intrinsic) 認知負荷 ネットワーク 仮想化技術 サーバ

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

    インフラ/ミドルウェアの設計 ミドルウェア アプリケーションの設計 ライブラリ プログラミング言語 公式ドキュメント OSS 配信動画 フォークされたOSS 大量生産された解説ブログ チャットAI クラウド コンテナ CI/CD クラウド設計 CI/CD設計 コンテナ設計 外在的(Extraneous) 認知負荷
  6. Platform Engineeringが生まれた背景 あなたのチームは、スーパーマン頼りになっていませんか? 学習関連(Germane) 認知負荷 内在的(Intrinsic) 認知負荷 ネットワーク 仮想化技術 サーバ

    インフラ/ミドルウェアの設計 ミドルウェア アプリケーションの設計 ライブラリ プログラミング言語 クラウド コンテナ CI/CD クラウド設計 CI/CD設計 コンテナ設計 アプリケーション以外の一切合切をやってくれる =その人がいないと開発が止まる 外在的(Extraneous) 認知負荷
  7. 個人的な経験からのPlatformの優先度 プロダクトであること ドキュメントがあること 認知負荷の削減 UXを考えること セルフサービスであること オプションであること デフォルトで安全であること スケール  ・社内標準になったら耐えられるか

    プロダクトマーケットフィット  ・開発者の課題を解決するか  ・最小限の開発で試行できるか ユーザ体験の向上  ・利用することで逆に   認知負荷は増えないか
  8. 抽象化した機能の提供 Platform Engineeringの提供機能 Cloud Native版 https://tag-app-delivery.cncf.io/whitepapers/platforms/ より和訳 プロダクトチーム プラットフォームチーム インター フェース

    提供 機能 ドキュメント GUI (ポータル) プロジェクトテンプレート APIとCLI 環境とリソースの提供 インフラリソース データ保管 メッセージング ID管理と認証 CI/CD サービス連携 成果物管理 セキュリティ 可観測性
  9. 前半:Platform Engineeringの動向 • Platform Engineeringとは ◦ 生まれた背景 ◦ 構成要素 •

    Platform Engineeringの普及 ◦ コミュニティ動向 ◦ ベンダ動向
  10. プラットフォーム提供ベンダ動向 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
  11. © Recruit Co., Ltd. All Rights Reserved 23 Speaker  

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

    02 03 04 リクルートにおける          横断データ プロダクトの事例紹介 Platform Engineering は組織にどのような変 化をもたらしたか Platform Engineering におけるリスク要因と 対応 おわりに
  13. © Recruit Co., Ltd. All Rights Reserved 25 Key Takeaways

    文化/マインドを変化させる仕組みを生み出せる Platform Engineering はプロダクト進化の硬直リスクを孕んでいる Platform Engineering は開発生産性に寄与する文化/マインドに変 化をもたらす 単に開発生産性を向上させるだけではない 持続的な進化の実現に向けて運営設計する 運営方式を誤ると進化を阻害する結果に繋がる ❶ ❷
  14. © 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 を運営 担当プロダクト範囲
  15. © 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 時点
  16. © Recruit Co., Ltd. All Rights Reserved 本セッションではプロダクト詳細は割愛します Platform Engineering

    Meetup #6 にて詳しく説明しているのでこちらの資料をご参照ください https://speakerdeck.com/recruitengineers/platformengineeringmeetup_suganuma
  17. Google Cloud Platform team のマインド変化 Developer team のマインド変化 30 02

    Platform Engineering は組織にどのような変化をもたらしたか
  18. © Recruit Co., Ltd. All Rights Reserved 31 Platform team

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

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

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

    のマインド変化 委託気質な開発から 自律的な開発へ 顧客志向から パートナー志向へ 01 02 Platform team と相互扶助的に改善を積み重ねる Developer team がアプリケーション品質のオーナーシップを持つ
  22. © 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 を実践できる環境を提供
  23. © Recruit Co., Ltd. All Rights Reserved 36 Platform team

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

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

    におけるリスク要因 Developer team への利用強制 Developer team 要望への盲信 過度なプロダクト品質の提供 01 02 03
  26. © Recruit Co., Ltd. All Rights Reserved 40 Developer team

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

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

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

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

    チーム間の責任境界や SLO 定義/稼働状況などもドキュメントに公開 適度なプロダクト品質の下で、効率的な開発を維持する ※一部抜粋 ※一部抜粋
  32. © Recruit Co., Ltd. All Rights Reserved 47 Key Takeaways

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

    delivery performance,   Operational performance から Productivity &   Organizational performanceへ 高い生産力を維持したまま、さらに生産効率の高い組織へ変革する
  34. © Recruit Co., Ltd. All Rights Reserved 49 Developer team

    による Self-service にコスト改善できる仕組みを構築 • Developer team 毎の従量課金設計/請求 • Developer team へのコストダッシュボード 提供 • Platform によるコスト最適化の自動提案 / 自動反映 • etc. Cost Dashboard の一部抜粋(黒塗) この例ではプロジェクト毎にコスト分析できる
  35. 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