持続可能なプラットフォーム目指す、Platform Engineering 支援 / Enabling Platform Engineering

Google Cloud Modern Infra & App Summit Tokyo '24 にて登壇した内容です。

https://cloudonair.withgoogle.com/events/modern-infra-apps-summit-24?talk=session-c2

Transcript

1. 持続可能な プラットフォームを目指す、 Platform Engineering 支援 October 8, 2024 3-shake inc, Annosuke Yokoo |
2. Google Cloud Speaker Introduction • 3-shake inc, ◦ Google Cloud や Kubernetes を中心とした Cloud Native な SRE のプラクティス導入をお手伝い ◦ GKE Autopilot を中心に据えた FinTech サービスの案件 / LLM Infra の案件を担当 • Community : Jagu'e'r O11y-SRE Organizer • Interest : SRE 🦎 / Kubernetes 🚢 / O11y 🔭 Annosuke Yokoo Engineering Team Lead / SRE （@866mfs）
3. Google Cloud SRE / DevOps 内製化支援 クラウド ネイティブ アプリケーション開発支援 GenAI 基盤構築支援 ・AWS, Google Cloud クラウド ネイティブ支援 （Kubernetes に強み） ・AWS, Google Cloud SRE / DevOps 内製化支援 ・CCoE 立ち上げ支援 ・Platform Engineering 支援 データ モダナイゼーション支援 ・パイロット アプリケーション開発支援 ・モダナイゼーション支援 ・バックエンド開発支援（ Go, Python, TypeScript） ・フロントエンド開発支援（ Vue, React） ・BigQuery / Dataplex メインのデータ基盤構築支援 ・BI（Looker）構築をフルスタックで支援 ・Snowflake メインのデータ基盤構築支援 ・DBRE 支援（Spanner / AlloyDB） ・NewSQL（TiDB, YugabyteDB）支援 ・Vertex AI シリーズ構築運用内製化支援 ・外部 SaaS 連携支援 ・Gemini API 導入支援 ・AICoE 立ち上げ支援 ・SRELLM の提供 Sreake の紹介
4. Google Cloud SRE / DevOps 内製化支援 クラウドネイティブアプリケーション開発支援 GenAI 基盤構築支援 ・AWS, Google Cloud クラウドネイティブ支援 （Kubernetes に強み） ・AWS, Google Cloud SRE / DevOps 内製化支援 ・CCoE 立ち上げ支援 ・Platform Engineering 支援 データモダナイゼーション支援 ・パイロットアプリケーション開発支援 ・モダナイゼーション支援 ・バックエンド開発支援（ Go, Python, TypeScript） ・フロントエンド開発支援（ Vue, React） ・BigQuery / Dataplex メインのデータ基盤構築支援 ・BI（Looker）構築をフルスタックで支援 ・Snowflake メインのデータ基盤構築支援 ・DBRE 支援（Spanner / AlloyDB） ・NewSQL（TiDB, YugabyteDB）支援 ・Vertex AI シリーズ構築運用内製化支援 ・外部 SaaS 連携支援 ・Gemini API 導入支援 ・AICoE 立ち上げ支援 ・SRELLM の提供 Sreake の紹介 SRE / DevOps 内製化支援 ・AWS, Google Cloud クラウド ネイティブ支援 （Kubernetes に強み） ・AWS, Google Cloud SRE / DevOps 内製化支援 ・CCoE 立ち上げ支援 ・Platform Engineering 支援 ここのお話をします 🗣
5. Google Cloud Platform Engineering と聞くと、自組織でのチームを起点として始めていく イメージを持つかと思います 今回は「Platform Engineering 支援」というカタチでお客様組織に入る第 3 者的視点からの Platform Engineering についてお話しします
6. Google Cloud Agenda 1. Platform Engineering 支援のカタチとポイント 2. 持続可能なプラットフォームを目指して 3. 知識の継承 4. プラットフォームの継承 5. 最後に
7. Google Cloud 01 Platform Engineering 支援のカタチとポイント
8. Google Cloud 「Gartner - プラットフォーム・エンジニアリングとは何か？ 」より引用 Platform Engineering • 原則や性質や概要図は存在するが、 正解があるわけではなく、現場や開発 者と向かい合って作り上げていく概念 と認識 • 自組織に最適となるよう、開発者体験 と開発生産性向上を目指していき、セ ルフサービスで利用できるツール チェーンとワークフローを設計・構築す る分野
9. Google Cloud Platform Engineering の特性 • Platform as a product • User experience • Documentation and onboarding • Self-service • Reduced cognitive load for users • Optional and composable • Secure by default 「CNCF Platforms White Paper」より引用
10. Google Cloud Documentation and onboarding (1/2) • プラットフォームを利用するための文章や例も重要 • オンボーディングを楽にし、開発者の認知負荷を軽減すべく、コードや機能テンプ レート、ドキュメント等（ゴールデンパス）の提供を目指す • 開発者や運用者の知見や経験が均一化されることにより、トイルが減り、開発生 産性向上が期待できる
11. Google Cloud Documentation and onboarding (2/2) ゴールデンパスの例 • スタートガイド • スケルトン ソースコード • 依存関係の管理 • CI/CD パイプライン テンプレート • Infrastructure as Code 用テンプレート • Kubernetes YAML ファイル • ポリシー ガードレール • ロギングとモニタリング計測 • リファレンス ドキュメント Google Cloud Japan ブログ「 道を照らす : プラットフォーム エンジニアリング、ゴール デンパス、セルフサービスのパワー 」より引用
12. Google Cloud 組織はなぜ、 Platform Engineering を 必要とするのか？
13. Google Cloud Platform Engineering の目的 「CNCF Platforms White Paper」より引用 【White Paper からの解釈】 プロダクト チームの認知的負荷を軽減 し、開発効率を向上させ、ビジネス価値 をより早くユーザーに提供すること
14. Google Cloud プロダクト チームの認知的負荷を軽減 1 開発生産性を向上 2 （顧客の）ビジネス価値 を より早くユーザーに提供 ３ Platform Engineering 支援の目的
15. Google Cloud Platform Engineering のニーズ Platform Engineering 導入を希望するお客様から頂くニーズ • 外部有識者として、伴走型で Platform Engineering の導入を支援して欲しい • 将来的には、エンジニアへの内製化支援をして欲しい • SRE、CCoE、Platform Engineer などのチーム作りから一緒に進めて欲しい Platform Engineering 導入時の課題 • 既存システムに対して適用する際に、どこから初めて良いか分からない • クラウド ネイティブな技術に精通した人材が自社にいない • Platform Engineering 導入による定量的な効果（ ROI）について自社では十分な説明が行えない • Platform Engineering 導入に対応した運用の仕組み・体制が必要となる
16. Google Cloud Platform Engineering 支援においては・・・ Platform Engineering による ビジネス的効果を説明・実践できること が より一層求められる
17. Google Cloud フ ロ ン ト エ ン ド エ ン ジ ニ ア バ ッ ク エ ン ド エ ン ジ ニ ア S R E プロダクト A フ ロ ン ト エ ン ド エ ン ジ ニ ア バ ッ ク エ ン ド エ ン ジ ニ ア S R E プロダクト B ・・・ フ ロ ン ト エ ン ド エ ン ジ ニ ア バ ッ ク エ ン ド エ ン ジ ニ ア S R E プロダクト X 　プラットフォーム チーム Platform Engineering 支援のカタチ 伴走
18. Google Cloud フ ロ ン ト エ ン ド エ ン ジ ニ ア バ ッ ク エ ン ド エ ン ジ ニ ア S R E プロダクト A フ ロ ン ト エ ン ド エ ン ジ ニ ア バ ッ ク エ ン ド エ ン ジ ニ ア S R E プロダクト B ・・・ フ ロ ン ト エ ン ド エ ン ジ ニ ア バ ッ ク エ ン ド エ ン ジ ニ ア S R E プロダクト X 　プラットフォーム チーム Platform Engineering 支援のカタチ 伴走
19. Google Cloud Platform Engineering を導入する際のポイント 小さく始める • 組織体制や開発プロセスの変革を伴う場合が多いため、一気に始めるのでは なく、特定のプロダクトから始め、徐々に範囲を拡大していく 組織文化も変革する • 技術だけでなく組織文化の変革も重要で、開発者が新しい技術を学び、 活用できるよう継続的な教育やサポートが不可欠であり、組織全体で開発プロ セスの変革に対する意識付けを行うことが必要 継続的に改善する • イノベーションを促進する文化と、継続して学び、現状を改善していこうとする意 識が持続可能な Platform Engineering を支える鍵となる 01 02 03
20. Google Cloud 02 持続可能なプラットフォームを目指して
21. Google Cloud ここでいったん本日のタイトルを振り返ってみます
22. 持続可能な プラットフォームを目指す、 Platform Engineering 支援 October 8, 2024 3-shake inc, Annosuke Yokoo | 再掲
23. 持続可能な プラットフォームを目指す、 Platform Engineering 支援 October 8, 2024 3-shake inc, Annosuke Yokoo | 再掲 持続可能な プラットフォームを目指す、 Platform Engineering 支援 「持続可能な 」とは？
24. Google Cloud 少し振り返り：共通プラットフォームは特に新しい話では無い 業種業態問わず、ある一定の規模以上の会社であれば、共通のプラットフォームを 作ろうという話が一度は出ているはず (次世代 | 新) (共通 | 汎用 | 統合) (基盤 | プラットフォーム) みたいな名称のプロジェクト、関与したこともある人も多いのでは？ 「k8sを始める人に知ってもらいたい、 Platform Engineeringの話」より引用
25. Google Cloud そのプラットフォーム 上手くいきましたか？ 「k8sを始める人に知ってもらいたい、 Platform Engineeringの話」より引用
26. Google Cloud 上手くいくプラットフォーム作りは本当に難しい • 上手くいく= 使われる • ある一定のプラットフォームは、使われなくなっている or 負債となっている • ゴールデンパスを整備するだけで、 使われない（持続可能でない） プラットフォームを 作っても意味が無い • 特に「 Platform Engineering 支援」として外部から入る場合ではなおのこと • Platform Engineering 支援という性質上、永続的な関与には限界がある
27. Google Cloud ではどうすれば「 持続可能な 」状態に近づくか？
28. Google Cloud 知識とプラットフォームを継承し、 内製化を促すこと
29. Google Cloud フ ロ ン ト エ ン ド エ ン ジ ニ ア バ ッ ク エ ン ド エ ン ジ ニ ア S R E プロダクト A フ ロ ン ト エ ン ド エ ン ジ ニ ア バ ッ ク エ ン ド エ ン ジ ニ ア S R E プロダクト B ・・・ フ ロ ン ト エ ン ド エ ン ジ ニ ア バ ッ ク エ ン ド エ ン ジ ニ ア S R E プロダクト X 　プラットフォームチーム 知識とプラットフォームの両面から継続的にアプローチする 知識 プラットフォーム 伴走
30. Google Cloud 持続可能な プラットフォームに必要な要素
31. Google Cloud Platform Engineering の特性 • Platform as a product • User experience • Documentation and onboarding • Self-service • Reduced cognitive load for users • Optional and composable • Secure by default 再掲
32. Google Cloud Platform as a Product • プラットフォームはユーザー（ 開発者）の要求を答えるた めに存在する • プロダクト・ユーザー・バックログと、Platform Engineering の設計ループをプロダクト開発 として捉え、 成熟度に応じて再考して価値に繋げていく • ユーザーリサーチを実施して優先事項をより深く理解する ことで、ユーザー重視の姿勢を強めることが持続可能なプ ラットフォームにつながると考えている • 開発者がユーザーであり、プラットフォームを開発者に 提供するプロダクトとして位置付けて整備するため、持 続可能なプラットフォームとなる 「Laying the foundation for a career in platform engineering」より引用
33. Google Cloud プラットフォームは 静的なものではなく、 組織の成熟度に合わせて進化 していくべきもの
34. Google Cloud 03 知識の継承
35. Google Cloud 知識とプラットフォームを継承し、 内製化を促すこと 再掲 知識 再掲
36. Google Cloud 「知識」の前提 知識創造企業 (新装版) - 野中　郁次郎著／竹内　弘高著／梅本　勝博訳 「暗黙知」と「形式知」の意味や具体例とは？ 形式知化する「ナレッジマネジメント」のポイントや企業事例も紹介 暗黙知 • 経験や直感に基づく、言葉や文章で明確に表現することが難しい知識 • 主観的であり、個人の感覚的なものであるため他者に共有し辛い • 同じ体験 / 感覚を共有する必要があるため、同期的な知識移転とな る 　　 形式知 • 文章や図表などの形式で表現される知識 • 客観的 / 論理的であり、他者に共有し易い • 非同期的に知識を移転できる
37. Google Cloud 「知識」とは？ 知識創造企業 (新装版) - 野中　郁次郎著／竹内　弘高著／梅本　勝博訳 「暗黙知」と「形式知」の意味や具体例とは？ 形式知化する「ナレッジマネジメント」のポイントや企業事例も紹介 暗黙知 • 経験や直感に基づく、言葉や文章で明確に表現することが難しい知識 • 主観的であり、個人の感覚的なものであるため他者に共有し辛い • 同じ体験 / 感覚を共有する必要があるため、同期的な知識の移転となる 　　 形式知 • 文章や図表などの形式で表現される知識 • 客観的 / 論理的であり、他者に共有し易い • 非同期的に知識を移転出来る 自分達の暗黙知を形式知に落とし込み、 どのようにクライアントの暗黙知へと変換させるかが鍵！
38. Google Cloud 知識創造企業 (新装版) - 野中　郁次郎著／竹内　弘高著／梅本　勝博訳 : SECIモデルとは? 必要な4つのステップと創出すべき環境 知識創造のためのプロセス： SECI モデル 共同化 （Socialization） 表出化 （Externalization） 内面化 （Internalization） 連結化 （Combination） 暗 黙 知 暗黙知 暗黙知 形 式 知 形 式 知 形式知 形式知 暗 黙 知
39. 共同化 （Socialization） 表出化 （Externalization） 内面化 （Internalization） 連結化 （Combination） 暗 黙 知 暗黙知 暗黙知 形 式 知 形 式 知 形式知 形式知 暗 黙 知 ・共同化は、経験を共有することに 　よって、技術やメンタルモデルなどの 　暗黙知を移転するステップのこと ・直接的な経験の他、観察や模倣なども 　含まれる 知識創造のためのプロセス： SECI モデル
40. 共同化 （Socialization） 表出化 （Externalization） 内面化 （Internalization） 連結化 （Combination） 暗 黙 知 暗黙知 暗黙知 形 式 知 形 式 知 形式知 形式知 暗 黙 知 ・表出化は、個人の暗黙知を言語などの形　式 的なものに変換するステップのこと ・主観的 / 直感的な共同化と違い、客観的 / 　論 理的に伝えることが可能である 知識創造のためのプロセス： SECI モデル
41. 共同化 （Socialization） 表出化 （Externalization） 内面化 （Internalization） 連結化 （Combination） 暗 黙 知 暗黙知 暗黙知 形 式 知 形 式 知 形式知 形式知 暗 黙 知 ・連結化は、表出化で生み出した形式知同　士 を組み合わせ、新たな形式知を創造す　るス テップのこと 知識創造のためのプロセス： SECI モデル
42. 共同化 （Socialization） 表出化 （Externalization） 内面化 （Internalization） 連結化 （Combination） 暗 黙 知 暗黙知 暗黙知 形 式 知 形 式 知 形式知 形式知 暗 黙 知 ・内面化は、今までの形式知を自身の暗黙　知 へと変換させるステップのこと ・実践を通じて暗黙知を体得する 知識創造のためのプロセス： SECI モデル
43. Google Cloud 知識の継承には、 SECI モデルをサイクル化する 共同化 （Socialization） 表出化 （Externalization） 内面化 （Internalization） 連結化 （Combination） 暗 黙 知 暗黙知 暗黙知 形 式 知 形 式 知 形式知 形式知 暗 黙 知 　実演　 　実践　 　発展　 　知識移転　
44. Google Cloud フ ロ ン ト エ ン ド エ ン ジ ニ ア バ ッ ク エ ン ド エ ン ジ ニ ア S R E プロダクト A フ ロ ン ト エ ン ド エ ン ジ ニ ア バ ッ ク エ ン ド エ ン ジ ニ ア S R E プロダクト B ・・・ フ ロ ン ト エ ン ド エ ン ジ ニ ア バ ッ ク エ ン ド エ ン ジ ニ ア S R E プロダクト X 　プラットフォーム チーム 知識とプラットフォームの両面から継続的にアプローチする 知識 プラットフォーム 伴走 知識 日々の取り組みの中で、 知識継承のサイクルを繰り返し、 顧客の暗黙知に落とし込んでいく
45. Google Cloud 「 SRE NEXT 2024 - 内製化を見据えた効果的な SRE支援のアプローチ 」から掲載
46. Google Cloud 04 プラットフォームの継承
47. Google Cloud 知識とプラットフォームを継承し、 内製化を促すこと 再掲 　　　プラットフォーム 再掲
48. Google Cloud Documentation and onboarding (2/2) ゴールデンパスの例 • スタートガイド • スケルトンソースコード • 依存関係の管理 • CI/CD パイプラインテンプレート • Infrastructure as Code 用テンプレート • Kubernetes YAML ファイル • ポリシーガードレール • ロギングとモニタリング計測 • リファレンスドキュメント 「道を照らす : プラットフォーム エンジニアリング、ゴールデンパス、セルフサービスの パワー」より引用 すでにあるプラットフォーム上で 「スモールかつオプショナル 」に導入 しやすところから始める！
49. Google Cloud ゴールデンパスの構成 現在ではほとんどのクラウドプロバイダが、オープンイニシア ティブの成功を推進する CNCF プロジェクトに関与していま す。 これにより各クラウドプロバイダが、門戸を閉ざさずにオープ ンイノベーションを実施できるようになります。 Mauricio Salatino「 Platform Engineering on Kubernetes 」 1.2.2 「CNCF Landscape 」のパズル より引用
50. Google Cloud 「 Platform Engineering on Kubernetes 」より引用 ゴールデンパスの構成 現在ではほとんどのクラウドプロバイダが、オープンイニシア ティブの成功を推進する CNCF プロジェクトに関与していま す。 これにより各クラウドプロバイダが、門戸を閉ざさずにオープ ンイノベーションを実施できるようになります。 Mauricio Salatino「 Platform Engineering on Kubernetes 」 1.2.2 「CNCF Landscape 」のパズル より引用 ベンダーロックインしない OSS をベースとしながらも マネージドなクラウド プラットフォームの良さを踏襲できるようなカタチとすることで、 プラットフォームの「持続性」を図る
51. Google Cloud マルチプロダクトを GKE 上で動かす組織を 例にゴールデンパスを少しご紹介 󰢧
52. Google Cloud CI/CD パイプラインテンプレート例 (1/2） アプリケーション CI パイプライン K8s マニフェスト CI パイプライン CD パイプライン
53. Google Cloud CI/CD パイプラインテンプレート例 (2/2） 「マルチプロダクトの組織でマイクロサービスアーキテクチャを支 えるCICDプラットフォーム設計」より引用 Helm チャート • Helm lint 　✅ Helm チャート構造の誤りを検出 Kubernetes マニフェスト • Kubeconform 　✅ Kubernetes リソースの YAML ファイルをスキーマに基づい て検証（文法の誤りを検出） • Pluto 　✅ Kubernetesリソースの非推奨APIを検出 • Polaris 　❌ Kubernetesのリソースがベストプラクティスに準拠している か評価 • Trivy 　✅ Kubernetesのマニフェストの脆弱性や設定ミスを検出
54. Google Cloud ポリシー ガードレール - GKE Policy Controller (1/2) GKE Policy Controller • GKE Policy Controller は OPA（Open Policy Agent） の Gatekeeper ベースのサービスで、ポリシーを設定してポリシーに 違反する API リクエストを監査したり、ブロックしたりすることが可能 ◦ CIS Kubernetes Benchmark / PCI-DSS ◦ GKE Enterprise 限定の機能 ◦ 制約テンプレート ライブラリにより、デフォルトでポリシー ライブラリがインストールされている ◦ Example : ▪ 各 Namespace に 1 つ以上のラベルがあることを必須とする制約 ▪ 指定されたコンテナ イメージを pull できるリポジトリを制限する制約 ▪ コンテナを特権モードで実行できるかどうかを制御する制約
55. Google Cloud ポリシー ガードレール - GKE Policy Controller (1/2) GKE Policy Controller ✖ Security Command Center • Security Command Center と統合されているので、ポリシー違反をダッシュボード上から確認できる
56. Google Cloud フ ロ ン ト エ ン ド エ ン ジ ニ ア バ ッ ク エ ン ド エ ン ジ ニ ア S R E プロダクト A フ ロ ン ト エ ン ド エ ン ジ ニ ア バ ッ ク エ ン ド エ ン ジ ニ ア S R E プロダクト B ・・・ フ ロ ン ト エ ン ド エ ン ジ ニ ア バ ッ ク エ ン ド エ ン ジ ニ ア S R E プロダクト X 　プラットフォームチーム 知識とプラットフォームの両面から継続的にアプローチする 知識 プラットフォーム 伴走 スモールかつオプショナルにできると ころからはじめ、持続可能な技術で 構成していく プラットフォーム
57. Google Cloud 05 最後に
58. Google Cloud 最後に • Platform Engineering 支援はビジネス的効果をより一層意識する必要がある • 大切なのは、自組織（お客様組織）のコンテキストを深く理解し、 そこに適した形で Platform Engineering の考え方を継続的に取り入れていくこと • Platform Engineering 支援においては、知識とプラットフォームを継承し、 内製化を促すことが持続可能なプラットフォームにつながる • 内製化の先には、Platform Engineering のプラクティスを自分たちなりに解釈して、 組織やプラットフォームと向き合い、継続的に改善を続けた先に、 あなた (の組織)らしい Platform Engineering が実現される
59. Thank you |