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

Slide 1

Slide 1 text

Platform Engineering on Kubernetes Kubernetesで実現できる Platform Engineering の現在地 2025/3/25 Kubernetesで実践する Platform Engineering - FL#88 @nwiizo 50min #Forkwell_Library

Slide 2

Slide 2 text

nwiizo 株式会社スリーシェイクでプロのソフトウェアエンジニアをやっているものだ格闘技、読書、グラビアが趣味人生を通して"運動、睡眠、読書"をちゃんとやりたい 2

Slide 3

Slide 3 text

about 3-shake 3

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

原著者のコメント今回のイベントの件を伝えたところ、それは素晴らしいことだ！本当にありがとう KubeCon Japan 2025 の結果待ちです。(採択されてました) もし受かったら、6月にまた東京に行きます。 5

Slide 6

Slide 6 text

原著者の旅行記原著者に様々なイベントで登壇していただきました。 https://www.salaboy.com/2025/02/03/platform-engineering-in-tokyo/ 6

Slide 7

Slide 7 text

もとは2021年9月に異なるタイトルで作成されました The "Why" なぜの部分 The "What" 何を実現するか 7

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

『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

Slide 10

Slide 10 text

『Platform Engineering on Kubernetes』の構成 Kubernetesで実践する Platform Engineering https://www.shoeisha.co.jp/book/detail/9784798188379 第1章では、プラットフォームとは何か、なぜそれが必要なのか、そしてクラウドプロバイダーが提供するものとどう違うのかを紹介する。第2章では、Kubernetes 上で動作するクラウドネイティブで分散されたアプリケーションを構築する際の課題を評価する。第3章では、異なるクラウドプロバイダー上でアプリケーションを実行するためのリソースの構築、パッケージ化、デリバリーに必要な追加手順に焦点を当てる。 10

Slide 11

Slide 11 text

『Platform Engineering on Kubernetes』の構成 Kubernetesで実践する Platform Engineering https://www.shoeisha.co.jp/book/detail/9784798188379 第4章では、パイプラインの概念を中心に、 GitOps アプローチを用いて複数の環境の構成を宣言的なアプローチで管理する方法を説明する。第5章では、Crossplaneを使用してクラウドプロバイダー間でアプリケーションのインフラストラクチャコンポーネントをプロビジョニングする Kubernetesネイティブなアプローチについて説明する。第6章では、開発環境の作成に特化した、 Kubernetes 上にプラットフォームを構築することを提案する。 11

Slide 12

Slide 12 text

『Platform Engineering on Kubernetes』の構成 Kubernetesで実践する Platform Engineering https://www.shoeisha.co.jp/book/detail/9784798188379 第7章では、プラットフォームチームが利用可能なリソースにどのように接続するかを決定できるアプリケーションレベルの API で開発チームを支援することに焦点を当てる。第8章では、新しいリリースを本格的にコミットする前に実験するために使用できるリリース戦略を示す。第9章では、プラットフォームのデータを取り込み、プラットフォームの取り組みを評価するための重要な指標を計算する2つのアプローチを評価する。 12

Slide 13

Slide 13 text

現代の課題 - 複雑なソフトウェア環境の課題 Taming Your Dragon https://learning.oreilly.com/library/view/taming -your-dragon/9798868802645/ 1. 技術的負債の管理と計画的返済継続的拡張とメンテナンスの過程で、システム内に蓄積された技術的負債がプロジェクトの進行速度と品質に影響を及ぼしています。長期的なシステム健全性の確保とイノベーション推進のための余力創出が喫緊の課題となっています。計画的な負債返済戦略と優先順位付けの仕組みが必要です。 2. 組織全体での技術的負債への理解促進技術的負債管理は技術チームだけの問題ではなく、組織全体の戦略的課題として認識されるべきものです。経営層とのコミュニケーション強化とトレードオフ判断の透明化により、短期的な成果と長期的な持続可能性のバランスを取る文化の醸成が重要です。 13

Slide 14

Slide 14 text

