$30 off During Our Annual Pro Sale. View Details »

Platform Engineering ことはじめ

Platform Engineering ことはじめ

Oracle Cloud Hangout Cafe Season9 第2回目 資料

oracle4engineer

November 06, 2024
Tweet

Video

More Decks by oracle4engineer

Other Decks in Technology

Transcript

  1. Platform Engineering ことはじめ Oracle Cloud Hangout Café Season9 #2 Yutaka

    Ichikawa Oracle Corporation Japan Solutions Architect Nov 6, 2024
  2. 自己紹介 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
  3. 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
  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 (吉川 俊甫[著])
  5. Copyright © 2024, Oracle and/or its affiliates 6 Platform Engineering

    とは? 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. プラットフォームエンジニアリングは、セルフサービスの内部開発プラットフォームを構築し運用するための専門分野です。 各プラットフォームは、ツールやプロセスと連携し、ユーザーのニーズをサポートするために専任のプロダクトチームによって 作成され、維持されるレイヤーです。プラットフォームエンジニアリングの目的は、生産性の最適化、ユーザー体験の向上、 そしてビジネス価値の提供を加速させることです。
  6. Copyright © 2024, Oracle and/or its affiliates 7 Platform Engineering

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

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

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

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

    とは? Platform Engineering におけるプラットフォーム これまでのプラットフォームの考え方の違い プラットフォーム作りを成功させる考え方が含まれていること プラットフォームの成功、失敗はそもそも何なのか?
  11. Copyright © 2024, Oracle and/or its affiliates 12 Platform Engineering

    とは? Platform Engineering におけるプラットフォーム 開発者 • ローカル環境では開発を進めている • アプリケーションをサーバーにデプロイしたいが CI/CD 環境構築はハードルが高い(認知負荷) 一例から Platform Engineering におけるプラットフォームを考えてみましょう!
  12. Copyright © 2024, Oracle and/or its affiliates 13 Platform Engineering

    とは? Platform Engineering におけるプラットフォーム プラットフォーム提供者 開発者 CI/CD プラットフォームを提供 CI/CD プラットフォーム
  13. Copyright © 2024, Oracle and/or its affiliates 14 Platform Engineering

    とは? Platform Engineering におけるプラットフォーム 開発者 提供された CI/CD プラットフォームは、馴染みの無い 技術で構築されてメンテンナンスできない プラットフォーム提供者 CI/CD プラットフォームを提供した後は、放置状態 CI/CD プラットフォーム
  14. Copyright © 2024, Oracle and/or its affiliates 15 Platform Engineering

    とは? Platform Engineering におけるプラットフォーム 開発者 自分たちでメンテンナンスしやすい 新たな CI/CD プラットフォームつくることにしよう! 新CI/CD プラットフォーム
  15. Copyright © 2024, Oracle and/or its affiliates 16 Platform Engineering

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

    とは? Platform Engineering におけるプラットフォーム プロダクト開発と同様に、プラットフォーム開発においても「誰に」、「何を」を明確に意識する 利用者に対して価値を提供できているかの観点で、継続的なプラットフォームの更新と運用をする(「どのように」) 一例からの考察! 誰に 何を どうやって プラットフォーム 利用者 ◦◦という価値 技術 出典: CodeZine 「Platform Engineeringとは何か? なぜ注目されているのか 第2回 Platform EngineeringはこれまでのSREやインフラチームと何が違うのか?」 図:Platform Engineeringにおいて意識するポイント (https://bit.ly/CZ-PF02) を参考 継続的に回す Platform Engineering でのフォーカスポイント 失敗するプラットフォームが フォーカスしがちなポイント
  17. 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を満たさな かった場合の対応を説明した契約
  18. 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) を参考
  19. Copyright © 2024, Oracle and/or its affiliates 22 チームトポロジーとは? Team

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

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

    コンプリケイテッド・サブシステムチーム イネーブリングチーム ストリームアラインドチーム プラットフォームチーム 出典: 『Team Topologies』 by Matthew Skelton and Manuel Pais, 2019 P141 「図 5.1 4つの基本的なチームタイプ」を元に発表者作成
  23. Copyright © 2024, Oracle and/or its affiliates 26 チームトポロジーとは? コラボレーション

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

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

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

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

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

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

    改善するためには? ストリームアラインドチーム コンプリケイテッド・サブシステムチーム プラットフォームチーム イネーブリングチーム 他の3つのチームと連携して、高い認知負荷の削減を目指す! プラットフォームチームがストリームアラインドチームに対して実施する認知負荷の削減支援の方法論こそが Platform Engineering
  30. Copyright © 2024, Oracle and/or its affiliates 33 チームトポロジーとは? ストリームアラインドチームとプラットフォームチーム

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

    Platform as a Product プラットフォームチームは、ストリームアラインドチームを顧客として扱う コミュニケーションを重視してニーズを把握する ストリームアラインドチーム プラットフォームチーム 顧客 価値の提供 価値の提供 プラットフォームをプロダクトとして見立てる X-as-a-Service 継続的な運用と拡張 Platform as a Product
  32. 2つの IDP - Internal Developer Platform & Internal Developer Portal

    - Copyright © 2024, Oracle and/or its affiliates 35
  33. Copyright © 2024, Oracle and/or its affiliates 36 2つの IDP

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

    - 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つの主要コンポーネントを網羅すように設計することが推奨される
  35. Copyright © 2024, Oracle and/or its affiliates 38 2つの IDP

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

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

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

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

    - Internal Developer Platform & Internal Developer Portal - デプロイメント管理 プラットフォームチームが CI/CD のテンプレートを提供して、開発者がより簡単にデプロイできるようにする ストリームアラインドチーム 開発者 Git CI CD 開発環境 QA環境 本番環境 プラットフォームチーム テンプレート提供
  40. Copyright © 2024, Oracle and/or its affiliates 43 2つの IDP

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

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

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

    - Internal Developer Platform & Internal Developer Portal - Internal Developer Portal Internal Developer Portal (内部開発者ポータル) ストリームアラインドチーム 開発者 Internal Developer Platform (内部開発者プラットフォーム) 開発者が Web UI を経由して、内部開発者ポータルから内部開発者プラットフォームを操作する。 開発者ポータルを構築する代表的なツールが Backstage
  44. Copyright © 2024, Oracle and/or its affiliates 48 Backstage とは?

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

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

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

    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/
  48. Copyright © 2024, Oracle and/or its affiliates 52 Backstage とは?

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

    Backstage のコンセプト 1. Backstage is the interface Backstage は、複数のツールを同一のインターフェースを通して一元化することを目的としている。 2. Backstage embraces autonomy Backstage を通して、開発者に必要なものをセルフサービスで提供し、開発者、チームへの自律性を支援する。 3. Backstage demands clear ownership Backstage で管理するツールやソフトウェアのコンポーネントを所有するチームに紐づけて明確化する。
  50. Copyright © 2024, Oracle and/or its affiliates 54 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/
  51. Copyright © 2024, Oracle and/or its affiliates 55 株式会社エーピーコミュニケーションズ 亀崎仁志

    セッション資料 Backstage 入門 https://bit.ly/backstage-introduction
  52. Copyright © 2024, Oracle and/or its affiliates 57 Platform Engineering

    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
  53. Copyright © 2024, Oracle and/or its affiliates 58 Platform Engineering

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

    on Kubernetes Crossplane とは? Crossplaneは、Kubernetes 上でクラウドインフラやアプリケーションリソースを管理するための オープンソースの制御プレーン https://www.crossplane.io/
  55. Copyright © 2024, Oracle and/or its affiliates 60 Platform Engineering

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

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

    on Kubernetes Crossplane とは? 3. Composite Resource (XR) XRDで定義された型の実際のインスタンスであり、具体的なリソース作成の要求。 クラウドリソースにおいて、「このリソースを作ってください」を定義する
  58. Copyright © 2024, Oracle and/or its affiliates 63 Platform Engineering

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

    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
  60. Copyright © 2024, Oracle and/or its affiliates 65 Platform Engineering

    on Kubernetes OAM (Open Application Model) と Platform Engineering この書籍を読み進めていく中で、 OAM (Open Application Model) と Platform Engineering との相性が良かったりするのでは?
  61. Copyright © 2024, Oracle and/or its affiliates 66 Platform Engineering

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

    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
  63. Copyright © 2024, Oracle and/or its affiliates 68 Platform Engineering

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

    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 アーキテクチャ
  65. Copyright © 2024, Oracle and/or its affiliates 70 Platform Engineering

    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 ネームスペースにデプロイされる
  66. Copyright © 2024, Oracle and/or its affiliates 71 Platform Engineering

    on Kubernetes KubeVela - get started - Application マニフェスト例 1.Component(コンポーネント) 2. Traits(トレイト) Pod のスケール設定 Webアプリデプロイ用のコンポーネント タイプ、使用するコンテナイメージ、 ポート番号、外部公開を定義
  67. Copyright © 2024, Oracle and/or its affiliates 72 Platform Engineering

    on Kubernetes KubeVela – get started - Application マニフェスト例 3.Policies(ポリシー) KubeVela がインストールされたローカルクラスター にデプロイする設定を定義 • default ネームスペースにデプロイする設定 • prod ネームスペースにデプロイする設定
  68. Copyright © 2024, Oracle and/or its affiliates 73 Platform Engineering

    on Kubernetes KubeVela - get started - Application マニフェスト例 4. Workflow(ワークフロー) policies で定義した 「target-default」、 「target-prod」、 「deploy-ha」 に従ってデプロイするためのワークフローを定義 default ネームスペースにデプロイ ↓ 手動承認 ↓ prod ネームスペースにデプロイ
  69. Copyright © 2024, Oracle and/or its affiliates 74 Platform Engineering

    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.クリーアップ
  70. Copyright © 2024, Oracle and/or its affiliates 75 Platform Engineering

    on Kubernetes KubeVela - get started - ブラウザで表示される Webアプリケーション
  71. Copyright © 2024, Oracle and/or its affiliates 76 Platform Engineering

    on Kubernetes KubeVela - get started - Workflow のステータス(手動承認後) Workflow のステータス(承認待ち)
  72. Copyright © 2024, Oracle and/or its affiliates 77 Platform Engineering

    on Kubernetes KubeVela - get started - クラスタのリソース状況
  73. Copyright © 2024, Oracle and/or its affiliates 78 Platform Engineering

    on Kubernetes OAM (Open Application Model) と Platform Engineering プラットフォームチームとストリームアラインドチームの役割 ストリームアラインド チーム プラットフォーム チーム Application マニフェスト 環境管理 テンプレート 提供 マニフェスト 作成/適用 リリース 対象環境 開発者に寄り添った環境管理とテンプ レートマニフェスト(Component / Trait / Policy)の作成 プラットフォームチームか ら提供されたマニフェスト を利用し、開発に専念
  74. Copyright © 2024, Oracle and/or its affiliates 79 株式会社エーピーコミュニケーションズ 亀崎仁志

    セッション資料 Backstage 入門 https://bit.ly/backstage-introduction2 Slide Page : P38-P40
  75. 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
  76. Copyright © 2024, Oracle and/or its affiliates 82 コミュニティ &

    カンファレンス Platform Engineering Meetup Platform Engineering Kaigi 2024 https://www.cnia.io/pek2024/ https://platformengineering.connpass.com/
  77. Copyright © 2024, Oracle and/or its affiliates 83 コミュニティ &

    カンファレンス Platform Engineering Meetup #10 https://platformengineering.connpass.com/event/329871/