⼤規模ゲーム開発を⽀える Azure DevOpsによるクラウドネイティブなCI/CDの紹介 株式会社バンダイナムコスタジオ 技術スタジオ ネットワークシステム部 ⼋重樫 剛史 Takeshi Yaegashi

⾃⼰紹介 ⼋重樫 剛史 Takeshi Yaegashi § 株式会社バンダイナムコスタジオ (BNS) 所属 § Linux・Unix・OSS・Go ⾔語が好きなエンジニア § 組み込みシステム開発、ゲームサーバ開発、 開発環境のクラウドシフトなどの業務に従事 主な活動場所 ホームページ・ブログ https://l0w.dev GitHub https://github.com/yaegashi GitLab https://gitlab.com/yaegashi Twitter https://twitter.com/hogegashi

本⽇のアジェンダ § バンダイナムコスタジオにおけるクラウドネイティブ CI/CD インフラの探求 § Azure DevOps によるクラウドネイティブ CI/CD インフラの構築 § Unity アプリのクラウドネイティブ CI/CD インフラの構築 § Unreal Engine アプリのクラウドネイティブ CI/CD インフラの構築

本⽇の話題の中⼼ § いわゆるゲームクライアント側アプリの CI/CD インフラについて扱います - つまり PC、コンソール、モバイル端末などで動作するアプリ - ゲームサーバ側アプリの CI/CD インフラの話はでてきません - 開発ツールの都合上 Windows VM でビルドを⾏う話が多くなります - Unity、Unreal の 2 ⼤ゲームエンジンのアプリビルドの事情について § 過去の講演の内容を再構成し、新しいトピックを追加しています - JTF2021W: Azure DevOps で実現する Unity アプリのハイパフォーマンス CI/CD - CEDEC2021: 2020年代のゲーム開発のためのクラウドネイティブCI/CDパイプラインの構築 - CEDIL より資料がダウンロードできます (登録が必要) h)ps://cedil.cesa.or.jp/cedil_sessions/view/2417

バンダイナムコスタジオにおける クラウドネイティブなCI/CDインフラの探求

バンダイナムコスタジオ (BNS) の IT インフラの状況 § バンダイナムコグループの Microsoft/Windows ベースの IT インフラ - 10,000 名近くのグループ従業員のほとんどが Office 365 E3 ライセンスを所持 - 全グループ従業員・組織が登録された ID 認証基盤として Azure AD がすでに存在する § バンダイナムコスタジオの状況 - 従業員約 1,000 名のグループ内で最⼤のゲーム開発会社 - エンジニアのほとんどは Visual Studio サブスクリプションを所持 - Azure → 毎⽉ 6,000 円の Azure 無料クレジット、Azure VM の Windows OS 代⾦免除 - Azure DevOps → 無料で利⽤可能 § これを踏まえ 2020 年より社内での Azure および Azure DevOps の利⽤推進を本格化

CI/CDインフラの様々な要素・⽤語 § コントローラ × 1 - CI/CD パイプラインを管理する役割 - エージェントへのジョブ割当てやオーケストレーションを⾏う - Jenkins CI のマスタ § エージェント × N - パイプライン上でアプリビルドなどのジョブを実⾏する役割 - Jenkins CI のスレーブ § ストレージ - リポジトリ → アプリのソースコードやアセットを保持するストレージ - その他、アーティファクトやキャッシュなどのデータを格納する様々なストレージが存在

従来のオンプレミスのCI/CDインフラ ( ) PC Jenkins CI PC C PC B PC A PC Active Directory PC VPN § オンプレミスのプラ イベートネットワー クで、各プロジェク トの開発者がPCやVM を使って様々なCI/CD インフラを構築して いる § 境界型セキュリティで保護されている ため、認証はほとんど設定されておら ず、通信の暗号化などを要求されるこ ともない § COVID-19 で在宅勤務の開発者が増えた ことから、オンプレミスでの CI/CD イ ンフラ構築は限界となっており、クラ ウドに移⾏する機運が⾼まっている

クラウドにリフトアンドシフトしたCI/CDインフラ ( ) Azure VNet (IaaS) PC NGINX SSL Jenkins CI Azure VM C Azure Storage Azure VM B Azure VM A PC Azure AD Azure DNS PC SSL § オンプレミスでの構成の ままクラウドに移⾏ § クラウド上で安全に稼働 させるためDNS、SSL証明 書、認証・認可など多く の要素が追加されている § ゼロトラストセキュリ ティによりVPNが不要と なり在宅勤務の開発者の 帯域制限問題が解消 § ただし、これらすべてを ⾃⼒で構築できる開発者 は少なく、多くの場合イ ンフラエンジニアの助け が必要

