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

2024年4月20日開催されたGlobal Azureの登壇資料です。

概要

以下の内容について解説しました。
- Microsoftのプラットフォーム エンジニアリング ガイドを読んでプラットフォームエンジニアリング
- MicrosoftのDeveloper Technologiesを使ってプラットフォーム エンジニアリングを実現する方法
- GitHubを使ってどのようにしてプラットフォーム エンジニアリングを実現する方法

Microsoftのプラットフォーム エンジニアリング ガイド
https://learn.microsoft.com/ja-jp/platform-engineering/what-is-platform-engineering

スライド内で紹介したリンク

Azureの可能性を引き出せ！Terraform活用で変わるインフラ構築術 - connpass
https://youtu.be/eyAuD797AnE?feature=shared&t=1470

本の翻訳者による発表
『チームトポロジー』と Platform Engineering
https://speakerdeck.com/miholovesq/team-topologies-with-platform-engineering

チームトポロジー （単行本）
価値あるソフトウェアをすばやく届ける適応型組織設計
https://pub.jmam.co.jp/book/b593881.html

Azure Developer CLI support for Azure Deployment Environments
https://learn.microsoft.com/ja-jp/azure/developer/azure-developer-cli/ade-integration

引用：Microsoft Dev Box を構成する
https://learn.microsoft.com/ja-jp/azure/dev-box/quickstart-configure-dev-box-service

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

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

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

Internal Developer Platform
https://internaldeveloperplatform.org/

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

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

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

Transcript

