k8sを始める人に知ってもらいたい、Platform Engineeringの話

Kubernetes Novice Tokyo #23 で登壇した資料です
https://k8s-novice-jp.connpass.com/event/274994/

Transcript

1. K8sを始める人に 知ってもらいたい Platform Engineeringの話
2. Kazuto Kusama @jacopen Senior Solutions Engineer @HashiCorp Japan Co-Chair @CloudNative Days Organizer @PaaSJP Organizer @Platform Engineering Meetup
3. みなさんの役割は？ • 開発者としてk8sを利用している • K8sをつかったプラットフォームづくりの担当 • k8sを使いたいなーと思って情報収集している
4. k8s使ってみてどう思いましたか？ • おもしろい！ • 難しい！ • 是非自社の環境にも採用したい！
5. k8s使ってみてどう思いましたか？ • おもしろい！ • 難しい！ • 是非自社の環境にも採用したい！ ⇒ 良い話だと思います
6. クラウドネイティブ技術を試すときは 会社によっては、新しいものを試すときは、 計画立てや採用する根拠を求められるケースがあります。 ですが、あまり机上の検討にこだわりすぎず、 まずは手を動かして試してみるのがお勧めです。 なぜなら、技術の進歩が激しいため、机上で検討している間に 状況が変わってしまうことが多いからです。
7. ただし もしk8sを『社内の共通プラットフォーム』として採用しよう と思っている場合は、技術面以外も考慮したほうがいいかもし れません。
8. Platform Engineering
9. Platform Engineeringとは 決まった定義はまだない Gartner: アプリケーションのデリバリとビジネス価値の創出を加速させるための、テクノロジに対する新しいアプロー チ プラットフォーム・エンジニアリングは、再利用可能なツールとセルフサービス機能を実装し、インフラスト ラクチャ・オペレーションを自動化することで、開発者のエクスペリエンスと生産性を向上させる Platformengineering.org : クラウドネイティブ時代のソフトウェアエンジニアリング組織のセルフサービス機能を実現するツールチェー ンとワークフローを設計・構築する分野 プラットフォームエンジニアは、アプリケーションのライフサイクル全体の運用に必要なものを網羅する、 「内部開発者プラットフォーム」と呼ばれる統合製品を提供することが多い。
10. Platform Engineeringとは 開発者体験と生産性を向上させるために セルフサービスで利用できるツールチェーンとワークフローを 設計・構築する分野
11. k8sとDevOps
12. クラウドの登場とDevOps Dev Ops Configure Verify Package Plan Monitor Release Create Plan DevとOpsの垣根をなくし、ソフトウェアの開発とデリバリーを継続して行えるよ うにするアプローチ。 このプロセスの中にセキュリティ対策を組み込むDevSecOpsというパターンも登 場した
13. 真のDevOps “You build it, you run it” 開発者が、アプリをエンドツーエンドでデプロイし、実行する
14. 真のDevOps “You build it, you run it” 開発者が、アプリをエンドツーエンドでデプロイし、実行する ただし、多くの組織にとって現実的ではない
15. 真のDevOps 開発者が、アプリをエンドツーエンドでデプロイし、実行する ただし、多くの組織にとって現実的ではない Kubernetes Buildkit Helm Dockerfile Grafana Prometheus GitHub Actions React Next.js Security Node.js Terraform ArgoCD APM Compliance 認知負荷が 高すぎる これをやり切れ る人材は少ない
16. 認知負荷の増大 https://www.infoq.com/articles/platform-engineering-primer/ より引用 特にk8sを中心とした クラウドネイティブ技術の 認知負荷まじやばい
17. じゃあどうするか
18. o11y Repository CI/CD Container Golden Path プラットフォームチームが適切な抽象化とセルフサービス化によって ゴールデンパスを作る Kubernetes Buildkit Helm Dockerfile Grafana Prometheus GitHub Terraform ArgoCD APM IDP Developer Platform Team self service
19. Internal Developer Platform プラットフォームチームによって構築される、開発者のセルフサービスによる利 用を可能にする基盤。 さまざまな技術やツールによって構成され、コンテキストや基礎となる技術を抽 象化しすぎることなく、開発者の認知負荷を軽減していく Developer Platform Team self service o11y Repository CI/CD Container Kubernetes Buildkit Helm Dockerfile Grafana Prometheus GitHub Terraform ArgoCD APM IDP
20. Team Topologies 価値のあるソフトウェアを素早く届けられるよ うにするための組織設計。 4タイプのチーム定義と、3つのインタラクショ ンモードが定義されている。 Platform TeamがStream-aligned Teamに、 XaaSの形で関与するのがIDPの話に近い。 (実際にはもっとネストされたパターンもある)
21. よく陥るアンチパターン Ops Embedded in Dev Team DevとOpsのサイロ化を防ごうとした結果、Devチー ムの中にOpsを担う人材を抱えるようになる 多くの場合、幅広い知見を持つ、チームの中でもっ とも価値のあるエンジニアが シャドーオペレーションを行う形になる 結果として、チームの能力を最大限に発揮すること ができなくなる https://web.devopstopologies.com/#anti-types より引用
22. 注 例では分かりやすさ優先でOSSのツールを並 べているが、IDPは自前のツールやOSSに限 る必要は無い パブリッククラウドを使いつつ、そのマネー ジドサービスを活用したゴールデンパスも普 通にあり得る (むしろそっちがメジャー) Kubernetes Buildkit Helm Dockerfile Grafana Prometheus GitHub Actions Security Terraform ArgoCD APM Compliance IDP
23. IDPは分かったけど、 これって別に新しい話じゃないよね？
24. 共通プラットフォームは特に新しい話では無い 業種業態問わず、ある一定の規模以上の会社であれば、 共通のプラットフォームを作ろうという話が一度は出ているはず。 (次世代|新)(共通|汎用|統合)(基盤|プラットフォーム) みたいな名称のプロジェクト、関与したことある人も多いのでは
25. そのプラットフォーム 上手くいきましたか？
26. 上手くいくプラットフォーム作りは、本当に難しい • 4割の共通プラットフォームは、生まれながらに死んでいる • 4割の共通プラットフォームは、上手く運用出来ずに死んでいく • 成功するのは2割か、それ以下 (注: jacopenの感覚値なので数字に根拠はありません！)
27. 共通プラットフォームの失敗とは 失敗したプラットフォーム = あまり使われないプラットフォーム
28. 共通プラットフォームの失敗とは 失敗したプラットフォーム = あまり使われないプラットフォーム 何故使われないのか = そのプラットフォームに価値がないから
29. 価値とは 『誰にとっての価値か』が大事 プラットフォームにとって、価値があるかないか判断をするのは 『プラットフォームの利用者』 つまり 『開発者』 開発者に価値を提供できなければ、そのプラットフォームは失敗している
30. 誰に 何を どうやって
31. 誰に 何を どうやって 失敗するプラットフォームは ここばかり気にする
32. どうやって 時代はマイクロサービスでしょ VMは古い。今はコンテナ 全社統一のセキュリティ コ ンプライアンス基準を リソースの利用率を向上さ せてコスト削減 コンテナ Kubernetes サービス メッシュ 分散トレー シング オブザーバ ビリティ
33. どうやって 時代はマイクロサービスでしょ VMは古い。今はコンテナ 全社統一のセキュリティ コ ンプライアンス基準を リソースの利用率を向上さ せてコスト削減 コンテナ Kubernetes サービス メッシュ 分散トレー シング オブザーバ ビリティ Developer 別にコンテナにしなくても困っ てないし、マイクロサービスに するフェーズじゃないし･･･ セキュリティも、どうせあとで チェックシート記入求められる んでしょ
34. プラットフォームの悲劇 • 生まれながらに死んでいるパターン ◦ 開発者が欲しいものに全然マッチしてなかった ◦ 2年くらい頑張ったが、出したときには既に 技術がオワコンになっていた • 上手く回せず死ぬパターン ◦ 特定の技術に依存してしまったため、技術が廃れるのと同時に 使われなくなった ◦ 『プラットフォーム構築プロジェクト』が終わったらチームの半分が 召し上げられてしまって、普段の運用で手一杯。だんだん時代遅れに ◦ コストセンターとみなされ、予算が割り振られなくなって縮小
35. 誰に 何を どうやって プラットフォーム の利用者 ◦◦という価値を 技術 ツールチェーン ワークフロー ここにちゃんとフォーカスすること これを継続的に回せること
36. Platform as a Product • 開発者を『顧客』として考え、顧客にプラット フォームという『プロダクト』を提供していく というアプローチ • 世の中に提供されているさまざまなプロダクト と同じ管理手法を、プラットフォームにも取り 込んでいく 顧客 Platform Product プロダクトを提供 プロダクトを提供 プラットフォームチーム
37. Platform as a Product 顧客 Platform Product プロダクトを提供 プロダクトを提供 プラットフォームチーム どういう価値を提供できれば 使って貰えるか 顧客が何に困っているか どうやってサポートしていく か どうやって教育していくか どうやって安定したチームを 作るか プラットフォームによる効果 がどのくらい出ているか 何をいつまでに提供するか 世の中のトレンドはどうなっ ているか
38. Platform as a Product 顧客 Platform Product プロダクトを提供 プロダクトを提供 プロダクト マネージャー プロダクトマネジメントの 手法がそのまま使える。 チームに専任のプロダクトマ ネージャーを置き、プロダク トとしてのプラットフォーム の方向性を決めていく
39. Kubernetes Novice Tokyo #10
40. まとめると 真のDevOpsのために 開発者の認知負荷を下げ、セルフサービスで利用できるプラットフォームを提供し 迅速なアプリケーションの開発体験とデリバリーを実現する。 そのために、顧客を正確に理解し、継続的なプラットフォームの開発体制を プロダクト開発の知見を取り入れながら作り上げていく のがPlatform Engineering
41. CI/CD Conference 2023 By CloudNative Days に参加してみませんか！？ 3/20 (月)
42. 3/20(月)12時〜ハイブリッド開催！！！！ 日比谷国際ビル　カンファレンス　スクエア
 霞ケ関駅直結・虎ノ門駅徒歩5分
