Platform Engineering ことはじめ

Platform Engineering ことはじめ Oracle Cloud Hangout Café Season9 #2 Yutaka
Ichikawa Oracle Corporation Japan Solutions Architect Nov 6, 2024

自己紹介 2 Copyright © 2024, Oracle and/or its affiliates 市川
豊 (Yutaka Ichikawa) CoE本部 / ソリューションアーキテクト部日本オラクル株式会社 Role • Principal Cloud Engineer Belong • Oracle Cloud Hangout Café • Oracle Groundbreakers Adovocate Publications @cyberblack28

Copyright © 2024, Oracle and/or its affiliates 3 Agenda 1.
Platform Engineering とは？ 2. Platform Engineer、SRE、インフラエンジニアの整理 3. チームトポロジーとは？ 4. 2つの IDP - Internal Developer Platform & Internal Developer Portal - 5. Backstage とは？ 6. Platform Engineering on Kubernetes

Platform Engineering とは？ Copyright © 2024, Oracle and/or its affiliates
4

Copyright © 2024, Oracle and/or its affiliates 5 Platform Engineering
とは？ Platform Engineering 市場動向 CodeZine 「プラットフォームづくりを成功に導く！開発者のための「Platform Engineering」入門 https://codezine.jp/article/corner/990 • Platform Engineering とは何か？なぜ注目されているのか (草間一人（jacopen）[著]) • Platform Engineering はこれまでの SRE やインフラチームと何が違うのか (渡邊武志（Buzz）[著] ) • Platform Engineering を実現する上で重要な組織論「チームトポロジー」とは？ (上林太洋[著]) • Platform Engineering の2つの「IDP」～ Internal Developer Platform とは？ (石川諒（ishikawa-pro）[著]) • Platform Engineering の2つの「IDP」～ Internal Developer Portal とその代表例 Backstage (吉川俊甫[著])