現代の課題 - 複雑性に立ち向かう方法は？ Architecture Modernization https://learning.oreilly.com/library/view/architecture- modernization/9781633438156/ 1. アーキテクチャ現代化の必然性技術負債の蓄積により、システムの拡張性と保守性が著しく低下しており、新機能開発の遅延とサービス品質の低下を招いています。モノリシックな構造から脱却し、疎結合アーキテクチャへの移行が競争力維持のために不可欠となっています。 2. 組織横断的な変革アプローチ独立した価値ストリームの実現には、技術面だけでなくチーム編成とドメイン境界の再定義が必要です。EventStormingやTeam Topologies を活用した協働的手法により、ビジネス・開発・運用の一貫性を確保することが変革成功の鍵となります。 14

Slide 15

Slide 15 text

プラットフォームエンジニアリングとは Platform Engineering https://learning.oreilly.com/library/view/platformengineering/9781098153632/ テクノロジースタックの複雑化クラウドネイティブ時代において、テクノロジースタックの複雑さは指数関数的に増加しています。この複雑性は、単なる技術的な課題ではなく、組織としての意思決定プロセスにも大きな影響を与えています。責任範囲の不明確化インフラチームとアプリケーションチームの境界線が曖昧になってきており、誰が何の決定権を持つべきかという問題が浮上しています。 15

Slide 16

Slide 16 text

プラットフォームエンジニアリングの柱本書を読む前に、プラットフォームエンジニアリングについての理解しておくとより理解が深まります。 16

Slide 17

Slide 17 text

プラットフォームエンジニアリングの柱 (1/4) 1. 製品としてのアプローチ開発者を「顧客」として扱う UXデザインを重視した設計製品として一貫性のあるインターフェースを提供フィードバックループの確立継続的な改善サイクルの実装「舗装された道」の提供標準的なワークフローを整備し、開発者が安全かつ効率的に進められる道筋を提供することで、日常的な作業の摩擦を減らします。 17

Slide 18

Slide 18 text

プラットフォームエンジニアリングの柱 (2/4) 2. ソフトウェアエンジニアリングプラットフォーム自体をコードとして開発適切な抽象化レイヤーの設計 APIファーストの設計アプローチ GitOpsによる構成管理継続的インテグレーション/継続的デリバリー宣言的なインターフェースユーザーが「何を」望むかを記述できるようにし、「どのように」実現するかはプラットフォームが処理することで、複雑さを隠蔽します。 18

Slide 19

Slide 19 text

プラットフォームエンジニアリングの柱 (3/4) 3. 包括的アプローチ幅広い開発者層のニーズに対応マルチテナンシーによる環境分離セルフサービス機能の充実様々なスキルレベルに合わせた体験設計プラットフォーム機能の透明性確保ユーザー観測性開発者が自分のワークロードの状態、使用リソース、パフォーマンス指標などを可視化できるようにし、問題の早期発見を促進します。 19

Slide 20

Slide 20 text

プラットフォームエンジニアリングの柱 (4/4) 4. 運用効率高い信頼性と可用性の確保包括的な可観測性の実現効率的なインシデント管理データ駆動の継続的な改善ビジネス目標との整合性確保プラットフォームSLO プラットフォーム自体のサービスレベル目標を定義し、測定・公開することで、ユーザーからの信頼を獲得し、改善の指針とします。 20

Slide 21

Slide 21 text

実践知を学べる勉強会があります https://www.cnia.io/pek2024/ https://platformengineering.connpass.com/ 21

Slide 22

Slide 22 text

KubernetesとPlatform Engineering Figure 1.11 Platform journey on Kubernetes 「残念ながらKubernetes自体はプラットフォームではない。これはプラットフォームを構築するための最強の基盤である。」 22

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

ここからは本書で紹介されているいくつかのツールを紹介していきます。 24

Slide 25

Slide 25 text

Crossplaneによるクラウドリソース管理 (1/5) Crossplane https://crossplane.io/ https://blog.crossplane.io/crossplane-vs-terraform/ Crossplaneの基本概念 Kubernetesの拡張として動作するクラウドリソース管理ツールクラウドプロバイダー固有のリソースを Kubernetes APIで管理宣言的なリソース定義と管理マルチクラウド環境の一元管理 25