1. MicrosoftのPlatform Engineeringガイドを読んで 実際になにかやってみた 1
2. • 自己紹介 • プラットフォームエンジニアリングとは ◦ 背景 ◦ 補足：プラットフォームエンジニアリングの誤解 ◦ 概要 ◦ 要するにどういうこと ◦ もうちょっと踏み込んで • 内部開発者ってなんですか ◦ 内部開発者とは ◦ 2つのIDP • ゴールデンパスとか認知負荷ってなんですか ◦ ゴールデンパスとは ◦ ゴールデンパスを作るとどうなるか ◦ ゴールデンパスを作るタイミング ◦ 認知負荷とは ◦ 補足：認知負荷にまつわる話 話すこと 2 • プラットフォームエンジニアリングの原則 ◦ 顧客に優先順位を付ける ◦ 製品マインドセットを採用する ◦ セルフサービスによる強化 ◦ 検出可能性を向上させる • で、具体的になにしたらええの ◦ ドキュメントを整理する ◦ 問題領域を定義する ◦ プラットフォームチームを構築する ◦ 開発者テンプレートを作る ▪ 具体例1 ▪ 具体例2 ▪ 具体例3 ▪ 具体例4 • まとめ • Tips
3. 自己紹介 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. プラットフォームエンジニアリングとは 4
5. “自分で作ったものは自分で運用する” というアプローチは、複雑な現代の ソフトウェア スタックではもはや実現不可能 5
6. 背景 6 求められている技術スタック・概念が多い。複雑化！
7. 背景 7 求められている技術スタック・概念が多い。幅広い専門分野における熟練した技術が必要 コンテナ ネットワーク セキュリティ DevOps 仮想化 クラウド CI/CD マイクロサービス AI 機械学習 IaC DR対応 データベース データ分析 QA 設計 マネジメント 自動テスト 可用性
8. 背景 8 求められることが多すぎる！1人何役こなすんだ！ コンテナ ネットワーク セキュリティ DevOps 仮想化 クラウド CI/CD マイクロサービス AI 機械学習 IaC DR対応 データベース データ分析 QA 設計 マネジメント 自動テスト 可用性
9. 背景 9 技術が増えると生産性が上がるかというと… 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術
10. 背景 10 技術が増えると生産性が上がるかというと…そうでもない 生産性 要因：学習コストの増加、役割の多様化、コミュニケーションコストの増加 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術
11. 背景 11 技術が増えると生産性が上がるかというと…そうでもない 生産性 つまりは認知負荷が高いので生産性が下がっている！ 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術 技術
12. 背景 12 人を増やして生産性を上げればイイかというとなかなかそうもいかない！ コスト
13. コスト 認知負荷 背景 13 そもそも認知負荷が高いことが原因なので人を増やすのは逆効果 そして、必ずしも生産性が上がるとは限らない。
14. 背景 14 認知負荷を下げつつ、生産性を上げる方法としてプラットフォームエンジニアリングが 生まれた。 「みんなで共通プラットフォームを構築して生産性を上げていこうぜ」という取り組み 簡単にいえば 👉プラットフォームエンジニアリング
15. 補足：プラットフォームエンジニアリングの誤解 15 Web検索でだいたいの情報は出てくる。それこそAIに聞けば、生産性の問題は解決できるのでは？ プラットフォームエンジニアリングは組織内で標準化されたベストプラクティスを簡 単に利用できるようにしていく活動（とも言える） 👉「技術的な観点で調べればできる」や「AIに聞けばよい」という話ではないこと 👉「組織のポリシーに沿っているか」という観点があること 👉オンボーディングの観点でいえば、誰もが想定された開発環境で開発ができること
16. プラットフォームエンジニアリングとは 16 引用：プラットフォーム エンジニアリングとは | Microsoft Learn なにいってんのかまったくわからない。つらい。
17. 要するにどういうこと 17 プラットフォームエンジニアリングの活動は組織の大きさを問わない。 内部開発者の負担が軽減される活動 内部開発者のエクスペリエンスを向上させる活動 サービスを提供するまでにかかる時間を最小限にする活動
18. もうちょっと踏み込んで 18 • 内部開発者のニーズを特定したうえで最小限のセルフサービスを実装すること • 内部開発者が自身の作業を自己解決できるようにすること • 内部開発者を主軸とした開発プロセスを定義してゴールデンパスを作ること • 内部開発者が再利用可能なことを低い認知負荷ですぐに活用できるようにすること 内部開発者？ゴールデンパス？認知負荷？
19. 内部開発者ってなんですか 19
20. 内部開発者（Internal Developer）とは プロダクトやサービス開発に携わる/関わる者として定義される。 ※必ずしも開発者（ソフトウェアデベロッパー）とは限らないところがポイント • デザイナー • プロジェクトマネージャー • 運用担当者 • エンジニア（種類は問わない） • データサイエンス • etc 内部開発者はポータルを通してプラットフォームを操作する。 20
21. 2つのIDP 21 内部開発者 プラットフォーム 内部開発者 ポータル ユーザーインターフェイス 基盤 内部開発者ポータル（IDP）※ Microsoft Learnでは単に「ポータル」と表現 ※内部開発者プラットフォーム（IDP）はポータルのバックエンドに位置
22. ゴールデンパスとか認知負荷ってなんですか 22
23. ゴールデンパス（舗装された道路）とは 迅速なプロジェクト開発に役立つコードと機能のテンプレートとドキュメント もしくは 実際のプロダクト/サービス開発に至るまでの道、標準化され、自動化された手順 23
24. ゴールデンパスを作るとどうなるか • ストリームアラインドチームの認知負荷が低減される • 本来のコーディング業務に専念できる • スキル習得に専念できる 👆これらはプラットフォームチームの役割 24 ※ストリームアラインドチーム：製品を開発して責任を持つチーム
25. ゴールデンパスを作るタイミング • 例：インフラの複雑さに悩まされ、高い認知負荷を抱えているとき • 例：運用チームが常にトラブルに直面しているとき • 例：ドキュメントや個々人のやり方がバラバラで統一されていないとき 25
26. 認知負荷（Cognitive load）とは 認識における脳の負荷のこと 26
27. 認知負荷（Cognitive load）とは 認識における脳の負荷のこと 27 課題外在性負荷 👉
28. 認知負荷（Cognitive load）とは 認識における脳の負荷のこと 28 課題外在性負荷 課題内在性負荷 👉
29. 認知負荷（Cognitive load）とは 認識における脳の負荷のこと 29 課題外在性負荷 課題内在性負荷 学習関連負荷 👉
30. 認知負荷の具体例 課題外・課題内在性負荷が比較的に高い状態 =新しいことを学ぶことについては苦しくない。一方で業務に取り組む際に難易度が高すぎて困難 30 課題外在性負荷 課題内在性負荷 学習関連負荷 高 高 低
31. 認知負荷の具体例 課題外在性負荷が比較的に高い状態 ＝業務の難易度はさほど高くない。課題達成のための制約が多いことで課題の遂行が困難 31 課題外在性負荷 課題内在性負荷 学習関連負荷 高 低 低
32. 認知負荷の具体例 課題内在性負荷が比較的に高い状態 ＝課題に取り組む人と取り組んでいる課題の難易度がマッチしていない 32 課題外在性負荷 課題内在性負荷 学習関連負荷 低 高 低
33. 補足：認知負荷にまつわる話 33 課題に着手するまでに20秒以上経過してしまうと人はその課題をやらなくなってしまう。 20秒以内 20秒以上 ある意味で 認知負荷が高い状態 ある意味で 認知負荷が低い状態
34. （再掲）もうちょっと踏み込んで 34 • 内部開発者のニーズを特定したうえで最小限のセルフサービスを実装すること ◦ つまり、今必要とされていることを認識してサービスを実装すること • 内部開発者が自身の作業を自己解決できるようにすること ◦ つまり、ベースとなる作業はすべて自己解決できるようにすること • 内部開発者を主軸とした開発プロセスを定義してゴールデンパスを作ること ◦ つまり、実務に携わるときに準備のプロセスを「道」として示すこと • 内部開発者が再利用可能なことを低い認知負荷ですぐに活用できるようにすること ◦ つまり、ほぼ何も考えずに本当にやりたいことに集中できること
35. プラットフォームエンジニアリングの原則 35 ここからMicrosoft Learnを参考にプラットフォームエンジニアリングの原則をみていくYo!
36. プラットフォームエンジニアリングの原則 1. 顧客に優先順位を付ける 2. 製品マインドセットを採用する 3. セルフサービスによる強化 4. 検出可能性を向上させる 36
37. 顧客に優先順位を付ける プラットフォームを整備するエンジニアは内部開発者をお客さんとして見る。 実装のニーズを見極め、優先順位をつけ、合意を取ったうえで小規模に始める。 また、お客さんがよく使うツールに合わせてプラットフォーム（あるいはポータル）を調整する。 37 内部開発者 プラットフォームエンジニア 顧客中心のアプローチをとる。
38. 製品マインドセットを採用する 38 実際に開発者のエクスペリエンスが向上しなければ、作る意味がない。 また、プラットフォームを作っても使ってくれるとは限らない。 利用しているか活用しているかどうかを計測して効果を見る。 Dev Ops プラットフォームが効果的に働くかどうかを 一貫した測定方法で測定する。
39. セルフサービスによる強化 39 ゴールデンパスを作ったとしてもそれが組織のポリシーと合致しているかどうかわからない。 安全のためにセキュリティの有識者と協力してセルフサービスを作り、ガードレールを設置する。 ゴールデンパスだけでなく、セルフサービスを提供 ゴールデンパスにガードレールを構築する！ 開発者 ポリシー ポリシー 開発者
40. 検出可能性を向上させる 40 組織内でチームが分裂して管理が複雑になっていくと、となりで何が起きているかがわからなくなったりす る。たとえば、同じフレームワークを作っていたり、消してイイのかよくわからないインスタンスが建って いたりする。プラットフォームエンジニアはこれらを追跡する必要がある。 フレームワークAを作った。 フレームワークAを作った。 うわ、あっちと被っとるやん テスト用に特大インスタンス建てよう （記録なし） 新入社員：知らないインスタンスが建っているけど これ大丈夫かな このPJできるのは俺だけ！ 俺的神リポジトリを作ったぜウェイ！ よく使うインフラテンプレートを作ったぜ これメンテされてんのか？
41. で、具体的になにしたらええの 41
42. ドキュメントを整理する 一番最初にできて、最も簡単なアプローチ • Private GitHub Pagesで社内ページを作成する • GitHub organizationにプライベートリポジトリを作成する • Azure DevOpsのWikiを整備する ＝＞社内で使い慣れた製品を使って資料を作成する いずれにしても作ったら有識者を集めてレビューをしてもらう！ 42
43. 問題領域を定義する 内部開発者にとって何が課題となっているかを特定する。 Thinnest Viable Platform（最低限のプラットフォーム）を定義して Minimum Viable Product（実用最小限の製品）を開発する。 例： 「ドキュメントが読みにくいもしくは整理されていないことが一番の問題である場合」 👉ドキュメントを整理すれば解決する可能性があるため、ポータルは作成せず 最小限でかつ実用的なアクションで済ませる。 43
44. プラットフォームチームを構築する • Ops（運用）と製品のマインドセットを理解したメンバーで構成する ◦ メンバーそれぞれの技術的バックグラウンドは重要ではない プラットフォームエンジニアリングの目的を明確にする意味でも ナレッジがまとまっていない場合はチームの構築よりも先にドキュメントを作成する。 44 ※本の翻訳者による発表 『チームトポロジー』と Platform Engineering https://speakerdeck.com/miholovesq/team-topologies-with-platform-engineering 引用：チームトポロジー （単行本） 価値あるソフトウェアをすばやく届ける適 応型組織設計 https://pub.jmam.co.jp/book/b593881. html
45. 開発者テンプレートを作る 一貫性のある開発環境でチーム開発の統制をとりたい 45 活用できそうなサービス • Dev Containers • GitHub Codespaces • Azure Developer CLI（azd） • Azure Deployment Environments（ADE） • Dev Box + Visual Studio • Terraform Cloud + GitHub • Backstage
46. 具体例1: Dev ContainersとGitHub Codespaces 引用：超高速で構築するクラウド開発環境 https://github.co.jp/features/codespaces 46 • devcontainer.jsonとCodespacesによる環境提供でゴールデンパスとセルフサービスを提供する 設定が書き込まれたjsonとGitHubアカウントがあれば、すぐに動く環境が手に入る状態
47. 具体例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
48. 具体例3: Dev Box + Visual Studio 48 引用：Microsoft Dev Box を構成する https://learn.microsoft.com/ja-jp/azure/dev-box/quickstart-configure-dev-box-service 開発環境をOSまるごと提供する。Visual Studioで開発をコラボレーション
49. 49 2022/11/22投稿 Microsoft Dev Box を使ってみよう！ 〜 詳細編 〜| Azure 入門 56 [# くらでべ ] https://youtu.be/lCPwtC5w1k8?feature=shared&t=759
50. 具体例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
51. まとめ • プラットフォームエンジニアリングは組織内で標準化されたベストプラクティスを簡単に 利用できるようにしていく活動といえる（なお、定義はさまざま） • 「DevOps、内部開発者、IDP、認知負荷、ゴールデンパス、セルフサービス、テンプ レート」などがプラットフォームエンジニアリングにとりかかる上で重要になりそう • Microsoftにはプラットフォームエンジニアリングを実現するサービスが揃っている ◦ 他のクラウドと比較しても揃っている印象を受けた • プラットフォームエンジニアリングを実現する際は使い慣れたツールを使う ◦ Azureに限定する必要はない 51
52. プラットフォームエンジニアの役割（まとめ） • 内部開発者を顧客としてみるアプローチ • ざまざまなユースケースで負担となっている点を特定すること • チームのプレイヤーであること • 絶えず学び、新しい技術のエバンジェリストになること • 問題解決志向、細部に気を配る、チーム間コミュニケーション • 内部開発者プラットフォームを宣伝、訴求 • DevSecOpsのプラクティスに精通していること 52
53. 53 ここから先はプラットフォームエンジニアリングで参考になる資料集 Tips
54. 54 Platform reference architecture on Azure https://humanitec.com/reference-architectures/azure GitHub：https://github.com/humanitec-architecture/reference-architecture-azure
55. 55 Platform reference architecture on Google Cloud https://github.com/humanitec-architecture/reference-architecture-gcp
56. 56 プラットフォームの組織構造 https://cloud.google.com/architecture/enterprise-application-blueprint/dev eloper-platform-controls?hl=ja
57. 57 Platform reference architecture on AWS https://github.com/humanitec-architecture/reference-architecture-aws
58. 58 Platform tooling landscape https://platformengineering.org/platform-tooling
59. 59 Internal Developer Platform https://internaldeveloperplatform.org/
60. 60 What Is an Internal Developer Platform https://humanitec.com/blog/what-is-an-internal-developer-platform
61. 61 What is platform engineering https://humanitec.com/platform-engineering
62. 62 https://bliki-ja.github.io/TeamTopologies チームトポロジ