43. こんな方に来てほしい！！ • アプリケーション開発のライフサイクルを高速化するための最新のCI/CD技 術やテスト手法に関心がある • クラウドネイティブを始める足がかりとしてCI/CDに取り組みたい • 既にCI/CDを導入していて、他のプロジェクトがどう運用しているか関心が ある • 情報収集やノウハウ共有を通して様々な視点からCI/CDについて議論を深め たい • クラウドネイティブやCI/CDに取り組んでいる仲間を見つけたい ディスカッションや交流重視の方は オフライン（現地参加）がおすすめ！
44. CNDT 2022 現地の模様
45. Discussion Board / Job Board / Free Board オフライン with ホワイトボード 参加者が自由に書き込めるホワイトボードをロビーに設置！ 詳細は CICD2023 視聴サイトの右上メニューから！ CICDに関してのディスカッションやお悩み相談が出来 る “Discussion Board” 求人情報を共有できる “Job Board” フリーなテーマで好きに書けるボード
46. 懇親会 直近数年できていなかったオフライン懇親会を開催します！ ワールドカフェ形式で、様々なテーマに沿って ディスカッションや交流を行うことで、会社の 垣根を超えた、知識・知見の共有、人と人の ネットワーキングの広がりを提供します！ オフラインでのご参加、お待ちしております！
47. CICD2023セッションの紹介（1/3） 大規模レガシーテストを倒すためのCI基盤の作り方 　　　　　株式会社ミラティブ 　　　　　クラウドエンジニア 　　　　　Uchio Kondo さん GitHub ActionsとDeployGateで始める AndroidアプリのCI/CD 　　　　　アララ株式会社 　　　　　プログラマー 　　　　　Yuhei FUJITA さん インフラ専任者・チームがいない組織で 開発ワークフローの継続的改善に挑戦してみた 　　　　　株式会社みんせつ 　　　　　SRE 　　　　　chiroru & Kousuke Ida & trowems さん 最高の開発者体験を目指して AWS CDKでCI/CDパイプラインを改善し続けている話 　　　　　株式会社ニューズピックス / 株式会社アルファドライブ 　　　　　SREリーダー 　　　　　Yuki Ando さん GitHub Actionsと"仲良くなる"ための練習方法 　　　　　株式会社オルターブース 　　　　　Chief Technical Architect 　　　　　Yuta Matsumura さん 小さく始める Blue/Green Deployment 　　　　　株式会社ティアフォー 　　　　　Software Engineer (SRE) 　　　　　Hideaki Masuda さん 現地 現地 現地 現地
48. CICD2023セッションの紹介（2/3） トランクベース開発の実現に向けた 開発プロセスとCIパイプラインの継続的改善 　　　　　合同会社DMM.com 　　　　　認証認可チームリーダー 　　　　　Anri Kobayashi さん 自分のデータは自分で守る − あなたのCI/CDパイプラインをセキュアにする処方箋 　　　　　HashiCorp Japan株式会社 　　　　　Senior Solutions Engineer 　　　　　Kazuto Kusama さん インフラCI/CDの継続的改善の道のり 　　　　　GMOペパボ株式会社 　　　　　SRE 　　　　　Ryuichi Watanabe さん Kubernetesリソースの安定稼働に向けた TerratestによるHelmチャートのテスト自動化 　　　　　ソフトバンク株式会社 　　　　　システムエンジニア 　　　　　Nobuhiko Kokubo さん "State of DevOps" ウェブアプリケーションの deliveryを考えるとき、今何をすればいいのか(実践編) 　　　　　freee株式会社 　　　　　DevOps Engineer/Engineering Manager 　　　　　fujiwara shunki さん OSSで構築するOpenAPI開発のCI/CD 　　　　　Kong Inc. 　　　　　Solutions Engineer 　　　　　Wenhan Shi さん 現地 現地 現地 現地 現地
49. CICD2023セッションの紹介（3/3） UbieはなぜSnykを選んだのか？ 安全で高速なアプリケーション開発ライフサイクルの実現へ 　　　　　Ubie株式会社 　　　　　Masayoshi Mizutani さん Snyk株式会社 Toshi Aizawaさん すべてのアプリにWAFを組み込むCICDの実現 〜開発ツールとしてのNGINX WAF活用方法〜 　　　　　F5ネットワークスジャパン合同会社 　　　　　Yoichi Komineさん 　　　　　株式会社日立製作所 　　　　　Kiminori Kurihara さん 昔とあるCI/CDツールを使って馬車馬のように働いていた私が、 GitLabを使い始めて気付いた「CI/CDの質」 　　　　　GitLab合同会社 　　　　　Senior Solutions Architect 　　　　　Naoharu Sasaki さん Karpenter を活用した GitLab CI/CD ジョブ実行基盤の自 動スケール 　　　　　株式会社スリーシェイク 　　　　　SRE 　　　　　Toshiki Shimomura さん ローコードで実現するDevOps ～継続的テスト編～ 　　　　　mabl Inc. 　　　　　Product Marketing Manager 　　　　　Shohei Oda (odasho) さん OSSでセキュリティをCI/CDパイプラインに透過的に取込む方法 　　 　　SUSEソフトウエアソリューションズジャパン株式会社 　　　　　Sales Engineer 　　　　　Jianqiang Chengさん 現地 現地 現地
50. CICD2023でお会いしましょう！