파이프라인 효율성
CI/CD 파이프라인은 GitLab CI/CD의 기본적인 구성 요소입니다. 파이프라인을 더 효율적으로 만들면 개발자의 시간을 절약할 수 있으며 다음과 같은 이점을 얻을 수 있습니다:
- DevOps 프로세스를 가속화합니다.
- 비용을 줄입니다.
- 개발 피드백 루프를 단축합니다.
새로운 팀이나 프로젝트가 느리고 비효율적인 파이프라인으로 시작하고 시행착오를 통해 구성을 개선하는 것은 흔한 일입니다. 더 나은 방법은 즉시 효율성을 향상시키는 파이프라인 기능을 사용하여 빠르게 소프트웨어 개발 수명주기를 단축하는 것입니다.
먼저 GitLab CI/CD 기초를 익히고 빠른 시작 가이드를 이해하는 것이 중요합니다.
병목 현상과 일반적인 실패 확인
비효율적인 파이프라인을 파악하는 가장 쉬운 지표는 작업, 단계의 실행 시간 및 파이프라인 전체 실행 시간입니다. 전체 파이프라인 실행 시간은 다음과 같은 요소에 많은 영향을 받습니다:
또한 GitLab 러너와 관련하여 주의할 사항은 다음과 같습니다:
- 러너의 가용성과 구성된 리소스
- 빌드 의존성 및 설치 시간
- 컨테이너 이미지 크기
- 네트워크 지연 및 느린 연결
불필요하게 자주 실패하는 파이프라인은 개발 수명주기를 늦추기도 합니다. 실패한 작업에서 문제가 있는 패턴을 찾아야 합니다:
- 임의로 실패하는 불안정한 단위 테스트 또는 신뢰할 수 없는 테스트 결과를 만드는 경우
- 코드 품질과 관련된 테스트 커버리지의 감소
- 안전하게 무시할 수 있는 실패이지만 파이프라인을 중지시키는 문제 있는 실패
- 긴 파이프라인의 끝에서 실패하는 테스트가 있는데, 이는 이른 시기에 있을 수 있으며, 지연된 피드백을 유발합니다.
파이프라인 분석
파이프라인 성능을 분석하여 효율성을 향상시킬 방법을 찾습니다. 분석을 통해 CI/CD 인프라의 잠재적인 차단 요소를 확인할 수 있습니다. 이에는 다음과 같은 사항을 분석하는 것이 포함됩니다:
- 작업 작업량
- 실행 시간의 병목 현상
- 전체 파이프라인 아키텍처
파이프라인 워크플로우를 이해하고 문서화하고 가능한 조치 및 변경사항에 대해 논의하는 것이 중요합니다. 파이프라인 리팩터링은 DevSecOps 수명주기의 팀 간 신중한 상호 작용이 필요할 수 있습니다.
파이프라인 분석은 비용 효율성 문제를 식별하는 데 도움이 될 수 있습니다. 예를 들어, 유료 클라우드 서비스에서 호스팅되는 러너가 CI/CD 파이프라인에 필요한 것보다 더 많은 리소스로 구성된 경우 비용을 낭비할 수 있습니다. 또한 충분한 리소스가 없어 실행 시간이 늘어나는 경우 시간을 낭비할 수 있습니다.
파이프라인 인사이트
파이프라인 성공 및 실행 시간 차트는 파이프라인 실행 시간과 실패한 작업 수에 대한 정보를 제공합니다.
단위 테스트, 통합 테스트, 엔드 투 엔드 테스트, 코드 품질 테스트 및 기타 테스트를 실행하여 문제를 자동으로 찾을 수 있습니다. 긴 실행 시간을 초래할 수 있는 많은 파이프라인 단계가 관련될 수 있습니다.
전반적인 실행 시간을 줄이기 위해 병렬로 다른 것들을 테스트하는 작업을 동일한 단계에서 실행하여 전반적인 실행 시간을 줄일 수 있습니다. 단점은 병렬 작업을 지원하기 위해 동시에 더 많은 러너가 필요하다는 것입니다.
GitLab의 테스트 수준은 많은 구성 요소가 관련된 복잡한 테스트 전략의 예시를 제공합니다.
방향성이 있는 비순환 그래프 (DAG) 시각화
방향성이 있는 비순환 그래프 (DAG) 시각화는 파이프라인의 크리티컬 패스를 분석하고 가능한 차단 요소를 이해하는 데 도움이 됩니다.
파이프라인 모니터링
전역 파이프라인 상태는 작업 및 파이프라인 실행 시간과 함께 모니터링할 수 있는 주요 지표입니다. CI/CD 분석은 파이프라인 상태를 시각적으로 나타냅니다.
인스턴스 관리자는 성능 메트릭 및 자가 모니터링에 대한 추가 정보에 액세스할 수 있습니다.
API에서 특정 파이프라인 건강 메트릭을 가져올 수 있습니다. 외부 모니터링 도구는 API를 폴링하여 파이프라인 건강을 확인하거나 장기간 SLA 분석을 위한 메트릭을 수집할 수 있습니다.
예를 들어, GitLab CI 파이프라인 익스포터는 Promtheus를 통해 API 및 파이프라인 이벤트에서 메트릭을 가져올 수 있습니다. 이를 통해 프로젝트의 브랜치를 자동으로 확인하고 파이프라인 상태와 실행 시간을 확인할 수 있습니다. Grafana 대시보드와 함께 사용하면 운영팀이 대시보드에서 실질적인 정보를 얻을 수 있습니다. 메트릭 그래프는 문제 해결을 용이하게 합니다. 또한 작업 및 환경에 대한 메트릭을 내보낼 수도 있습니다.
GitLab CI 파이프라인 익스포터를 사용하는 경우 예시 구성으로 시작해야 합니다.
또는 예를 들어, check_gitlab과 같이 스크립트를 실행할 수 있는 모니터링 도구를 사용할 수도 있습니다.
Runner monitoring
호스트 시스템에서 또는 Kubernetes와 같은 클러스터에서 CI 러너를 모니터링할 수도 있습니다. 이에는 다음이 포함됩니다:
- 디스크와 디스크 IO
- CPU 사용률
- 메모리
- 러너 프로세스 리소스
Prometheus Node Exporter는 Linux 호스트에서 러너를 모니터링할 수 있으며, kube-state-metrics는 Kubernetes 클러스터에서 실행됩니다.
또한 클라우드 제공업체와 함께 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 이미지는 많은 공간을 차지하고 느린 연결 속도로 다운로드하는 데 많은 시간이 걸릴 수 있습니다.
가능하다면 모든 작업에 대한 하나의 큰 이미지를 사용하지 말고 특정 작업에 대한 각각의 작은 이미지를 사용하여 더 빨리 다운로드하고 실행할 수 있습니다.
소프트웨어가 사전 설치된 커스텀 Docker 이미지를 사용하세요. 일반 이미지를 사용하고 매번 소프트웨어를 설치하는 것보다 더 큰 사전 구성된 이미지를 다운로드하는 것이 보통 훨씬 빠릅니다. Docker Dockerfile 작성을 위한 Best practices 기사에는 효율적인 Docker 이미지 작성에 대한 자세한 정보가 포함되어 있습니다.
Docker 이미지 크기를 줄이는 방법:
- 작은 베이스 이미지를 사용하세요. 예를 들어
debian-slim. - 엄격히 필요하지 않은 경우 vim이나 curl과 같은 편의 도구를 설치하지 마세요.
- 전용 개발 이미지를 만드세요.
- 공간을 절약하기 위해 패키지 설치 시 설치된 매뉴얼 페이지 및 문서를 비활성화하세요.
-
RUN계층을 줄이고 소프트웨어 설치 단계를 결합하세요. - 빌더 패턴을 사용하는 여러 Docker 파일을 하나의 Docker 파일로 병합하여 이미지 크기를 줄일 수 있는 다단계 빌드를 사용하세요.
-
apt를 사용하는 경우 불필요한 패키지를 피하기 위해--no-install-recommends를 추가하세요. - 이미 더 이상 필요하지 않은 캐시 및 파일을 정리하세요. 예를 들어, 데비안과 우분투의 경우
rm -rf /var/lib/apt/lists/*, RHEL과 CentOS의 경우yum clean all을 사용하세요. - 이미지를 분석하고 축소하기 위해 dive 또는 DockerSlim과 같은 도구를 사용하세요.
Docker 이미지 관리를 단순화하기 위해 Docker 이미지를 관리하는 전용 그룹을 생성하고 CI/CD 파이프라인을 통해 테스트, 빌드 및 게시할 수 있습니다.
테스트, 문서 작성 및 학습
파이프라인의 개선은 반복적인 과정입니다. 작은 변경을 가하고 영향을 모니터링한 후에 다시 반복하세요. 많은 작은 개선 사항이 파이프라인 효율성의 큰 증가로 이어질 수 있습니다.
파이프라인 설계와 아키텍처를 문서화하는 것이 도움이 될 수 있습니다. 이를 GitLab 리포지토리에서 마크다운의 Mermaid 차트를 사용하여 직접 할 수 있습니다.
CI/CD 파이프라인의 문제 및 사건을 이슈에 문서화하십시오. 이 과정에는 수행한 연구와 발견한 해결책이 포함되어야 합니다. 이는 새 팀 멤버를 온보딩하는 데 도움이 되며, 또한 CI 파이프라인 효율성과 관련된 반복적인 문제를 식별하는 데 도움이 됩니다.
도움말