MicrosoftのPlatform Engineeringガイドを読んで実際になにかやってみた

MicrosoftのPlatform Engineeringガイドを読んで実際になにかやってみた 1

• 自己紹介 • プラットフォームエンジニアリングとは ◦ 背景 ◦ 補足：プラットフォームエンジニアリングの誤解 ◦ 概要
◦ 要するにどういうこと ◦ もうちょっと踏み込んで • 内部開発者ってなんですか ◦ 内部開発者とは ◦ 2つのIDP • ゴールデンパスとか認知負荷ってなんですか ◦ ゴールデンパスとは ◦ ゴールデンパスを作るとどうなるか ◦ ゴールデンパスを作るタイミング ◦ 認知負荷とは ◦ 補足：認知負荷にまつわる話話すこと 2 • プラットフォームエンジニアリングの原則 ◦ 顧客に優先順位を付ける ◦ 製品マインドセットを採用する ◦ セルフサービスによる強化 ◦ 検出可能性を向上させる • で、具体的になにしたらええの ◦ ドキュメントを整理する ◦ 問題領域を定義する ◦ プラットフォームチームを構築する ◦ 開発者テンプレートを作る ▪ 具体例1 ▪ 具体例2 ▪ 具体例3 ▪ 具体例4 • まとめ • Tips

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

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

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

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

背景 8 求められることが多すぎる！1人何役こなすんだ！コンテナネットワークセキュリティ DevOps 仮想化クラウド CI/CD
マイクロサービス AI 機械学習 IaC DR対応データベースデータ分析 QA 設計マネジメント自動テスト可用性

背景 9 技術が増えると生産性が上がるかというと… 技術技術技術技術技術技術技術
技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術

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

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

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

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

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

補足：プラットフォームエンジニアリングの誤解 15 Web検索でだいたいの情報は出てくる。それこそAIに聞けば、生産性の問題は解決できるのでは？プラットフォームエンジニアリングは組織内で標準化されたベストプラクティスを簡単に利用できるようにしていく活動（とも言える） 👉「技術的な観点で調べればできる」や「AIに聞けばよい」という話ではないこと 👉「組織のポリシーに沿っているか」という観点があること 👉オンボーディングの観点でいえば、誰もが想定された開発環境で開発ができること

プラットフォームエンジニアリングとは 16 引用：プラットフォームエンジニアリングとは | Microsoft Learn なにいってんのかまったくわからない。つらい。

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

もうちょっと踏み込んで 18 • 内部開発者のニーズを特定したうえで最小限のセルフサービスを実装すること • 内部開発者が自身の作業を自己解決できるようにすること • 内部開発者を主軸とした開発プロセスを定義してゴールデンパスを作ること • 内部開発者が再利用可能なことを低い認知負荷ですぐに活用できるようにすること
内部開発者？ゴールデンパス？認知負荷？

内部開発者ってなんですか 19

内部開発者（Internal Developer）とはプロダクトやサービス開発に携わる/関わる者として定義される。 ※必ずしも開発者（ソフトウェアデベロッパー）とは限らないところがポイント • デザイナー • プロジェクトマネージャー • 運用担当者
• エンジニア（種類は問わない） • データサイエンス • etc 内部開発者はポータルを通してプラットフォームを操作する。 20

2つのIDP 21 内部開発者プラットフォーム内部開発者ポータルユーザーインターフェイス基盤内部開発者ポータル（IDP）※ Microsoft
Learnでは単に「ポータル」と表現 ※内部開発者プラットフォーム（IDP）はポータルのバックエンドに位置

ゴールデンパスとか認知負荷ってなんですか 22

ゴールデンパス（舗装された道路）とは迅速なプロジェクト開発に役立つコードと機能のテンプレートとドキュメントもしくは実際のプロダクト/サービス開発に至るまでの道、標準化され、自動化された手順 23

ゴールデンパスを作るとどうなるか • ストリームアラインドチームの認知負荷が低減される • 本来のコーディング業務に専念できる • スキル習得に専念できる 👆これらはプラットフォームチームの役割 24 ※ストリームアラインドチーム：製品を開発して責任を持つチーム

ゴールデンパスを作るタイミング • 例：インフラの複雑さに悩まされ、高い認知負荷を抱えているとき • 例：運用チームが常にトラブルに直面しているとき • 例：ドキュメントや個々人のやり方がバラバラで統一されていないとき 25

認知負荷（Cognitive load）とは認識における脳の負荷のこと 26

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

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

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

認知負荷の具体例課題外・課題内在性負荷が比較的に高い状態 =新しいことを学ぶことについては苦しくない。一方で業務に取り組む際に難易度が高すぎて困難 30 課題外在性負荷課題内在性負荷学習関連負荷高高低

