GitHub Actions Self-hosted runner を 3年間運用したこれまでとこれから 〜 分散するワークフローと管理の課題

GitHub Actions self-hosted runner を 3年間運用したこれまでとこれから 分散するワークフローと管理の課題 2025/10/10 Game Developers Meeting Vol.64 © DeNA Co., Ltd. 1

登壇者プロフィール 白柳 隆澄 株式会社ディー・エヌ・エー ゲームサービス事業本部開発運営統括部第一技術部 テクノロジー推進第三グループ グループリーダー 2007年からゲーム業界でエンジニア 2017年DeNA入社 2019年頃からSREを自称 「ゲーム開発者のための SRE」 として開発をいかに楽にしていくか 毎日考えています © DeNA Co., Ltd. 2

目次 1 GitHub Actions の構成について 2 分散するワークフローと管理の課題 3 現在の取り組みとこれから 4 まとめ © DeNA Co., Ltd. 3

GitHub Actions の構成について © DeNA Co., Ltd. 4

GitHub Actions の構成について ● GitHub Enterprise Server ● 全社共通とプロジェクト固有の2種類のランナーを運用 ○ ランナーバージョンは GitHub.com の最新バージョンに追従 ○ node24 などランナーバージョン依存の機能は使える ○ Artifacts v4 や Enterprise バージョンに依存する機能は使えない ■ upload-artifact@v4+ is not currently supported on GitHub Enterprise Server (GHES) yet. If you are on GHES, you must use v3. ● © DeNA Co., Ltd. v3-node 系を使う必要がある 5

• https://github.com/actions/upload-artifact?tab=readme-ov-file#v4---whats-new

2種類の Self-hosted runner © DeNA Co., Ltd. 6

