Google Cloudで始めるプラットフォームエンジニアリング

by Kento.Yamada

Slide 1

Slide 1 text

Google Cloudで始めるプラットフォームエンジニアリング 1

Slide 2

Slide 2 text

● 自己紹介 ● 宣伝 ● プラットフォームエンジニアリングとは ○ 背景 ○ （要約）プラットフォームエンジニアリング ○ 補足：プラットフォームエンジニアリングの誤解 ● プラットフォームエンジニアリングの取り組み ○ やること ○ ユーザーにヒアリングして問題を見つける ○ プラットフォームを製品として扱う ○ プラットフォームチームを作る話すこと 2 ● Google Cloudでプラットフォームエンジニアリング ○ 公式ブログによると ○ つまりどういうこと ○ 補足：認知負荷（Cognitive load）とは ○ Modern App Summitによると ● どのように実装すれば良いのか ○ ⚪⚪⚪で実装しないといけないのか ● おひとり様プラットフォームエンジニアリング ○ チームを作る前に個人でできることを探る ○ 実際に困っていたこと ○ 活用できそうなサービスを模索 ○ 生成AIを活用することを想定してやってみた ○ 効果測定 ● まとめ

Slide 3

Slide 3 text

自己紹介 3 Kento.Yamada ● クラウドの運用分析・MSP向けのプラットフォームの開発と提供・新しいサービスの検証 ● github＠ymd65536 ● 受賞歴 ○ Microsoft MVP for Developer Technologies（2024年〜） ○ Google Cloud Partner Tech Blog Challenge 2023 Cloud AI/ML 部門受賞 ○ LAPRAS OUTPUT AWARD 2024 01

Slide 4

Slide 4 text

4 宣伝1 技術書典16に出典しました。 PagerDutyを使っている7人が思いのたけをぶちまけた作品！ PagerDuty FANBOOK Vol.1

Slide 5

Slide 5 text

5 宣伝2 社内のメンバーで書きました。 AWSの認定資格対策本というヤツです。 AWS認定高度なネットワーキングー専門知識(ANS-C01) 完全対応テキスト

Slide 6

Slide 6 text

プラットフォームエンジニアリングとは 6

Slide 7

Slide 7 text

“自分で作ったものは自分で運用する” というアプローチは、複雑な現代のソフトウェアスタックではもはや実現不可能 7

Slide 8

Slide 8 text

背景 8 求められている技術スタック・概念が多い。複雑化！

Slide 9

Slide 9 text

背景 9 求められている技術スタック・概念が多い。幅広い専門分野における熟練した技術が必要コンテナネットワークセキュリティ DevOps 仮想化クラウド CI/CD マイクロサービス AI 機械学習 IaC DR対応データベースデータ分析 QA 設計マネジメント自動テスト可用性

Slide 10

Slide 10 text

背景 10 技術が増えると生産性が上がるかというと…そうでもない生産性要因：学習コストの増加、役割の多様化、コミュニケーションコストの増加技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術

Slide 11

Slide 11 text

背景 11 技術が増えると生産性が上がるかというと…そうでもない生産性つまりは認知負荷が高いので生産性が下がっている！技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術

Slide 12

Slide 12 text

補足：認知負荷（Cognitive load）とは認識における脳の負荷のこと 12

Slide 13

Slide 13 text

認知負荷（Cognitive load）とは認識における脳の負荷のこと 13 課題外在性負荷 👉

Slide 14

Slide 14 text

認知負荷（Cognitive load）とは認識における脳の負荷のこと 14 課題外在性負荷課題内在性負荷 👉

Slide 15

Slide 15 text

認知負荷（Cognitive load）とは認識における脳の負荷のこと 15 課題外在性負荷課題内在性負荷学習関連負荷 👉

Slide 16

Slide 16 text

補足：認知負荷にまつわる話 16 課題に着手するまでに20秒以上経過してしまうと人はその課題をやらなくなってしまう。 20秒以内 20秒以上ある意味で認知負荷が高い状態ある意味で認知負荷が低い状態

Slide 17

Slide 17 text

背景 17 人を増やして生産性を上げればイイかというとなかなかそうもいかない！コスト

