Kubernetesで実現できるPlatform Engineering の現在地

本日、「Kubernetesで実践する Platform Engineering - FL#88」というイベントで「Kubernetesで実現できるPlatform Engineering の現在地」🎵🧭 というタイトルで登壇しました！

🔍 イベント詳細:
- イベント名: Kubernetesで実践する Platform Engineering - FL#88
- 公式URL: https://forkwell.connpass.com/event/348104/

🗣️ 関連スライド
- インフラをつくるとはどういうことなのか、 あるいはPlatform Engineeringについて
- https://speakerdeck.com/nwiizo/inhurawotukurutohadouiukotonanoka-aruihaplatform-engineeringnituite
- Platform Engineeringは自由のめまい
- https://speakerdeck.com/nwiizo/platform-engineeringhazi-you-nomemai

Transcript

1. Platform Engineering on Kubernetes Kubernetesで実現できる Platform Engineering の現在地 2025/3/25 Kubernetesで実践する Platform Engineering - FL#88 @nwiizo 50min #Forkwell_Library
2. nwiizo 株式会社スリーシェイクで プロのソフトウェアエンジニアをやっているものだ 格闘技、読書、グラビアが趣味 人生を通して"運動、睡眠、読書"をちゃんとやりたい 2
3. about 3-shake 3
4. Platform Engineering on Kubernetes (Book) Platform Engineering on Kubernetes 2023年 https://www.oreilly.co.jp/books/9784873119648/ 原書名：Platform Engineering on Kubernetes 執筆開始：2020年2月 出版：2023年10月 原著者：Mauricio Salatino(@Salaboy) 実践的なアプローチ プラットフォームのバックエンド、メカニズム、API に焦点を当てる 4
5. 原著者のコメント 今回のイベントの件を伝えたところ、 それは素晴らしいことだ！ 本当にありがとう KubeCon Japan 2025 の結果待ちです。(採択されてました) もし受かったら、6月にまた東京に行きます。 5
6. 原著者の旅行記 原著者に様々なイベントで登壇していただきました。 https://www.salaboy.com/2025/02/03/platform-engineering-in-tokyo/ 6
7. もとは2021年9月に異なるタイトルで作成されました The "Why" なぜの部分 The "What" 何を実現するか 7
8. Kubernetesで実践する Platform Engineering Kubernetesで実践する Platform Engineering https://www.shoeisha.co.jp/book/detail/9784798188379 翻訳開始：2024年7月 出版：2025年2月 翻訳者チーム：株式会社スリーシェイクの4名 (@nwiizo,@tozastation,@Hiroki__IT,@Kazumatcha) 特徴： 用語解説Tipsの追加 専門用語の丁寧な解説 補章の収録 日本のコンテキストに合わせた説明 8
9. 『Platform Engineering on Kubernetes』 の構成 Kubernetesで実践する Platform Engineering https://www.shoeisha.co.jp/book/detail/97847981 88379 目次 第1章　Kubernetes上のプラットフォーム（の台頭） 第2章　クラウドネイティブアプリケーションの課題 第3章　サービスパイプライン：クラウドネイティブアプリケーションの構築 第4章　実行環境パイプライン：クラウドネイティブアプリケーションのデプロイ 第5章　マルチクラウド（アプリケーション）インフラストラクチャー 第6章　Kubernetes上にプラットフォームを構築しよう 第7章　プラットフォーム機能 I：共有アプリケーションの懸念事項 第8章　プラットフォーム機能 II：チームによる実験を可能にする 第9章　プラットフォームの測定 補章　クラウドネイティブ技術とマイクロサービスアーキテクチャーのつながり 9
10. 『Platform Engineering on Kubernetes』 の構成 Kubernetesで実践する Platform Engineering https://www.shoeisha.co.jp/book/detail/9784798188379 第1章では、プラットフォームとは何か、なぜそれ が必要なのか、そしてクラウドプロバイダーが提 供するものとどう違うのかを紹介する。 第2章では、Kubernetes 上で動作するクラウドネ イティブで分散されたアプリケーションを構築す る際の課題を評価する。 第3章では、異なるクラウドプロバイダー上でアプ リケーションを実行するためのリソースの構築、 パッケージ化、デリバリーに必要な追加手順に焦 点を当てる。 10
11. 『Platform Engineering on Kubernetes』 の構成 Kubernetesで実践する Platform Engineering https://www.shoeisha.co.jp/book/detail/9784798188379 第4章では、パイプラインの概念を中心に、 GitOps アプローチを用いて複数の環境の構成を宣 言的なアプローチで管理する方法を説明する。 第5章では、Crossplaneを使用してクラウドプロ バイダー間でアプリケーションのインフラストラ クチャコンポーネントをプロビジョニングする Kubernetesネイティブなアプローチについて説明 する。 第6章では、開発環境の作成に特化した、 Kubernetes 上にプラットフォームを構築すること を提案する。 11
12. 『Platform Engineering on Kubernetes』 の構成 Kubernetesで実践する Platform Engineering https://www.shoeisha.co.jp/book/detail/9784798188379 第7章では、プラットフォームチームが利用可能な リソースにどのように接続するかを決定できるア プリケーションレベルの API で開発チームを支援 することに焦点を当てる。 第8章では、新しいリリースを本格的にコミット する前に実験するために使用できるリリース戦略 を示す。 第9章では、プラットフォームのデータを取り込 み、プラットフォームの取り組みを評価するため の重要な指標を計算する2つのアプローチを評価 する。 12
13. 現代の課題 - 複雑なソフトウェア環境の課題 Taming Your Dragon https://learning.oreilly.com/library/view/taming -your-dragon/9798868802645/ 1. 技術的負債の管理と計画的返済 継続的拡張とメンテナンスの過程で、システム内に蓄積された技術的負債 がプロジェクトの進行速度と品質に影響を及ぼしています。長期的なシス テム健全性の確保とイノベーション推進のための余力創出が喫緊の課題と なっています。計画的な負債返済戦略と優先順位付けの仕組みが必要で す。 2. 組織全体での技術的負債への理解促進 技術的負債管理は技術チームだけの問題ではなく、組織全体の戦略的課題 として認識されるべきものです。経営層とのコミュニケーション強化とト レードオフ判断の透明化により、短期的な成果と長期的な持続可能性のバ ランスを取る文化の醸成が重要です。 13
14. 現代の課題 - 複雑性に立ち向かう方法は？ Architecture Modernization https://learning.oreilly.com/library/view/architecture- modernization/9781633438156/ 1. アーキテクチャ現代化の必然性 技術負債の蓄積により、システムの拡張性と保守性が著しく低下して おり、新機能開発の遅延とサービス品質の低下を招いています。モノ リシックな構造から脱却し、疎結合アーキテクチャへの移行が競争力 維持のために不可欠となっています。 2. 組織横断的な変革アプローチ 独立した価値ストリームの実現には、技術面だけでなくチーム編成と ドメイン境界の再定義が必要です。EventStormingやTeam Topologies を活用した協働的手法により、ビジネス・開発・運用の一貫性を確保 することが変革成功の鍵となります。 14
15. プラットフォームエンジニアリングとは Platform Engineering https://learning.oreilly.com/library/view/platform- engineering/9781098153632/ テクノロジースタックの複雑化 クラウドネイティブ時代において、テクノロジースタ ックの複雑さは指数関数的に増加しています。この複 雑性は、単なる技術的な課題ではなく、組織としての 意思決定プロセスにも大きな影響を与えています。 責任範囲の不明確化 インフラチームとアプリケーションチームの境界線が 曖昧になってきており、誰が何の決定権を持つべきか という問題が浮上しています。 15
16. プラットフォームエンジニアリングの柱 本書を読む前に、プラットフォームエンジニアリングについての理解しておくとより理解が深まります。 16
17. プラットフォームエンジニアリングの柱 (1/4) 1. 製品としてのアプローチ 開発者を「顧客」として扱う UXデザインを重視した設計 製品として一貫性のあるインターフェースを提供 フィードバックループの確立 継続的な改善サイクルの実装 「舗装された道」の提供 標準的なワークフローを整備し、開発者が安全かつ効率的に進められる道筋を提 供することで、日常的な作業の摩擦を減らします。 17
18. プラットフォームエンジニアリングの柱 (2/4) 2. ソフトウェアエンジニアリング プラットフォーム自体をコードとして開発 適切な抽象化レイヤーの設計 APIファーストの設計アプローチ GitOpsによる構成管理 継続的インテグレーション/継続的デリバリー 宣言的なインターフェース ユーザーが「何を」望むかを記述できるようにし、 「どのように」実現するかはプ ラットフォームが処理することで、複雑さを隠蔽します。 18
19. プラットフォームエンジニアリングの柱 (3/4) 3. 包括的アプローチ 幅広い開発者層のニーズに対応 マルチテナンシーによる環境分離 セルフサービス機能の充実 様々なスキルレベルに合わせた体験設計 プラットフォーム機能の透明性確保 ユーザー観測性 開発者が自分のワークロードの状態、使用リソース、パフォーマンス指標などを 可視化できるようにし、問題の早期発見を促進します。 19
20. プラットフォームエンジニアリングの柱 (4/4) 4. 運用効率 高い信頼性と可用性の確保 包括的な可観測性の実現 効率的なインシデント管理 データ駆動の継続的な改善 ビジネス目標との整合性確保 プラットフォームSLO プラットフォーム自体のサービスレベル目標を定義し、測定・公開することで、 ユーザーからの信頼を獲得し、改善の指針とします。 20
21. 実践知を学べる勉強会があります https://www.cnia.io/pek2024/ https://platformengineering.connpass.com/ 21
22. KubernetesとPlatform Engineering Figure 1.11 Platform journey on Kubernetes 「残念ながらKubernetes自体はプラットフォームではない。 これはプラットフォームを構築するための最強の基盤である。 」 22
23. 1. サービスパイプライン (第3章) コンテナ化とCI/CD Tekton / Dagger / GitHub Actions ローカル開発体験の向上 2. 環境パイプライン (第4章) Argo CDによるGitOps Helmによる環境構成管理 宣言的なインフラストラクチャ 3. マルチクラウドインフラ (第5章) Crossplaneによるクラウドリソース管理 XRD/Compositionによる抽象化 ベンダーロックイン回避 4. プラットフォーム機能 (第7-8章) Daprによる共通機能の提供 Knative/Argo Rolloutsによるリリース戦略 セルフサービスとオブザーバビリティ "開発者が本来の価値創造に集中できる環境を Platform Engineeringが実現する" 23
24. ここからは本書で紹介されている いくつかのツールを紹介していきます。 24
25. Crossplaneによるクラウドリソース管理 (1/5) Crossplane https://crossplane.io/ https://blog.crossplane.io/crossplane-vs-terraform/ Crossplaneの基本概念 Kubernetesの拡張として動作するクラウ ドリソース管理ツール クラウドプロバイダー固有のリソースを Kubernetes APIで管理 宣言的なリソース定義と管理 マルチクラウド環境の一元管理 25
26. Crossplaneによるクラウドリソース管理 (2/5) https://docs.crossplane.io/latest/getting-started/introduction/ プロバイダー AWS、GCP、Azure、Alibaba Cloudなど、各クラウドプロバイダーへの接続を提供するコンポーネント。 各プロバイダーは、そのクラウドサービスのリソースを表すCRDをインストールします。 26
27. Crossplaneによるクラウドリソース管理 (3/5) Composite Resources https://docs.crossplane.io/latest/concepts/composite-resources/ マネージドリソース 特定のクラウドプロバイダー内のリソース （例：RDSインスタンス、S3バケット、GCP Cloud SQLなど）を表すカスタムリソース。 プロバイダーによって作成・管理されます。 27
28. Crossplaneによるクラウドリソース管理 (4/5) 複合リソース定義 (XRD):アプリケーションチーム向けの抽象化されたAPI定義。プラットフォーム チームによって設計され、実際のクラウドリソースの詳細を隠蔽します。 apiVersion: apiextensions.crossplane.io/v1 kind: CompositeResourceDefinition metadata: name: xpostgresqlinstances.database.example.org spec: group: database.example.org names: kind: XPostgreSQLInstance plural: xpostgresqlinstances versions: - name: v1alpha1 served: true referenceable: true 28
29. Crossplaneによるクラウドリソース管理 (5/5) Figure 5.10 Lifecycle of managed resources with Crossplane 書籍の実装例 「プラットフォームチームはXRDを設計し、アプリケーショ ンチームは簡素化されたAPIを利用します。これにより、ク ラウドプロバイダー間の移行が容易になり、ベンダーロック インを回避できます。 」 「第5章では、Crossplaneを活用してクラウドプロ バイダーを抽象化し、 アプリケーションチームに一貫したインフラAPIを 提供する方法が詳しく解説されています」 29
30. vclusterによるマルチテナンシー (1/4) https://www.vcluster.com/docs/v0.19/architecture/ overview/ vclusterとは 単一のKubernetesクラスター内に仮想クラ スターを作成するツール 完全な分離された環境を軽量に提供 コスト効率の高いマルチテナンシー実現手 段 仮想クラスターの仕組み 仮想コントロールプレーン（API Server、Controller Manager、 etcd）がNamespace内にPodとして実行されます。 30
31. vclusterによるマルチテナンシー (2/4) https://www.vcluster.com/docs/v0.19/architecture/ overview/ vclusterの主な特徴 開発チームごとの独立した環境を容易に提供 実際のワークロードはホストクラスターの Namespaceにマッピング リソース使用量の効率化と最適化 31
32. vclusterによるマルチテナンシー (3/4) https://www.vcluster.com/docs/v0.19/architecture/ overview/ vclusterの主な特徴 apiVersion: platform.dev/v1alpha1 kind: Environment metadata: name: team-a-dev-env spec: compositionSelector: matchLabels: type: development parameters: installInfra: true 32
33. vclusterによるマルチテナンシー (4/4) Figure 6.14 vcluster provides isolation at the Kubernetes (K8s) API server 管理者権限の委譲 vclusterでは、各チームに管理者権限を安全に委譲できるた め、チームの自律性が高まります。これにより、プラットフ ォームチームの負担も軽減されます。 「第6章では、vclusterを使用して開発者に柔軟かつ隔離され た環境を提供しながら、 基盤となるインフラを効率的に管理する方法が詳細に解説さ れています」 33
34. Argo Rolloutsによる高度なデプロイ戦略 (1/4) https://argoproj.github.io/argo-rollouts/architecture/ Argo Rolloutsとは Kubernetesネイティブなプログレッシブデリバリー 詳細なロールアウト制御と自動化 blue/greenデプロイメントの実装 メトリクスに基づく自動昇格/ロールバック 34
35. Argo Rolloutsによる高度なデプロイ戦略 (2/4) Site Reliability Engineering on Kubernetes https://speakerdeck.com/nwiizo/site-reliability-engineering-on-kubernetes 書籍でのブルー/グリーン実装 apiVersion: argoproj.io/v1alpha1 kind: Rollout metadata: name: frontend spec: strategy: blueGreen: activeService: frontend-active previewService: frontend-preview autoPromotionEnabled: false 35
36. Argo Rolloutsによる高度なデプロイ戦略 (3/4) Site Reliability Engineering on Kubernetes https://speakerdeck.com/nwiizo/site-reliability-engineering-on-kubernetes Analysis Runs メトリクスベースの分析を自動化し、新バージョンのパ フォーマンスや安定性を評価して、自動的に昇格または ロールバックを判断します。 「第8章では、Argo Rolloutsを使用した高度なデプロイ パターンを通じて、 新機能のリスクを最小化しながら安全に本番環境に導入 する方法が示されています」 36
37. Argo Rolloutsによる高度なデプロイ戦略 (4/4) カナリアリリース トラフィックの一部（例：5%）を新バー ジョンに転送 段階的にトラフィック比率を増加 問題が検出された場合は元のバージョンに 戻す リアルユーザーでの検証に最適 Knative ServingやArgo Rolloutsで実現可能 ブルー/グリーンデプロイメント 新旧2つの環境を並行して維持 新環境（グリーン）でテストを実施 問題がなければトラフィックを一度に切り 替え 即時ロールバックが可能 Argo Rolloutsで実装可能 37
38. A/Bテスト ユーザー属性に基づくトラフィック振り分 け 異なるバージョン間のパフォーマンス比較 データ駆動の意思決定 UXやビジネス指標の最適化 Istioとの組み合わせで実現可能 フィーチャーフラグ コード内の機能を動的に有効/無効化 開発とリリースの分離 特定のユーザーグループへの機能提供 段階的なロールアウト OpenFeatureで標準化可能 「第8章では、これらのリリース戦略をKubernetes上で実装する方法が詳細に解説されています」 38
39. CloudEventsによるプラットフォーム評価 (1/3) プラットフォームの測定と評価 (第9章) 「測定できないものは改善できない」という原則に基づく評価 DevOps Research and Assessment (DORA)メトリクスの活用 客観的なデータに基づく改善サイクルの確立 プラットフォームの価値を定量的に示す指標 39
40. DORAメトリクスによるプラットフォーム評価 (2/3) デプロイ頻度 組織が本番環境に変更をデプロイする頻度。高頻 度のデプロイは、小さな変更を迅速に提供する能 力を示します。 リードタイム コミットから本番デプロイまでの時間。短いリー ドタイムは、効率的なパイプラインと自動化の証 拠です。 変更失敗率 本番環境へのデプロイが失敗または問題を引き起 こす割合。低い失敗率は、品質保証プロセスの有 効性を示します。 サービス復旧時間 障害発生から復旧までの平均時間。短い復旧時間 は、効果的なモニタリングと緊急対応プロセスを 反映しています。 40
41. CloudEventsによるプラットフォーム評価 (3/3) https://v1.keptn.sh/ より引用 「第9章では、DORAメトリクスを実装し、<>プラットフォームの成功を客観的に測定するための 具体的な方法が示されています」 41
42. Platform Engineering実践のための要諦 戦略の要諦 https://bookplus.nikkei.com/atcl/catalog/2 3/10/13/01057/ 1. 開発者の痛点に正面から向き合う - 理想論ではなく実際の課題を特定 2. 既存のツールと知見を最大限活用する - ゼロから構築せず統合と抽象化に注力 3. スコープクリープを避け核心部分に集中 - 「素晴らしい機能」の誘惑に負けない 4. 現場と密に連携し実践的なフィードバックを得る - 理論よりも実際の使用体験を重視 42
43. プラットフォームの進化段階/成熟度 https://tag-app-delivery.cncf.io/whitepapers/platform-eng-maturity-model/ より引用 初期段階 基本的な自動化 ドキュメントの整備 標準化されたデプロイ 成長段階 セルフサービスポータル 環境自動プロビジョニング 統合オブザーバビリティ 成熟段階 完全な自動化と抽象化 プラットフォームAPI 開発者体験の最適化 43
44. さいごに プラットフォームは完成を目指す静的なものではなく常に進化する動的なもの 開発者体験の最適化を最優先にすることが大切で忘れると死にゆく 理論より実践、完璧より前進 📚 今日から始めること 書籍を手に入れ、理解する GitHubのサンプルコードを実行(salaboy/platforms-on-k8s) 『一日で学ぶクラウドネイティブ技術実践ハンズオン』もオススメです 机上の空論ではなく小さなPoCでの実験を計画 🌐 コミュニティに参加 Platform Engineering Meetup Platform Engineering Kaigi Cloud Native Days 44
45. 参考資料 Kubernetesで実践する Platform Engineering Platform Engineering on Kubernetes Crossplane vCluster Argo Rollouts CNCF Platform Engineering Maturity Model CloudEvents 45
46. 参考資料 DORA Metrics Tekton Knative Platform Engineering Meetup Salaboy's Blog - Platform Engineering in Tokyo Dapr OpenFeature 一日で学ぶクラウドネイティブ技術実践ハンズオン 46
47. ありがとうございました ご質問・ご相談はお気軽にお問い合わせください @nwiizo | https://3-shake.com