オンプレミスベアメタル vs. クラウドVM § ベアメタルはハードウェアの最⾼のパフォーマンスを発揮可能 - さらに近年のワークステーション向け PC はめざましい性能向上を達成 - 例：AMD Ryzen Threadripper による 64コア128スレッドの CPU - 例：PCIe 4.0 NVMe SSD による転送速度 7000MB/s のストレージ § クラウド VM の相対的なコストパフォーマンスの低下 - 仮想化された CPU とストレージは柔軟性と引き換えにパフォーマンスを損なっている - 特にゲーム開発分野の CI/CD ではクラウドの優位性がゆらぐ事態 - 例：オンプレミスPCでは20分でビルドできるのにクラウドVMだと1時間かかる - 例：クラウドVMのビルドを数ヶ⽉運⽤すると新しいPCが1台買える - CI/CD インフラのクラウド移⾏においては、単純なリフトアンドシフト⼿法ではメリットが 薄れてきており、クラウドネイティブなアプローチが今後重要になる

クラウドネイティブとは？ § 本講演の⽂脈では… オンプレミスで稼働していた既存のインフラをクラウドに移植するのではなく、 クラウドに最適化された機能・サービスを活⽤して新しいインフラを設計・構築すること § Cloud Native Computing Foundation (CNCF) による定義とはだいぶ異なる クラウドネイティブ技術は、パブリッククラウド、プライベートクラウド、ハイブリッドクラウドなどの 近代的でダイナミックな環境において、スケーラブルなアプリケーションを構築および実⾏するための能 ⼒を組織にもたらします。 このアプローチの代表例に、コンテナ、サービスメッシュ、マイクロサービス、 イミュータブルインフラストラクチャ、および宣⾔型APIがあります。 これらの⼿法により、回復性、管理⼒、および可観測性のある疎結合システムが実現します。 これらを堅 牢な⾃動化と組み合わせることで、エンジニアはインパクトのある変更を最⼩限の労⼒で頻繁かつ予測ど おりに⾏うことができます。 Cloud Native Computing Foundationは、オープンソースでベンダー中⽴プロジェクトのエコシステムを育成・ 維持して、このパラダイムの採⽤を促進したいと考えてます。 私たちは最先端のパターンを⺠主化し、こ れらのイノベーションを誰もが利⽤できるようにします。 引⽤： https://github.com/cncf/toc/blob/main/DEFINITION.md

クラウドネイティブなCI/CDインフラ (Kubernetes) § 「クラウドネイティブな CI/CDインフラ」で連想さ れるかもしれないもの § ベンダ中⽴技術で構成 § ジョブのパイプラインを 複数のコンテナで構成し Kubernetes でオーケスト レーションする § インフラおよびパイプラ イン構築の難易度は⾼く、 専任のエンジニアが必要 § ゲーム開発が必要とする CI/CDインフラには必ずし もフィットしない (後述) Azure VNet (IaaS) Azure Kubernetes Service (PaaS) DAG ( ) PC Ingress Controller Tekton Pipelines Azure Storage PC Azure AD Azure DNS PC SSL Azure Container Registry GitHub (SaaS)

クラウドネイティブなCI/CDインフラ (GitHub) § SaaS であるため、インフ ラの知識がないゲーム開 発者でも容易に構築可能 § GitHub によるマネージド なVMエージェントが⽤ 意されているが、ゲーム 開発のCI/CDには性能が⾜ りない § セルフホストVMエー ジェントでは任意の⾼ス ペックVMが利⽤可能だ が、オートスケールが難 しい (後述) Azure VNet (IaaS) GitHub (SaaS) ( ) PC GitHub GitHub Actions Azure Storage PC Azure AD PC VM VM Workflow YAML

クラウドネイティブなCI/CDインフラ (Azure DevOps) § SaaS である Azure DevOps Services の活⽤ § AzureおよびAzure ADとの 親和性が⾮常に⾼く、 BNSのようなAzureを使っ ている組織なら第⼀にお すすめ § Azure Pipelines はセルフ ホストVMエージェント のオートスケールに対応 している (後述) Azure VNet (IaaS) VM Azure DevOps (SaaS) VM ( ) PC Azure DevOps Azure Pipelines Azure Storage PC Azure AD PC (VMSS) Pipeline YAML

