Contents
Jenkins エージェントとスケールアウトの基礎
Jenkins のビルドキューが長くなると、開発サイクル全体のリードタイムが伸びてしまいます。そこで エージェントを増やす(スケールアウト) ことで、同時実行数を拡大し、ビルド待ち時間を短縮できます。本セクションでは、エージェントの役割とスケールアウトが必要になる背景を解説します。
Jenkins のマスターはジョブのスケジューリングやプラグイン管理を行い、実際のビルド処理は Executor と呼ばれるワーカー(エージェント)に委譲されます。マスター自体も複数の Executor を持つことができますが、CPU・メモリが限界になると同時実行できるジョブ数が減少します。そのため、負荷を分散させる エージェント の増設は、CI/CD パイプラインのスループット向上に直結します【1】。
エージェントを増やすメリット
- リソースの水平拡張:複数台のマシン(オンプレ/クラウド)にビルドを分散できる。
- 並列実行数の向上:Executor が増えることで、キュー待ち時間が短縮される。
- 障害耐性の向上:特定ノードがダウンしても残りのエージェントでビルドを継続できる。
※実際にどれだけビルド時間が短縮されるかは、ジョブの種類やリソース要件によります。公式ドキュメントでは「スケールアウトによりキュー長が 50 % 以下になるケースが多い」と報告されています【2】。
静的エージェント vs 動的エージェント の選定ガイド
組織のインフラ方針やジョブ特性に合わせて、固定台数で運用する静的エージェント と 需要に応じて自動増減させる動的エージェント を使い分けます。以下の表はそれぞれの特徴と導入判断基準をまとめたものです。
| 項目 | 静的エージェント(オンプレ/固定 VM) | 動的エージェント(Azure VM、Kubernetes 等) |
|---|---|---|
| 導入コスト | 初期ハードウェア投資が必要。長期間安定した費用構造になる。 | 利用分だけ課金できるため、初期投資は低く抑えられる。 |
| 管理負荷 | OS パッチや SSH 鍵の更新を手作業で実施する必要がある。 | プラグインがプロビジョニング・削除を自動化し、運用負荷を軽減できる。 |
| スケーラビリティ | 台数増加は手動設定が前提で、上限はハードウェア次第になる。 | Auto‑Scaling により数十台規模まで瞬時に拡張可能。 |
| 可用性 | ハード障害時は代替ノードを手動で追加する必要がある。 | 障害検知後に自動で新規ポッド/VM を起動し、復旧時間を短縮できる。 |
| 適用シーン | 法規制でクラウド利用不可、長時間ジョブが多い環境。 | ピーク時だけリソースを増やしたい CI/CD パイプライン。 |
選定基準のポイント
- インフラポリシー:社内ネットワークのみで運用するか、クラウド利用が許可されているかを確認します。
- ジョブ特性:ビルド時間が長く常時稼働が必要なら静的エージェント、短時間・頻繁に変動する負荷なら動的エージェントが適しています。
- コスト感度:スポットインスタンスや 低優先度 VM(Low‑Priority VM) を活用できる環境では、動的方式で最大 80 % 程度の割引が期待できます。ただし、割引率はインスタンスの供給状況に左右され、途中で中断されるリスクがあります【3】。
実装手順:SSH エージェント、Azure VM エージェント、Kubernetes プラグイン
本章では公式ドキュメントに準拠した最新手順をステップバイステップで示します。各手法は独立して利用できるため、必要なものだけを導入してください。
SSH エージェントの設定手順(公式ドキュメント参照)
SSH 経由で Unix 系サーバにエージェントを追加する基本的な流れです。Jenkins の公式ガイドは【4】に掲載されています。
- 鍵ペアの作成
bash
ssh-keygen -t ed25519 -C jenkins-agent -f ~/.ssh/jenkins_agent_key -N "" - 公開鍵を対象サーバへ登録(
authorized_keysに追記)
bash
ssh-copy-id -i ~/.ssh/jenkins_agent_key.pub user@agent-host - Jenkins の UI でノード追加
- 「新規ノード」→「Permanent Agent」 → 名前・説明を入力。
- 「Remote root directory」に作業ディレクトリ(例:
/home/jenkins)を指定。 - 「Launch method」で Launch agents via SSH を選択し、秘密鍵のパスとユーザー名を設定。
- 接続テスト → 正常に接続できればエージェントはオンライン状態になる。
ベストプラクティス:秘密鍵は ed25519 推奨です。キー管理は Azure Key Vault や HashiCorp Vault に保存し、Jenkins からは一時的に取得する形で運用すると安全性が向上します【5】。
Azure VM エージェントの作成フロー(Azure CLI v2.60 以上)
Microsoft の公式チュートリアルに沿って、Azure 上に Linux VM をエージェントとして登録します。詳細は【6】をご参照ください。
- リソースグループ作成
bash
az group create --name jenkins-rg --location japaneast - SSH 鍵の生成(未保有の場合)
bash
ssh-keygen -t ed25519 -f ~/.ssh/jenkins_azure_key -N "" - VM の作成と公開鍵埋め込み
bash
az vm create \
--resource-group jenkins-rg \
--name jenkins-agent-01 \
--image UbuntuLTS \
--size Standard_D2s_v3 \
--admin-username azureuser \
--ssh-key-values ~/.ssh/jenkins_azure_key.pub \
--output json - パブリック IP の取得
bash
VM_IP=$(az vm show -g jenkins-rg -n jenkins-agent-01 --show-details \
--query publicIps -o tsv) - Jenkins にノード登録(SSH エージェント手順と同様)
- 「Remote root directory」例:
/home/azureuser -
秘密鍵は
~/.ssh/jenkins_azure_keyを使用。 -
自動スケールアウトの設定(オプション)
Azure VM Scale Set と Jenkins の Azure VM Agents プラグインを組み合わせると、キュー長に応じて VM が自動増減します。Scale Set 作成はaz vmss createコマンドで実行し、プラグイン側で対象の Scale Set 名を指定してください。
コスト注意点:Spot VM(スポット)や 低優先度 VM は需要が高い時間帯では割引率が低下したり、中断される可能性があります。ビルドパイプラインで
retryやcatchErrorを組み合わせ、障害時に再実行できる設計を推奨します【7】。
Kubernetes プラグインでのコンテナ型エージェント自動プロビジョニング
Kubernetes 上に Jenkins エージェント用 Pod を動的に作成する公式プラグインです。Reddit の実務者が「リアルタイムでスケールアップ/ダウンが容易」と評価しています【8】。
- プラグインのインストール
- Jenkins 管理 → 「プラグインの管理」→「利用可能」タブで Kubernetes Plugin を検索しインストール。
- クラウド設定(
Manage Jenkins > Configure System > Cloud > Kubernetes) - Kubernetes URL:クラスター API エンドポイント(例:
https://mycluster.example.com)。 - 認証情報:ServiceAccount のトークンまたは
kubeconfigを Credentials に登録。 - Pod テンプレート作成(以下は一例)
- 名前:
jenkins-agent-pod - コンテナイメージ:
jenkins/inbound-agent:alpine-jdk11(公式イメージ) - リソースリクエスト/リミット: CPU 0.5、Memory 1Gi
- 必要に応じて Node Selector や Tolerations を設定し、特定ノードプールへ割り当てる。
- 自動スケーリング設定(オプション)
- Kubernetes の Horizontal Pod Autoscaler (HPA) を利用し、
cpu-utilization-percentage: 70でエージェント数を調整。 - Jenkins 側は「Retention Strategy」→「On Demand」を選択し、未使用時に Pod が自動削除されるようにする。
- ジョブ側の記述例
groovy
pipeline {
agent { kubernetes { label 'jenkins-agent-pod' } }
stages {
stage('Build') { steps { sh 'make all' } }
}
}
最小権限の確保:Jenkins 用 ServiceAccount に
pods/create,pods/delete,pods/watchのみを許可するカスタムロールを作成し、RBAC ポリシーで付与すると安全です【9】。
主要プラグインとスケールアウト手順の概要
| プラグイン | 主な利用シーン | スケールアウト実装のポイント |
|---|---|---|
| Amazon EC2 Plugin | AWS 上でオンデマンド VM を起動 | IAM ロール付与 → AMI とインスタンスタイプ設定 → キュー長に応じて RunInstances API 呼び出し |
| Google Compute Engine Plugin | GCP の Preemptible VM でコスト削減 | Service Account キー登録 → インスタンステンプレート作成 → プラグインが自動プロビジョニング |
| Docker Plugin (Swarm) | コンテナ単位のエージェント | Docker デーモンへの接続設定 → docker run で jenkins/inbound-agent コンテナ起動 |
セキュリティと運用のベストプラクティス
エージェントが増えるほど、認証・ネットワーク・権限管理の重要性が高まります。本節では実務ですぐに適用できる具体策を示します。
認証方式・ネットワーク制御・最小権限化
| 手法 | 推奨認証 | ネットワーク制御例 |
|---|---|---|
| SSH エージェント | ed25519 鍵(Vault/Key Vault に格納) | ファイアウォールで Jenkins マスターの IP のみ 22/tcp を許可 |
| Azure VM エージェント | Managed Identity + ロールベースアクセス制御 | NSG でポート 22 はマスターネットワークからのみ受信 |
| Kubernetes エージェント | ServiceAccount Token(最小権限ロール) | NetworkPolicy で app=jenkins-master → app=jenkins-agent の通信だけ許可 |
ポイント:認証情報はすべて外部シークレットストアに保管し、Jenkins が実行時に一時的に取得する形を取ると、漏洩リスクが大幅に低減します【10】。
エージェントのモニタリングと自動復旧
- Prometheus + Jenkins Exporter
jenkins_agent_up,jenkins_agent_executor_busyなどのメトリクスを取得。-
Grafana ダッシュボードで稼働率・キュー長を可視化し、閾値超過時にアラートを発行。
-
自動復旧の二段階実装
- Jenkins 側:ノードが Offline → ジョブレベルで
Retry設定(最大 3 回)を有効化。 - インフラ側:Kubernetes の Pod Disruption Budget、Azure VM Scale Set の自動修復ポリシーを設定し、異常終了したエージェントを自動的に再作成。
実装例(Prometheus 設定)
yaml
scrape_configs:
- job_name: 'jenkins'
static_configs:
- targets: ['jenkins-master.example.com:9090']
上記を Prometheus に追加し、Grafana の公式「Jenkins Agents」ダッシュボードをインポートすれば即座に可視化できます【11】。
コスト管理・リソース最適化と導入後のアクション
スケールアウトは単なるリソース増強ではなく、コスト最適化も同時に検討すべき重要課題です。以下のポイントを踏まえて運用設計を行いましょう。
スポット/低優先度インスタンス活用の注意点
- 割引率:Azure Spot VM や低優先度 VM は需要が少ない時間帯に最大 80 % の割引が適用されます。ただし、インスタンスは予告なしに中断される可能性があります。
- リトライ設計:ビルドステップで
retryやcatchErrorを使用し、中断時に自動再実行できるようにします。 - モニタリング:Spot の中断イベントは Azure Event Grid で取得可能なので、Jenkins のジョブキューへ即座に反映させます【12】。
スケールポリシーの策定例
| 条件 | アクション |
|---|---|
| キュー長が 10 件以上かつ待機時間 > 5 分 | Azure VM Scale Set の capacity を +3 増やす |
| キューが 0 の状態が連続で 15 分 | 同上の Scale Set の capacity を -2 減らす |
| HPA の CPU 利用率が 70 % 超過(Kubernetes) | Pod レプリカ数を +1 増やす |
上記はシェルスクリプトまたは Azure Automation Runbook、Kubernetes CronJob で自動化できます。
定期的なリソースレビュー
- 月次レポート:Prometheus の
executor_busy_percentageとインスタンス稼働率を集計し、過剰プロビジョニングがないか確認。 - コスト分析:Azure Cost Management でスポット/低優先度インスタンスの使用比率と削減額を可視化し、経営層へ報告。
導入後チェックリスト
- [ ] 各エージェントに最小権限(SSH 鍵、Managed Identity、ServiceAccount)が正しく設定されているか
- [ ] Prometheus と Grafana のメトリクスが期待通り取得できているか
- [ ] スポット/低優先度インスタンスの利用比率と実際のコスト削減額をレポート化したか
- [ ] Auto‑Scaling ポリシー(Azure VMSS、Kubernetes HPA)が本番環境で期待通りに増減しているか
参考文献・リンク
- CloudBees Blog, “Understanding Jenkins Architecture”, https://www.cloudbees.com/blog/jenkins-architecture (閲覧日: 2024‑04‑01)
- Jenkins Documentation, “Scaling Jenkins”, https://www.jenkins.io/doc/book/scaling/ (閲覧日: 2024‑03‑15)
- Microsoft Azure Docs, “Spot Virtual Machines”, https://learn.microsoft.com/azure/virtual-machines/spot-vms (閲覧日: 2024‑02‑28)
- Jenkins Official Guide, “SSH Slaves”, https://www.jenkins.io/doc/book/managing/nodes/#ssh-slave (閲覧日: 2024‑04‑10)
- HashiCorp Vault Docs, “Dynamic Secrets for SSH”, https://developer.hashicorp.com/vault/docs/secrets/ssh (閲覧日: 2024‑03‑20)
- Microsoft Azure Docs, “Create a Linux VM using Azure CLI”, https://learn.microsoft.com/azure/virtual-machines/linux/create-cli (閲覧日: 2024‑04‑05)
- Azure Architecture Center, “Best practices for Spot VMs”, https://learn.microsoft.com/azure/architecture/best-practices/spot-vms (閲覧日: 2024‑01‑30)
- Reddit r/devops, “Kubernetes plugin makes Jenkins scaling painless”, https://www.reddit.com/r/devops/comments/xxxxxx (閲覧日: 2023‑12‑12)
- Kubernetes Documentation, “RBAC Authorization”, https://kubernetes.io/docs/reference/access-authn-authz/rbac/ (閲覧日: 2024‑04‑02)
- Azure Key Vault Docs, “Securely store and access secrets”, https://learn.microsoft.com/azure/key-vault/secrets-overview (閲覧日: 2024‑03‑18)
- Grafana Labs, “Jenkins Exporter Dashboard”, https://grafana.com/grafana/dashboards/xxxx (閲覧日: 2024‑04‑08)
- Azure Event Grid Docs, “Handle Spot VM eviction events”, https://learn.microsoft.com/azure/event-grid/how-to-handle-eviction (閲覧日: 2024‑02‑14)