Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
第138回 雲勉 Google Cloudではじめるプラットフォームエンジニアリング
Search
iret.kumoben
July 04, 2024
Technology
0
78
第138回 雲勉 Google Cloudではじめるプラットフォームエンジニアリング
下記、勉強会での資料です。
https://youtu.be/dCpElhPi1gI
iret.kumoben
July 04, 2024
Tweet
Share
More Decks by iret.kumoben
See All by iret.kumoben
第159回 雲勉 Amazon Bedrock でブラウザを操作する AI エージェントを作ってみた
iret
0
18
第158回 雲勉 AWS CDK 入門 ~ プログラミング言語で書くインフラ Python 編 ~
iret
0
30
第157回 雲勉 AWSインフラ監視をNew Relicで行う際の個人的Tips
iret
0
36
第156回 雲勉 AWS on Windows入門
iret
0
70
第155回 雲勉 サーバレスアーキテクチャを 用いたコスト重視 AI サービス
iret
0
51
第154回 雲勉 AWS Codeシリーズ盛り上げ隊 ~ Codeシリーズは砕けない ~
iret
0
54
第153回 雲勉 トラシューが秒で終わる新機能 Amazon Q Developer operational investigations
iret
0
65
第150回 雲勉 AWS AppSyncではじめるGraphQL体験
iret
0
57
第151回 雲勉 プロジェクトのドキュメントにおける課題をAmazon Bedrockで解決してみる
iret
0
72
Other Decks in Technology
See All in Technology
Riverpod & Riverpod Generatorを利用して状態管理部分の処理を書き換えてみる簡単な事例紹介
fumiyasac0921
0
110
30代エンジニアが考える、エンジニア生存戦略~~セキュリティを添えて~~
masakiokuda
4
2k
ISUCONにPHPで挑み続けてできるようになっ(てき)たこと / phperkaigi2025
blue_goheimochi
0
140
モジュラーモノリスでスケーラブルなシステムを作る - BASE のリアーキテクチャのいま
panda_program
7
2k
Redefine_Possible
upsider_tech
0
260
大規模アジャイル開発のリアル!コミュニケーション×進捗管理×高品質
findy_eventslides
0
530
caching_sha2_passwordのはなし
boro1234
0
220
Amazon GuardDuty Malware Protection for Amazon S3を使おう
ryder472
2
100
[CATS]Amazon Bedrock GenUハンズオン座学資料 #2 GenU環境でRAGを体験してみよう
tsukuboshi
0
140
問題解決に役立つ数理工学
recruitengineers
PRO
7
2.2k
グループポリシー再確認
murachiakira
0
170
ペアーズにおけるData Catalog導入の取り組み
hisamouna
0
130
Featured
See All Featured
Navigating Team Friction
lara
184
15k
Rails Girls Zürich Keynote
gr2m
94
13k
Mobile First: as difficult as doing things right
swwweet
223
9.5k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.5k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
16k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
32
2.2k
What’s in a name? Adding method to the madness
productmarketing
PRO
22
3.4k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
160
15k
Practical Orchestrator
shlominoach
187
10k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
33
2.1k
Designing for humans not robots
tammielis
250
25k
Intergalactic Javascript Robots from Outer Space
tanoku
270
27k
Transcript
第138回 雲勉【オンライン】 Google Cloudではじめる プラットフォームエンジニアリング
話すこと 2 • 自己紹介 • 宣伝 • プラットフォームエンジニアリングとは ◦ 背景
◦ 補足:認知負荷(Cognitive load)とは ◦ 背景(話を戻して) ◦ (要約)プラットフォームエンジニアリング ◦ 補足:プラットフォームエンジニアリングに対する誤解 • プラットフォーム エンジニアリングの取り組み ◦ やること ◦ ユーザーにヒアリングして問題を見つける ◦ プラットフォームを製品として扱う ◦ プラットフォームチームを作る • Google Cloudでプラットフォームエンジニアリング ◦ 公式ブログによると ◦ つまりどういうこと ◦ Modern App Summitによると • どのように実装すれば良いのか ◦ ⚪⚪⚪で実装しないといけないのか • お一人様プラットフォームエンジニアリング ◦ チームを作る前に個人でできることを探る ◦ 実際に困っていたこと ◦ 活用できそうなサービスを模索 ◦ 生成AIを活用することを想定してやってみた ◦ 効果測定(定性的に) • まとめ
自己紹介 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 技術書典16に頒布しました。 PagerDutyを使っている 7人が思いのたけをぶちまけた作品! PagerDuty FANBOOK Vol.1
宣伝 5 社内のメンバーで書きました。 AWSの認定資格対策本というヤツです。 AWS認定 高度なネットワーキングー専門知識 (ANS-C01) 完全対応テキスト
6 プラットフォームエンジニアリングとは
7 “自分で作ったものは自分で運用する ” というアプローチは、複雑な現代の ソフトウェア スタックではもはや実現不可能
背景 8 求められている技術スタック・概念が多い。複雑化!
背景 9 求められている技術スタック・概念が多い。幅広い専門分野における熟練した技術が必要 コンテナ ネットワーク セキュリティ DevOps 仮想化 クラウド CI/CD
マイクロサービス AI 機械学習 IaC DR対応 データベース データ分析 QA 設計 マネジメント 自動テスト 可用性
背景 10 技術が増えると生産性が上がるかというと…そうでもない 生産性 要因:学習コストの増加、役割の多様化、コミュニケーションコストの増加 技術 技術 技術 技術 技術
技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術
背景 11 技術が増えると生産性が上がるかというと…そうでもない 生産性 つまりは認知負荷が高い ので生産性が下がっている! 技術 技術 技術 技術
技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術
補足:認知負荷( Cognitive load)とは 12 認識における脳の負荷のこと
補足:認知負荷( Cognitive load)とは 13 認識における脳の負荷のこと 課題外在性負荷 👉
14 認識における脳の負荷のこと 課題外在性負荷 課題内在性負荷 👉 補足:認知負荷( Cognitive load)とは
15 認識における脳の負荷のこと 課題外在性負荷 課題内在性負荷 学習関連負荷 👉 補足:認知負荷( Cognitive load)とは
補足:認知負荷にまつわる話 16 課題に着手するまでに20秒以上経過してしまうと人はその課題をやらなくなってしまう。 20秒以内 20秒以上 ある意味で 認知負荷が高い状態 ある意味で 認知負荷が低い状態
背景(話を戻して) 17 人を増やして生産性を上げればイイかというとなかなかそうもいかない! コスト
18 コスト 認知負荷 そもそも認知負荷が高いことが原因なので人を増やすのは逆効果 そして、必ずしも生産性が上がるとは限らない。 背景(話を戻して)
19 認知負荷を下げつつ、生産性を上げる方法 「みんなで共通プラットフォームを構築して生産性を上げていこうぜ」という取り組み 簡単にいえば 👉プラットフォームエンジニアリング 背景(話を戻して)
(要約)プラットフォームエンジニアリングとは 20 プラットフォームエンジニアリングの活動は組織の大きさを問わない。 内部開発者の負担が軽減される活動 内部開発者のエクスペリエンスを向上させる活動 サービスを提供するまでにかかる時間を最小限にする活動
補足:プラットフォームエンジニアリングに対する誤解 21 Web検索でだいたいの情報は出てくる。それこそAIに聞けば、生産性の問題は解決できるのでは? 組織内で標準化されたベストプラクティスを簡単に利用できるようにしていく活動 ※組織内で標準化されたベストプラクティスを教えてくれる社内GPTがいる場合はさておき
22 プラットフォームエンジニアリングの取り組み
やること 23 ユーザーに ヒアリングして 問題を見つける プラットフォームを 製品として扱う プラットフォーム チームを作る
内部開発者にヒアリングして問題を見つける 24 問題となっていることを見つけるために内部開発者にヒアリングする。 • 内部開発者の要望を理解して課題とする 課題を解決するためのプロダクトを開発する。 (次のページ) 内部開発者 プラットフォームエンジニア イイカンジ
に自動化し たい 承知
プラットフォームを製品として扱う 25 • MVPにプラットフォームを作成してプラットフォームを製品として扱う • 内部開発者を顧客として見て、継続して利用したいと思えるものを開発する プラットフォームエンジニア 内部開発者 実際に開発者のエクスペリエンスが向上するように継続的にヒアリングを行う。 どれくらい活用しているかを計測して効果を見る。
プラットフォームチームを作る 26 ストリームアラインドチームを支えるプラットフォームチームを作る。 (このときプラットフォームチームの目的を明確にします。) ※ストリームアラインドチーム:自社の製品・サービスをリリースするチームのこと ※プラットフォームチーム:Platform as a Productと定めて運用するチーム プラットフォームチーム
ストリームアラインドチーム ポータル プラット フォーム 運用保守 TVP 利用 {
27 Google Cloudで プラットフォームエンジニアリングをやりたい
プラットフォームチームを作る 28 引用:「道を照らす: プラットフォーム エンジニアリング、ゴールデンパス、セルフサービスのパワー」( Google Cloud様のブログより) https://cloud.google.com/blog/ja/products/application-development/golden-paths-for-engineering-execution-consistency
つまりどういうこと 29 ポイント 組織で使っているツールをまとめながら役立つこと、ベストプラクティスを抽象化する。 • デベロッパー(内部開発者)の生産性が低下しないようにする • デベロッパー(内部開発者)が燃え尽きないようにする • デベロッパー(内部開発者)の認知負荷を上げないようにする
Modern App Summit Tokyo '24 Track2によると 30 実は今年の3月に開催されたModern App Summit
Tokyo '24で プラットフォームエンジニアリングについて紹介されています。
Modern App Summit Tokyo '24 Track2によると 31 ※Platform Engineering Kaigiにも登壇されます。
https://www.cnia.io/pek2024/sessions/eedb9b5a-ef54-4fee-bea9-eeed6e98160d/
Modern App Summit Tokyo '24 Track2によると 32 • 舗装された道路(ゴールデンパス)を使う(この道を歩めば誰でもできる )
• プラットフォームを製品として扱う(内部開発者にとってはプロダクト ) • ユーザーにヒアリングをして何が必要か調査する(ヒアリングが重要 ) • ガバナンスとガードレールを敷く(ルールの逸脱を防ぐ ) • 各種PaaSを活用する(利用を強制するものではない ) 以下をポータルで提供する(セルフサービス UXの提供) • プロビジョニングの自動化 • アプリケーションのテンプレート
ガバナンスとガードレールを敷く(ルールの逸脱を防ぐ) 33 内部開発者 ルール ルール 内部開発者 組織のルールを逸脱してしまわないようにゴールデンパスにはガードレールを設置する。 👉内部開発者が利用するゴールデンパスにはガードレールが含まれる。
各種PaaSを活用する(利用を強制するものではない) 34 • GAE • Cloud Run • Google Kubernetes
Engine(GKE) 👉“PaaSを使いなさい”というプラクティスではない 👉“PaaSを使う”ことは認知負荷を下げるアプローチの1つ
35 どのように実装すれば良いのか
GKEで実装しないといけないのか 36 プラットフォームエンジニアリング(PFE)の実装として GKEはオーバースペックなのでは? GKEで PFEやってよ GKE ナニモワ カラナイ 引用:「コンテナの実際の使用に関する
10 のインサイト」(Datadog様のレポートより) https://www.datadoghq.com/ja/container-report/
37 お一人様プラットフォームエンジニアリング
チームを作る前に個人でできることを探る 38 • まわりが困っていること以前に個人的に面倒だと感じていることはないか • 個人的に面倒だと感じていることをMVPで作成してチームに展開できないか 👉「認知負荷を下げる取り組みとして何かできないか」を探す
(実は)そもそも実際に困っていたこと 39 生成AIを使ったアプリケーションを構築することになったものの 何があれば、目的のものを開発できるのかわからない状態 👉開発環境は?(すぐに修正できる?機能追加は容易?) 👉フレームワークの使い方は覚えてる? 👉どのようにデプロイする? ※社内にではPrisma Accessを導入しているのでそれを踏まえた環境整備
活用できそうなサービスを探る 40 プラットフォームエンジニアリングに利用できそうなものを探る(一部) • Apigee • Cloud Run • Cloud
Functions • Cloud Workstations • Vertex AI Workbench マネージドノートブックを使うと幸せになれそう! Google CloudでAIと言ったらVertex AI Workbench
生成AIを活用することを想定してやってみた 41 Cloud Run Artifact Registry Vertex AI Workbench マネージドノートブック
コンテナイメージをpull コマンド送信 イメージのプッシュ SSHで接続
効果測定 42 一番大きな変化: 機能追加時にとりあえずノートブックを開く というアクションに統一できたこと • 最小限のポリシーをもったサービスアカウントを使う ◦ ベストプラクティスに従ったRBAC(ガードレール )
• マネージドノートブック自体がコンテナイメージ ◦ カスタムして利用することも可能(開発者テンプレートの提供 ) • README.mdで作業手順をノートブック内に置く ◦ 何をしたら良いかの判断に迷わない(認知負荷低減 )
まとめ 43 • プラットフォームエンジニアリングは認知負荷を下げつつ、生産性を上げる活動のこと ◦ 定義はさまざまだが、PaaSを導入することではない • Google Cloudのイベントを含め、資料を見た ◦
プラットフォームエンジニアリングは特定のベンダーに依存しないもの • プラットフォームエンジニアリングの取り組み ◦ ユーザーにヒアリングして問題を見つける ◦ プラットフォームを製品として扱う ◦ プラットフォームチームを作る • Google Cloudにはさまざまなサービスがある • GKEで実装することも可能だが、Vertex AI Workbenchでも可能 ◦ 実際にやってみたら、それなりに良い結果が出たのでチームに広めたい(検討中)