バンダイナムコスタジオの新しい CI/CD インフラ § 新しい CI/CD インフラの要件 - すべてがオンプレミスではなくクラウドサービスで稼働する - コントローラの要件 - 普通のゲーム開発者が容易に構築・運⽤可能なマネージドサービス (SaaS) - エージェントの要件 - LinuxだけでなくWindowsやmacOSもサポート - コンテナだけでなく仮想マシンもサポート - マネージドエージェントだけでなくセルフホストエージェントもサポート - セルフホストエージェントのオートスケールをサポート - ワークスペースの永続化をサポート

セルフホスト Jenkins CI からの卒業 § Jenkins CI の問題点 - 定期的なアップデート、プラグイン互換性チェックなどのメンテナンスコスト - Jenkinsfile および Groovy スクリプト習得のコスト (個⼈差あり) § ゼロトラストセキュリティ時代のセルフホストな web アプリ全般の問題点 - ⼀般的なゲーム開発者が⽚⼿間に構築して運⽤を続けることは難しい - https://192.168.0.1:8080 のような URL で社内公開していた時代とは異なる - DNS、SSL証明書、 認証・認可設定などでインフラスペシャリストの助けが必要 - ⾃⼒で気軽に構築できなければ、クラウド移⾏どころか CI/CD ⾃体が敬遠されがちに… § マネージドサービス (SaaS) を中⼼とした CI/CD インフラを推進

エージェント：OS § 現時点では Windows のエージェントが必要 - Unity → Windows/macOS でのビルドが前提、Linux でのビルドはベータ段階 - Unreal → Windows でのビルドが前提 § macOS の問題 - iOS アプリ (iPhone, iPad 向け) をビルドするには macOS で動く Xcode が必要 - リーズナブルな価格で使える macOS VM のクラウドサービスが存在しない - AWS EC2 の mac1.metal は1⽇単位でしか使えず価格が⾼くなりすぎる - 現時点では macOS のビルドにはマネージドな macOS エージェントか、 部分的にクラウド化をあきらめてセルフホストな macOS エージェントを使⽤している

エージェント：仮想マシン vs. コンテナ § 現時点では仮想マシン (IaaS) で動くエージェントが必要 - コンテナでの動作をサポートしていない開発ツールが多い - Linux 以外の OS のコンテナ環境がサイズや性能の⾯であまり便利でない - ただし、状況は変わってきている (後述) - Unity → フローティングライセンスのサブスクリプションが登場 - Unreal → unrealcontainers.com のコンテナ開発が UE 4.27 でサポート対象になった § コンテナ化できれば CI/CD プラットフォームの幅が広がる - ゲーム開発ツール各社はコンテナ対応も頑張ってほしい

エージェント：マネージド vs. セルフホスト § マネージドエージェント - SaaS が提供してくれるエージェントマシンを使⽤する - 良い点 → マシンの管理が不要・すぐに起動する・安価 - 悪い点 → マシンの性能が固定されている・必要なソフトがプリインストールできない § セルフホストエージェント - ⾃分で⽤意したマシン上でエージェントを⾛らせて SaaS に接続する - 良い点 → ⾼性能なマシンが使える・GPUやFPGAも使える・必要なソフトがプリインストー ルできる・ワークスペース永続化が可能・既存インフラリソースと連携可能 - 悪い点 → マシン管理が必要・適切なオートスケールができないと⾼額な稼働コスト・すぐ に起動できない場合がある

エージェント：マネージド vs. セルフホスト § CI/CD パフォーマンス向上のためにはセルフホストエージェントの活⽤が必須 項⽬ マネージド セルフホスト マシンの所有と管理 サービス ユーザー マシンのスペック 限られたスペックから選択 任意のスペックが利⽤可能 マシンの OS 限られたOS・バージョンから選択 任意のOS・バージョンが利⽤可能 マシンのカスタマイズ 不可 必要なツールは毎回インストール 可能 必要なツールはプリインストール マシンのオートスケール ⾃動 ⼀部のサービスでのみ可能 ワークスペース永続化 不可 キャッシュが代替⼿段 可能 構成に依存する コスト 安価 マシン稼働コスト + 管理コスト

