チームトポロジーに見るKubernetes×PlatformEngineeringの目指す姿 / Team Topologies Kubernetes Platform Engineering

2024/07/04 Platform Engineering Meetup #9

Transcript

1. Version number here V00000 チームトポロジーに見る Kubernetes × Platform Engineeringの目指す姿 Shintaro Kitamura Specialist Solution Architect Red Hat K.K. Platform Engineering Meetup #9
2. 2 北村 慎太郎 Red Hat - Specialist Solution Architect - OpenShiftを中心としたプリセールス 得意領域：SRE, Automation, CICD Backstage 修行中 #Kubernetes #OpenShift #AWS #GCP #Terraform
3. 3 Today is ...
 話すこと Kubernetes環境に対して、どのようにチームトポロジーの組織論とPlatform Engineeringの取り組 みを適用していくのか？ 話さないこと Platform Engineering および チームトポロジーそのものの細かい説明 注意ポイント “DevOpsを成功させるためのチームを構成するアプローチには、万能のものはない” →今日の紹介内容もあくまで一例 出典：『チームトポロジー』（マシュー・スケルトン、マニュエル・パイス著、原田騎郎、永瀬美穂、吉羽龍太郎 訳、日本能率協会マネジメントセンター 、2021、p.79）
4. 4 Team Topologies
 効果的なソフトウェア開発を実現するために、 組織内のチームの配置や構造、コミュニケーションのパターンを設計・最適化する方法論 チームトポロジー
 価値あるソフトウェアをすばやく届ける適応型組織設計 
 Platform Engineerの聖書 30分で分かった気になる
 チームトポロジー
 ＠吉羽 龍太郎さん https://www.ryuzee.com/contents/blog/14566 『チームトポロジー』と 
 Platform Engineering
 ＠永瀬 美穂さん https://speakerdeck.com/miholovesq/team -topologies-with-platform-engineering
5. 5 Team Topologies × Platform Engineering なぜ？
6. 6 組織構造と技術の整合性を図る
 Team Topologies 効果的なソフトウェア開発のための 組織構造とチームの配置に 焦点を当てる Platform Engineering 効果的なソフトウェア開発のための 共通インフラとツールを提供することに 焦点を当てる 技術論 組織全体の効率性と生産性を最大化 組織論 SRE も スクラム も DevOps も ぜ〜んぶ 組織論と技術論の組み合わせ
