第138回 雲勉 Google Cloudではじめるプラットフォームエンジニアリング

下記、勉強会での資料です。
https://youtu.be/dCpElhPi1gI

Transcript

1. 第138回 雲勉【オンライン】 
 Google Cloudではじめる 
 プラットフォームエンジニアリング 

2. 話すこと 2 • 自己紹介 • 宣伝 • プラットフォームエンジニアリングとは ◦ 背景 ◦ 補足：認知負荷（Cognitive load）とは ◦ 背景（話を戻して） ◦ （要約）プラットフォームエンジニアリング ◦ 補足：プラットフォームエンジニアリングに対する誤解 • プラットフォーム エンジニアリングの取り組み ◦ やること ◦ ユーザーにヒアリングして問題を見つける ◦ プラットフォームを製品として扱う ◦ プラットフォームチームを作る • Google Cloudでプラットフォームエンジニアリング ◦ 公式ブログによると ◦ つまりどういうこと ◦ Modern App Summitによると • どのように実装すれば良いのか ◦ ⚪⚪⚪で実装しないといけないのか • お一人様プラットフォームエンジニアリング ◦ チームを作る前に個人でできることを探る ◦ 実際に困っていたこと ◦ 活用できそうなサービスを模索 ◦ 生成AIを活用することを想定してやってみた ◦ 効果測定（定性的に） • まとめ
3. 自己紹介 3 経歴 • 2022年10月～現在 アイレット株式会社 MSP開発セクション • （2016年～2022年9月）某通信キャリアの子会社 ITスペシャリスト 直近の実績 • Microsoft MVP for Developer Technologies（2024年〜） • 2024年3月 LAPRAS OUTPUT AWARD • 2024年2月 Google Cloud Partner Tech Blog Challenge 2023 Cloud AI/ML部門 github,zenn,Qiita,X（旧Twitter）,Facebook＠ymd65536
4. 宣伝 4 技術書典16に頒布しました。 PagerDutyを使っている 7人が思いのたけをぶちまけた作品！ PagerDuty FANBOOK Vol.1
5. 宣伝 5 社内のメンバーで書きました。 AWSの認定資格対策本というヤツです。 AWS認定 高度なネットワーキングー専門知識 (ANS-C01) 完全対応テキスト
6. 6 プラットフォームエンジニアリングとは
7. 7 “自分で作ったものは自分で運用する ” というアプローチは、複雑な現代の ソフトウェア スタックではもはや実現不可能
8. 背景 8 求められている技術スタック・概念が多い。複雑化！
9. 背景 9 求められている技術スタック・概念が多い。幅広い専門分野における熟練した技術が必要 コンテナ ネットワーク セキュリティ DevOps 仮想化 クラウド CI/CD マイクロサービス AI 機械学習 IaC DR対応 データベース データ分析 QA 設計 マネジメント 自動テスト 可用性
10. 背景 10 技術が増えると生産性が上がるかというと…そうでもない 生産性 要因：学習コストの増加、役割の多様化、コミュニケーションコストの増加 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術
11. 背景 11 技術が増えると生産性が上がるかというと…そうでもない 生産性 つまりは認知負荷が高い ので生産性が下がっている！ 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術
12. 補足：認知負荷（ Cognitive load）とは 12 認識における脳の負荷のこと
13. 補足：認知負荷（ Cognitive load）とは 13 認識における脳の負荷のこと 課題外在性負荷 👉
14. 14 認識における脳の負荷のこと 課題外在性負荷 課題内在性負荷 👉 補足：認知負荷（ Cognitive load）とは
15. 15 認識における脳の負荷のこと 課題外在性負荷 課題内在性負荷 学習関連負荷 👉 補足：認知負荷（ Cognitive load）とは
16. 補足：認知負荷にまつわる話 16 課題に着手するまでに20秒以上経過してしまうと人はその課題をやらなくなってしまう。 20秒以内 20秒以上 ある意味で 認知負荷が高い状態 ある意味で 認知負荷が低い状態
17. 背景（話を戻して） 17 人を増やして生産性を上げればイイかというとなかなかそうもいかない！ コスト
18. 18 コスト 認知負荷 そもそも認知負荷が高いことが原因なので人を増やすのは逆効果 そして、必ずしも生産性が上がるとは限らない。 背景（話を戻して）
19. 19 認知負荷を下げつつ、生産性を上げる方法 「みんなで共通プラットフォームを構築して生産性を上げていこうぜ」という取り組み 簡単にいえば 👉プラットフォームエンジニアリング 背景（話を戻して）
20. （要約）プラットフォームエンジニアリングとは 20 プラットフォームエンジニアリングの活動は組織の大きさを問わない。 内部開発者の負担が軽減される活動 内部開発者のエクスペリエンスを向上させる活動 サービスを提供するまでにかかる時間を最小限にする活動
21. 補足：プラットフォームエンジニアリングに対する誤解 21 Web検索でだいたいの情報は出てくる。それこそAIに聞けば、生産性の問題は解決できるのでは？ 組織内で標準化されたベストプラクティスを簡単に利用できるようにしていく活動 ※組織内で標準化されたベストプラクティスを教えてくれる社内GPTがいる場合はさておき
22. 22 プラットフォームエンジニアリングの取り組み
23. やること 23 ユーザーに ヒアリングして 問題を見つける プラットフォームを 製品として扱う プラットフォーム チームを作る
24. 内部開発者にヒアリングして問題を見つける 24 問題となっていることを見つけるために内部開発者にヒアリングする。 • 内部開発者の要望を理解して課題とする 課題を解決するためのプロダクトを開発する。 （次のページ） 内部開発者 プラットフォームエンジニア イイカンジ に自動化し たい 承知
25. プラットフォームを製品として扱う 25 • MVPにプラットフォームを作成してプラットフォームを製品として扱う • 内部開発者を顧客として見て、継続して利用したいと思えるものを開発する プラットフォームエンジニア 内部開発者 実際に開発者のエクスペリエンスが向上するように継続的にヒアリングを行う。 どれくらい活用しているかを計測して効果を見る。
26. プラットフォームチームを作る 26 ストリームアラインドチームを支えるプラットフォームチームを作る。 （このときプラットフォームチームの目的を明確にします。） ※ストリームアラインドチーム：自社の製品・サービスをリリースするチームのこと ※プラットフォームチーム：Platform as a Productと定めて運用するチーム プラットフォームチーム ストリームアラインドチーム ポータル プラット フォーム 運用保守 TVP 利用 {
27. 27 Google Cloudで プラットフォームエンジニアリングをやりたい
28. プラットフォームチームを作る 28 引用：「道を照らす: プラットフォーム エンジニアリング、ゴールデンパス、セルフサービスのパワー」（ Google Cloud様のブログより） https://cloud.google.com/blog/ja/products/application-development/golden-paths-for-engineering-execution-consistency
29. つまりどういうこと 29 ポイント 組織で使っているツールをまとめながら役立つこと、ベストプラクティスを抽象化する。 • デベロッパー（内部開発者）の生産性が低下しないようにする • デベロッパー（内部開発者）が燃え尽きないようにする • デベロッパー（内部開発者）の認知負荷を上げないようにする
30. Modern App Summit Tokyo '24 Track2によると 30 実は今年の3月に開催されたModern App Summit Tokyo '24で プラットフォームエンジニアリングについて紹介されています。
31. Modern App Summit Tokyo '24 Track2によると 31 ※Platform Engineering Kaigiにも登壇されます。 https://www.cnia.io/pek2024/sessions/eedb9b5a-ef54-4fee-bea9-eeed6e98160d/
32. Modern App Summit Tokyo '24 Track2によると 32 • 舗装された道路（ゴールデンパス）を使う（この道を歩めば誰でもできる ） • プラットフォームを製品として扱う（内部開発者にとってはプロダクト ） • ユーザーにヒアリングをして何が必要か調査する（ヒアリングが重要 ） • ガバナンスとガードレールを敷く（ルールの逸脱を防ぐ ） • 各種PaaSを活用する（利用を強制するものではない ） 以下をポータルで提供する（セルフサービス UXの提供） • プロビジョニングの自動化 • アプリケーションのテンプレート
33. ガバナンスとガードレールを敷く（ルールの逸脱を防ぐ） 33 内部開発者 ルール ルール 内部開発者 組織のルールを逸脱してしまわないようにゴールデンパスにはガードレールを設置する。 👉内部開発者が利用するゴールデンパスにはガードレールが含まれる。
34. 各種PaaSを活用する（利用を強制するものではない） 34 • GAE • Cloud Run • Google Kubernetes Engine（GKE） 👉“PaaSを使いなさい”というプラクティスではない 👉“PaaSを使う”ことは認知負荷を下げるアプローチの1つ
35. 35 どのように実装すれば良いのか
36. GKEで実装しないといけないのか 36 プラットフォームエンジニアリング（PFE）の実装として GKEはオーバースペックなのでは？ GKEで PFEやってよ GKE ナニモワ カラナイ 引用：「コンテナの実際の使用に関する 10 のインサイト」（Datadog様のレポートより） https://www.datadoghq.com/ja/container-report/
37. 37 お一人様プラットフォームエンジニアリング
38. チームを作る前に個人でできることを探る 38 • まわりが困っていること以前に個人的に面倒だと感じていることはないか • 個人的に面倒だと感じていることをMVPで作成してチームに展開できないか 👉「認知負荷を下げる取り組みとして何かできないか」を探す
39. （実は）そもそも実際に困っていたこと 39 生成AIを使ったアプリケーションを構築することになったものの 何があれば、目的のものを開発できるのかわからない状態 👉開発環境は？（すぐに修正できる？機能追加は容易？） 👉フレームワークの使い方は覚えてる？ 👉どのようにデプロイする？ ※社内にではPrisma Accessを導入しているのでそれを踏まえた環境整備
40. 活用できそうなサービスを探る 40 プラットフォームエンジニアリングに利用できそうなものを探る（一部） • Apigee • Cloud Run • Cloud Functions • Cloud Workstations • Vertex AI Workbench マネージドノートブックを使うと幸せになれそう！ Google CloudでAIと言ったらVertex AI Workbench
41. 生成AIを活用することを想定してやってみた 41 Cloud Run Artifact Registry Vertex AI Workbench マネージドノートブック コンテナイメージをpull コマンド送信 イメージのプッシュ SSHで接続
42. 効果測定 42 一番大きな変化： 機能追加時にとりあえずノートブックを開く というアクションに統一できたこと • 最小限のポリシーをもったサービスアカウントを使う ◦ ベストプラクティスに従ったRBAC（ガードレール ） • マネージドノートブック自体がコンテナイメージ ◦ カスタムして利用することも可能（開発者テンプレートの提供 ） • README.mdで作業手順をノートブック内に置く ◦ 何をしたら良いかの判断に迷わない（認知負荷低減 ）
43. まとめ 43 • プラットフォームエンジニアリングは認知負荷を下げつつ、生産性を上げる活動のこと ◦ 定義はさまざまだが、PaaSを導入することではない • Google Cloudのイベントを含め、資料を見た ◦ プラットフォームエンジニアリングは特定のベンダーに依存しないもの • プラットフォームエンジニアリングの取り組み ◦ ユーザーにヒアリングして問題を見つける ◦ プラットフォームを製品として扱う ◦ プラットフォームチームを作る • Google Cloudにはさまざまなサービスがある • GKEで実装することも可能だが、Vertex AI Workbenchでも可能 ◦ 実際にやってみたら、それなりに良い結果が出たのでチームに広めたい（検討中）