エージェント：オートスケール § CI/CD インフラのパフォーマンス向上のために重要な要件 - ビルドジョブの実⾏待ちキューを⾒て VM エージェントの作成・停⽌を⾃動的に⾏う - ビルドジョブごとに完全に新しいVMを⽤意することでビルドの再現性確保 - ビルドジョブの並列化が容易になる (例：各プラットフォーム・構成ごとのビルド) § 課題：セルフホストエージェントのオートスケール - これに完全に対応している SaaS はほとんどない - SaaS の API を活⽤してオートスケールを実現するソフトウェアはいくつか存在する

セルフホストエージェントのオートスケールの事例 Solution Agent Platform Agent Type Supported OS Managed or self-hosted? Azure Pipelines (Azure DevOps Services) Azure VM (VMSS) VM Linux, Windows Fully managed (dev.azure.com) Jenkins CI + ec2-fleet-plugin AWS EC2 (Spot Fleet, ASG) VM Linux, Windows Fully self-hosted GitHub Actions + actions-runner-controller Kubernetes Container Linux Managed (GitHub.com) + self-hosted (K8s controller) GitHub Actions + myshoes AWS EC2, LXD, OpenStack VM Linux Managed (GitHub.com) + self-hosted (daemon) GitLab CI + GitLab Runner Kubernetes, AWS EC2, Fargate Container Linux Managed (GitLab.com) + self-hosted (runner) Drone CI + Drone Autoscaler AWS, GCP, DigitalOcean,etc. VM Linux, Windows Managed (cloud.drone.io) + self-hosted (autoscaler) Buildkite + Elastic CI Stack for AWS AWS EC2 (ASG) VM Linux, Windows Fully Managed (buildkite.com) ? GitHub Actions 関連については https://jonico.github.io/awesome-runners/ のリストも参照

セルフホストエージェントのオートスケールの現状 § 現時点では Azure Pipelines が最も我々のニーズに合致しているといえる - マネージドサービス (SaaS) だけで完結、セルフホストなサーバは⼀切不要 - Linux および Windows に完全に対応 - Azure をインフラとして使⽤ § 個⼈的な願望 - GitHub Actions ⾃⾝に Azure Pipelines と同じようなフルマネージドなセルフホストエージェン トのオートスケール機能をマルチクラウド対応で提供してほしい

エージェント：ワークスペースの永続化 § 増⼤するコード・アセットとの闘い - 近年の⼤規模ゲーム開発では100GBを越えるコード・アセットを扱うことは珍しくない - リポジトリからのチェックアウトだけで数10分〜数時間かかることもある - ビルド時間短縮のため、ワークスペースの内容をビルド後も保持しておきたい - Jenkins CI のオートスケールしないセルフホストエージェントではこれがデフォルトだった - マネージドエージェント → キャッシュのような代替⼿段しかない - セルフホストエージェント → 既存インフラの活⽤で対処できる可能性がある § クラウドリソース活⽤の試み - クラウド上のデータディスク → Azure 管理ディスク、AWS EBS、GCP PD - データディスクは VM エージェントのライフサイクルと関係なく永続化できる - VM エージェントはジョブ実⾏の都度、特定のデータディスクに接続・マウントする

Azure ディスク・スナップショットの活⽤ § Azure VM ⽤ディスク・スナップショットリソースの特徴 - ディスク ←→ スナップショットのクローンが異常に速い (多くの場合数秒) - クローンしたディスクは即座に VM から接続・マウントして利⽤できる (30秒以内) - スナップショットの価格はディスクよりも⼤幅に安い (使⽤データ量だけ5.6円/GB/⽉) § データディスク・スナップショット操作ライブラリを開発、検証を実施 100GB/1TB VM 10 100GB/1TB 17409 / P30 100GB 560 / 100GB/1TB 17409 / P30 100GB/1TB 100GB/1TB 30 VM 30 VM

Azure ディスク・スナップショットの応⽤ § 例：膨⼤な量 (100GB〜) のコード・アセットを持つリポジトリをチェックアウトし たディスクを効率的にクローンして複数の構成向けの並列ビルドを⾏う DataSnapshot-1001 DataDisk-1001 ( ) DataDisk-1002 DataDisk-1003 DataDisk-1004 1002 (PC) 1003 (PS) 1004 (Xbox) 1001 765GB DataDisk-1011 DataSnapshot-1011 2 1011 DataDisk-1012 1012 (PC)

