大規模エンタープライズの全員参加が可能な内部開発者ポータルの野望
9.1K Views
July 09, 24
スライド概要
2024/07/09(火) Platform Engineering Kaigi 2024
https://www.cnia.io/pek2024/sessions/342bb6b7-33c0-48ef-9476-4a87529c2a37/
Microsoft MVP for Microsoft Azure
関連スライド
各ページのテキスト
Platform Engineering Kaigi 2024 大規模エンタープライズの全員参加が可能な内部開発者ポータルの野望 2024年07月09日(火) 株式会社バンダイナムコスタジオ 技術スタジオ 第3グループ オンラインテクノロジー部 サーバソリューションユニット DXセクション 八重樫 剛史 Takeshi Yaegashi
自己紹介 • 八重樫 剛史 Takeshi Yaegashi • 株式会社バンダイナムコスタジオ (BNS) 技術スタジオ 第3グループ オンラインテクノロジー部 サーバソリューションユニット DXセクション テクニカルディレクター • 社内開発者向けのクラウドサービス導入推進 プラットフォームエンジニアリングのプロジェクトに従事 • Microsoft MVP for Microsoft Azure (2023) https://mvp.microsoft.com/ja-jp/PublicProfile/5005134 • Web (blog) X (Twitter) GitHub https://l0w.dev https://x.com/hogegashi https://github.com/yaegashi 2
本日のお話 • バンダイナムコスタジオのプラットフォームエンジニアリングプロジェクト • Bandai Namco DX Cloud Studios (2022, 2024) の紹介 • バンダイナムコスタジオのインナーソース (InnerSource) 推進プロジェクト • 大規模エンタープライズにおけるインナーソースプラットフォームの課題 • 内部開発者ポータル (Internal Developer Portal, IDP) による課題の解決・緩和策 • バンダイナムコスタジオにおけるインナーソースポータルの構築計画 • 「大規模エンタープライズの全員参加が可能な内部開発者ポータルの野望」とは？ • 本日のお話の一部は計画段階であり、完成したもの・実績があるものではないことを示します • 来月以降の登壇イベントでもプラットフォームエンジニアリングの取り組みの進捗を継続して報告いたします ご期待ください (詳細は最後に) 3
バンダイナムコスタジオのプラットフォームエンジニアリング • Bandai Namco DX Cloud Studios • 「クラウド上のゲーム開発スタジオ」を構築しようという取り組み • コロナ禍をきっかけに始まった2022 年版と、現在社内テスト実施中の2024年版がある • GPU搭載VMによる仮想デスクトップやゲームアプリビルドのCI/CD環境などを提供する • インナーソース • いわゆる「社内オープンソース」推進の取り組み • 社内インナーソースのカタログを提供するインナーソースポータルをBackstageで構築 4
Bandai Namco DX Cloud Studios (2022) • CEDEC 2022「DX(開発者体験)の向上を目指すゲーム開発インフラの進化とDX(デジタル変革)」 • コロナ禍の在宅勤務の開始をきっかけとしてAzureでクラウド上のゲーム開発スタジオ構築を目指す • 新人研修ゲーム開発プロジェクトなどで活用実績を残したが、ほぼワンオペであったため規模拡大できず [1] https://cedec.cesa.or.jp/2022/session/detail/184 5
Bandai Namco DX Cloud Studios (2024) • 自動化と運用体制の不備を反省して2023年にリブートしたプロジェクト • 目標: 高度なセルフサービスが可能なインフラ・プラットフォームの構築プロジェクト • 完全にIaC・自動化されたマネージドインフラ • Azure Virtual Desktop, Windows 365 Enterprise, Microsoft Dev Box, Azure Deployment Environments に対応 • 汎用タスクランナー • GitHub Actionsで定義されたマネージドインフラ操作のタスクを実行 • セルフサービスポータル • 開発者によるマネージドインフラと汎用タスクランナーの利用を可能にするWebアプリ • 2024年6月に社内でアルファテスト開始の段階 6
DX Cloud Portal: 個人用 Azure Virtual Desktop 管理ダッシュボード (開発中) • 個人の Azure Virtual Desktop ホストを管理できるダッシュボード • 仮想マシンの電源のオンオフ、RDP接続、サイズ変更などの操作がセルフサービスでできる 7
DX Cloud Portal: セルフサービスタスクランナー (開発中) • さまざまなセルフサービスタスクを選択して入力パラメータつきで実行できる • GitHubリポジトリ内のYAMLの設定ファイルによりMarkdownドキュメントや実行するGitHub Actionsを指定 8
Bandai Namco DX Cloud Studios (2024) • 参考: Microsoft Learn「開発者向けセルフサービス基盤を設計する」[1] • Microsoftのプラットフォームエンジニアリングのドキュメントに含まれるガイドライン • 今回紹介した Bandai Namco DX Cloud Studios (2024) もこのガイドラインにほぼ従っている [1] https://learn.microsoft.com/ja-jp/platform-engineering/developer-self-service 9
インナーソース推進の取り組み • インナーソース (InnerSource) とは？ • オープンソースの開発手法・カルチャー・ベストプラクティスを企業内のソフトウェアで実践する取り組み • 組織内のサイロを壊し、コラボレーションを加速して、車輪の再発明を防ぐ 1-2 InnerSource とは︖ 1-2 InnerSource で⽬指す姿 ● InnerSource は、企業内のソフトウェア開発にオープンソースの実践と ベストプラクティスと原則を適⽤したものです。 ● InnerSource ソフトウェアは、会社としてはプロプライエタリなものとなりますが、 内部にはオープンで、誰もが利⽤したり貢献したりできるようになります。 つまり ・・・ 今まで ⽬指す姿 サイロごとに閉じている 何をしているか⾃部⾨以外のことは知らない サイロを取り払い、コラボレーションが各所で発⽣︕ Open all artifacts! Welcome visitors! ・・・ を企業内で実践することです。 Dirk Riehle, Inner Source (Software Development), InnerSource Summit 2018 InnerSource Commons Japan Source: インナーソースで始める組織内オープンソース開発入門 10 InnerSource Commons Japan 10 11
インナーソース推進コミュニティの活動 • InnerSource Commons [1] • 750の組織から3000人が参加するグローバルコミュニティ • InnerSource Commons Japan [2] • 07/02(火) InnerSourceの価値基準を考える会#3 [3] → 日本企業組織でインナーソースを普及させるための企画会議 • 08/08(木) InnerSource Gatherning Tokyo 2024 [4] → 有名人・有名書籍・有名企業のコンテンツがたくさん [1] https://innersourcecommons.org/ [2] https://innersourcecommons.connpass.com/ [3] https://innersourcecommons.connpass.com/event/322114/ [4] https://innersourcecommons.connpass.com/event/317995/ 11
コミュニティによるインナーソース導入・推進のガイド • インナーソースで始める組織内オープンソース開発入門 [1] • インナーソースの基本的な用語・組織・役割・カルチャーの解説 • インナーソースの参加者全員にまず読んでもらうのに最適な資料 • インナーソースパターンブック [2] • 様々な組織で実績のあるベストプラクティスのパターン集 • 「インナーソースポータル」パターンが存在する • Managing InnerSource Projects [3] • 英語版のみ・一部未完成の本 • インナーソースのためのインフラ・プラットフォームについて論じる • GitHub を利用する場合の推奨戦略が参考になる • InnerSource Dedicated Environment • Enterprise/Organization/Repository の推奨設定 [1] https://speakerdeck.com/yuhattor/innersource-learning-path-japanese [2] https://innersourcecommons.org/ja/learn/books/innersource-patterns/ [3] https://innersourcecommons.org/learn/books/managing-innersource-projects/ 12
インナーソースのプラットフォームに関する常識(？) • GitHubまたは類似の開発者プラットフォーム (GitHub, GitLab, Azure DevOps, etc.) を利用している • インナーソースが手本とするオープンソースプロジェクトの多くがGitHubを利用 • リポジトリだけでなくイシュー、プルリクエスト、ディスカッション、リリースなどの機能を備える → インナーソースを推進する組織や役割、カルチャーを実現するために活用している • インナーソースの参加者全員がその開発者プラットフォームを利用できる • 参加者は開発者プラットフォームのユーザーIDを持ち (認証)、適切なアクセス権限が設定されている (認可) → インナーソースプロジェクトはクローズドなソフトウェア資産を扱うため厳密なアクセス管理が必要 • 多数のプロジェクトの多数のステークホルダーが同時に参加できる → インナーソースは参加者の数が多ければ成功の可能性が高まる → エンジニアだけでなく単なるユーザーも開発者プラットフォームにアクセスできることが望ましい → ただし現実の大規模エンタープライズでは上記の前提が成り立たないことがある 13
大規模エンタープライズにおけるインナーソースのプラットフォームの課題 ① • 理想 → 参加者全員が単一の開発者プラットフォーム(GitHubなど)でインナーソースを推進 • 現実 → 参加者全員が利用できる開発者プラットフォームがなくインナーソースを推進できない • 多くの組織で開発者プラットフォームの分断が発生している • 特に利用料金がネックとなり、特定のプロジェクトや特定の職種のユーザー以外にアクセス権限が与えられないことが多い • 大規模エンタープライズではその規模と歴史的経緯から開発者プラットフォームが乱立しがち • 一部のユーザーしかアクセスできない開発者プラットフォームは利用を敬遠されてしまう [Source] https://twitter.com/hogegashi/status/1798468330111857093 14
大規模エンタープライズにおけるインナーソースのプラットフォームの課題 ② • 大規模なエンタープライズに特有の多層化したインナーソースのスコープ • ソフトウェア資産ごとに公開範囲が限定される「エンタープライズ全体」「A会社のみ」「Aプロジェクトのみ」 • 多くエンタープライズではMicrosoft Entra IDなどで組織を反映したグループ階層を定義しているのでそれを活用する A会社 A事業部 A部 A課 B課 B会社 B事業部 C事業部 D事業部 B部 C部 D部 E部 C課 D課 E課 F課 Aプロ ジェクト Bプロ ジェクト Cプロ ジェクト 15
大規模エンタープライズにおけるインナーソースのプラットフォームの課題の解決・緩和策 • 全ユーザーが参加できるインナーソースポータルの構築 • いわゆる内部開発者ポータル Internal Developer Portal (IDP)の追加による問題解決のアプローチ • ポータルはユーザーの数に関係なく低コストで運用可能 • ポータルは組織内の開発者プラットフォームにアクセスしてソフトウェアカタログを構築する • ユーザーが組織内のインナーソースプロジェクトを発見するための新たなビューを提供する 16
インナーソースパターン: インナーソースポータル • 「インナーソースパターンブック」にもインナー ソースポータルのアプローチの記載がある [1] • インナーソースポータルは組織内に存在するインナーソー スプロジェクトのインデックスを提供する • 組織内の潜在的なコントリビューターが貢献可能なイン ナーソースプロジェクトの存在を知るきっかけとなる • インナーソースポータルの参考実装としてWebアプリ 「Project Portal for InnerSource」が紹介されている [2] [1] https://patterns.innersourcecommons.org/v/ja/toc [2] https://github.com/SAP/project-portal-for-innersource 17
Managing InnerSource Projects: InnerSource Catalogs as an InnerSource Dedicated Environment • 「Managing InnerSource Projects」でGitHubの 「InnerSource Dedicated Environment」として 「InnerSource Catalogs」が提案されている [1] • インナーソースカタログのアプローチ • 定義: 可視性を高めたいリポジトリが、収集の目印とな るタグを自分につけて、インナーソースカタログに収 集される。 • 利点: 再利用を希望するリポジトリが一箇所に集まるの で、インナーソースの発見や効果測定が容易になる。 • 欠点: 多くの開発者は積極的に業務を離れてカタログ探 究に時間を割こうとはしない。また「カタログに含ま れる = インナーソース」という誤解が生じるリスクが ある。 [1] https://innersourcecommons.gitbook.io/managing-innersource-projects/innersource-tooling/github-strategy 18
大規模エンタープライズにおけるインナーソースポータルの要件 • 低コストで運用可能なポータル • ユーザーの数に関係なく、セルフホストで運用でき、実装がオープンソースであることが望ましい • 組織内のすべてのユーザーをカバーできるID基盤 • 大規模エンタープライズのユーザーが全員参加できるようにする • ポータル利用にまつわる手続き的・心理的な障害を可能なかぎりなくす → なるべく多くのユーザーが使うクラウドサービス(MS365など)と同じ既存ID基盤でSSOできるようにする → 新規ID基盤の導入は多くの場合アンチパターン: ユーザーは使うのが面倒で足が遠のいてしまう • 組織内の多様な開発者プラットフォーム(GitHub, GitLab, Azure DevOpsなど)との連携 • 開発者プラットフォームはポータルを特別なユーザー・アプリとしてアクセスを許可する (GitHub App などを利用) • ポータルはユーザーに代わり開発者プラットフォーム内を探索しインナーソースプロジェクトカタログを作成する • 詳細なアクセス制御手段 • エンタープライズ内の一部の組織・ユーザーにのみに公開したいという要件に対応する • ユーザーに負担のないポータル更新手段の提供 • 例1: リポジトリに設定するトピック・タグによりカタログへの記載・不記載をコントロールできる • 例2: リポジトリ内の特定のファイル (README.mdやcatalog-info.yamlなど) が自動的にカタログに記載される 19
大規模エンタープライズにおけるインナーソースポータルの Backstage による実装 公式サイト https://backstage.io デモサイト https://demo.backstage.io Spotifyが開発した「開発者ポータル構築フレームワーク」 2020年3月 Cloud Native Computing Foundation (CNCF) に寄贈されたオープンソースプロジェクトとなる 柔軟性の高いプラグインアーキテクチャにより 高度な拡張・カスタマイズが可能 大規模エンタープライズのさまざまな件を満たす 20
Backstage の基本機能 • Core Features • Software Catalog → ソフトウェアだけでなくグループやユーザーの情報(Entity)をIntegrationsを通じて取得する • TechDocs → mkdocs形式の文書を閲覧可能にする • インナーソースポータル構築に必要な機能が最初から備わっている • Integrations • AWS S3・Azure DevOps・Bitbucket・Datadog・Gerrit・GitHub・GitLab・Gitea・Google GCS・LDAP • さまざまな開発者プラットフォームやデータソースに対するデータ取得手段を提供する • Authentication • Auth0・Atlassian・Microsoft・Bitbucket・Cloudflare・GitHub・GitLab・Google・Okta・OneLogin・VMware • Azure Easy Auth・Google IAP・OAuth2 Proxy のようなプロキシ型の認証にも対応している • Backstageのユーザー認証結果からユーザーEntityへのマッピングを行う (sign-in resolver) • Permission • BackstageにサインインしたユーザーによるEntity操作の可否を試行の都度判定する • 認可判定のコードを統一できる Permission Framework を備える 21
Backstage Software Catalog: 組織のグループ・ユーザー情報 (Entity) 収集と認証統合 • Microsoft Entra ID や GitHub Enterprise など複数のデータソースから組織のグループ・ユーザー情報 (Entity) を収集 • ユーザー認証結果から対応するユーザー Entity の解決 (sign-in resolver) 22
Backstage Software Catalog: プロジェクト登録 • リポジトリのトップの catalog-info.yaml ファイルに情報を記載すると定期的に Backstage が収集・登録してくれる • 検索しやすくするために適切な metadata を設定し spec.owner でプロジェクトオーナーの連絡先を明示する apiVersion: backstage.io/v1alpha1 kind: Component metadata: name: 876-devstage title: Bandai Namco DevStage DevOps description: Bandai Namco DevStage DevOps tags: - backstage - devops - azure-container-apps - azure-developer-cli annotations: github.com/project-slug: AAAAAAAA/876-devstage backstage.io/techdocs-ref: dir:. links: - url: https://devstage.sites.local title: DevStage (production) icon: dashboard type: production - url: https://devstagedev.sites.local title: DevStage (development) icon: dashboard type: development spec: type: website owner: user:me/ZZZZZZZZ.bandainamco.co.jp 23
Backstage TechDocs: プロジェクトドキュメント生成 • リポジトリに含まれる MkDocs 形式[1]のドキュメントをインナーソースポータル内で表示 • catalog-info.yaml の anotation.backstage.io/techdocs-ref で指定した場所の mkdocs.yml ファイルを読み込む site_name: DevOps for Backstage on Azure Container Apps plugins: - techdocs-core nav: - Introduction: index.md - Local development: local_development.md - Azure deployment: azure_deployment.md - Architecture: architecture.md - How to contribute: contributing.md [1] https://www.mkdocs.org/ 24
バンダイナムコグループ向けインナーソースポータルの Backstage による実装の概要 • Backstage Web App DevOps • Azure Container Apps によるクラウドネイティブな実装と運用 • 様々なデータソースからユーザー・グループカタログを生成 • Microsoft Entra ID (ME-ID) ユーザー・グループ情報 (ほぼ全従業員をカバーする) • GitHub Enterprise ユーザー・チーム情報 (エンジニアのみ) • オンプレミスActive Directory ユーザー・グループ情報 (対応予定) • 様々な開発者プラットフォームからプロジェクトカタログを生成 • GitHub Enterprise Cloud (指定のGitHub AppをインストールしたOrg/Repoが対象) • Azure DevOps Services (指定のME-IDサービスプリンシパルをアクセス許可したOrg/Repoが対象) • オンプレミスGitLab (対応予定) • 厳密なアクセスコントロールの実現 (計画中) • GitHubリポジトリ リリース情報・アセットダウンロードの提供 (計画中) 25
Backstage Web App DevOps • dx2devops-backstage-containerapp [1] • Backstage を Azure Container Apps でクラウドネイティブに運用するためのプロジェクト • Bicep および Azure Developer CLI による IaC を徹底し将来的には SaaS 化した Backstage の実現を目指す [1] https://github.com/yaegashi/dx2devops-backstage-containerapp 26
Microsoft Entra ID (ME-ID) からのユーザー・グループカタログ生成 • 基本的な方針 • Microsoft Graph PowerShellスクリプトでME-IDからUser/Groupカタログファイルを生成しGitHubリポジトリに格納 • Backstageサイトごとにapp-config.yamlのlocationsにより必要なカタログファイルをGitHubリポジトリから読み取る • 他のデータソースと重ならないように名前空間を分ける • BackstageのmicrosoftGraphOrg Integrationを使わず自作スクリプトでカタログ生成する理由 • ME-ID管理者権限がないためBackstageにUser.Read.Allのような強い権限を与えるアプリ登録が作れない • BackstageからMicrosoft Graphの直接アクセスがなくなるためセキュリティが向上し負荷対策にもなる • スクリプトの作成は大して難易度が高くなくカタログ記載内容に大きな柔軟性が得られる • オンプレミスADのようなクラウドから直接アクセスできない情報ソースの統合にも応用できる 27
Microsoft Entra ID (ME-ID) から生成したユーザー・グループカタログYAMLの例 apiVersion: backstage.io/v1alpha1 kind: User metadata: namespace: me name: ZZZZZZZZ.bandainamco.co.jp title: 八重樫 剛史 Takeshi Yaegashi description: テクニカルディレクター annotations: graph.microsoft.com/user-type: Member microsoft.com/email: [email protected] graph.microsoft.com/user-job-title: テクニカルディレクター graph.microsoft.com/user-id: 759b0071-ba18-4cc1-9a88-ff1b90a35c82 graph.microsoft.com/user-sam-account-name: yaegashi graph.microsoft.com/user-principal-name: [email protected] spec: profile: email: [email protected] displayName: 八重樫 剛史 Takeshi Yaegashi memberOf: - 938f6261-cad8-42dc-bb28-357f2c3ab465 apiVersion: backstage.io/v1alpha1 kind: Group metadata: namespace: me name: 938f6261-cad8-42dc-bb28-357f2c3ab465 title: ＤＸセクション annotations: microsoft.com/email: [email protected] graph.microsoft.com/group-id: 938f6261-cad8-42dc-bb28-357f2c3ab465 spec: profile: email: [email protected] displayName: BNS-技術スタジオ第３グループオンラインテクノロジー部サーバーソ リューションユニットＤＸセクション type: business-unit parent: 23a88184-a126-47b8-8885-303e7b276f6f children: [] 28
柔軟なアクセスコントロールの実現 (計画中) • インナーソースポータル内でプロジェクトの公開範囲を設定できる機能 • 大規模エンタープライズでは一般的な要件 • Entity の効率的な可視性判定が可能な Backstage Permission Policy を開発中 • カスタムの sign-in resolver によりユーザーが所属する推移的なグループのリストを作って claims に追加する [1] • spec.visibleTo でその entity が「見える」ユーザーやグループの entityRef を指定可能にする apiVersion: backstage.io/v1alpha1 kind: Component metadata: name: 876-devstage title: Bandai Namco DevStage DevOps description: Bandai Namco DevStage DevOps tags: [...] annotations: github.com/project-slug: AAAAAAAA/876-devstage backstage.io/techdocs-ref: dir:. links: [...] spec: type: website lifecycle: experimental owner: user:me/ZZZZZZZZ.bandainamco.co.jp visibleTo: - group:me/23a88184-a126-47b8-8885-303e7b276f6f [1] https://backstage.io/docs/auth/identity-resolver/#custom-ownership-resolution 29
GitHubリポジトリ リリース情報・アセットダウンロードの提供 (計画中) • インナーソースポータルでGitHubアカウントがないユーザーにもリリース成果物を提供する • より多くのステークホルダーをプロジェクトに巻き込むことでインナーソースをさらに推進する • GitHubリポジトリのリリース情報をBackstage TechDocsに変換するmkdocsプラグインの開発 • 参考: mkdocs_github_changelog プラグイン [1] • 各リリースのMarkdownドキュメントをTechDocsのページとして整形する • 各リリースのアセットファイルをBackstageユーザーがアクセス可能な場所にミラーする [1] https://github.com/djpugh/mkdocs_github_changelog 30
CEDEC2024 で引き続き報告します！ • CEDEC2024 [1] 08/21(水) – 08/23(金) パシフィコ横浜ノース • 「社内開発者ポータルを活用したインナーソースの推進と技術的課題の解決」 [2] 第5会場 08/23(金) 13:40-14:40 レギュラーセッション • 今回紹介したBackstageによるインナーソースポータルの実装計画を完成させるとともに、 実際の組織で運用してみた事例を報告します。ご期待ください。 [1] https://cedec.cesa.or.jp/2024/ [2] https://cedec.cesa.or.jp/2024/session/detail/s6609d4c7012c9/ 31
まとめ • 本日お話したトピック • バンダイナムコスタジオのプラットフォームエンジニアリングとインナーソース推進の取り組み • 大規模エンタープライズが抱える課題とその内部開発者ポータルによる解決・緩和策 • インナーソースポータル構築を目的としたBackstageのインテグレーションと改良実装計画 • イベントのお知らせ • 08/08(木) InnerSource Gatherning Tokyo 2024 • 08/09(金) GitHub Actions Meetup Tokyo #4 • 08/23(木) CEDEC 2024「社内開発者ポータルを活用したインナーソースの推進と技術的課題の解決」 32
Thank You!! 33