こんにちは！日々のCI/CDパイプラインの運用、本当にお疲れ様です。
「ビルドの数が急増してキューが詰まる……」「でも、常時ハイスペックなJenkinsの常設ノードを立てておくのは、AWSのクラウドコストが心配……」
そんなジレンマに悩まされていませんか？
今回は、その悩みを鮮やかに解決する「Amazon EC2 Fleetプラグイン」を使ったコストゼロのバースト環境の作り方を、誰よりも分かりやすく解説します。
これをマスターすれば、ビルド負荷に応じて自動でスポットインスタンスが爆誕し、仕事が終わったら瞬時に消えていく、美しく経済的なスケーラブルCI環境が手に入りますよ。さあ、一緒に見ていきましょう！
—
1. なぜ「EC2 Fleet ＋ スポットインスタンス」なのか？
まず、ツールの役割と今回のアーキテクチャの思想を整理しておきましょう。
- Jenkinsの常設ノードの悲劇: 24時間365日、使ってもいないのに立ち上がっているビルドサーバーは、AWSの請求書を見るたびに心を冷やします。かといってスペックをケチると、コンパイルが遅くなって開発者の生産性が落ちます。
- スポットインスタンスの魔力: AWSの余剰コンピューティングパワーを格安（通常価格の最大90%OFF）で借りる仕組みです。デメリットは「AWS側の都合で突然強制終了されること」ですが、「ビルドが終わったら即破棄する使い捨てのCIノード」であれば、この強制終了リスクは実質ノーリスクになります。
- EC2 Fleetの役割: 複数のインスタンスタイプ（例: `c5.xlarge`, `c4.xlarge`, `m5.xlarge`など）をあらかじめ定義しておき、「今一番安くて空いているリソースを自動でかき集めてグループ（Fleet）を作る」という神がかった機能です。これにより、スポットインスタンス特有の「空きがなく起動できない（Capacity Unavailable）」という絶望を回避できます。
—
2. 全体像：どうやって動くのか？
仕組みはとてもシンプルです。
1. 開発者がJenkinsにビルドを投げる。
2. Jenkinsが「おっ、ビルドキューが溜まったな」と検知する。
3. EC2 Fleetプラグインが裏でAWSに「今すぐスポットインスタンスを1台くれ！」とリクエストを飛ばす。
4. 数十秒でピカピカの新規インスタンスが立ち上がり、自動でJenkinsの「エージェント（スレーブ）」として登録される。
5. 高速にビルドを実行する。
6. ビルドが完了したら、インスタンスは自動でシャットダウン＆破棄され、課金がピタッと止まる。
最高ですよね？それでは、実際にこの環境を構築していきましょう。
—
3. 実践セットアップ手順
ステップ1：AWS側の準備（IAMとセキュリティ）
まずは、JenkinsマスターからAWSを操作するための「権限（IAM）」と「通信経路」を作ります。
1. IAMユーザー / ロール の作成
Jenkinsマスター（EC2上で動いていることを想定）にアタッチする、またはプラグイン用の認証情報として、以下の権限を持つIAMポリシーを付与します。
- `ec2:RunInstances`
- `ec2:DescribeInstances`
- `ec2:TerminateInstances`
- `ec2:DescribeSpotInstanceRequests`
- `iam:PassRole` （Jenkinsエージェント用プロファイルを使う場合）
2. セキュリティグループの準備
Jenkinsマスターから、起動されるエージェント（EC2）への通信（通常はTCP 22番や、JNLP用の50000番など）が通るようにセキュリティグループを設定しておきます。
—
ステップ2：Jenkinsへのプラグイン導入
Jenkinsの管理画面から必要なプラグインをインストールします。
1. 「Jenkinsの管理」 > 「プラグインの管理」を開く。
2. 「利用可能」タブから以下を検索してインストール。
- Amazon EC2 Fleet Plugin
3. Jenkinsを再起動します。
—
ステップ3：EC2 Fleet云々のクラウド設定（核心部）
ここが一番重要な設定です。「Jenkinsの管理」>「ノードの管理」>「Clouds」へと進み、新しいCloudとして「Amazon EC2 Fleet」を追加します。
設定項目の核心を、丁寧な解説付きのコード風（設定イメージ）で見ていきましょう。
— EC2 Fleet Cloud 基本設定 —
Profile Name: “aws-spot-fleet-cluster”
AWS Region: “ap-northeast-1” (東京リージョン)
Credentials: “aws-jenkins-iam-credentials” (先ほど準備したAWS認証情報)
— Fleetの挙動設定 —
Target Capacity: 1 # 1リクエストあたりの基本容量
Limit: 5 # 最大で何台までスケールアウトを許容するか（バースト上限）
Idle Minutes Before Termination: 5 # アイドル状態が5分続いたら自動破棄
— ランチャー設定（Jenkinsとどう接続するか） —
Launch Method: “Launch agent via SSH”
Credentials: “ec2-ssh-key-pair” # EC2にログインするための秘密鍵
— テンプレート設定（Launch Templateの指定） —
Use Launch Template: ON
Launch Template ID: “lt-0123456789abcdef0” # あらかじめAWS側で作ったテンプレートID
Launch Template Version: “$Default”
> 💡 先輩エンジニアのワンポイント・ハック
> AWS側（EC2コンソール）で「起動テンプレート（Launch Template）」を事前に作っておくのがコツです。AMI（Ubuntu 22.04やAmazon Linux 2など、ビルドに必要なツールの入った黄金イメージ）やサブネット、セキュリティグループをそこで固定しておくと、Jenkins側の設定が劇的にシンプルになります。
さらに、Fleet Configのセクションで、コスト削減のキモである「複数インスタンスタイプの指定（Instance Types）」を行います。
例：C5やM5系のバリエーションを持たせ、スポットの獲得率を上げる
Instance Types:
- c5.large
- c5a.large
- m5.large
- t3.xlarge
Allocation Strategy: “capacity-optimized” # 空き容量ベースで賢く取得
`capacity-optimized` を選ぶことで、AWS側で中断（プレemption）されにくい最適なインスタンスタイプを自動選択してくれます。これがプロの技です。
—
4. 精度高い「Hello World」動作確認（検証パイロラインの作成）
さあ、設定が完了したら、実際にこのスポットフリートが正しく爆誕して仕事をこなすかテストしてみましょう！
新規で「パイプライン（Pipeline）」ジョブを作成し、以下のスクリプトを貼り付けます。
pipeline {
// ここで先ほど設定したCloudのラベルを指定します
agent {
label ‘aws-spot-fleet-cluster’
}
stages {
stage(‘環境確認’) {
steps {
echo “🚀 スポットインスタンス上でビルドが開始されました！”
sh ‘uname -a’
sh ‘uptime’
sh ‘docker –version’ // Dockerが入ったAMIならここで確認可能
}
}
stage(‘負荷テスト・ビルドシミュレーション’) {
steps {
echo “⚡️ 高速なCPUパワーでビルドを処理中…”
sh ‘sleep 10’
}
}
}
post {
always {
echo “✨ ビルド完了。まもなくこのインスタンスは自動消滅します。”
}
}
}
動作確認の手順
1. このジョブを「ビルドを実行」します。
2. Jenkinsの「ノードの管理」画面を見てみてください。
3. 数十秒後、シュッと新しいEC2インスタンスがノードとしてリストに出現し、ビルドが走り始めます。
4. ビルドが無事に完了し、数分経つと、そのノードはスッと消え去ります。
AWSのEC2コンソールを開いて、インスタンスが「terminated（終了済）」になっているのを確認した瞬間、言い知れない達成感とコスト削減の喜びがこみ上げてくるはずです。
—
まとめ：あなたのCI/CDを「持続可能」なものへ
今回は、Amazon EC2 Fleetプラグインを活用した、スポットインスタンスによるコストゼロのバースト環境の構築方法を解説しました。
- 常設サーバーの維持費にサヨナラできる
- 必要な時だけ無限に（上限設定内ですが）スケールアウトできる
- スポットインスタンスの短所を「使い捨て」という思想で完全に克服できる
これをマスターすれば、会社のインフラコストを劇的に抑えつつ、開発者には「待ち時間ゼロ」のパワフルなCI環境を提供できます。毎日のJenkins運用が、少し誇らしく、そして楽になりますよ。
ぜひあなたの環境でも導入してみてください。それでは、快適なDevOpsライフを！