現実：そんなうまい話はやはりないらしい § クローン直後のディスク読み込みレイテンシ劣化がドキュメントで⽰唆されている - https://docs.microsoft.com/ja-jp/azure/virtual-machines/premium-storage-performance - 実際に試すと確かにかなり遅くなったが、リポジトリの負荷を分散する効果はあるため、 まったく役に⽴たないわけではない - AWS の EBS Snapshot にも同じ問題があり Fast Snapshot Restore のような機能を提供している

このセクションのまとめ § バンダイナムコスタジオにおけるゲーム開発の CI/CD インフラの追求 - セルフホスト Jenkins CI からの卒業と CI/CD のマネージドサービス (SaaS) の活⽤ - セルフホストエージェントの活⽤とオートスケールの実現 - ワークスペースの永続化とクラウドのディスク・スナップショットリソースの活⽤ § オンプレミス・ベアメタルに負けないクラウドネイティブな CI/CD インフラを⽬指 して様々な検証を⾏っています § 次のセクションで実際の新しい CI/CD インフラ構築の取り組みについて紹介します

Azure DevOps で構築する クラウドネイティブ CI/CD インフラ

クラウドネイティブ CI/CD インフラの技術研究 § 技術研究の概要 - 2021/04 より Azure DevOps ベースのクラウドネイティブな CI/CD インフラを研究し、 様々な製品向けアプリのビルドに適⽤できるテンプレートを作成している - メインターゲットは Unity および Unreal のゲームエンジンを使⽤するアプリ - バンダイナムコスタジオ社内の複数のプロジェクトで評価・導⼊検討中 § CI/CD インフラの特徴 - コントローラ → Azure Pipelines (Azure DevOps Services) - エージェント → オートスケールするセルフホスト Azure VM (Windows/Linux) - エージェント VM イメージのカスタマイズ⼿順の確⽴と⽀援ツールの開発 - エージェント VM からディスク・スナップショットが操作できるライブラリの開発

CI/CD インフラの構成要素 サービス 種類 ⽤途 Azure Active Directory IDaaS ユーザー・組織の認証基盤 すべてのサービスのユーザー認証・認可を司る Azure DevOps Services SaaS Azure Repos – Git リポジトリ Azure Pipelines – CI/CD コントローラ Azure IaaS PaaS 仮想マシン、仮想マシンスケールセット (VMSS) ディスク、スナップショット VMイメージ、共有イメージギャラリー Azure Image Builder Visual Studio App Center SaaS アーティファクト配布先 (モバイルアプリ専⽤) Microsoft 365 SaaS アーティファクト配布先 (SharePoint Online)

Azure DevOps Services § Microsoft によるプロジェクトホスティングサービス § 同じ Microsoft の GitHub と重複するサービスが多い - 相互連携により必要な機能のみ選択して利⽤可能 - 例: GitHub Repository を Azure Pipelines でビルド ただし GitHub の LFS 帯域制限には注意 § Azure DevOps を選ぶ理由 - Azure および Azure Active Directory との緊密な統合 - Microsoft 365 や Visual Studio Subscription を導⼊している 組織・チームにおすすめ Azure DevOps Boards Pipelines Repos Artifacts Test Plans GitHub Actions Repository Packages Issues

Azure Pipelines § Azure DevOps の CI/CD コントローラのサービス § Windows/macOS/Linux ホストでの実⾏に対応 § リポジトリ内の YAML ファイルでジョブを定義 - ジョブの定義は複雑に⾒えるが、基本構成を押さえれ ば⽐較的簡単に書くことができる - Visual Studio Code 拡張などの⼊⼒⽀援もある - template 構⽂により簡単に複数のファイルに分割可能 でモジュール化・再利⽤しやすい - TypeScript により独⾃の task が定義可能 GitHub Actions に似たエコシステムがある - Jenkinsfile を書くよりもメンテナンスはしやすい (個⼈の感想) trigger: none parameters: - name: config type: string default: Development values: [Development, Release] variables: - template: variables.yml jobs: - job: iOSUnityBuild pool: name: UnityWindowsPool1 steps: - template: steps-disk.yml - template: steps-unity.yml parameters: target: iOS config: ${{parameters.config}} publish: xcode - job: iOSXcodeBuild dependsOn: iOSUnityBuild pool: vmImage: macOS-latest steps: - template: steps-xcode.yml parameters: download: current publish: ios