とは？ Platform Engineering 市場動向 Gartner 社による2024年の戦略的技術トレンドトップ10入りを果たすほどの注目される技術分野出典: 「Gartner Identifies the Top 10 Strategic Technology Trends for 2024」 (https://bit.ly/GIT10STT2024) Platform Engineering Platform engineering is the discipline of building and operating self-service internal development platforms. Each platform is a layer, created and maintained by a dedicated product team, designed to support the needs of its users by interfacing with tools and processes. The goal of platform engineering is to optimize productivity, the user experience and accelerate delivery of business value. プラットフォームエンジニアリングは、セルフサービスの内部開発プラットフォームを構築し運用するための専門分野です。各プラットフォームは、ツールやプロセスと連携し、ユーザーのニーズをサポートするために専任のプロダクトチームによって作成され、維持されるレイヤーです。プラットフォームエンジニアリングの目的は、生産性の最適化、ユーザー体験の向上、そしてビジネス価値の提供を加速させることです。

とは？ Platform Engineering が注目される背景開発者における認知負荷の増加認知負荷とは？開発者がアプリケーション開発以外に必要な環境やツールを理解・対応するために負担する思考の量 • クラウドの普及（AWS、Azure、Google Cloud、Oracle 等） • クラウドネイティブ技術（コンテナ、Kubernetes、サーバーレス） • マイクロサービスアーキテクチャの浸透 • DevOps の普及による担当範囲の拡大認知負荷の増大要因

とは？ Platform Engineering が注目される背景開発者における認知負荷の増加認知負荷の影響生産性の低下：開発者が意識する技術領域の範囲が拡大し、本来の開発（コーディング）に集中できない出典: CodeZine 「Platform Engineeringとは何か？なぜ注目されているのか第1回 Platform Engineeringのメリットと、登場の背景」図:開発者の認知負荷の変遷 (https://bit.ly/CZ-PF01)

とは？ Platform Engineering の目的と役割開発者における認知負荷の増加という背景から登場した Platform Engineering Platform Engineering の目的開発者の認知負荷軽減と生産性向上 Platform Engineering の役割専任チームを設けて、負荷の根源を解決する基盤＝プラットフォームを構築および運用 ↓ 開発者が効率的に作業できる環境を提供

とは？ Platform Engineering という言葉の生い立ち Platform Engineering は、2019年に出版された『Team Topologies』という書籍をきっかけに体系化された技術分野として登場開発者の認知負荷を軽減し、自律的に作業できるようサポートする専任チーム「プラットフォームチーム」の考え方に基づく効率的なソフトウェアの提供を支援する共通基盤やツールを構築および運用を目指す役割現在一般的に言われている Platform Engineering は、このコンセプトを深掘りし、体系化された形で発展している

とは？ Platform Engineering におけるプラットフォームこれまでのプラットフォームの考え方の違いプラットフォーム作りを成功させる考え方が含まれていることプラットフォームの成功、失敗はそもそも何なのか？

とは？ Platform Engineering におけるプラットフォーム開発者 • ローカル環境では開発を進めている • アプリケーションをサーバーにデプロイしたいが CI/CD 環境構築はハードルが高い（認知負荷）一例から Platform Engineering におけるプラットフォームを考えてみましょう！

とは？ Platform Engineering におけるプラットフォームプラットフォーム提供者開発者 CI/CD プラットフォームを提供 CI/CD プラットフォーム

とは？ Platform Engineering におけるプラットフォーム開発者提供された CI/CD プラットフォームは、馴染みの無い技術で構築されてメンテンナンスできないプラットフォーム提供者 CI/CD プラットフォームを提供した後は、放置状態 CI/CD プラットフォーム

とは？ Platform Engineering におけるプラットフォーム開発者自分たちでメンテンナンスしやすい新たな CI/CD プラットフォームつくることにしよう！新CI/CD プラットフォーム

とは？ Platform Engineering におけるプラットフォーム提供されたプラットフォームが利用されなかった背景プラットフォーム提供者が、アプリ開発者のニーズを捉えきれていなかった • 事前に開発者から馴染みある技術をヒアリングして、望む CI/CD プラットフォームを提供するべきであった • 提供後にメンテナンスをして、開発者にナレッジ共有するなど開発者と一緒に改善を図るべきであった 1. プラットフォーム提供者側で持ち合わせている技術の範囲で可能なものを提供 2. 提供後の放置失敗要因成功要因見込み

とは？ Platform Engineering におけるプラットフォームプロダクト開発と同様に、プラットフォーム開発においても「誰に」、「何を」を明確に意識する利用者に対して価値を提供できているかの観点で、継続的なプラットフォームの更新と運用をする（「どのように」）一例からの考察！誰に何をどうやってプラットフォーム利用者 ◦◦という価値技術出典: CodeZine 「Platform Engineeringとは何か？なぜ注目されているのか第2回 Platform EngineeringはこれまでのSREやインフラチームと何が違うのか？」図:Platform Engineeringにおいて意識するポイント (https://bit.ly/CZ-PF02) を参考継続的に回す Platform Engineering でのフォーカスポイント失敗するプラットフォームがフォーカスしがちなポイント

Platform Engineer、SRE、インフラエンジニアの整理 Copyright © 2024, Oracle and/or its affiliates
18

Copyright © 2024, Oracle and/or its affiliates 19 Platform Engineer、SRE、インフラエンジニアの整理
Platform Engineer 開発者の開発効率、デベロッパーエクスペリエンスを向上 SRE (Site Reliability Engineer) システムの信頼性および可用性の担保インフラエンジニアアプリケーションが稼働するインフラ基盤の提供各ロールの目的サービスレベル概要サービスレベル指標（SLI：Service Level Indicators）システムの可用性を特定するための主要な測定値およびメトリクスサービスレベル目標（SLO：Service Level Objectives）外部からシステムに対して期待される可用性に関して設定された目標サービスレベル契約（SLA：Service Level Agreements）合意された内容およびシステムがSLOを満たさなかった場合の対応を説明した契約

Copyright © 2024, Oracle and/or its affiliates 20 Platform Engineer、SRE、インフラエンジニアの整理
各ロールの役割とアプローチ項目 Platform Engineer SRE (Site Reliability Engineer) インフラエンジニア役割開発者の開発効率を向上させる、プラットフォームの提供システムの信頼性と可用性の担保アプリケーションを稼働させるインフラ基盤の設計、構築、運用アプローチ開発者が求める価値を満たすソリューションを提供し続ける SLI、SLO、 SLA といった定めた指標を元に、運用を改善アプリケーションの可用性を満たすサーバー、ネットワーク、ストレージといったインフラを提供と運用出典: CodeZine 「Platform Engineeringとは何か？なぜ注目されているのか第2回 Platform EngineeringはこれまでのSREやインフラチームと何が違うのか？」表:Platform Engineer、SRE、インフラエンジニアの違い(https://bit.ly/CZ-PF02-2) を参考

Copyright © 2024, Oracle and/or its affiliates 22 チームトポロジーとは？ Team
Topologies (チームトポロジー) 著者:Matthew Skelton, Manuel Pais サービスの安定を保ちながらリリース頻度を高め顧客価値を最大化していくための開発組織における設計方法論 ① 4つのチームの役割分担 ② 3つの連携方法 ③ 組織構造進化の方法

Copyright © 2024, Oracle and/or its affiliates 23 チームトポロジーとは？ 4つのチームの役割分担
４つのチーム役割ストリームアラインドチームユーザやビジネスニーズに直接結びついた機能を開発し、価値を提供する。製品やサービス開発の中心となるチーム。プラットフォームチームストリームアラインドチームの認知負荷を下げ、自律的に仕事ができるようにインフラ、ツール、知識などをセルフサービスで提供するチーム。コンプリケイテッド・サブシステムチーム複雑で専門的なサブシステムに対して、ストリームアラインドチームの認知負荷を下げるために、特定の技術的課題や領域に特化して取り組むチーム。イネーブリングチームストリームアラインドチームのスキルギャップを埋めるために、有識者としてコーチ、並走するチーム。ストリームアラインドチームは、組織の根幹となるチームタイプで、それ以外のチームはストリームアラインドチームの認知負荷を減らすことを目的としている。

Copyright © 2024, Oracle and/or its affiliates 24 チームトポロジーとは？ 3つの連携方法（3つのインタラクションモード）
4つのチームのインタラクション（相互作用）の進化が、組織にとって戦略的な優位性や有効性をもたらす。インタラクションモード役割コラボレーション他のチームとの密接な連携 X-as-a-Service 最小限の連携で、サービスとして他のチームに機能を提供したり利用したりする連携ファシリテーション特定の課題に対して他のチームを支援したりされたりする連携コラボレーション X-as-a-Service 出典: 『Team Topologies』 by Matthew Skelton and Manuel Pais, 2019 P259 「図 7.2 3つのチームインタラクションモード」を元に発表者作成ファシリテーション

Copyright © 2024, Oracle and/or its affiliates 25 チームトポロジーとは？ 4つのチームの役割分担・3つの連携方法（3つのインタラクションモード）
コンプリケイテッド・サブシステムチームイネーブリングチームストリームアラインドチームプラットフォームチーム出典: 『Team Topologies』 by Matthew Skelton and Manuel Pais, 2019 P141 「図 5.1 4つの基本的なチームタイプ」を元に発表者作成

Copyright © 2024, Oracle and/or its affiliates 26 チームトポロジーとは？コラボレーション
一例新しいマイクロサービスの設計ストリームアラインドチームとコンプリケイテッド・サブシステムチームが一時的に連携し、特定の技術的課題を解決するために新しいマイクロサービスを設計・開発する。専門的な知識を活かしつつ、迅速にソリューションを提供できる。

Copyright © 2024, Oracle and/or its affiliates 27 チームトポロジーとは？ X-as-a-Service
一例 CI/CD パイプラインの提供プラットフォームチームが、ストリームアラインドチームに対して、標準化された CI/CD パイプラインをサービスとして提供。 • パイプラインを使ってアプリケーションのビルド、テスト、デプロイを効率的に行える • 本来の開発作業に集中できるストリームアラインドチームプラットフォームチーム • CI/CD パイプラインを提供 • パイプラインの保守・改善を行う

Copyright © 2024, Oracle and/or its affiliates 28 チームトポロジーとは？ファシリテーション
一例内部開発者ポータルの構築プラットフォームチームが、各チームが利用できる Internal Developer Portal を構築し、開発者がプラットフォーム機能やサービスに自律的にアクセスしやすくする。プラットフォームチーム • ポータルに、設定テンプレート、ドキュメント、利用手順などを整備 • 各チームが自律的にプラットフォームを活用できるように支援ストリームアラインドチーム A～E • 開発者がプラットフォーム機能やサービスにアクセスしやすくなる • 支援を受ける側として学習に対してオープンでいる

Copyright © 2024, Oracle and/or its affiliates 29 チームトポロジーとは？組織構造進化の方法
組織的センシングで組織構造を進化させる組織全体やその一部が外部環境や内部の変化を敏感に察知し、その情報を収集、分析、活用して、適切な意思決定を行う方法やプロセス密接なコラボレーション限定的なコラボレーション確立された予測可能なデリバリーのための X-as-a-Service 探索確立出典: 『Team Topologies』 by Matthew Skelton and Manuel Pais, 2019 P259 「図 8.6 チームトポロジーの進化」を元に発表者作成

Copyright © 2024, Oracle and/or its affiliates 30 チームトポロジーとは？ストリームアラインドチームとプラットフォームチーム
ストリームアラインドチームが、顧客価値を最大化するために提唱されている一つ「速いフロー (fast flow)」リリース後に顧客からのフィードバックを受けて、迅速な追加機能開発や修正を行い、継続的に顧客向けの機能を素早くリリースストリームアラインドチーム開発インフラ QA 運用顧客出典: CodeZine 「Platform Engineeringとは何か？なぜ注目されているのか第3回 Platform Engineeringを実現する上で重要な組織論「チームトポロジー」とは？」図：ストリームアラインドチームに求められる速いフロー(https://bit.ly/CZ-PF03)を元に発表者作成フィードバック顧客への価値提供

従来の組織における課題出典: CodeZine 「Platform Engineeringとは何か？なぜ注目されているのか第3回 Platform Engineeringを実現する上で重要な組織論「チームトポロジー」とは？」図：他部署への依頼が速いフロー実現のボトルネックに (https://bit.ly/CZ-PF03)を元に発表者作成 • 他部署への依頼で待ち時間が発生し、ボトルネックになる • 速い開発には、工程を開発チーム内で完結させる必要がある • 運用後もチームがオーナーシップを持ち、継続開発を行うフェーズ部署開発インフラ QA 運用開発インフラ構築テスト運用引継ぎ運用依頼依頼依頼依頼 • 多くのスキルの習得が求められる • 新しい技術やツールの習熟も必要となり、認知負荷が増大するストリームアラインドチームで、ビジネス、インフラ、QA、運用、デザインなどをチーム内で完結させる必要がある

改善するためには？ストリームアラインドチームコンプリケイテッド・サブシステムチームプラットフォームチームイネーブリングチーム他の3つのチームと連携して、高い認知負荷の削減を目指す！プラットフォームチームがストリームアラインドチームに対して実施する認知負荷の削減支援の方法論こそが Platform Engineering

ストリームアラインドチームプラットフォームチームストリームアラインドチームに対して、認知負荷の原因となるノンコア業務を代替えするプラットフォームを提供顧客顧客価値を上げるためのコア業務であるビジネスロジックの開発に集中開発者にとってのユーザ体験（DevEx）の良いセルフサービス型で提供高い顧客価値の提供認知負荷の低減内部開発者プラットフォーム（Internal Developer Platform） • システム関連のリソース（インフラサービス、開発ツールなど） • 業務プロセスの整備（ドキュメント、ナレッジなど）開発者を顧客として考える Platform as a Product

Copyright © 2024, Oracle and/or its affiliates 34 チームトポロジーとは？開発者を顧客として考える
Platform as a Product プラットフォームチームは、ストリームアラインドチームを顧客として扱うコミュニケーションを重視してニーズを把握するストリームアラインドチームプラットフォームチーム顧客価値の提供価値の提供プラットフォームをプロダクトとして見立てる X-as-a-Service 継続的な運用と拡張 Platform as a Product

2つの IDP - Internal Developer Platform & Internal Developer Portal
- Copyright © 2024, Oracle and/or its affiliates 35

Copyright © 2024, Oracle and/or its affiliates 36 2つの IDP
- Internal Developer Platform & Internal Developer Portal - Internal Developer Platform プラットフォームチームが提供するプラットフォーム Internal Developer Platform （内部開発者プラットフォーム）開発者がアプリケーションを開発するために必要な環境を提供するプラットフォーム

- Internal Developer Platform & Internal Developer Portal - Internal Developer Platform を構成する5つのコンポーネント主要コンポーネント概要アプリケーション設定管理アプリケーション設定を動的かつスケーラブルで信頼性のある方法で管理するインフラストラクチャのオーケストレーションコンテキストに応じて、インフラを動的かつインテリジェントに管理する環境管理開発者が必要に応じて新しい完全プロビジョン済みの環境を作成できるようにするデプロイメント管理継続的デリバリーまたは継続的デプロイメント（CD）のためのパイプラインを構築するロールベースアクセス制御誰が何を行えるかをスケーラブルな方法で管理する出典: The 5 Core Components of an Internal Developer Platform (IDP) https://internaldeveloperplatform.org/core-components/ Internal Developer Platform は、5つの主要コンポーネントを網羅すように設計することが推奨される

- Internal Developer Platform & Internal Developer Portal - アプリケーション設定管理アプリケーションの設定情報（Kubernetes マニフェスト、Terraform コード、環境変数など）を信頼性高く、動的およびスケーラビリティを担保した状態での管理を目指す • 開発者が迅速に開発を進めるためには、設定情報の作成や変更できることが望ましい • 設定情報に対する自主的な操作が、開発のスピードを向上させる

- Internal Developer Platform & Internal Developer Portal - アプリケーション設定管理（例）Kubernetes マニフェスト • Kubernetesのマニフェストファイルの作成や変更には、Kubernetesオブジェクトに関する知識が必要 • 全ての開発者がこれらの作業を行えるわけではない • 技術的に難易度の高い作業は、開発者の開発効率を低下させる原因となる • プラットフォームチームは、Kubernetes のマニフェストテンプレートや設定情報を容易に変更できる仕組みを提供する • 開発者はアプリケーションの設定情報を簡単に作成・変更できるようになる • 開発効率の向上が期待される

- Internal Developer Platform & Internal Developer Portal - インフラストラクチャのオーケストレーション Kubernetes Clusters Container Image Registry Database Cache Server Message Queue 開発者が全てを構築して管理するのは困難外部チーム依頼は、コミュニケーションコストなど増える開発効率が下がる Internal Developer Platform 必要なリソースを一元的に提供自動化ツールを活用して、これらのサービスを統合効率的に開発プラットフォームチームが定めるベストプラクティスやセキュリティポリシーが設定された品質高いプラットフォーム

- Internal Developer Platform & Internal Developer Portal - 環境管理 Internal Developer Platform ストリームアラインドチーム開発者 Web/API/CLI 開発環境 QA環境本番環境リソースアプリケーションプラットフォームチーム環境のセットアップと管理を自動化開発者が必要な環境をセルフサービスで利用できるようにすることを目的 Internal Developer Platform を活用して、開発者は環境の作成、設定、デプロイなどの一連のプロセスを容易に実行できるようになり、開発の効率が向上

- Internal Developer Platform & Internal Developer Portal - デプロイメント管理プラットフォームチームが CI/CD のテンプレートを提供して、開発者がより簡単にデプロイできるようにするストリームアラインドチーム開発者 Git CI CD 開発環境 QA環境本番環境プラットフォームチームテンプレート提供

- Internal Developer Platform & Internal Developer Portal - RBAC によるアクセス制御 RBAC (Role-based Access Control) で開発者がアクセスできる機能やリソースの範囲制限して、リスク管理とセキュリティ向上を図る。開発責任者開発者開発責任者ロール開発者閲覧ロール本番環境アプリケーション開発責任者開発者開発責任者ロール開発者閲覧ロール本番環境アプリケーションリソース閲覧リソース操作開発責任者以外は操作不可

- Internal Developer Platform & Internal Developer Portal - 価値ある内部開発プラットフォーム（Internal Developer Platform）の提供 Platform as a Product • ユーザー体験の追求: IDP は直感的で使いやすい UI/UX を備え、開発者の認知負荷を軽減することが重要。 • 開発者のニーズ重視: 開発者の課題を理解し、それを解決する機能を優先的に提供。定期的なフィードバックの収集と改善。 • 最低限の機能提供: 必要最低限の機能に絞り、プラットフォームの複雑さを抑える。 • 利用の強制を避ける: 開発者にメリットを示し、プラットフォームを自発的に利用させることが重要。

- Internal Developer Platform & Internal Developer Portal - Internal Developer Portal Internal Developer Platform（内部開発プラットフォーム）を操作するためのインターフェース Internal Developer Portal （内部開発者ポータル） • 開発者がアプリケーションの構成管理、環境作成、デプロイメントといった多岐にわたる作業を統一されたインターフェースで操作 • 開発者はプラットフォーム上で必要な操作を直感的かつ効率的に行うことができ、開発効率の向上とプロセスの簡素化を実現

- Internal Developer Platform & Internal Developer Portal - Internal Developer Portal Internal Developer Portal （内部開発者ポータル）ストリームアラインドチーム開発者 Internal Developer Platform （内部開発者プラットフォーム）開発者が Web UI を経由して、内部開発者ポータルから内部開発者プラットフォームを操作する。開発者ポータルを構築する代表的なツールが Backstage

Copyright © 2024, Oracle and/or its affiliates 48 Backstage とは？
Internal Developer Portal Internal Developer Portal （内部開発者ポータル）ストリームアラインドチーム開発者 Internal Developer Platform （内部開発者プラットフォーム）開発者はポータルを利用して、プラットフォームに対する操作や一元的に管理された情報を利用。リソースドキュメント各種ツールポータルを通して、操作および一元管理されたプラットフォームの情報を利用プラットフォームの操作、情報の集約

Golden Path について開発のベストプイラクティスとそれを実現するための環境を開発者に提供することで、迷わず効率的に仕事を進められるようにする考え方。 • 効率的な開発をサポートするために、開発者が複雑な設定やツールの選択に迷わず、スムーズに作業できるようにする • 開発者が必要なツールやリソース、手順をひとまとめにして、誰でも簡単に利用できるようにする Golden Path 主な目的開発者が「何をどうやれば良いか」があらかじめ決められた最適な道で、迷わずに効率よく作業できるようにする開発効率が向上し、生産性の向上へもつながる

Internal Developer Portal としての Backstage Backstage は、Internal Developer Portal として、開発者が必要なツール、リソース、手順、テンプレートなどを一か所で簡単に探して利用できるようにするツール。 https://backstage.io/

Backstage について • Backstage は音楽配信サービス事業者の Spotify 社によって開発 • 現在は CNCF（Cloud Native Computing Foundation）のプロジェクトとして開発が進められている • BackstageCon というイベントも開催されている “Our goal is to provide engineers with the best developer experience in the world.” 世界に最高の開発者体験を提供 https://backstage.io/docs/overview/vision/

Backstage の特徴 Plugin Plugin Plugin App Backstage Core 出典: 「Backstage をはじめよう！」by tanayan / namayasai_tech 図：P15 「Backstage の 3 層構造モデル」を元に発表者作成オープンソースプロジェクトのコア開発者によって開発された基本機能 • エンドユーザが利用する開発者ポータル部分 • プラグインとコア機能を結合する • ニーズに合わせて拡張するための追加機能 • オープンソースや独自開発してプラグインとして利用可能 Bakcstage は、プラグインベースのアーキテクチャにより、ユーザがニーズに合わせて機能をカスタマイズ可能。コミュニティや企業が提供するプラグインを利用して多様なツールを統合でき、ユーザー自身で独自プラグイン開発も可能。

Backstage のコンセプト 1. Backstage is the interface Backstage は、複数のツールを同一のインターフェースを通して一元化することを目的としている。 2. Backstage embraces autonomy Backstage を通して、開発者に必要なものをセルフサービスで提供し、開発者、チームへの自律性を支援する。 3. Backstage demands clear ownership Backstage で管理するツールやソフトウェアのコンポーネントを所有するチームに紐づけて明確化する。

Backstage の利用体系 OSS オープンソースソフトウェアとして、GitHub 上にソースを公開ベンダーパッケージ製品 Red Hat 社 : Red Hat Developer Hub https://github.com/backstage/backstage Broadcom 社 : VMware Tanzu Developer Portal https://www.redhat.com/ja/technologies/cloud-computing/developer-hub https://tanzu.vmware.com/platform SaaS Roadie 社 https://roadie.io/

Copyright © 2024, Oracle and/or its affiliates 55 株式会社エーピーコミュニケーションズ亀崎仁志
セッション資料 Backstage 入門 https://bit.ly/backstage-introduction

Platform Engineering on Kubernetes Copyright © 2024, Oracle and/or its
affiliates 56

on Kubernetes 書籍概要 1. (The rise of) platforms on top of Kubernetes 2. Cloud-native application challenges 3. Service pipelines: Building cloud-native applications 4. Environment pipelines: Deploying cloud-native applications 5. Multi-cloud (app) infrastructure 6. Let’s build a platform on top of Kubernetes 7. Platform capabilities I: Shared application concerns 8. Platform capabilities II: Enabling teams to experiment 9. Measuring your platforms https://www.manning.com/books/platform-engineering-on-kubernetes

on Kubernetes 書籍概要 Kubernetesを基盤とし、複数のオープンソースツールを組み合わせて、チームのソフトウェア開発を効率化するプラットフォームを作り上げる方法を詳しく解説 • プラットフォームエンジニアリングの基本原則 • オープンソースツールの活用 • マルチクラウド戦略 Kubernetes 上でのプラットフォーム設計にどのように適用されるかを説明 Helm、Tekton、Argo CD などを使用して、パッケージ管理、バージョン管理、継続的デリバリーを実現する方法 Crossplane を用いたマルチクラウド対応のインフラストラクチャを導入し、Knative と Argo Rollouts で段階的なアップグレードを管理する方法 • チームの効率向上標準的なアプリケーション API を通じて、開発チームの認知負担を軽減し、迅速なリリースを可能にするプラットフォーム API の構築

on Kubernetes Crossplane とは？ Crossplaneは、Kubernetes 上でクラウドインフラやアプリケーションリソースを管理するためのオープンソースの制御プレーン https://www.crossplane.io/

on Kubernetes Crossplane とは？各クラウドプロバイダーの Crossplane プロバイダーをインストール https://github.com/oracle- samples/crossplane-provider- oci Crossplane Provider for OCI 各クラウドプロバイダーの固有のリソースを宣言的に作成各クラウドプロバイダーのリソースをプロビジョニング各クラウドプロバイダーをインストールする際に認証設定も行うクラウドリソースを手動で変更した場合、自動的にマニフェストで定義した状態に戻される

on Kubernetes Crossplane とは？ 1. Composite Resource Definitions (XRD) 2. Composition 複数のインフラリソースを1つのカスタムリソースとして定義するための仕組み。これにより、ユーザーは特定の目的に応じた複合リソースを作成し、インフラ構成を抽象化・簡素化できる。クラウドリソースにおいて、「こういうものを作ります」を定義する XRDで定義されたカスタムリソースが実際にどのようなリソースで構成されるかを具体化するテンプレート。クラウドリソースにおいて、「こうやって作ります」を定義する

on Kubernetes Crossplane とは？ 3. Composite Resource (XR) XRDで定義された型の実際のインスタンスであり、具体的なリソース作成の要求。クラウドリソースにおいて、「このリソースを作ってください」を定義する

on Kubernetes Crossplane と Platform Engineering ベストプラクティスに基づく実装方法を定義 • セキュリティ設定 • コンプライアンス要件 • コスト最適化 Crossplane基盤の準備 • Crossplaneインストール • 必要なプロバイダーの設定 • 認証設定基盤とルールを整備標準化されたリソース利用 • 標準化されたインフラ提供 • ガバナンスの確保 • 運用負荷の削減複雑なインフラを意識せず開発に集中セルフサービスの提供セルフサービスの自立利用

on Kubernetes Crossplane と Platform Engineering Git ストリームアラインドチーム • XR マニフェスト更新 • プルリクエスト作成プラットフォームチーム • プルリクエストレビュー • 承認とマージ • マニフェストの更新検知 • マニフェストを適用 • Crossplaneプロバイダが更新を検知 • クラウドリソースを更新 Crossplane と ArgoCD を組み合わせた GitOps による管理 1. クラウドリソースの管理をGitで実施 2. 開発者はXRマニフェストを通じてリソース要求のプルリクエスト 3. プラットフォームチームのレビューおよびマージ 4. ArgoCDが自動的に変更を検知 5. Crossplaneによるクラウドリソースの更新インフラ変更の追跡性と自動化を実現 Team A Environment Team B Environment Team C Environment

on Kubernetes OAM (Open Application Model) と Platform Engineering この書籍を読み進めていく中で、 OAM (Open Application Model) と Platform Engineering との相性が良かったりするのでは？

on Kubernetes OAM (Open Application Model) と Platform Engineering OAM（Open Application Model）アプリケーションの定義と運用を標準化するためのモデル開発者と運用者がそれぞれの役割に集中できるように設計 Component 開発者が定義するアプリケーションコンポーネント Trait 運用者が定義する運用に関する設定やポリシー開発と運用の境界を明確にして、プラットフォームに依存しない標準化された方法でアプリケーションリリースを実現する

on Kubernetes OAM (Open Application Model) と Platform Engineering KubeCon CloudNativeCon EU 2023 https://kccnceu2023.sched.com/event/1Hyaw/tutorial-deploying-cloud- native-applications-using-kubevela-and-oam-daniel-higuero- napptive?iframe=no&w=100%&sidebar=yes&bg=no このセッションをベースとした考察！ https://techblog.ap-com.co.jp/entry/2023/04/22/153955

on Kubernetes OAM (Open Application Model) と Platform Engineering OAM（Open Application Model）を実装したアプリケーション配信基盤 https://kubevela.io/ 標準パターン（Component）と追加機能（Trait）を組み合わせる開発者は必要な設定だけを記述、運用チームは組織の標準やポリシーを効率的に提供

on Kubernetes OAM (Open Application Model) と Platform Engineering OAM (Open Application Model) Application Component Traits Policy Workflow Cloud On-Premises Others Developer 出典: 「KubeVela: the road to cloud native application and platform engineering」 (https://www.cncf.io/blog/2023/03/31/kubevela-the-road-to-cloud-native-application-and- platform-engineering/) OAM ベースの KubeVela アーキテクチャ

on Kubernetes KubeVela - get started - Namespace : default Namespace : prod Namespace : vela-system kubevela-cluster-gateway kubevela-vela-core velaux-server Service Pod Service Pod Pod express-server express-server- xxxx-xxxx express-server express-server- xxxx-xxxx express-server- xxxx-xxxx port:8000 port:8000 Workflow 1.default ネームスペースにデプロイ ↓ 2.手動承認コマンド実行 ↓ 3. prod ネームスペースにデプロイ Deploy First Application https://kubevela.io/docs/quick-start/ 3. prod ネームスペースにデプロイ： pod の replica 数が 2 で Prod ネームスペースにデプロイされる 2.手動承認コマンド実行： vela workflow resume first-vela-app 1. default ネームスペースにデプロイ： pod の replica 数が 1 で default ネームスペースにデプロイされる

on Kubernetes KubeVela - get started - Application マニフェスト例 1.Component（コンポーネント） 2. Traits（トレイト） Pod のスケール設定 Webアプリデプロイ用のコンポーネントタイプ、使用するコンテナイメージ、ポート番号、外部公開を定義

on Kubernetes KubeVela – get started - Application マニフェスト例 3.Policies（ポリシー） KubeVela がインストールされたローカルクラスターにデプロイする設定を定義 • default ネームスペースにデプロイする設定 • prod ネームスペースにデプロイする設定

on Kubernetes KubeVela - get started - Application マニフェスト例 4. Workflow（ワークフロー） policies で定義した「target-default」、「target-prod」、「deploy-ha」に従ってデプロイするためのワークフローを定義 default ネームスペースにデプロイ ↓ 手動承認 ↓ prod ネームスペースにデプロイ

on Kubernetes KubeVela - get started - $ vela env init prod --namespace prod $ vela up -f https://kubevela.net/example/applications/first-app.yaml $ vela status first-vela-app $ vela workflow resume first-vela-app $ vela status first-vela-app $ vela delete first-vela-app 1.prod ネームスペース作成 2.マニフェスト適用 3.ステータス確認 4.手動承認 5.ステータス確認 6.クリーアップ

on Kubernetes KubeVela - get started - ブラウザで表示される Webアプリケーション

on Kubernetes KubeVela - get started - Workflow のステータス（手動承認後） Workflow のステータス（承認待ち）

on Kubernetes KubeVela - get started - クラスタのリソース状況

on Kubernetes OAM (Open Application Model) と Platform Engineering プラットフォームチームとストリームアラインドチームの役割ストリームアラインドチームプラットフォームチーム Application マニフェスト環境管理テンプレート提供マニフェスト作成/適用リリース対象環境開発者に寄り添った環境管理とテンプレートマニフェスト（Component / Trait / Policy）の作成プラットフォームチームから提供されたマニフェストを利用し、開発に専念

Copyright © 2024, Oracle and/or its affiliates 81 参考資料 CodeZine
「プラットフォームづくりを成功に導く！開発者のための「Platform Engineering」入門 https://codezine.jp/article/corner/990 • Platform Engineering とは何か？なぜ注目されているのか • Platform Engineering はこれまでの SRE やインフラチームと何が違うのか？ • Platform Engineering を実現する上で重要な組織論「チームトポロジー」とは？ • Platform Engineering の2つの「IDP」～ Internal Developer Platform とは？ • Platform Engineering の2つの「IDP」～ Internal Developer Portal とその代表例 Backstage 著者:Matthew Skelton, Manuel Pais 著者:Mauricio Salatino 著者:tanayan / namayasai_tech KubeVela デモソース https://github.com/oracle-japan/ochacafe-s9-2

Platform Engineering ことはじめ

Platform Engineering ことはじめ

Video

More Decks by oracle4engineer

Other Decks in Technology

Featured

Transcript