認知負荷の具体例課題外在性負荷が比較的に高い状態＝業務の難易度はさほど高くない。課題達成のための制約が多いことで課題の遂行が困難 31 課題外在性負荷課題内在性負荷学習関連負荷高低低

認知負荷の具体例課題内在性負荷が比較的に高い状態＝課題に取り組む人と取り組んでいる課題の難易度がマッチしていない 32 課題外在性負荷課題内在性負荷学習関連負荷低高低

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

（再掲）もうちょっと踏み込んで 34 • 内部開発者のニーズを特定したうえで最小限のセルフサービスを実装すること ◦ つまり、今必要とされていることを認識してサービスを実装すること • 内部開発者が自身の作業を自己解決できるようにすること ◦ つまり、ベースとなる作業はすべて自己解決できるようにすること
• 内部開発者を主軸とした開発プロセスを定義してゴールデンパスを作ること ◦ つまり、実務に携わるときに準備のプロセスを「道」として示すこと • 内部開発者が再利用可能なことを低い認知負荷ですぐに活用できるようにすること ◦ つまり、ほぼ何も考えずに本当にやりたいことに集中できること

プラットフォームエンジニアリングの原則 35 ここからMicrosoft Learnを参考にプラットフォームエンジニアリングの原則をみていくYo!

プラットフォームエンジニアリングの原則 1. 顧客に優先順位を付ける 2. 製品マインドセットを採用する 3. セルフサービスによる強化 4. 検出可能性を向上させる 36

顧客に優先順位を付けるプラットフォームを整備するエンジニアは内部開発者をお客さんとして見る。実装のニーズを見極め、優先順位をつけ、合意を取ったうえで小規模に始める。また、お客さんがよく使うツールに合わせてプラットフォーム（あるいはポータル）を調整する。 37 内部開発者プラットフォームエンジニア顧客中心のアプローチをとる。

製品マインドセットを採用する 38 実際に開発者のエクスペリエンスが向上しなければ、作る意味がない。また、プラットフォームを作っても使ってくれるとは限らない。利用しているか活用しているかどうかを計測して効果を見る。 Dev Ops プラットフォームが効果的に働くかどうかを一貫した測定方法で測定する。

セルフサービスによる強化 39 ゴールデンパスを作ったとしてもそれが組織のポリシーと合致しているかどうかわからない。安全のためにセキュリティの有識者と協力してセルフサービスを作り、ガードレールを設置する。ゴールデンパスだけでなく、セルフサービスを提供ゴールデンパスにガードレールを構築する！開発者ポリシーポリシー開発者

検出可能性を向上させる 40 組織内でチームが分裂して管理が複雑になっていくと、となりで何が起きているかがわからなくなったりする。たとえば、同じフレームワークを作っていたり、消してイイのかよくわからないインスタンスが建っていたりする。プラットフォームエンジニアはこれらを追跡する必要がある。フレームワークAを作った。フレームワークAを作った。うわ、あっちと被っとるやんテスト用に特大インスタンス建てよう（記録なし）
新入社員：知らないインスタンスが建っているけどこれ大丈夫かなこのPJできるのは俺だけ！俺的神リポジトリを作ったぜウェイ！よく使うインフラテンプレートを作ったぜこれメンテされてんのか？

で、具体的になにしたらええの 41

ドキュメントを整理する一番最初にできて、最も簡単なアプローチ • Private GitHub Pagesで社内ページを作成する • GitHub organizationにプライベートリポジトリを作成する •
Azure DevOpsのWikiを整備する＝＞社内で使い慣れた製品を使って資料を作成するいずれにしても作ったら有識者を集めてレビューをしてもらう！ 42

問題領域を定義する内部開発者にとって何が課題となっているかを特定する。 Thinnest Viable Platform（最低限のプラットフォーム）を定義して Minimum Viable Product（実用最小限の製品）を開発する。例：「ドキュメントが読みにくいもしくは整理されていないことが一番の問題である場合」
👉ドキュメントを整理すれば解決する可能性があるため、ポータルは作成せず最小限でかつ実用的なアクションで済ませる。 43

プラットフォームチームを構築する • Ops（運用）と製品のマインドセットを理解したメンバーで構成する ◦ メンバーそれぞれの技術的バックグラウンドは重要ではないプラットフォームエンジニアリングの目的を明確にする意味でもナレッジがまとまっていない場合はチームの構築よりも先にドキュメントを作成する。 44 ※本の翻訳者による発表『チームトポロジー』と
Platform Engineering https://speakerdeck.com/miholovesq/team-topologies-with-platform-engineering 引用：チームトポロジー（単行本）価値あるソフトウェアをすばやく届ける適応型組織設計 https://pub.jmam.co.jp/book/b593881. html

