젠킨스 Executor 최적화 마스터하기: 더 빠른 빌드를 위한 가이드

젠킨스 Executor 최적화는 사실 작은 단위의 용량 계획입니다. Executor는 젠킨스가 노드에서 작업을 실행할 수 있는 슬롯입니다. 슬롯을 너무 적게 추가하면 작업이 대기열에서 기다립니다. 너무 많이 추가하면 모든 빌드가 CPU, 메모리, 디스크, 네트워크, 그리고 때로는 동일한 종속성 캐시를 두고 경쟁하게 됩니다.

목표는 "더 많은 Executor"가 아닙니다. 목표는 개별 빌드를 불안정하게 만들지 않으면서 전체 피드백 시간을 단축하는 것입니다.

컨트롤러 Executor를 0으로 유지

대부분의 최신 젠킨스 설치에서 컨트롤러는 작업을 스케줄링하고, UI를 제공하며, 작업 구성을 저장하고, 에이전트를 조정해야 합니다. 코드를 컴파일하거나 테스트 스위트를 실행해서는 안 됩니다.

특별히 작고 의도적인 관리 작업이 반드시 컨트롤러에서 실행되어야 하는 경우가 아니라면 컨트롤러 Executor를 0으로 설정하세요. 컨트롤러에서 바쁜 빌드가 실행되면 UI가 느려지고, 대기열 스케줄링이 지연되며, 플러그인 문제를 진단하기 어려워질 수 있습니다. 컨트롤러가 불안정해지면 Jenkins를 사용하는 모든 팀이 그 영향을 받습니다.

빌드 작업을 명확한 레이블이 있는 에이전트로 이동하세요:

linux && docker
linux && maven
windows && visualstudio
large-memory

레이블은 Executor 최적화의 일부입니다. linux && docker를 기다리는 작업은 유휴 Windows Executor가 있어도 상관하지 않기 때문입니다.

보편적인 공식이 아닌 워크로드 유형부터 시작

CPU 집약적인 빌드의 경우 물리적 또는 가상 CPU 코어 수에 가깝게 시작하세요. C++ 컴파일 또는 대규모 Java 테스트 스위트를 실행하는 8코어 빌드 VM은 6~8개의 Executor로 시작한 다음 측정 결과에 따라 줄이거나 늘릴 수 있습니다.

I/O 집약적인 빌드의 경우 작업이 네트워크 다운로드, 아티팩트 업로드 또는 테스트 서비스를 기다리는 데 시간을 소비하기 때문에 CPU 코어보다 더 많은 Executor를 실행할 수 있습니다. 종속성이 많은 8코어 에이전트는 10~12개의 Executor를 잘 처리할 수 있습니다. 디스크가 느리거나 메모리가 부족하면 6개에서도 문제가 발생할 수 있습니다.

메모리가 종종 실제 제한을 설정합니다. 각 빌드가 2GB의 RAM을 사용하고 에이전트에 16GB가 있는 경우 8개의 Executor는 OS, Docker 데몬, 언어 런타임, 브라우저 테스트 또는 파일 시스템 캐시를 위한 공간을 남기지 않습니다. 이 경우 8개보다 4~5개의 Executor가 더 빠를 수 있습니다. 시스템이 스와핑을 피하기 때문입니다.

다음과 같은 워크시트를 사용하세요:

에이전트 RAM: 32 GB
OS 및 데몬 예약: 4 GB
빌드 사용 가능: 28 GB
일반적인 빌드 피크: 3 GB
시작 Executor: 8 또는 9, 그런 다음 부하 상태에서 검증

숫자가 완벽할 필요는 없습니다. 실제 빌드를 관찰한 후 조정할 수 있을 만큼 명시적이어야 합니다.

대기열 이유 확인

젠킨스 빌드 대기열은 작업이 기다리는 이유를 알려줍니다. "다음 사용 가능한 Executor를 기다리는 중"은 "레이블이 있는 노드가 없음"과 다릅니다. 첫 번째는 용량 압력을 시사합니다. 두 번째는 레이블 또는 에이전트 프로비저닝 문제를 시사합니다.

개발자가 젠킨스가 느리다고 불평할 때 확인하세요:

• 레이블별 대기열 길이.
• 평균 대기열 대기 시간.
• 에이전트 온라인/오프라인 변동.
• 잠긴 리소스를 기다리며 멈춘 빌드.
• 예상보다 많은 Executor를 소비하는 병렬 파이프라인 단계.

10개의 병렬 브랜치가 있는 단일 파이프라인은 10개의 Executor 슬롯을 소비할 수 있습니다. 테스트 매트릭스에 원하는 것일 수 있습니다. 또한 소규모 젠킨스 설치에서 다른 모든 작업을 굶길 수 있습니다.

폐기 가능한 에이전트당 하나의 Executor 사용

Kubernetes 에이전트 및 많은 클라우드 생성 에이전트의 경우 pod 또는 인스턴스당 하나의 Executor가 일반적으로 가장 깔끔한 모델입니다. Pod는 격리 단위입니다. 더 많은 동시성이 필요한 경우 관련 없는 빌드를 동일한 폐기 가능한 작업 공간에 패킹하는 대신 더 많은 Pod를 만드세요.

이 모델은 리소스 요청을 중요하게 만듭니다:

resources:
  requests:
    cpu: "2"
    memory: "4Gi"
  limits:
    memory: "6Gi"

요청이 너무 낮으면 Kubernetes가 너무 많은 Jenkins 에이전트를 하나의 노드에 패킹할 수 있습니다. Jenkins는 사용 가능한 Executor를 보지만 클러스터 노드는 과부하 상태입니다. 제한이 너무 빡빡하면 빌드가 애플리케이션 문제처럼 보이는 메모리 오류와 함께 실패합니다.

정적 VM 에이전트의 경우 여러 Executor가 괜찮을 수 있습니다. 작업 공간 레이아웃, 캐시 디렉토리 및 도구 설치를 동시 작업에 맞게 설계하기만 하면 됩니다.

시끄러운 작업 제한

일부 작업은 Jenkins가 스케줄할 수 있는 만큼 많은 복사본을 실행해서는 안 됩니다. 데이터베이스 통합 테스트, 브라우저 테스트, 부하 테스트 및 이미지 빌드는 공유 시스템을 빠르게 포화시킬 수 있습니다.

작업 수준 제한, 잠글 수 있는 리소스 또는 파이프라인 제어를 사용하세요:

pipeline {
  agent { label 'linux && docker' }
  options {
    disableConcurrentBuilds()
  }
  stages {
    stage('Build Image') {
      steps {
        sh 'docker build -t app:${BUILD_NUMBER} .'
      }
    }
  }
}

공유 스테이징 데이터베이스의 경우 잠금이 더 명확합니다:

lock('staging-db') {
  sh './run-integration-tests.sh'
}

이렇게 하면 하나의 작업이 기다릴 수 있지만, 다섯 개의 작업이 함께 실패하여 모든 Executor 시간을 낭비하는 것을 방지합니다.

Jenkins뿐만 아니라 에이전트도 측정

Jenkins는 대기열 시간과 Executor 사용량에 대해 알려줄 수 있습니다. 운영 체제는 Executor 수가 적절한지 알려줍니다.

Linux 에이전트에서 확인하세요:

uptime
mpstat 1
iostat -xz 1
free -h
df -h
docker system df

높은 CPU와 낮은 I/O 대기는 CPU 바운드 작업을 의미합니다. 높은 I/O 대기는 Executor를 추가하면 빌드가 느려질 가능성이 높음을 의미합니다. 빌드 중 스왑 사용은 Executor를 줄이거나 메모리를 늘려야 한다는 강력한 신호입니다. 거의 가득 찬 디스크는 체크아웃, 아카이빙 및 Docker 빌드를 느리게 만들 수 있습니다.

개별 빌드 기간도 확인하세요. 대기열 시간이 1분 줄었지만 각 빌드가 5분 느려진다면 더 높은 Executor 수는 이점이 아닙니다.

작은 변경으로 조정

Executor 수를 점진적으로 변경하세요. 에이전트를 4에서 6으로 이동하고, 몇 분주한 날 동안 관찰한 다음 결정하세요. 큰 점프는 회귀의 원인을 숨깁니다.

메모를 유지하세요:

2026-05-24: linux-build-03 executors 4 -> 6
이유: linux && maven 대기열 평균 12분
관찰: CPU, iowait, Maven 캐시 잠금 경합, 빌드 기간
롤백: p95 빌드 기간이 예상보다 많이 상승하면 4로 설정

