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

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

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

自己紹介 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Kento.Yamada

More Decks by Kento.Yamada

Other Decks in Programming

Featured

Transcript