エンジニアの皆さん、こんにちは。
GitHub Actionsを使っていて、「ビルドの待ち時間が長い」「でも、常にインスタンスを動かし続けるとクラウド代が跳ね上がる」というジレンマに頭を抱えたことはありませんか？
今日は、GitHub Actionsの「セルフホストランナー」を、KEDA（Kubernetes Event-driven Autoscaling）を使って魔法のように自動スケールさせる方法を伝授します。これをマスターすれば、ビルドがない時はコストゼロ、負荷が来れば一瞬でスケールする「夢のCI環境」が手に入ります。
—
1. なぜ「固定のランナー」では限界なのか
多くの現場では、EC2やVMにランナーを常駐させています。しかし、これには2つの大きな「負」があります。
- コストの浪費: 深夜や休日に誰もコードをコミットしていない間も、インスタンス料金を払い続けることになります。
- スケーラビリティの欠如: 開発者が一斉にPushしたとき、ランナーが1台しかなければビルドは行列を作り、生産性が著しく低下します。
そこで登場するのが、KEDAです。KEDAは「GitHubのワークフロー待機キュー」を監視し、ジョブが溜まった瞬間にKubernetes上のランナー（Pod）を増殖させ、終われば即座に削除する、まさに「現場の救世主」です。
—
2. KEDAによる自動スケール：全体アーキテクチャ
仕組みは非常にシンプルです。
1. GitHub Actions API: 現在のジョブ待ち数を確認。
2. KEDA Scaler: APIを監視し、待機ジョブがあればK8sに「Podを増やせ！」と命令。
3. Runner Pod: 増えたPodがジョブを消化。
4. 終了後: ジョブがなくなればPodを自動終了。
—
3. 【実践】環境構築のステップ
まずは、Kubernetesクラスターが用意されている前提で、以下の3ステップで構築します。
STEP 1: KEDAのインストール
まずはK8sにKEDAを導入します。helmを使うのが最も安全で早いです。
KEDA用の名前空間作成
kubectl create namespace keda
Helmでインストール
helm repo add kedacore https://kedacore.github.io/charts
helm repo update
helm install keda kedacore/keda –namespace keda
STEP 2: GitHubの認証設定
ランナーがGitHubと通信するためのトークンをSecretとして登録します。
github-secret.yaml
apiVersion: v1
kind: Secret
metadata:
name: github-token
type: Opaque
stringData:
# GitHubのSettings > Developer settingsから取得したPAT
# リポジトリまたはOrganizationの管理者権限が必要
token: ghp_xxxxxxxxxxxxxxxxxxxx
`kubectl apply -f github-secret.yaml` で適用してください。
STEP 3: ScaledObjectの定義（ここが心臓部！）
これが「キューが溜まったらPodを増やせ」という指令書です。
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
name: github-runner-scaler
spec:
scaleTargetRef:
# 実際のリソース（Deployment等）を指定
name: actions-runner-deployment
minReplicaCount: 0 # 誰も使っていない時は0台！これがコスト削減の鍵
maxReplicaCount: 10 # 最大10台まで自動スケール
triggers:
- type: github-runner
metadata:
owner: your-org-name
repo: your-repo-name
runnerScope: repo
authenticationRef:
name: github-token # 先ほど作ったSecretを参照
—
4. HelloWorld的な動作確認
設定が終わったら、実際にスケールするか確認しましょう。
1. 確認: `kubectl get pods` を実行。現在ランナーが0個であることを確認します。
2. トリガー: GitHubリポジトリで、わざと重いワークフロー（`sleep 60` を含むものなど）を複数回実行します。
3. 観察: すぐに `kubectl get pods` を打ってみてください。
- 魔法のようにPodが立ち上がり、ジョブを実行し始めます。
- ジョブ完了から数分後（KEDAのデフォルトクールダウン期間）、Podは自動的に消滅します。
—
5. 先輩からの「現場の知恵」
最後に、現場で泣きを見ないためのアドバイスを3つ贈ります。
- 1. ノードの余力管理: K8sのノード自体が足りないと、Podは「Pending」のままです。KarpenterなどのNode AutoScalerを併用し、クラスター自体の台数も自動増減させると、まさに最強のインフラになります。
- 2. セキュリティ: GitHubのトークンは強力な権限を持つため、必ずGitHub Appsを使用して権限をスコープ化することをお勧めします。
- 3. ログの保存: Podが消えるとログも消えます。LokiやCloudWatch Logsなど、外部のログ集約基盤へ飛ばす設定を忘れずに。
—
最後に
いかがでしたか？「GitHub Actionsのランナーを自分で管理するのは面倒」という常識は、KEDAを使えば過去のものになります。
最初は複雑に見えるかもしれませんが、一度この「イベント駆動型スケーリング」を構築してしまえば、あなたはインフラの運用から解放され、本来の「価値あるコードを書く」ことに集中できるようになります。
毎日の作業が劇的に楽になる未来へ、ぜひ一歩踏み出してみてくださいね。応援しています！