Slide 18

Slide 18 text

コスト認知負荷背景 18 そもそも認知負荷が高いことが原因なので人を増やすのは逆効果そして、必ずしも生産性が上がるとは限らない。

Slide 19

Slide 19 text

背景 19 認知負荷を下げつつ、生産性を上げる方法としてプラットフォームエンジニアリングが生まれた。「みんなで共通プラットフォームを構築して生産性を上げていこうぜ」という取り組み簡単にいえば 👉プラットフォームエンジニアリング

Slide 20

Slide 20 text

（要約）プラットフォームエンジニアリングとは 20 プラットフォームエンジニアリングの活動は組織の大きさを問わない。内部開発者の負担が軽減される活動内部開発者のエクスペリエンスを向上させる活動サービスを提供するまでにかかる時間を最小限にする活動

Slide 21

Slide 21 text

補足：プラットフォームエンジニアリングの誤解 21 Web検索でだいたいの情報は出てくる。それこそAIに聞けば、生産性の問題は解決できるのでは？組織内で標準化されたベストプラクティスを簡単に利用できるようにしていく活動 ※組織内で標準化されたベストプラクティスを教えてくれる社内GPTがいる場合はさておき

Slide 22

Slide 22 text

プラットフォームエンジニアリングの取り組み 22

Slide 23

Slide 23 text

やること 23 ユーザーにヒアリングして問題を見つけるプラットフォームを製品として扱うプラットフォームチームを作る

Slide 24

Slide 24 text

ユーザー（内部開発者）にヒアリングして問題を見つける問題となっていることを見つけるために内部開発者にヒアリングする。 ● 内部開発者の要望を理解して課題とする課題を解決するプロダクトを開発する。（次のページ） 24 内部開発者プラットフォームエンジニアイイカンジに自動化したい承知

Slide 25

Slide 25 text

プラットフォームを製品として扱う ● MVPにプラットフォームを作成してプラットフォームを製品として扱う ● 内部開発者を顧客として見て、継続して利用したいと思えるものを開発する 25 プラットフォームエンジニア内部開発者実際に開発者のエクスペリエンスが向上するように継続的にヒアリングを行う。どれくらい活用しているかを計測して効果を見る。

Slide 26

Slide 26 text

