이직 후 맡은 Jenkins에는 GUI로 만든 Job이 천 개 가까이 쌓여 있었고, CentOS 7.9 기반 배치 Jenkins 8대가 분산돼 있었다. 가장 먼저 개선한 대상은 한 번 실행하는 데 약 60분이 걸리던 글로벌 클라이언트 앱 빌드였다.
순차 빌드를 단계별로 병렬화하고 유휴 서버에 분산해 전체 대기 시간을 줄였다.
먼저, 순차로 도는 것을 병렬로
빌드 로그를 확인하니 의존성이 없는 플랫폼별·모듈별 단계가 순차로 실행되고 있었다. 해당 단계를 parallel로 구성해 빌드 시간을 약 60분에서 40분으로 줄였다. 이후 단일 서버의 CPU가 포화돼 파이프라인 병렬화만으로는 추가 단축이 어려웠다.
사용률이 낮은 물리 서버에 분산
마침 사내에 빌드용으로 받아 두고 거의 쓰지 않던 물리 서버가 세 대 있었다. 이걸 Jenkins Agent로 붙여 빌드를 분산했다. 빌드 스크립트는 Job 안에 들어 있던 것을 Git으로 빼내, Agent가 어디서 돌든 같은 스크립트를 받게 했다. 이렇게 하니 10분대로 떨어졌다. 60분에서 10분이면 거의 6분의 1이다.
그다음은 Job 정리
빌드 시간과 별개로 약 1,000개의 GUI Job도 정리가 필요했다. 이 가운데 절반가량은 2년 이상 실행 이력이 없었다. 운영에 사용하는 403개를 선별해 코드 기반으로 이전하고, 8대에 분산된 배치 Jenkins는 신규 Jenkins의 Agent로 통합했다. Job 실행 시 컨테이너를 동적으로 생성하고 종료 후 제거하도록 구성해 관리 지점을 하나로 줄였다.
작업 자체는 화려할 게 없지만 "어떤 Job이 살아 있느냐"를 아무도 자신 있게 답하지 못하던 상태에서 벗어난 게 컸다. 천 개 중 무엇이 진짜인지 모르는 채로는 다음 작업을 할 수 없기 때문이다.
버전도 같이 올렸다. Jenkins 2.345.1 → 2.399, OS는 CentOS 7.9에서 Rocky Linux 8.7로 새로 구성했다. Node 18 빌드가 필요해 어차피 한 번은 해야 했던 일이다.
여기까지가 Jenkins를 "쓸 만하게" 만든 단계다. 다만 이 작업을 하는 내내 한쪽에서는 "이걸 언제까지 Jenkins로 버티나" 하는 생각이 들었는데, 그 이야기는 다음에 따로 다룬다.
참고