Slide 26

Slide 26 text

Crossplaneによるクラウドリソース管理 (2/5) https://docs.crossplane.io/latest/getting-started/introduction/ プロバイダー AWS、GCP、Azure、Alibaba Cloudなど、各クラウドプロバイダーへの接続を提供するコンポーネント。各プロバイダーは、そのクラウドサービスのリソースを表すCRDをインストールします。 26

Slide 27

Slide 27 text

Crossplaneによるクラウドリソース管理 (3/5) Composite Resources https://docs.crossplane.io/latest/concepts/composite-resources/ マネージドリソース特定のクラウドプロバイダー内のリソース（例：RDSインスタンス、S3バケット、GCP Cloud SQLなど）を表すカスタムリソース。プロバイダーによって作成・管理されます。 27

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

Crossplaneによるクラウドリソース管理 (5/5) Figure 5.10 Lifecycle of managed resources with Crossplane 書籍の実装例「プラットフォームチームはXRDを設計し、アプリケーションチームは簡素化されたAPIを利用します。これにより、クラウドプロバイダー間の移行が容易になり、ベンダーロックインを回避できます。」「第5章では、Crossplaneを活用してクラウドプロバイダーを抽象化し、アプリケーションチームに一貫したインフラAPIを提供する方法が詳しく解説されています」 29

Slide 30

Slide 30 text

vclusterによるマルチテナンシー (1/4) https://www.vcluster.com/docs/v0.19/architecture/ overview/ vclusterとは単一のKubernetesクラスター内に仮想クラスターを作成するツール完全な分離された環境を軽量に提供コスト効率の高いマルチテナンシー実現手段仮想クラスターの仕組み仮想コントロールプレーン（API Server、Controller Manager、 etcd）がNamespace内にPodとして実行されます。 30

Slide 31

Slide 31 text

vclusterによるマルチテナンシー (2/4) https://www.vcluster.com/docs/v0.19/architecture/ overview/ vclusterの主な特徴開発チームごとの独立した環境を容易に提供実際のワークロードはホストクラスターの Namespaceにマッピングリソース使用量の効率化と最適化 31

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

vclusterによるマルチテナンシー (4/4) Figure 6.14 vcluster provides isolation at the Kubernetes (K8s) API server 管理者権限の委譲 vclusterでは、各チームに管理者権限を安全に委譲できるため、チームの自律性が高まります。これにより、プラットフォームチームの負担も軽減されます。「第6章では、vclusterを使用して開発者に柔軟かつ隔離された環境を提供しながら、基盤となるインフラを効率的に管理する方法が詳細に解説されています」 33

Slide 34

Slide 34 text

Argo Rolloutsによる高度なデプロイ戦略 (1/4) https://argoproj.github.io/argo-rollouts/architecture/ Argo Rolloutsとは Kubernetesネイティブなプログレッシブデリバリー詳細なロールアウト制御と自動化 blue/greenデプロイメントの実装メトリクスに基づく自動昇格/ロールバック 34

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

Argo Rolloutsによる高度なデプロイ戦略 (3/4) Site Reliability Engineering on Kubernetes https://speakerdeck.com/nwiizo/site-reliability-engineering-on-kubernetes Analysis Runs メトリクスベースの分析を自動化し、新バージョンのパフォーマンスや安定性を評価して、自動的に昇格またはロールバックを判断します。「第8章では、Argo Rolloutsを使用した高度なデプロイパターンを通じて、新機能のリスクを最小化しながら安全に本番環境に導入する方法が示されています」 36

Slide 37

Slide 37 text

Argo Rolloutsによる高度なデプロイ戦略 (4/4) カナリアリリーストラフィックの一部（例：5%）を新バージョンに転送段階的にトラフィック比率を増加問題が検出された場合は元のバージョンに戻すリアルユーザーでの検証に最適 Knative ServingやArgo Rolloutsで実現可能ブルー/グリーンデプロイメント新旧2つの環境を並行して維持新環境（グリーン）でテストを実施問題がなければトラフィックを一度に切り替え即時ロールバックが可能 Argo Rolloutsで実装可能 37