開発者テンプレートを作る一貫性のある開発環境でチーム開発の統制をとりたい 45 活用できそうなサービス • Dev Containers • GitHub Codespaces
• Azure Developer CLI（azd） • Azure Deployment Environments（ADE） • Dev Box + Visual Studio • Terraform Cloud + GitHub • Backstage

具体例1: Dev ContainersとGitHub Codespaces 引用：超高速で構築するクラウド開発環境 https://github.co.jp/features/codespaces 46 • devcontainer.jsonとCodespacesによる環境提供でゴールデンパスとセルフサービスを提供する設定が書き込まれたjsonとGitHubアカウントがあれば、すぐに動く環境が手に入る状態

具体例2: azdとADE 47 • azdとADEによる環境提供でゴールデンパスとセルフサービスを提供する • azdで.NET Aspireを使うと、OTelのモニタリング設定までついてくるインフラの環境を保存したテンプレートを保存するADE、インフラとアプリケーションを展開するazd Azure
Developer CLI support for Azure Deployment Environments https://learn.microsoft.com/ja-jp/azure/developer/azure-developer-cli/ade-integration

具体例3: Dev Box + Visual Studio 48 引用：Microsoft Dev Box
を構成する https://learn.microsoft.com/ja-jp/azure/dev-box/quickstart-conﬁgure-dev-box-service 開発環境をOSまるごと提供する。Visual Studioで開発をコラボレーション

49 2022/11/22投稿 Microsoft Dev Box を使ってみよう！〜詳細編〜| Azure
入門 56 [# くらでべ ] https://youtu.be/lCPwtC5w1k8?feature=shared&t=759

具体例4: Terraform Cloud + GitHub 50 • Terraform Cloud：ステート管理、プロバイダの統一、Registryの利用 •
GitHub：アプリケーションレイヤーのテストをGitHub Actions • インフラのテスト：Terraform Cloud上で担保※ • アプリケーションのテスト：GitHub Actions + その他で担保 ※Azureの可能性を引き出せ！Terraform活用で変わるインフラ構築術 - connpass https://youtu.be/eyAuD797AnE?feature=shared&t=1470

まとめ • プラットフォームエンジニアリングは組織内で標準化されたベストプラクティスを簡単に利用できるようにしていく活動といえる（なお、定義はさまざま） • 「DevOps、内部開発者、IDP、認知負荷、ゴールデンパス、セルフサービス、テンプレート」などがプラットフォームエンジニアリングにとりかかる上で重要になりそう • Microsoftにはプラットフォームエンジニアリングを実現するサービスが揃っている ◦
他のクラウドと比較しても揃っている印象を受けた • プラットフォームエンジニアリングを実現する際は使い慣れたツールを使う ◦ Azureに限定する必要はない 51

プラットフォームエンジニアの役割（まとめ） • 内部開発者を顧客としてみるアプローチ • ざまざまなユースケースで負担となっている点を特定すること • チームのプレイヤーであること • 絶えず学び、新しい技術のエバンジェリストになること •
問題解決志向、細部に気を配る、チーム間コミュニケーション • 内部開発者プラットフォームを宣伝、訴求 • DevSecOpsのプラクティスに精通していること 52

53 ここから先はプラットフォームエンジニアリングで参考になる資料集 Tips

54 Platform reference architecture on Azure https://humanitec.com/reference-architectures/azure GitHub：https://github.com/humanitec-architecture/reference-architecture-azure

55 Platform reference architecture on Google Cloud https://github.com/humanitec-architecture/reference-architecture-gcp

56 プラットフォームの組織構造 https://cloud.google.com/architecture/enterprise-application-blueprint/dev eloper-platform-controls?hl=ja

57 Platform reference architecture on AWS https://github.com/humanitec-architecture/reference-architecture-aws

58 Platform tooling landscape https://platformengineering.org/platform-tooling

59 Internal Developer Platform https://internaldeveloperplatform.org/

60 What Is an Internal Developer Platform https://humanitec.com/blog/what-is-an-internal-developer-platform

61 What is platform engineering https://humanitec.com/platform-engineering

62 https://bliki-ja.github.io/TeamTopologies チームトポロジ

MicrosoftのPlatform Engineeringガイドを読んで実際になにかやってみた

MicrosoftのPlatform Engineeringガイドを読んで実際になにかやってみた

More Decks by Kento.Yamada

Other Decks in Programming

Featured

Transcript