Azure Pipelines エージェント § Azure Pipelines には 2 種類のビルドエージェントが存在する - Microsoft hosted エージェント (マネージド) - Microsoft が管理する Windows / macOS / Linux VM による実⾏ - 固定スペック: Windows / Linux では Azure VM (CPU:2cores RAM:7GB) - VM の管理が不要で⼿軽に使⽤可能 - 1並列度の価格 4,480 円/⽉ (145円/⽇) - Self hosted エージェント (セルフホスト) - ユーザーが管理する Azure VM やオンプレミスマシンでの実⾏ - 強⼒なスペックのCPU・GPU・メモリを搭載したマシンでビルド時間短縮が可能 - 1並列度の価格 1,680円/⽉ (54円/⽇)

VMSS エージェントプールのオートスケール § セルフホスト VM エージェントの課題 - 良い点 → 強⼒な VM や永続ストレージなどを駆使してビルド時間短縮ができる - 悪い点 → VM の管理が必要、強⼒な VM を常時稼働させると莫⼤なコストが発⽣ § Azure 仮想マシンスケールセット (VMSS) エージェントプール - 2020 年の夏に Azure Pipelines に追加された新しい機能 - Azure Pipelines がセルフホスト VM エージェントの管理をやってくれる - 待機ジョブの数にあわせ VM の稼働数を⾃動的に増減してくれる (0 まで減らすことも可能) - VM へのエージェントインストール、プールへの VM 登録、後始末も完全⾃動 - 他のマネージド CI サービスにはない Azure Pipelines + Azure ならではの機能 - Azure Pipelines が Azure のコントロールプレーンを直接制御 → 常時稼働サーバが不要 - Scale to/from zero が⼿軽に実現でき VM の稼働・管理コストの削減に⼤きな効果

Azure VM イメージ § VM イメージ ＝ VM 作成の元となるディスクイメージのリソース § VM イメージは CI/CD パイプラインの重要なカスタマイズ要素 - 必要な開発ツールをインストールした VM イメージでビルド時間が⼤幅短縮できる - VMSS エージェントプールでも新規起動 VM が使⽤するイメージが指定できる

Azure VM イメージの管理とカスタマイズのサポート § 共有イメージギャラリー (SIG) - VM イメージを登録できる Azure リソース - バージョン管理や地域間の⾃動レプリケーションの機能を持つ § Azure Image Builder (AIB) - HashiCorp Packer ベースのマネージドな Azure VM イメージカスタマイズサービス - 便利だが、最初の事前設定作業が⾮常に煩雑なのが⽋点 § Customazed CLI https://github.com/yaegashi/customazed - AIB 利⽤を⽀援するための拙作の CLI ツール (Windows, Linux, macOS に対応) - JSONC 設定ファイルから AIB セットアップと SIG などの関連リソース作成を⾃動実⾏できる - Unity開発・Unreal開発など各⽤途向け設定ファイルを⽤意

Customazed CLI 利⽤のスクリーンショット § macOS の Visual Studio Code で Windows VM イメージのカスタマイズ・ビルド作業

Azure インフラ操作ライブラリの整備 § AzBuilderUtility モジュール - VM エージェントから Azure インフラを操作するための PowerShell モジュール - Azure ディスク・スナップショット操作のコマンドレットも含まれる - 現時点では Windows 環境でしか動かないので、将来的には Go ⾔語の CLI で実装しなして Linux/Windows/macOS のマルチプラットフォームツールにできないかと思っている

AzBuilderUtility によるディスク管理の⼿法 § ディスクおよびスナップショットを 「Project: パイプライン名」のタグで分類 - リソース名は機械的に「DataDisk-ビルド番号」「 DataSnapshot-ビルド番号」の形式とする - リソース使⽤時はタグを使って検索し、最新のものを利⽤する - ビルドの完了後はディスクからタグ付きのスナップショット作成してディスクは削除