Slide 38

Slide 38 text

A/Bテストユーザー属性に基づくトラフィック振り分け異なるバージョン間のパフォーマンス比較データ駆動の意思決定 UXやビジネス指標の最適化 Istioとの組み合わせで実現可能フィーチャーフラグコード内の機能を動的に有効/無効化開発とリリースの分離特定のユーザーグループへの機能提供段階的なロールアウト OpenFeatureで標準化可能「第8章では、これらのリリース戦略をKubernetes上で実装する方法が詳細に解説されています」 38

Slide 39

Slide 39 text

CloudEventsによるプラットフォーム評価 (1/3) プラットフォームの測定と評価 (第9章) 「測定できないものは改善できない」という原則に基づく評価 DevOps Research and Assessment (DORA)メトリクスの活用客観的なデータに基づく改善サイクルの確立プラットフォームの価値を定量的に示す指標 39

Slide 40

Slide 40 text

DORAメトリクスによるプラットフォーム評価 (2/3) デプロイ頻度組織が本番環境に変更をデプロイする頻度。高頻度のデプロイは、小さな変更を迅速に提供する能力を示します。リードタイムコミットから本番デプロイまでの時間。短いリードタイムは、効率的なパイプラインと自動化の証拠です。変更失敗率本番環境へのデプロイが失敗または問題を引き起こす割合。低い失敗率は、品質保証プロセスの有効性を示します。サービス復旧時間障害発生から復旧までの平均時間。短い復旧時間は、効果的なモニタリングと緊急対応プロセスを反映しています。 40

Slide 41

Slide 41 text

CloudEventsによるプラットフォーム評価 (3/3) https://v1.keptn.sh/ より引用「第9章では、DORAメトリクスを実装し、<>プラットフォームの成功を客観的に測定するための具体的な方法が示されています」 41

Slide 42

Slide 42 text

Platform Engineering実践のための要諦戦略の要諦 https://bookplus.nikkei.com/atcl/catalog/2 3/10/13/01057/ 1. 開発者の痛点に正面から向き合う - 理想論ではなく実際の課題を特定 2. 既存のツールと知見を最大限活用する - ゼロから構築せず統合と抽象化に注力 3. スコープクリープを避け核心部分に集中 - 「素晴らしい機能」の誘惑に負けない 4. 現場と密に連携し実践的なフィードバックを得る - 理論よりも実際の使用体験を重視 42

Slide 43

Slide 43 text

プラットフォームの進化段階/成熟度 https://tag-app-delivery.cncf.io/whitepapers/platform-eng-maturity-model/ より引用初期段階基本的な自動化ドキュメントの整備標準化されたデプロイ成長段階セルフサービスポータル環境自動プロビジョニング統合オブザーバビリティ成熟段階完全な自動化と抽象化プラットフォームAPI 開発者体験の最適化 43

Slide 44

Slide 44 text

さいごにプラットフォームは完成を目指す静的なものではなく常に進化する動的なもの開発者体験の最適化を最優先にすることが大切で忘れると死にゆく理論より実践、完璧より前進 📚 今日から始めること書籍を手に入れ、理解する GitHubのサンプルコードを実行(salaboy/platforms-on-k8s) 『一日で学ぶクラウドネイティブ技術実践ハンズオン』もオススメです机上の空論ではなく小さなPoCでの実験を計画 🌐 コミュニティに参加 Platform Engineering Meetup Platform Engineering Kaigi Cloud Native Days 44

Slide 45

Slide 45 text

参考資料 Kubernetesで実践する Platform Engineering Platform Engineering on Kubernetes Crossplane vCluster Argo Rollouts CNCF Platform Engineering Maturity Model CloudEvents 45

Slide 46

Slide 46 text

参考資料 DORA Metrics Tekton Knative Platform Engineering Meetup Salaboy's Blog - Platform Engineering in Tokyo Dapr OpenFeature 一日で学ぶクラウドネイティブ技術実践ハンズオン 46

Slide 47

Slide 47 text

ありがとうございましたご質問・ご相談はお気軽にお問い合わせください @nwiizo | https://3-shake.com