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