AzBuilderUtility モジュールの利⽤ ① § ジョブ開始時：DataDisk をタグ付きの過去の DataSnapshot から作成して接続 - ⾃分⾃⾝ (VM) の情報はメタデータサービス http://169.254.169.254/metadata/instance から取得可能 $BuildId8 = '00001234' $DiskName, $SnapshotName = "DataDisk-$BuildId8", "DataSnapshot-$BuildId8" $SnapshotTag = @{Project='UE4Engine'} $ResourceGroup = 'D1P_UE4Engine1' # AzBuilderUtility モジュール読み込み Import-Module $PSScriptRoot¥AzBuilderUtility -Verbose:$false # 過去の DataSnapshot リソースを取得 (タグ Project:UE4Engine を持つ最新のリソースを選択) $snapshot = Get-AzBuilderSnapshot -ResourceGroup $ResourceGroup -Tag $SnapshotTag | ` Sort-Object -Property Name | ` Select-Object -Last 1 # 現在の DataDisk を過去のスナップショットから作成 $null = Restore-AzBuilderDiskSnapshot -ResourceGroup $ResourceGroup -Name $DiskName -Snapshot $snapshot # 現在の DataDisk を自分自身 (VM) に接続 $null = Connect-AzBuilderVMDisk -ResourceGroup $ResourceGroup -Name $DiskName # 現在の DataDisk を Z: にマウント $null = Mount-AzBuilderVMDisk -DriveLetter Z

AzBuilderUtility モジュールの利⽤ ② § ジョブ終了時：DataDisk を接続解除してタグ付きの新しい DataSnapshot を作成 - DataSnapshot 作成後の DataDisk は即座に削除してコストを削減 $BuildId8 = '00001234' $DiskName, $SnapshotName = "DataDisk-$BuildId8", "DataSnapshot-$BuildId8" $SnapshotTag = @{Project='UE4Engine'} $ResourceGroup = 'D1P_UE4Engine1' # AzBuilderUtility モジュール読み込み Import-Module $PSScriptRoot¥AzBuilderUtility -Verbose:$false # すべての DataDisk をディスマウント $null = Dismount-AzBuilderVMDisk # すべての DataDisk を自分自身 (VM) から接続解除 $null = Disconnect-AzBuilderVMAllDisks # 現在の DataDisk リソースを取得 $disk = Get-AzBuilderDisk -ResourceGroup $ResourceGroup -Name $DiskName # 新しい DataSnapshot を現在の DataDisk から作成 (タグ Project:UE4Engine を設定) $null = Save-AzBuilderDiskSnapshot -ResourceGroup $ResourceGroup -Name $SnapshotName -Tag $SnapshotTag -Disk $disk # DataDisk を削除 $null = Remove-AzDisk -Force -Confirm:$false -ResourceGroupName $disk.ResourceGroupName -DiskName $disk.Name

このセクションのまとめ § バンダイナムコスタジオで実施中の技術研究の紹介 - Azure DevOps と Azure をベースにしたクラウドネイティブ CI/CD インフラを開発中 - Unity および Unreal のゲームエンジンを使⽤するアプリがターゲット § 新しいクラウドネイティブ CI/CD インフラの解説 - Azure Pipelines と VMSS エージェントプールのオートスケール - Azure Image Builder & Customazed による VM イメージカスタマイズ - AzBuilderUtility PowerShell モジュール

Unity アプリの クラウドネイティブ CI/CD インフラの構築

Unity アプリ CI/CD インフラ これまでの取り組み § 要点 - Azure Pipelines によるクラウドネイティブ CI/CD インフラを実現 - macOS 問題を Azure Pipelines の MS hosted agent により解決 - Unity Build Server ライセンス (クラウドビルド専⽤ライセンス) の導⼊ § タイムライン - 2020年10⽉ 着⼿ - 2020年12⽉ Unity Build Server ライセンス購⼊ - 2021年1⽉ クラウドネイティブ CI/CD インフラ POC の完成 - 2021年4⽉〜 技術研究にて製品プロジェクトでの導⼊検証 § 過去の講演 - JTF2021W: Azure DevOps で実現する Unity アプリのハイパフォーマンス CI/CD

社屋内で稼働する Unity アプリのビルドサーバ Mac mini 全部盛り 302,800円(税別)

従来の Unity アプリ CI/CD パイプライン

クラウドシフトした Unity アプリ CI/CD パイプライン

Unity アプリ CI/CD インフラ 新しい取り組み (2021/04〜) § Unity Build Server ライセンスの全社的な導⼊ - ビルドマシンのノードロックライセンス管理から開放された § セルフホストエージェントと Azure クラウドインフラとのさらなる連携推進 - Azure データディスクへの Unity Editor のインストール・永続化 - Unity Accelerator (アセットキャッシュサーバ) への接続 § ポータブルなビルドスクリプティング環境の実現 - Unity Editor の C# 実⾏環境のみに依存するビルドスクリプトを整備する - これまで蓄積された⼤量の Jenkinsfile・Groovy スクリプトを置き換える - macOS/Windows/Linux のどのプラットフォームの Unity Editor でも同じようにビルドできるこ とを⽬指す