7. 7 4つのチームと3つの関係性 ストリームアラインドチーム 特定のサービスのエンドツーエンドのデリバリーに 責任を持つチーム イネイブリングチーム 他のチームが効果的に働くためにサポートし、 スキルや知識の向上を助けるチーム コンプリケイテッド・サブシステムチーム 専門知識が必要な複雑なサブシステムの開発を 担当するチーム プラットフォームチーム 他のチームが迅速かつ効率的に製品をデリバリーでき るよう、共通のプラットフォームやサービスを提供する チーム。 複数のチームが密接に連携し、短期間に共 同作業を行い特定の目標を達成する 一つのチームが他のチームに対してサービ スや機能を提供し、利用者がこれを要求に 応じて使用する あるチームが他のチームを支援し、 障害の除去や学習の促進を行う 出典：『チームトポロジー』（マシュー・スケルトン、マニュエル・パイス著、原田騎郎、永瀬美穂、吉羽龍太郎 訳、日本能率協会マネジメントセンター 、2021、はじめに xv）
8. 8 チームトポロジーの基本形 論理プラットフォーム プラットフォームチーム ストリームアラインドチーム ストリームアラインドチーム コンプリケイテッド・ サブシステムチーム フロー プラットフォームチーム ストリームアラインドチーム ストリームアラインドチーム イネイブリングチーム コンプリケイテッド・ サブシステムチーム 4つの基本的なチームタイプのための インタラクションモードの基本形 複数の基本的なチームタイプで構成するプラットフォーム 出典：『チームトポロジー』（マシュー・スケルトン、マニュエル・パイス著、原田騎郎、永瀬美穂、吉羽龍太郎 訳、日本能率協会マネジメントセンター 、2021、p.117、p.177）
9. 9 組織の成熟度に応じて役割や体制を変化させる 頻繁に コラボレーションし エンドツーエンドで オーナーシップを 持つチーム 信頼性に注力する、 エンドツーエンドチー ムと 専門チームの両方 強力な コラボレーションを 行う専門チーム サービスとしての プラットフォームに依 存する専門チーム エ ン ジ ニ ア リ ン グ の 成 熟 度 組織のサイズやソフトウェアの規模 低 高 低 高 高 低 高 低 スタートアップ、SaaS系企業の成長フロー 開発プロジェクト主導で CloudNativeを推進 エンタープライズ企業、情シスの成長フロー プラットフォーム主導で CloudNativeを推進 今日はこっちのテーマ 出典：『チームトポロジー』（マシュー・スケルトン、マニュエル・パイス著、原田騎郎、永瀬美穂、吉羽龍太郎 訳、日本能率協会マネジメントセンター 、2021、p.88） 規模、エンジニアリングの成熟度、技術選択の影響
10. 10 プラットフォーム主導でクラウドネイティブを推進 俺の出番だろ
12. 12 小さくはじめて大きくしていく
13. 13 開発プロジェクトチーム内にプラットフォーム担当者も参画 アプリ開発担当者 ビジネス企画/推進 プラットフォーム 担当者 単一のサービス開発 サービス提供チーム （ストリームアラインドチーム） Collaborate 将来共通プラットフォームを管理するメンバーが 開発チームの一員としてプロジェクトに参画 頻繁に コラボレーションし エンドツーエンドで オーナーシップを 持つチーム 信頼性に注力する、エン ドツーエンドチームと専門 チームの両方 強力な コラボレーションを 行う専門チーム サービスとしての プラットフォームに依存す る専門チーム エ ン ジ ニ ア リ ン グ の 成 熟 度 組織のサイズやソフトウェアの規模 プラットフォームチーム 規模感 スクラムチーム： 1 〜 2 チーム プラットフォームチーム： 1 〜 2 名 Step 1 : 単一のコラボレーションチーム
14. 14 プラットフォームチーム Step 1 の構成例 • Web3層規模のアプリから開始 • インフラは作成・削除が簡単なパブリッククラウドを利用 • アジャイル開発用のツールや、Git、CICDツールを導入して開発 スピードを向上 　👉このプロダクト特化のものでOK • 一般的な非機能の要素は押さえる ◦ モニタリング ◦ セキュリティ対策 ◦ バージョン管理 ◦ ロギング ◦ バックアップ ◦ キャパシティ管理 Public Cloud Development Production Database Web AP Database Web AP CICD Git Wiki/Ticket Non-functional requirement Monitoring Security Backup Capacity Version Logging Registry 頻繁に コラボレーションし エンドツーエンドで オーナーシップを 持つチーム 信頼性に注力する、エン ドツーエンドチームと専門 チームの両方 強力な コラボレーションを 行う専門チーム サービスとしての プラットフォームに依存す る専門チーム エ ン ジ ニ ア リ ン グ の 成 熟 度 組織のサイズやソフトウェアの規模
15. Step 2 : プラットフォームのサービス化に着手 15 アプリ開発担当者 ビジネス企画/推進 Embedded アプリ開発担当者 ビジネス企画/推進 Embedded Collaborate Collaborate プラットフォームチームを組成しつつ、引き続きプロジェクト単位にアサイン 担当者間でプロジェクトで培ったノウハウを連携 プラットフォーム 担当者 プラットフォーム 担当者 情報連携 規模感 スクラムチーム： 3 〜 10 チーム プラットフォームチーム： 3 〜 5 名 プラットフォームチームに所属しながら、 各PJにEmbedded サービス提供チーム （ストリームアラインドチーム） サービス提供チーム （ストリームアラインドチーム） 頻繁に コラボレーションし エンドツーエンドで オーナーシップを 持つチーム 信頼性に注力する、エン ドツーエンドチームと専門 チームの両方 強力な コラボレーションを 行う専門チーム サービスとしての プラットフォームに依存す る専門チーム エ ン ジ ニ ア リ ン グ の 成 熟 度 組織のサイズやソフトウェアの規模 プラットフォームチーム
16. Step 2 の構成例 16 プラットフォームチーム Aプロダクト環境 Bプロダクト環境 Development CI/CD CI/CD Security Security A Function B Function B Function C Function Staging 連携 Production Monitoring Monitoring ‥ ‥ IaC / GitOps (K8s Manifest) / Operator IaC / GitOps (K8s Manifest) / Operator デリバリー & 管理 プラットフォームチー ム ②初めて導入するプラットフォーム機能は 　PJ個別で導入検討する 　(ServiceMesh/Serverless/APMなど) ④部分的にIaCの導入や 　Operatorによる運用自動化を目指す ⑤プラットフォームメンバー同士 　で情報共有し、個別機能／共通機能　 の実装・運用ノウハウを蓄積 ①プロダクトごとに 　K8sクラスターを構築 ③共通的な機能は今後の 　横展開を見据えたツールを選定 アプリ開発担当 アプリ開発担当 ・・・ ・・・ ・・・ Development Staging Production 頻繁に コラボレーションし エンドツーエンドで オーナーシップを 持つチーム 信頼性に注力する、エン ドツーエンドチームと専門 チームの両方 強力な コラボレーションを 行う専門チーム サービスとしての プラットフォームに依存す る専門チーム エ ン ジ ニ ア リ ン グ の 成 熟 度 組織のサイズやソフトウェアの規模
17. Step 3 : 組織文化レベルの体制を目指す 17 アプリ開発担当者 ビジネス企画/推進 アプリ開発担当者 ビジネス企画/推進 SRE アプリ開発担当者 ビジネス企画/推進 アプリ運用担当者 アプリ運用担当者 アプリ運用担当者 Collaborate Collaborate Collaborate SREチームからインフラ共有リソースが提供され、 Platform Engineeringチームから開発テンプレートとノウハウが提供される。 プラットフォームチーム 規模感 スクラムチーム： 10 〜 チーム プラットフォームチーム： 5 〜 10 名 SRE Platform Engineeringチーム サービス提供チーム （ストリームアラインドチーム） サービス提供チーム （ストリームアラインドチーム） サービス提供チーム （ストリームアラインドチーム） 頻繁に コラボレーションし エンドツーエンドで オーナーシップを 持つチーム 信頼性に注力する、エン ドツーエンドチームと専門 チームの両方 強力な コラボレーションを 行う専門チーム サービスとしての プラットフォームに依存す る専門チーム エ ン ジ ニ ア リ ン グ の 成 熟 度 組織のサイズやソフトウェアの規模 ストリームアラインドチームにリリース戦略やCIを 検討する専任者をアサインし、 Platform EngineeringチームがEnablingを行う
18. Multi Cluster Management (モニタリング/セキュリティ/etc…) 18 GoldenPath (Rule & Process) Aプロダクト環境 CI/CD Security K8sクラスター Monitoring ‥ 操作/管理 IDP - Developer Portal A Function B Function B IDP - Developer Portal B Function 操作/管理 C IDP - Developer Portal C Function 操作/管理 イネイブリングチーム テクニカル チーム スペシャリスト チーム 連携 モニタリング チーム アプリ開発担当 アプリ開発担当 IaC / GitOps (K8s Manifest) / Operator プラットフォーム デリバリーチーム インフラリソースの 作成・管理 Golden Pathの 作成・更新 論理プラットフォーム アプリ開発担当 アプリ運用担当 アプリ運用担当 アプリ運用担当 SRE SRE PFE PFE PFE Step 3 の構成例
19. 19 Aプロダクト環境 CI/CD Security K8sクラスター Monitoring ‥ B C アプリ開発担当 アプリ開発担当 IaC / GitOps (K8s Manifest) / Operator プラットフォーム デリバリーチーム インフラリソースの 作成・管理 論理プラットフォーム アプリ開発担当 アプリ運用担当 アプリ運用担当 アプリ運用担当 ①プロダクトのサービスレベルに応じて 　複数のテンプレートの中からクラスターを自動デプロイ （Nodeの台数、スペックやマルチクラスターなど） IDP - Developer Portal IDP - Developer Portal IDP - Developer Portal SRE Step 3 の構成例
20. 20 Aプロダクト環境 CI/CD Security K8sクラスター Monitoring ‥ B C アプリ開発担当 アプリ開発担当 IaC / GitOps (K8s Manifest) / Operator プラットフォーム デリバリーチーム インフラリソースの 作成・管理 論理プラットフォーム アプリ開発担当 アプリ運用担当 アプリ運用担当 アプリ運用担当 ②アプリ開発担当者は開発テンプレート（Golden Path）から 　自分のアプリに合ったものを選択して、ポータルから 　デプロイ IDP - Developer Portal IDP - Developer Portal IDP - Developer Portal GoldenPath (Rule & Process) SRE Step 3 の構成例
21. 21 Aプロダクト環境 CI/CD Security K8sクラスター Monitoring ‥ B C アプリ開発担当 アプリ開発担当 IaC / GitOps (K8s Manifest) / Operator プラットフォーム デリバリーチーム インフラリソースの 作成・管理 論理プラットフォーム アプリ開発担当 アプリ運用担当 アプリ運用担当 アプリ運用担当 IDP - Developer Portal IDP - Developer Portal IDP - Developer Portal GoldenPath (Rule & Process) イネイブリングチーム ③コンテナやK8sでの開発が初めてのPJには 　イネイブリングチームがK8s環境操作、マニフェスト書き方など　のレク チャーおよび各種支援を実施 ④必要に応じてGolden Pathのチューニングを行う PFE SRE Step 3 の構成例
22. 操作/管理 操作/管理 操作/管理 22 Aプロダクト環境 CI/CD Security K8sクラスター Monitoring ‥ B C アプリ開発担当 アプリ開発担当 IaC / GitOps (K8s Manifest) / Operator プラットフォーム デリバリーチーム インフラリソースの 作成・管理 論理プラットフォーム アプリ開発担当 アプリ運用担当 アプリ運用担当 アプリ運用担当 IDP - Developer Portal IDP - Developer Portal IDP - Developer Portal GoldenPath (Rule & Process) イネイブリングチーム A Function B Function B Function C Function ⑤デリバリーされた環境上で 　開発のサポートや 　CICDパイプラインの整備などを実施 ⑥テンプレートで不足している 　機能は案件個々に導入を検討 PFE SRE Step 3 の構成例
23. 操作/管理 操作/管理 操作/管理 23 Aプロダクト環境 CI/CD Security K8sクラスター Monitoring ‥ B C アプリ開発担当 アプリ開発担当 IaC / GitOps (K8s Manifest) / Operator プラットフォーム デリバリーチーム インフラリソースの 作成・管理 アプリ開発担当 アプリ運用担当 アプリ運用担当 アプリ運用担当 IDP - Developer Portal IDP - Developer Portal IDP - Developer Portal GoldenPath (Rule & Process) イネイブリングチーム A Function B Function B Function C Function テクニカル チーム スペシャリスト チーム 連携 Golden Pathの 作成・更新 ⑦イノベーション加速＆信頼性向上に 　つながる技術の調査や導入検討を実施 ⑨プロダクト個々に導入した機能の 　共通化を検討し、Golden Pathに反映 論理プラットフォーム ⑧必要に応じてテクニカルチームや 　アプリ運用担当と連携して技術課題を解決 SRE PFE PFE PFE Step 3 の構成例
24. プラットフォーム デリバリーチーム Multi Cluster Management (モニタリング/セキュリティ/etc…) モニタリング チーム 操作/管理 操作/管理 操作/管理 24 Aプロダクト環境 CI/CD Security K8sクラスター Monitoring ‥ B C アプリ開発担当 アプリ開発担当 IaC / GitOps (K8s Manifest) / Operator インフラリソースの 作成・管理 アプリ開発担当 アプリ運用担当 アプリ運用担当 アプリ運用担当 IDP - Developer Portal IDP - Developer Portal IDP - Developer Portal GoldenPath (Rule & Process) イネイブリングチーム A Function B Function B Function C Function テクニカル チーム スペシャリスト チーム 連携 Golden Pathの 作成・更新 論理プラットフォーム ⑩マルチクラスター管理ツールや 　統合監視ツールを活用して 　プラットフォームレイヤの管理を実施 SRE PFE PFE PFE SRE Step 3 の構成例
25. 25 Role Responsibility Tasks 開発スピードの向上 アプリケーションの品質担保 • システムアーキテクチャの検討 • アプリコード、テストコード作成 • DBテーブル設計 • スクラムイベントの遂行 • アプリログの設計 • アプリメトリクスの設計 • アプリのセキュリティ対策 • リリース戦略の策定支援 インフラ・プラットフォームの信頼性の担保 環境構築／開発スピード向上支援 • プラットフォームのサービス仕様の定義 ◦ 　SLO ◦ 　ライフサイクル ◦ 　アップグレード方針 ◦ 　メンテナンスタイム ◦ 　クラスターデリバリ方針 ◦ 　バックアップ・リストア(RPO/RTOなど) ◦ 　セキュリティ対策 • プラットフォームのモニタリング・アラート対応 • プラットフォーム拡張機能の実装・管理 ◦ 　データストア/CDN/DNSなど ◦ 　Operator ◦ 　コンテナレジストリ • プラットフォームのキャパシティ管理・増設判断 • IDP(Internal Developer Portal)の構築 リリースのプロセス改善 アプリケーションの信頼性の向上 • CICDパイプラインの管理 • K8sマニフェストの管理 • Gitのブランチ戦略の策定 • Appの非機能要件の定義 ◦ SLO ◦ ライフサイクル ◦ デプロイ手法 ◦ バックアップ・リストア • Appのモニタリング・アラート対応 • コンテナイメージのセキュリティ対策 開発プロセスのEnabling 標準化 • CICDパイプラインの標準化(リリースプ ロセス、テストプロセス) • K8sマニフェストのガバナンス策定 • ブランチ戦略の策定 • マイクロサービス開発移行プロセス(モ ダナイズ)のパターン化 • コンテナイメージのセキュリティチェック 標準化 • Golden Pathの作成・メンテナンス • アプリ運用担当へのレクチャー Platform Engineering チーム SREチーム アプリ開発担当 アプリ運用担当 ストリームアラインドチーム プラットフォームチーム Role & Responsibility 例
26. 26 Platform Engineeringにおけるチームトポロジー 論理プラットフォーム プラットフォームチーム ストリームアラインドチーム ストリームアラインドチーム ストリームアラインドチーム コンプリケイテッド・ サブシステムチーム イネイブリング チーム イネイブリング チーム コンプリケイテッド・ サブシステムチーム ストリームアラインドチーム
27. Version number here V00000 linkedin.com/company/red-hat youtube.com/user/RedHatVideos facebook.com/redhatinc twitter.com/RedHat 27 Red Hat is the world’s leading provider of enterprise open source software solutions. Award-winning support, training, and consulting services make Red Hat a trusted adviser to the Fortune 500. Thank you