이 짧은 기록은 2주 후에 누군가 에이전트가 왜 느린지 물을 때 도움이 됩니다.

실용적인 목표

건강한 Jenkins 설정은 피크 시간에 대부분의 에이전트가 바쁘고, 일반적인 레이블에 대한 대기열이 짧고, 스왑이 없으며, 빌드 기간이 예측 가능하고, 컨트롤러 빌드가 없습니다. 또한 Docker 에이전트가 없어도 관련 없는 Maven 작업이 기다리지 않도록 충분한 레이블별 용량이 있습니다.

Executor 최적화는 일회성 설정이 아닙니다. 팀이 병렬 단계를 추가하거나, 더 큰 테스트 스위트로 이동하거나, Docker 빌드를 채택하거나, 정적 VM에서 Kubernetes 에이전트로 마이그레이션할 때 변경됩니다. 대기열 시간이 눈에 띄게 되거나, 에이전트가 스와핑을 시작하거나, 사람들이 제안하는 가장 빠른 수정이 "Executor를 더 추가하세요"일 때 검토하세요. 때로는 그것이 맞습니다. 종종 더 나은 수정은 새로운 에이전트 풀, 더 나은 레이블 또는 다른 모든 사람에게 피해를 주는 작업의 동시 복사본을 줄이는 것입니다.

병렬 단계에는 예산이 필요

파이프라인 병렬 처리는 큰 이점이 될 수 있지만 Executor를 빠르게 소비합니다. 4개의 Java 버전과 3개의 운영 체제에 걸친 매트릭스 빌드는 12개의 브랜치를 생성할 수 있습니다. 각 브랜치가 별도의 에이전트에서 실행되는 경우, 이 하나의 빌드는 배포 단계가 시작되기 전에 12개의 Executor를 소비할 수 있습니다.

팀이 계획한 경우에는 허용됩니다. 단일 풀 리퀘스트가 릴리스 빌드를 굶길 때는 고통스럽습니다. 대규모 팬아웃 작업에 제한을 두세요:

options {
  parallelsAlwaysFailFast()
}

비용이 많이 드는 브랜치를 올바른 풀로 보내는 레이블을 사용하고, 메인에서는 전체 매트릭스를 실행하고 풀 리퀘스트에서는 더 작은 매트릭스를 실행하는 것을 고려하세요. 목표는 모든 곳에서 최대 동시성이 아니라 중요한 곳에서 빠른 피드백입니다.

대화형 및 배치 기대치 분리

모든 Jenkins 작업이 동일한 대기열 목표를 가질 자격이 있는 것은 아닙니다. 프로덕션 핫픽스 빌드, 풀 리퀘스트 검증 작업, 야간 보안 스캔 및 주간 정리 작업은 모두 Jenkins에서 실행될 수 있지만 동등하게 경쟁해서는 안 됩니다.

레이블, 조용한 기간, 스로틀 및 예약된 시간으로 분리할 수 있습니다. 무거운 야간 작업은 대화형 PR 트래픽이 적을 때 실행되어야 합니다. 장기 실행 부하 테스트는 자체 에이전트가 있어야 합니다. 릴리스 작업은 예약된 용량이나 일반 브랜치 작업이 사용할 수 없는 레이블을 가질 자격이 있을 수 있습니다.

이것은 정치보다는 안정성에 관한 것입니다. 모든 워크로드가 하나의 Executor 풀을 공유하면 가장 시끄러운 워크로드가 모든 사람의 경험을 결정합니다.

문서화할 내용

각 에이전트 풀에 대해 작은 기록을 유지하세요:

레이블: linux && docker
에이전트 유형: 정적 VM
에이전트당 Executor: 4
주요 워크로드: Docker 이미지 빌드, 통합 테스트
알려진 제한: 디스크 I/O 및 Docker 레이어 증가
정리: 야간 docker prune, 빌드 후 작업 공간 정리
소유자: 플랫폼 팀

이 기록은 향후 튜닝을 훨씬 쉽게 만듭니다. 대기열 시간이 증가하면 동일한 에이전트를 더 추가할지, 워크로드를 새 풀로 분할할지, 또는 경합을 유발하는 작업의 동시성을 줄일지 결정할 수 있습니다.