Unity Build Server ライセンス利⽤状況の可視化 § ライセンスサーバの REST API に対して Prometheus exporter を作り、 Grafana でメトリクスをダッシュボードに表⽰している

Unreal Engine (UE4) アプリの クラウドネイティブ CI/CD インフラの構築

UE4 クラウドネイティブ CI/CD インフラ検証ステータス § 2021/04 からの技術研究で次の検証が進⾏中 - UE4 ビルド⽤ Azure VM イメージ構築 - Azure DevOps ベースのクラウドネイティブな CI/CD インフラの適⽤ - UE4 Installed Engine Build - UE4 サンプルプロジェクトビルド § 今後より規模の⼤きな UE4 プロジェクトでの検証を⾏う予定

UE4 CI/CD on Azure Pipelines 検証ステータス § Azure Pipelines によるさまざまな UE4 エンジ ンおよびサンプルプロジェクトの検証 - ⼀般に UE4 プロジェクトはサイズが⼤きいの で、Azure ディスク・スナップショットの活 ⽤を重点的に検証している (Build/Source と いったパイプラインがあるのはそのため) - エンジンのビルド (Installed Build) UE4 のソースコードをビルドして、開発チー ム内に配布するためのエンジン・エディター のパッケージを作成すること

UE4 Engine Installed Build の⽐較 § 左から - Azure Standard_D32as_v4 - Azure Standard_D96as_v4 - ⾃宅 Ryzen 7 5700G (8C16T)

UE4 Engine Installed Build の⽐較 項⽬ Standard_D32as_v4 Standard_D96as_v4 Ryzen 7 5700G vCPU 32 96 16 全体所要時間 1h21m25s 1h2m38s 2h24m5s Engine Installed Build 56m21s 39m18s 1h15m11s Publish Artifacts 43GB (Azure Pipelines 成果物アップロード) 5m37s 4m53s 15m20s Engine Package (7z.exe によるエンジン配布 ZIP 作成) 7m18s 6m22s 7m46s AzureFileCopy 15GB (Azure Blob Storage アップロード) 1m40s 33s 28m33s コスト 東⽇本 (円) 301.35 638.60 NA

UE4 の分散ビルドに関して § UE4 は IncrediBuild や FASTBuild などの分散ビルドシステムをサポートしている § CEDEC 2021 の参考になる講演 1年半運⽤してわかった！BLUE PROTOCOLにおけるビルドパイプラインのクラウド化の壁 - UE4 プロジェクトにおいては、IncrediBuild の分散ビルドと⽐較して、分散ではない AWS の 多数コア VM (96 コア) のビルドも有⽤であったことが報告されている - Azure にも AWS と同様な多数コア VM ラインアップがあり Azure Pipelines による単純な CI/CD パイプラインでも同様な結果が得られると予想している

Unreal Engine 4.27 新機能 § 2021/08/20(⾦) Unreal Engine 4.27 リリース - コンテナ対応が追加 (ベータ版) - https://unrealcontainers.com プロジェクトが公式サポートの扱いになった - Linux および Windows のコンテナイメージが公開 - 開発イメージ：UE4 プロジェクトをビルドするためのコンテナ - ランタイムイメージ： Dedicated servers のためのベースコンテナ § 本⽇のセッションには間に合わなかったが、今後はLinux環境やコンテナ環境でのビ ルド・デプロイについても積極的に検証していく

まとめ

本⽇の講演のまとめ § バンダイナムコスタジオ (BNS) における、COVID-19 をきっかけにゲーム開発環境の CI/CD インフラをクラウドネイティブ化を推進していく直近 1 年程度の取り組みにつ いて紹介しました - インフラエンジニアの数が少ない BNS に適したクラウド上の CI/CD インフラの追求 - Azure DevOps および Azure クラウドを活⽤した CI/CD インフラの実装 - Unity および Unreal ゲームエンジンを利⽤するアプリの CI/CD インフラの構築 § 今回紹介したライブラリやソフトウェアの公開も含め、今後も継続してバンダイナ ムコスタジオでの開発インフラ改善の取り組みを紹介していきたいと思いますので、 よろしくお願いします

おわり