2種類の Self-hosted runner ● 全社ランナー：Enterprise Runner：SWET 運用 ○ Linux runner (AWS) ○ macOS runner (AWS ※β提供) ● プロジェクトランナー：Organization Runner：SRE 運用 ○ Linux runner (GCE) ○ macOS runner (MacStadium / オフィス物理マシン) ○ Windows runner (オフィス物理マシン） © DeNA Co., Ltd. 7

全社ランナーとプロジェクトランナーの比較 全社ランナー プロジェクトランナー 提供方式 コンテナ /VM 常駐プロセス 特徴 クリーンスタート GitHub hosted runner と 若干異なるが遜色ない環境 前ジョブの状態が継続 ローカルキャッシュ可能 構成が自由 スケールアウト オートスケール プロセス増やす or マシンを購入 OS Linux/macOS Linux/macOS/Windows Unity なし プリインストール済み プリインストールなど マシン環境 ベースイメージ Ansible で構築 （Jenkins の資産流用） © DeNA Co., Ltd. 8

ランナーの使い分け ● 全社ランナー ○ オートスケール対応しているので基本的にはこちらを利用 ● プロジェクトランナー ○ 全社ランナーではできないジョブ（macOS、Unity 使うなど） ○ クライアント・アセットビルドなど速度やキャッシュがいるもの ○ 長時間実行する ○ 重要なワークフローの冗長性 © DeNA Co., Ltd. 9

常駐型ランナー © DeNA Co., Ltd. 10

常駐型ランナーの理由 ● Unity をジョブ中にセットアップするのは大変 ○ プロジェクト都合に合わせてプリインストール ○ 全社ランナーでも Unity をプリインストールは技術的には可能 ■ どのバージョンをプリインストールしておくかは課題 ● キャッシュサイズの問題 ○ Library ディレクトリをキャッシュしたいが GitHub Actions の キャッシュではサイズが大きすぎて無理だった © DeNA Co., Ltd. 11

常駐型の理由 ● Apple Silicon の恩恵 ○ Apple Silicon が非常に速くビルドは macOS がメイン ○ MacStadium の Bare Metal Mac とオフィス設置マシンを使用 © DeNA Co., Ltd. 12

常駐型ランナーの禁止事項 ● Unity CI/CD 完全に理解した 勉強会 GitHub Actions x Unity プロジェクトの裏側 | ドクセル © DeNA Co., Ltd. 13

• https://unity-fully-understood.connpass.com/event/324346/
• https://www.docswell.com/s/DeNA_Tech/ZYDNP3-2024-08-05-134204

常駐型ランナーの禁止事項 ● マシンおよびユーザーレベルの設定書き換え禁止 ○ よくある例： git config --global、brew install ○ GitHub hosted runner だと気にせずやってることが多いので注意 ● 他のランナープロセスに影響がでる操作に注意 ○ 1マシンに複数ランナープロセスがいる ○ 部分的にプロセスごとに空間を分けているが完璧ではない © DeNA Co., Ltd. 14

常駐型ランナーの禁止事項 ● シークレットファイルを残したままにすること ○ クリーンスタートではないので次のジョブで見えちゃう ○ ${{ runner.temp }} を使う、post 処理で必ず消すなどが必要 ● 不要なデータを大量に残す ○ クリーンされないので蓄積する、ディスク容量は有限 ○ ${{ runner.temp }} を使う、post 処理で必ず消すなどが必要 ○ docker run –-rm © DeNA Co., Ltd. 15

常駐型ランナーの禁止事項 ● ワークスペースを破壊する操作 ○ リポジトリで１つのパスを共有するので、別のジョブが失敗する ○ コンテナ内のジョブ実行 ■ ワークスペースの permission 問題を踏む ○ sparse-checkout © DeNA Co., Ltd. ■ sparse-checkout 済みのワークスペースをなしの状態に戻せない ■ パスを変えている場合は OK 16

• https://docs.github.com/ja/actions/how-tos/write-workflows/choose-where-workflows-run/run-jobs-in-a-container

分散するワークフローと管理の課題 © DeNA Co., Ltd. 17

3年間の運用で見えてきた課題 ● Jenkins は中央集権(※)、GitHub Actions は分散 ○ Git が分散型であり、ワークフローも分散して存在する ● ワークフロー開発の敷居が下がった ○ YAML 書けばすぐ動く、流行っていて情報も多い ○ 必要なツールのセットアップ、ロジックの大部分がアクションの 呼び出しだけでできる ※ Git で as Code 管理しているが、Jenkins ジョブは Controller 上に1つ © DeNA Co., Ltd. 18

分散するワークフローとアクション ● ワークフローが量産、様々なリポジトリで開発 ● 依存する多数のアクション ○ Jenkins はプラグインを運用者が管理してたが、こちらも分散 ○ 例 © DeNA Co., Ltd. ■ actions/*** ■ GitHub.com で公開されている 3rd party アクション ■ DeNA GitHub internal アクション ■ プロジェクト固有、リポジトリ下のローカルアクション 19

GitHub hosted runner のようには動かない現実 ● アクションが対応してない ○ GHES 非対応、クリーンスタートしか考慮されてない ● プリインストールが異なる ● ランナーによってできないこと、やってはいけないことがある ○ 常駐型ランナーは前述のとおり ○ 全社ランナーでも docker の特権モード使えないなど違いがある © DeNA Co., Ltd. 20

運用初期は運用メンバーがレビュー ● CODEOWNERS を全リポジトリに配布して .github/** のオーナーに設定 ● 誰かがワークフローを作ろうとしたら自動でレビュー依頼 ● 都度、レビューをして対応 © DeNA Co., Ltd. 21

GitHub Actions が浸透した結果 ● 自動化ハイ状態 ○ 様々な業務が自動化 ● 2,000 以上のワークフローが存在 ○ トピックブランチも含めると・・・？？？ ● ジョブの数、実行回数ともに Jenkins と比較して 10 倍以上に © DeNA Co., Ltd. 22

レビューもう無理ぽ © DeNA Co., Ltd. 23

管理の課題 ● 一旦現状を整理してみる © DeNA Co., Ltd. 24

管理の課題 ● Write 権限があれば誰でも実行可能 ● 車輪の再発明 ● メンテナンス ● ワークフローレビュー ● シークレット © DeNA Co., Ltd. 25

Write 権限があれば誰でも実行可能 ● 悪いことだけではない ○ むしろこれのおかげで敷居は下がってるし、 自動化もされ効率化に繋がっている ● 場合によっては必要以上の権限を持ててしまうので注意が必要 ● PR を出さなくてもワークフロー実行できちゃうのが困ってる © DeNA Co., Ltd. 26

車輪の再発明 ● 各リポジトリでワークフロー開発できるため、 チームを超えた共有が現状あまりできていない ○ チームごとに見えるリポジトリ、見えないリポジトリがある ○ Jenkins のころはチームがやりたいことをジョブ開発者に伝えて 開発していたので、自然と集約されていた © DeNA Co., Ltd. 27

メンテナンス ● ワークフローの共通化や更新が課題 ○ 環境の変化への追従が必要 ■ GitHub Enterprise Server のバージョン、node バージョン、 新機能や手法、プロジェクトの変化などメンテナンスは必須 ○ 一度分散したワークフローを作り直すのが大変 ■ 今ならそうは書かないのに・・・ ● ランナーを安全に停止させるのが手間 © DeNA Co., Ltd. 28

ワークフローレビュー ● レビューが追いつかない ● 使い方周知や車輪の再発明を防ぐなど、知ってもらうのが目的 © DeNA Co., Ltd. 29

シークレット ● いつの間にか増えてるリポジトリシークレット ○ Organization のシークレットの編集権限がごく一部しかない ○ Repository の管理者であれば、シークレット登録できちゃう © DeNA Co., Ltd. 30

現在の取り組みとこれから © DeNA Co., Ltd. 31

前提 ● 試行錯誤中の状態です ● まだまだ全然解決してないです ● やってること、やろうとしていることが正解ではない ● 懇親会でいろいろ教えて下さいmm © DeNA Co., Ltd. 32

ワークフローリポジトリを分離 ● 管理者用ワークフローリポジトリの作成 ○ ワークフローの配布などを目的に各 org に１つはある ● 機能や目的に合わせてリポジトリを切り分け ○ ビルドワークフロー、 Organization 専用アクションなど ○ 機能単位で分けたほうが使いまわししやすくなる ■ 単品でも組み合わせでも使いやすいことを意識 ○ 権限管理もしやすい © DeNA Co., Ltd. 33

ワークフローの共通化や更新 ● reusable workflow やアクションによる共通化 ○ ただし、結局はリポジトリにワークフローファイルは必須 ● 各リポジトリへのファイル配布ワークフロー作成 ○ gh repo list ORG --no-archived --source --limit 1000 --json nameWithOwner --jq '.[].nameWithOwner' ○ 権限付与は Organization Role Assignment を使うと楽 ■ © DeNA Co., Ltd. Write 権限必要。プロジェクト事情で個別付与と使い分け 34

ワークフローの配布方式 ● 上書き更新 ○ 簡単 ○ リポジトリ側での調整などできない ■ Variables を使うなど、変更可能な箇所を工夫 ○ Lint やコンフリクトマーカーのチェックとか どのようなリポジトリでも使える共通のワークフローを配布 ○ 管理者が設定を強制する場合に便利 © DeNA Co., Ltd. 35

ワークフローの配布方式 ● マーカー方式 ○ マーカー区間のみ更新する方法 ■ マーカー区間外をリポジトリ側で管理できる ○ CODEOWNERS で利用 ○ 配布したい部分が限られている場合に有効 ○ ワークフロー配布では現状使用していない © DeNA Co., Ltd. 36

ワークフローの配布方式 ● パッチ方式 ○ 配布元ファイルの差分を配布する ○ 配布ワークフローリポジトリで PR がマージされたら、 PR に含まれる配布ファイルの差分を各リポジトリで apply する ○ 配布先リポジトリでの改変を許容する仕組み ○ コンフリクトしたら解消が必要 ○ 微妙だったかも・・・ © DeNA Co., Ltd. 37

ワークフローの配布方式 ● 修正スクリプト実行方式 ○ 対象リポジトリで修正スクリプトを実行して PR ■ やってることはマーカー方式と同じ ○ ツール例 ■ GitHub - lindell/multi-gitter: Update multiple repositories in with one command ○ 修正スクリプトの負担が大きく、多用は避けたい © DeNA Co., Ltd. 38

• https://github.com/lindell/multi-gitter

ワークフローの配布方式 ● require workflows 方式 ○ そもそも配布しない ○ 指定したリポジトリのワークフローを Require できる機能 ■ Organization Settings > Repository > Rulesets で設定 ■ 他のリポジトリにあるワークフローが PR 時に実行できる ■ paths / branches フィルタは無視される ■ すべてのアクティビティに対応してない ○ 用途が限定される ※ 対応イベントは pull_request, pull_request_target, merge_groupのみ © DeNA Co., Ltd. 39

• https://docs.github.com/ja/enterprise-cloud@latest/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets#supported-event-triggers

ワークフローの共通化や更新 ● メンテナンスのことを考えると 極力、配布するワークフローにはロジックを書かない ● reusable workflow にしておけば配布することなく修正ができる ● アクションも処理をローカル実行可能にしておくのがオススメ ○ 10/23 の CI/CD Test Night #8 で話します ○ https://testnight.connpass.com/event/369890/ © DeNA Co., Ltd. 40

• https://testnight.connpass.com/event/369890/

ランナーロックワークフロー ● GitHub Actions のランナーは Jenkins と違って オフラインしてジョブが終わるのを待つができない ● 無限ループする runner lock ワークフローを作成 ○ inputs でラベルと matrix 数を指定 ● プロジェクトランナーにマシン名のラベルを付与 ● マシン名ラベルとランナープロセス数を入力して runner lock ○ ジョブが running になれば安全にメンテナンス可能になる © DeNA Co., Ltd. 41

シークレットの検出と管理
● リポジトリのシークレット監視ワークフロー
○ シークレットの名前をキーとした json をダンプ
■

gh secret list -R REPO --json name
--jq 'reduce .[] as $item ({}; .[$item.name] = "")' > secrets.json

○ ダンプしたファイルに差分があれば PR を作成
○ 定期実行することでシークレット増減を監視

© DeNA Co., Ltd.

42

シークレットの検出と管理 ● 監視するだけではもったいないのでドキュメント機能もつけた ● JSON を YAML として保存 ○ 値にシークレットの説明を記述する ○ 複数行で説明が書きやすかったので YAML 採用 ○ 以下のコマンドで値を維持しつつ更新する ■ yq -o json repo.yml > repo.json jq -s '.[0] as $a | .[1] | with_entries(.value = ($a[.key] // ""))' repo.json secrets.json | yq -p json -o yaml > repo.yml © DeNA Co., Ltd. ○ 43

CI/CD 関連の Organization 権限を付与 ● Organization Role Assignment で細かく権限管理可能 ● CI/CD Admin Organization Role ○ 事前定義ロールとして追加された ○ カスタムロールとして定義可能 ○ Owner にならなくても Organization Secrets を管理できる ○ （Admin じゃなくて Read だけも欲しい） © DeNA Co., Ltd. 44

• https://github.blog/changelog/2024-09-25-introducing-ci-cd-admin-a-new-pre-defined-organization-role-for-github-actions/

これから ● 今までは 共通化だったり、システム化だったり、自動化だったり、 技術面でのアプローチが主体でした ● 今後は既存の課題にもある通り、 存在を知ってもらうこと、使い方を知ってもらうこと、 機能を知ってもらうこと、など知識の共有がもっと必要 © DeNA Co., Ltd. 45

認知負荷理論 © DeNA Co., Ltd. 46

認知負荷理論 ● 先月初めて知りました ○ Platform Engineering Kaigi 2025 | PEK2025 ○ 認知負荷理論で挑むPlatform Engineering：サイボウズにおける Kubernetesプラットフォームの拡大に向けて © DeNA Co., Ltd. 47

• https://www.cnia.io/pek2025/
• https://www.cnia.io/pek2025/sessions/8f0fddd3-2674-491b-9c57-c72b7d225d51/

認知負荷の種類 ● 課題外在的負荷 ○ 理解・目的に無関係な要因による余計な負荷 ○ できるだけ削減すべき ● 課題内在的負荷 ○ 課題そのものの複雑さから生じる負荷 ○ その対象を理解するためには避けられないが間接的に減らせる ● 学習関連負荷 ○ 知識を定着させ、理解を深めるための処理で生じる生産的な負荷 ○ 積極的に発生させるべき ※ 引用：認知負荷理論で挑むPlatform Engineering：サイボウズにおけるKubernetesプラットフォームの拡大に向けて | ドクセル © DeNA Co., Ltd. 48

• https://www.docswell.com/s/zoetro/ZG2VJ9-2025-09-18-142816#p8

認知負荷は適度に必要 ● なんとなく認知負荷はないほうが良いと思っていた ● 学習関連負荷はできるだけ増やしたほうが良い ○ キャパシティには注意が必要 © DeNA Co., Ltd. 49

マージリレーで考えてみる ● 並行開発のマージリレー完全自働化と達成までのみちのり | CEDEC2024 ● CEDiL で資料公開されているので詳細はそちらへ https://cedil.cesa.or.jp/cedil_sessions/view/2902 ● 汎用化して複数プロジェクトで稼働中 ● まさに今も自動でリレーをしてくれています © DeNA Co., Ltd. 50

• https://cedec.cesa.or.jp/2024/session/detail/s6600ffd0c9eea/
• https://cedil.cesa.or.jp/cedil_sessions/view/2902

マージリレーで考えてみる ● 自分の PR とは関係のない差分を排除 ○ 課題外在的負荷の削減 ● コンフリクトの自動解決、リレーの自働化ワークフロー ○ 課題内在的負荷の削減 ○ 自動解決できないケースのコンフリクト時の負荷は残る ● コンフリクトを自分で解消するという機会 ○ 学習関連負荷 © DeNA Co., Ltd. 51

マージリレーで考えてみる ● 認知負荷という観点から見ても良かったのかも？ © DeNA Co., Ltd. 52

認知負荷理論と AI 利活用 ● 認知負荷理論を知らずとも取り組みは今までもやってきている ○ ドキュメントやコメント ○ ルール整備 ○ 勉強会や知見共有会 ● AIオールイン ○ 上記のようなところでも AI により大きく状況が変化している ○ AI を使いこなすうえでも認知負荷理論は知っておくと良さそう © DeNA Co., Ltd. 53

これから ● 負荷を軽減する自動化だけでなく、 できるを増やす自働化を進めていきたい © DeNA Co., Ltd. 54

まとめ © DeNA Co., Ltd. 55

まとめ ● GitHub Actions により大幅な業務効率改善ができている ● ただし、新たに生まれた課題もたくさんある ● 常に課題と向き合い解決をしていく姿勢が大事 ● 「ゲーム開発者のための SRE」のバリューは 自動化であり、自働化でもある ● 様々な観点や技術を活用し、今後も 開発チームが「楽」して開発・運営ができる場を目指します © DeNA Co., Ltd. 56

© DeNA Co., Ltd. 57