CI/CD를 처음 구성한 후, 첫 문제는 '빌드에 걸리는 시간' 이었습니다.
개인 컴퓨터에서 빌드했을때는 30초면 끝나던 빌드가, 젠킨스에서는 10분 가량이 걸렸고,
당시 젠킨스가 레드마인/깃랩과 같은 머신에서 돌고있었어서(지금은 분리했습니다.) 빌드하는 10분 동안 다른 툴들의 속도도 느려져 불편함이 많았습니다.
사실 젠킨스에 대해 무지했었기에 처음에는 원래 젠킨스로 빌드하면 느린가? 생각했는데, 상급자로부터 빌드 시간이 이상할정도로 느리다는 말을 듣고 해결방안을 찾게 되었습니다.
첫번째로 생각한 방안은 무식하게 리소스를 늘리는 방안이었습니다.
젠킨스가 가동되는 VM의 CPU 코어 갯수를 4개에서 16개로 늘리고, 램을 8기가에서 16기가로 늘렸습니다.
지금 생각하면 조기축구에 메시부른 급인데, 효능이 없음을 체크하고 그냥 롤백했습니다.
두번째로는 빌드 시간 자체를 줄이기 위해 의존성 패키지를 젠킨스가 설치된 OS에 깔아두는 방법이었습니다.
빌드 로그를 살펴보다보니 매 빌드마다 의존성 패키지를 다시 설치하는게 시간을 가장 많이 잡아먹는 스텝이었기때문에
자주 사용하는 패키지를 젠킨스가 설치된 OS에 설치해두면 이후에도 재사용할 수 있을 것이고 필요할때마다 불러오기만해서 사용하면 되지 않을까 하는 생각이었지만,
모든 프로젝트가 돌아갈 OS에서 한 프로젝트를 할때마다 몇개씩의 의존성을 직접 설치하다보면 여러 패키지가 얽히고 얽혀 다른 문제점이 생길 것 이라는 느낌이 강하게 들어서 넘겼습니다.
그래서 마지막으로 떠올린 세번째 방법이 Docker 이미지에 의존성 패키지를 포함하는 방법이었습니다.
Docker는 컨테이너라 불리는 가상 환경 시스템 덕분에 젠킨스가 설치된 OS에 영향을 받지않고 독립적인 환경을 구상할 수 있었기에, 두번째 방법의 문제가 어느정도 해결이 될 것이라고 생각했습니다.
그래서 다음 방법으로 나름의 최적화를 시도했습니다.
1. 개발자가 작성한 Dockerfile을 기반으로 필요한 의존성 패키지를 추린다.
2. 리눅스 alpine(기본) 이미지를 기반으로 컨테이너를 생성하여 추려놓은 의존성 패키지를 모두 설치한다.
3. alpine 이미지에 모든 의존성 패키지가 설치된 상태를 이미지로 만들어 도커 허브에 업로드한다.
4. 젠킨스의 파이프라인에서 해당 이미지를 베이스로 빌드를 시작한다.
처음 이 방식을 고려했을때는 정말 시간이 빨라질까? 싶은 생각이 있었는데, 주먹구구식으로 의식의 흐름을 따라 진행한 것 치고는 매우 효과적이었습니다.
개선 이전에 10분 걸리던 빌드가 개인 컴퓨터에서 빌드했을때처럼 30초만에 완료되는 것이었습니다.
이 방법보다 더 좋은 방법도 당연하게 있을 것이라고 생각하고, 기존에 누구나 다 하던 방법을 시행착오를 거쳐가며 뒤늦게 깨달은 걸 수도 있습니다.
하지만 문제 해결 방법을 찾아 고심하는 그 과정 자체가 도움이 되었다고 생각하고, 유의미한 결과까지 도출되어 매우 만족스러운 경험이었습니다.
'CI CD' 카테고리의 다른 글
| QA 입장에서 CI/CD의 기초적인 세팅을 진행한 경험 (1) | 2024.08.06 |
|---|