こんにちは。DevOpsの世界へようこそ。
GitLabを使い始めると、最初にぶつかるのが「CI/CDの実行コスト」という壁です。特にクラウド環境（AWS/GCP）でRunnerを動かしていると、気づかないうちに「請求書がとんでもない金額になっていた」というのは、この業界でよくある悪夢です。
今回は、GitLabのRunner階層構造をハックし、コストを極限まで最適化するための「現場の知恵」を授けます。これをマスターすれば、あなたのチームのクラウド支出は劇的に最適化され、開発者はより速く、より安全にコードを出荷できるようになります。
—
1. Runnerの階層構造を理解する：なぜ「場所」が重要なのか
GitLabにはRunnerを定義する場所が3つあります。
- Instance Runners: 全プロジェクトで共有。管理が楽だが、リソースの奪い合いが起きやすい。
- Group Runners: 特定のグループ（部署やプロダクト単位）で共有。ここが最適化のスイートスポットです。
- Project Runners: 特定のプロジェクト専用。管理コストが高く、放置されると「野良Runner」になりがちです。
【プロの視点】: 最初は「Instance Runner」で動かして満足しがちですが、これではコストのブラックボックス化を招きます。「グループ単位でRunnerを分け、オートスケーリングをかける」のが、コスト管理の絶対鉄則です。
—
2. 「Group Runners」によるコスト最適化戦略
クラウド料金を抑えるには、「使わない時はゼロにする」のが正義です。
オートスケーリングの極意（AWS EC2 / GCP Compute Engine）
`gitlab-runner` をインストールする際、`docker-machine` または `Instance Group` を使ったオートスケーリングを設定します。
config.toml の抜粋
[runners.docker]
# コンテナ終了時に必ずキャッシュをクリアし、ディスクを解放する
# これを忘れると、ストレージ料金が膨れ上がります
volumes = [“/cache”]
# 重いビルドが終わったら即座にインスタンスを落とす設定
IdleCount = 0
IdleTime = 60 # 60秒間何もなければ終了
【ハック】: `IdleTime` を短くしすぎると、連続するビルドでインスタンス起動のオーバーヘッドが発生します。プロジェクトのビルド時間に合わせ、30〜60秒の間で調整するのがベストです。
—
3. Runnerタグ運用：コストの「見える化」
すべてのプロジェクトが同じスペックのRunnerを使う必要はありません。
1. タグの設計: `small`, `medium`, `gpu` などのタグをRunnerに付与します。
2. パイプラインでの指定: プロジェクトごとの `.gitlab-ci.yml` で適切なタグを指定させます。
.gitlab-ci.yml
test_job:
tags:
- small # 安価なインスタンスで十分なテスト
script:
- npm test
build_docker_image:
tags:
- medium # ビルドにはメモリが必要なので中規模インスタンスへ
script:
- docker build -t my-app .
これにより、「テストは安いインスタンスで、デプロイは高スペックなインスタンスで」という適材適所のコスト配分が可能になります。
—
4. 初心者のための「HelloWorld」：動作確認のステップ
まずは、自分の環境でRunnerを動かしてみましょう。
ステップ1: Runnerのインストール
Linux環境であれば以下のコマンドで一発です。
GitLab Runnerをインストール
sudo curl -L “https://packages.gitlab.com/install/repositories/gitlab/gitlab-runner/script.deb.sh” | sudo bash
sudo apt-get install gitlab-runner
ステップ2: 登録（Registration）
GitLabの[Settings] > [CI/CD] > [Runners]からトークンを取得し、登録します。
sudo gitlab-runner register \
–url “https://gitlab.com/” \
–registration-token “YOUR_TOKEN” \
–executor “docker” \
–docker-image “alpine:latest”
ステップ3: 動作確認（.gitlab-ci.yml）
リポジトリのルートに以下のファイルを作成してプッシュしてください。
最もシンプルなCI確認用スクリプト
hello-world-job:
script:
- echo “Runnerが正常に動いています！”
- uname -a
tags:
- your-tag-name # 登録したRunnerのタグを指定
これが緑色のチェックマークで終われば、あなたの環境でCI/CDの第一歩が踏み出せたことになります。
—
最後に：先輩からのアドバイス
コスト管理は「一度やって終わり」ではありません。
GitLabの「CI/CD Minutes」の利用状況を定期的に確認し、「ビルド時間が異常に長いジョブ」を見つけてください。そのジョブこそが、あなたのクラウド予算を食いつぶしている犯人です。
無駄なビルドキャッシュを整理し、Dockerイメージを軽量化（Alpineベースに変えるなど）するだけで、実はRunnerのスペックを下げられることが多々あります。
ツールに振り回されるのではなく、ツールを飼いならす。その感覚が掴めたとき、あなたはもう立派なDevOpsエンジニアです。応援していますよ！