プラットフォームチームを作るストリームアラインドチームを支えるプラットフォームチームを作る。（このときプラットフォームチームの目的を明確にします。） ※ストリームアラインドチーム：製品をリリースするチームのこと ※プラットフォームチーム：Platform as Productと定めて運用するチーム 26 プラットフォームチームストリームアラインドチームポータルプラットフォーム運用保守 TVP 利用 {

Slide 27

Slide 27 text

Google Cloudでプラットフォームエンジニアリングをやりたい 27

Slide 28

Slide 28 text

公式ブログによると 28 道を照らす: プラットフォームエンジニアリング、ゴールデンパス、セルフサービスのパワー https://cloud.google.com/blog/ja/products/application-development/golden-paths-for-engineering-execution-consistency

Slide 29

Slide 29 text

つまりどういうこと 29 ポイント組織で使っているツールをまとめながら役立つこと、ベストプラクティスを抽象化する。 ● 内部開発者（デベロッパー）の生産性が低下しないようにする ● 内部開発者（デベロッパー）が燃え尽きないようにする ● 内部開発者（デベロッパー）の認知負荷を上げないようにする

Slide 30

Slide 30 text

30 実は今年の3月に開催されたModern App Summit Tokyo '24でプラットフォームエンジニアリングについて紹介されています。 Modern App Summit Tokyo '24 Track2によると

Slide 31

Slide 31 text

31 ※Platform Engineering Kaigiにも登壇されます。 https://www.cnia.io/pek2024/sessions/eedb9b5a-ef54-4fee-bea9-eeed6e98160d/ Modern App Summit Tokyo '24 Track2によると

Slide 32

Slide 32 text

32 Modern App Summit Tokyo '24 Track2によると ● 舗装された道路（ゴールデンパス）を使う（この道を歩めば誰でもできる） ● プラットフォームを製品として扱う（内部開発者にとってはプロダクト） ● ユーザーにヒアリングをして何が必要か調査する（ヒアリングが重要） ● ガバナンスとガードレールを敷く（ルールの逸脱を防ぐ） ● 各種PaaSを活用する（利用を強制するものではない）以下をポータルで提供する（セルフサービスUXの提供） ● プロビジョニングの自動化 ● アプリケーションのテンプレート

Slide 33

Slide 33 text

33 ガバナンスとガードレールを敷く（ルールの逸脱を防ぐ）開発者ポリシーポリシー開発者組織のポリシーを逸脱してしまわないようにゴールデンパスにはガードレールを設置する。 👉内部開発者が利用するゴールデンパスにはガードレールが含まれる。

Slide 34

Slide 34 text

各種PaaSを活用する（利用を強制するものではない） 34 ● GAE ● CloudRun ● Google Kubernetes Engine（GKE） 👉“PaaSを使いなさい”というプラクティスではない 👉“PaaSを使う”ことは認知を負荷を下げるアプローチの1つ

Slide 35

Slide 35 text

どのように実装すれば良いのか 35

Slide 36

Slide 36 text

GKEで実装しないといけないのか 36 プラットフォームエンジニアリングの実装として GKEはオーバースペックなのでは？ GKEで PFEやってよ GKE ナニモワカラナイコンテナの実際の使用に関する 10 のインサイト https://www.datadoghq.com/ja/container-report/

Slide 37

Slide 37 text

おひとり様プラットフォームエンジニアリング 37

Slide 38

Slide 38 text

チームを作る前に個人でできることを探る 38 ● まわりが困っていること以前に個人的に面倒だと感じていることはないか ● 個人的に面倒だと感じていることをMVPで作成してチームに展開できないか 👉「認知負荷を下げる取り組みとして何かできないか」を探す

Slide 39

Slide 39 text

（実は）そもそも実際に困っていたこと 39 生成AIを使ったアプリケーションを構築することになったものの何があれば、目的のものを開発できるのかわからない状態 👉開発環境は？（すぐに修正できる？機能追加は容易？） 👉フレームワークの使い方は覚えてる？ 👉どのようにデプロイする？ ※社内にはPrisma Accessを導入しているのでそれを踏まえた環境整備

Slide 40

Slide 40 text

活用できそうなサービスを探る 40 プラットフォームエンジニアリングに利用できそうなものを探る（一部） ● Apigee ● CloudRun ● Cloud Functions ● CloudWorkstations ● Vertex AI Workbench マネージドノートブックを使うと幸せになれそう！ Google CloudでAIと言ったらVertex AI Workbench

Slide 41

Slide 41 text

生成AIを活用することを想定してやってみた 41 Cloud Run Artifact Registry Vertex AI Workbench マネージドノートブックコンテナイメージをpull コマンド送信イメージのプッシュ SSHで接続

Slide 42

Slide 42 text

効果測定一番大きな変化：機能追加・障害時にとりあえずノートブックを開くというアクションに統一できたこと ● 最小限のポリシーをもったサービスアカウントを使う ○ ベストプラクティスに従ったRBAC（ガードレール） ● マネージドノートブック自体がコンテナイメージ ○ カスタムして利用することも可能（開発者テンプレートの提供） ● README.mdで作業手順をノートブック内に置く ○ 何をしたら良いかの判断に迷わない（認知負荷低減） 42

Slide 43

Slide 43 text

まとめ ● プラットフォームエンジニアリングは認知負荷を下げつつ、生産性を上げる活動のこと ○ 定義はさまざまだが、PaaSを導入することではない ● Google Cloudのイベントを含め、資料を見た ○ プラットフォームエンジニアリングは特定のベンダーに依存しないもの ● プラットフォームエンジニアリングの取り組み ○ ユーザーにヒアリングして問題を見つける ○ プラットフォームを製品として扱う ○ プラットフォームチームを作る ● Google Cloudにはさまざまなサービスがある ● GKEで実装することも可能だが、Vertex AI Workbenchでも可能 ○ 実際にやってみたら、それなりに良い結果が出たのでチームに広めたい（気持ちだけ） 43