파이프라인 효율성
CI/CD 파이프라인은 GitLab CI/CD의 기본적인 컴포넌트입니다. 파이프라인을 더 효율적으로 만들면 개발자 시간을 절약할 수 있으며, 이를 통해:
- DevOps 프로세스를 가속화시킵니다.
- 비용을 줄입니다.
- 개발 피드백 루프를 단축합니다.
새로운 팀이나 프로젝트가 천천히 움직이고 비효율적인 파이프라인으로 시작하고 시간이 지날수록 수행중에 시행착오를 거쳐 구성을 개선하는 것은 흔한 일입니다. 더 나은 프로세스는 즉시 효율성을 향상시키는 파이프라인 기능을 사용하고 좀 더 빠른 소프트웨어 개발 라이프사이클을 빨리 구현하는 것입니다.
먼저 GitLab CI/CD 기초를 이해하고 빠른 시작 가이드를 확인하세요.
병목 현상과 일반적인 실패 식별
비효율적인 파이프라인을 확인하는 가장 쉬운 지표는 작업, 단계, 그리고 파이프라인 전체의 실행 시간입니다. 총 파이프라인 기간은 다음과 같은 요소에 크게 영향을 받습니다:
GitLab Runners와 관련된 추가적인 사항은 다음과 같습니다:
- 러너의 가용성 및 할당된 자원.
- 빌드 의존성 및 설치 시간.
- 컨테이너 이미지 크기.
- 네트워크 지연 및 느린 연결.
불필요하게 자주 실패하는 파이프라인은 개발 라이프사이클에서 느림이 발생합니다. 실패한 작업과 관련된 문제 있는 패턴을 찾아야 합니다:
- 무작위로 실패하는 불안정한 단위 테스트 또는 신뢰할 수 없는 테스트 결과를 생성하는 테스트.
- 테스트 커버리지가 낮아져 그에 관련된 코드 품질이 하락함.
- 안전하게 무시될 수 있는 실패지만 파이프라인을 중지시키는 실패.
- 파이프라인 마지막에 실패하는 테스트지만 이전 단계에서도 실패할 수 있으며 이는 지연된 피드백을 유발합니다.
파이프라인 분석
효율성을 향상하는 방법을 찾기 위해 파이프라인 성능을 분석하세요. 이를 통해 CI/CD 인프라에서의 잠재적인 방해 요소를 식별할 수 있습니다. 분석 사항은 다음을 포함합니다:
- 작업 작업량.
- 실행 시간의 병목 현상.
- 전체 파이프라인 아키텍처.
파이프라인 워크플로우를 이해하고 문서화하고 가능한 조치 및 변경 사항에 대해 토의하는 것이 중요합니다. 파이프라인 리팩터링은 DevSecOps 라이프사이클에서의 팀 간 조심스러운 상호작용이 필요할 수 있습니다.
파이프라인 분석을 통해 비용 효율성 문제를 식별할 수 있습니다. 예를 들어, 유료 클라우드 서비스에 호스팅된 러너(runner)가 CI/CD 파이프라인에 필요한 것보다 더 많은 자원을 할당받아 돈을 낭비할 수 있습니다. 또한 충분한 자원이 없어 실행 시간이 느려지고 시간을 낭비합니다.
파이프라인 인사이트
파이프라인 성공 및 기간 차트는 파이프라인 실행 시간과 실패한 작업 수에 대한 정보를 제공합니다.
단위 테스트, 통합 테스트, 종단 간 테스트, 코드 품질 테스트 및 기타 테스트는 CI/CD 파이프라인에서 문제가 자동으로 발견되도록 보장합니다. 실행 시간이 오래 걸릴 수 있는 여러 파이프라인 단계가 있을 수 있습니다.
동일한 단계에서 병렬로 다른 작업을 테스트하는 작업을 실행함으로써 전반적인 실행 시간을 줄일 수 있습니다. 단점은 병렬 작업을 지원하기 위해 동시에 실행되는 러너가 더 필요하다는 것입니다.
GitLab의 테스트 레벨은 많은 컴포넌트가 관련될 수 있는 복잡한 테스트 전략의 예시를 제공합니다.
방향성 비순환 그래프(DAG) 시각화
방향성 비순환 그래프 (DAG) 시각화는 파이프라인의 중요 경로를 분석하고 가능한 방해 요소를 이해하는 데 도움이 될 수 있습니다.
파이프라인 모니터링
전역 파이프라인 상태는 작업 및 파이프라인 기간과 함께 모니터링할 수 있는 중요한 지표입니다. CI/CD 분석은 파이프라인 상태의 시각적 표현을 제공합니다.
인스턴스 관리자는 추가적인 성능 지표 및 자가 모니터링에 액세스할 수 있습니다.
특정 파이프라인 상태 메트릭을 API에서 가져올 수 있습니다. 외부 모니터링 도구는 API를 폴링하여 파이프라인 상태를 확인하거나 장기간 SLA 분석을 위한 메트릭을 수집할 수 있습니다.
예를 들어 GitLab CI 파이프라인 Exporter는 Prometheus에서 메트릭을 가져와 API와 파이프라인 이벤트를 확인할 수 있습니다. 프로젝트의 브랜치를 자동으로 확인하고 파이프라인 상태와 기간을 얻을 수 있습니다. Grafana 대시보드와 함께 사용하면 운영팀이 실질적인 시각을 구축하는 데 도움이 됩니다. 메트릭 그래프를 재해에 포함하여 문제 해결을 쉽게 할 수 있습니다. 또한 작업 및 환경에 대한 메트릭을 내보낼 수도 있습니다.
만약 GitLab CI 파이프라인 Exporter를 사용한다면, 예시 구성으로 시작해야 합니다.
또한 check_gitlab과 같은 스크립트를 실행할 수 있는 모니터링 도구를 사용할 수 있습니다.
러너 모니터링
호스트 시스템이나 쿠버네티스와 같은 클러스터에서 CI 러너 모니터링을 할 수 있습니다. 이는 다음을 확인합니다:
- 디스크 및 디스크 IO
- CPU 사용량
- 메모리
- 러너 프로세스 리소스
Prometheus 노드 Exporter는 Linux 호스트의 러너를 모니터링하고, kube-state-metrics는 쿠버네티스 클러스터에서 실행됩니다.
클라우드 공급자와 함께 GitLab 러너 자동 확장을 테스트하고 비용을 줄이기 위해 오프라인 시간을 정의할 수 있습니다.
대시보드 및 재해 관리
기존의 모니터링 도구와 대시보드를 사용하여 CI/CD 파이프라인 모니터링을 통합하거나 처음부터 만들 수 있습니다. 런타임 데이터가 팀 내에서 실질적이고 유용하며 운영 및 SRE(사이트 신뢰성 엔지니어)가 문제를 미리 식별할 수 있어야 합니다. 여기에 재해 관리도 도움이 될 수 있으며, 삽입된 메트릭 차트와 문제를 분석하기 위한 모든 소중한 세부 정보가 있습니다.
리포지터리 사용량
다음의 리포지터리 사용량을 검토하여 비용 및 효율성을 분석하는 데 도움이 됩니다:
-
작업 아티팩트 및 그들의
expire_in구성. 오랫동안 보관되면 리포지터리 사용량이 증가하여 파이프라인이 느려질 수 있습니다. - 컨테이너 레지스트리 사용.
- 패키지 레지스트리 사용.
파이프라인 구성
파이프라인 구성 시 리소스 사용량을 줄이고 파이프라인을 가속화하기 위해 신중한 선택을 해야 합니다. 이에는 GitLab CI/CD의 내장 기능을 활용하여 파이프라인을 더 빠르고 효율적으로 실행하는 것이 포함됩니다.
작업 실행 빈도 줄이기
모든 상황에서 실행할 필요가 없는 작업을 찾고 파이프라인 구성을 사용하여 해당 작업을 실행하지 않도록합니다:
- 새로운 파이프라인에 의해 대체된 경우 이전 파이프라인을 중지하기 위해
interruptible키워드를 사용합니다. - 필요하지 않은 테스트를 건너뛰기 위해
rules를 사용합니다. 예를 들어, 백엔드 코드만 변경된 경우 백엔드 테스트를 건너뜁니다. - 비필수적인 예약 파이프라인을 덜 자주 실행합니다.
빠르게 실패하도록 설정
CI/CD 파이프라인에서 오류를 초기에 감지할 수 있도록합니다. 오랜 시간이 걸리는 작업은 해당 작업이 완료될 때까지 파이프라인이 실패한 상태를 반환하지 못하게 합니다.
작업을 빠르게 실패하도록 설정하여 파이프라인이 조기에 실패하도록합니다. 예를 들어 조기 단계를 추가하고 구문, 스타일 린팅, Git 커밋 메시지 확인 및 유사한 작업을 해당 단계로 이동시킵니다.
오래 걸리는 작업이 조기에 실행되어야 하는지 여부를 결정하고 빠른 작업으로부터 빠른 피드백을 받습니다. 초기 실패는 나머지 파이프라인이 실행되지 않아도 된다는 것을 명확하게 하여 파이프라인 리소스를 절약합니다.
유향 비순환 그래프 (DAG)
기본 구성에서는 작업이 실행되기 전에 항상 이전 단계의 모든 다른 작업을 기다립니다. 이것은 가장 간단한 구성이지만 대부분의 경우 가장 느립니다. 유향 비순환 그래프 및 상위/하위 파이프라인은 더 유연하고 효율적일 수 있지만 파이프라인을 이해하고 분석하기 어렵게 만들 수도 있습니다.
캐싱
다른 최적화 방법은 의존성을 캐시하는 것입니다. NodeJS /node_modules 와 같이 의존성이 드물게 변경될 때 캐싱은 파이프라인 실행을 훨씬 더 빠르게 만들 수 있습니다.
작업이 실패해도 이미 다운로드한 의존성을 캐시하려면 cache:when를 사용할 수 있습니다.
Docker 이미지
Docker 이미지의 다운로드 및 초기화는 작업의 전체 실행 시간 중 상당한 부분을 차지할 수 있습니다.
Docker 이미지가 작업 실행을 늦추면 기본 이미지 크기와 레지스트리로의 네트워크 연결을 분석합니다. GitLab이 클라우드에서 실행 중이라면 공급 업체가 제공하는 클라우드 컨테이너 레지스트리를 찾아보세요. 또한 GitLab 컨테이너 레지스트리를 활용하여 다른 레지스트리보다 빠르게 GitLab 인스턴스에 액세스할 수 있습니다.
Docker 이미지 최적화
큰 Docker 이미지는 많은 공간을 사용하고 느린 연결 속도로 다운로드하는 데 시간이 오래 걸립니다. 가능하다면 모든 작업에 대해 하나의 큰 이미지를 사용하지 말고 각각 특정 작업을 위한 여러 작은 이미지를 사용하여 더 빨리 다운로드하고 실행하는 것이 좋습니다.
설치를 자주하지 않는 경우라면 vim 또는 curl과 같은 편리한 도구를 설치하지 마십시오. 엄격하게 필요하지 않은 경우에만 apt를 사용할 경우 --no-install-recommends를 추가하여 불필요한 패키지를 피하십시오.
이미지 크기를 줄이는 방법:
- 작은 기본 이미지 사용, 예를 들어
debian-slim. - Debian 및 Ubuntu의 경우 공간을 절약하기 위해 패키지에 의해 설치된 man 페이지 및 문서를 비활성화합니다.
rm -rf /var/lib/apt/lists/*(Debian 및 Ubuntu),yum clean all(RHEL 및 CentOS)과 같은 명령어를 사용하여 불필요한 캐시 및 파일을 정리합니다. - dive 또는 DockerSlim과 같은 도구를 사용하여 이미지를 분석하고 축소합니다.
Docker 이미지 관리를 단순화하기 위해 Docker 이미지를 만들고 CI/CD 파이프라인으로 테스트, 빌드 및 공개를 관리하는 전용 그룹을 생성할 수 있습니다.
테스트, 문서 작성 및 학습
파이프라인을 개선하는 것은 반복적인 프로세스입니다. 작은 변경 사항을 가하고 효과를 모니터링한 후 다시 반복합니다. 작은 개선 사항이 모이면 파이프라인 효율성이 크게 향상될 수 있습니다.
파이프라인 디자인과 아키텍처에 대한 문서 작성을 도움이 될 수 있습니다. GitLab 리포지터리에서 Markdown 내의 Mermaid 차트를 사용하여 이를 수행할 수 있습니다.
CI/CD 파이프라인 문제 및 사고를 문서화하여 새로운 팀 멤버를 도입하는 데 도움을 주고 CI 파이프라인 효율성에 관한 반복적인 문제를 식별하는 데 도움이 됩니다.
도움말