파이프라인 효율성

Tier: Free, Premium, Ultimate Offering: GitLab.com, Self-managed, GitLab Dedicated

CI/CD 파이프라인은 GitLab CI/CD의 기본적인 구성 요소입니다.
파이프라인을 더 효율적으로 만들면 개발자 시간을 절약할 수 있으며 다음과 같은 이점이 있습니다.

  • DevOps 프로세스를 가속화합니다.
  • 비용을 줄입니다.
  • 개발 피드백 루프를 단축합니다.

새로운 팀 또는 프로젝트가 느립니다 또는 비효율적인 파이프라인으로 시작하고, 시간이 지남에 따라 구성을 개선하는 것은 일반적입니다.
더 나은 프로세스는 즉시 효율성을 높이는 파이프라인 기능을 사용하고, 빠른 소프트웨어 개발 라이프사이클을 빠르게 얻는 것입니다.

먼저, GitLab CI/CD 기초를 익히고 빠른 시작 가이드를 이해하는 것이 중요합니다.

병목 현상과 일반적인 실패 식별

비효율적인 파이프라인의 가장 쉬운 지표는 작업, 단계, 그리고 파이프라인 전체의 실행 시간입니다.
파이프라인의 총 실행 시간은 다음과 관련이 있습니다.

  • 저장소 크기
  • 단계와 작업의 총 수
  • 작업 간의 의존성
  • 파이프라인의 “중요 경로”, 즉 파이프라인의 최소 및 최대 실행 시간을 나타냅니다.

GitLab Runners와 관련된 추가 사항은 다음과 같습니다.

  • 러너의 가용성과 할당된 리소스
  • 빌드 의존성, 설치 시간 및 저장 공간 요구 사항
  • 컨테이너 이미지 크기
  • 네트워크 지연 및 느린 연결

파이프라인이 불필요하게 자주 실패하면 개발 라이프사이클이 지연됩니다. 실패한 작업과 관련된 문제점을 살펴보아야 합니다.

  • 랜덤으로 실패하는 불안정한 단위 테스트 또는 신뢰할 수 없는 테스트 결과
  • 테스트 커버리지 감소 및 해당 동작과 관련된 코드 품질
  • 안전하게 무시할 수 있는 실패지만 파이프라인을 중단시키는 실패
  • 긴 파이프라인 끝에서 실패하는 테스트지만 조기 단계에 있을 수 있는 실패로 인해 지연된 피드백

파이프라인 분석

파이프라인의 성능을 분석하여 효율성을 높일 방법을 찾습니다. 분석을 통해 CI/CD 인프라에서 가능한 차단 요소를 식별할 수 있습니다. 이에는 다음이 포함됩니다.

  • 작업 작업량
  • 실행 시간의 병목 현상
  • 전체 파이프라인 아키텍처

파이프라인 워크플로우를 이해하고 문서화하고 가능한 조치와 변화에 대해 논의하는 것이 중요합니다. 파이프라인 리팩터링은 DevSecOps 라이프사이클의 팀 간 조심스러운 상호 작용이 필요할 수 있습니다.

파이프라인 분석을 통해 비용 효율성 문제를 식별할 수 있습니다. 예를 들어, 유료 클라우드 서비스로 호스팅된 런너들은 다음과 같은 리소스로 할당될 수 있습니다.

  • CI/CD 파이프라인에 필요한 것보다 더 많은 리소스로 낭비
  • 충분하지 않은 리소스로 인해 실행 시간이 느리고 시간이 낭비

파이프라인 인사이트

파이프라인 성공 및 실행 시간 차트는 파이프라인 실행 시간 및 실패한 작업 수에 대한 정보를 제공합니다.

유닛 테스트, 통합 테스트, 종단 간 테스트, 코드 품질 테스트 등과 같이 유형별 테스트가 자동으로 문제를 발견하도록 보장합니다. 긴 실행 시간을 유발하는 여러 파이프라인 단계가 있을 수 있습니다.

단일 단계에서 서로 다른 것을 테스트하는 작업을 병렬로 실행하여 전체 실행 시간을 줄일 수 있습니다. 그러나 이 경우 전체 실행 시간을 줄이기 위해 동시에 더 많은 작업을 실행해야 합니다.

needs 의존성 시각화

전체 파이프라인 그래프에서 needs 의존성을 보는 것은 파이프라인의 중요 경로를 분석하고 가능한 차단 요소를 이해하는 데 도움이 됩니다.

파이프라인 모니터링

전역 파이프라인 상태는 작업 및 파이프라인 실행 시간과 함께 모니터링할 주요 지표입니다. CI/CD 분석은 파이프라인 상태를 시각적으로 나타냅니다.

인스턴스 관리자는 추가적인 성능 지표 및 자가 모니터링에 액세스할 수 있습니다.

API에서 구체적인 파이프라인 상태 메트릭을 가져올 수 있습니다. 외부 모니터링 도구를 사용하여 장기간 SLA(서비스 수준 계약) 분석을 수행하거나 파이프라인 상태를 확인할 수 있습니다.

예를 들어, GitLab CI 파이프라인 익스포터는 API 및 파이프라인 이벤트에서 메트릭을 가져올 수 있습니다. 이는 프로젝트의 브랜치를 자동으로 확인하고 파이프라인 상태 및 실행 시간을 가져올 수 있습니다. Grafana 대시보드와 조합하여 운영팀이 취할 조치를 빌드하는 데 도움이 됩니다. 지표 그래프는 문제 해결이 쉬워지도록 인시던트에 통합될 수 있습니다. 또한 작업 및 환경에 대한 메트릭을 내보낼 수도 있습니다.

GitLab CI 파이프라인 익스포터를 사용하려면 예제 구성을 사용해야 합니다.

GitLab CI 파이프라인 Prometheus 익스포터를 위한 Grafana 대시보드

또는 예를 들어 check_gitlab과 같이 스크립트를 실행할 수 있는 모니터링 도구를 사용할 수도 있습니다.

런너 모니터링

호스트 시스템 또는 쿠버네티스와 같은 클러스터에서 CI 러너를 모니터링할 수 있습니다. 이는 다음을 확인합니다.

  • 디스크 및 디스크 IO
  • CPU 사용량
  • 메모리
  • 러너 프로세스 리소스

Prometheus Node Exporter는 리눅스 호스트에서 러너를 모니터링할 수 있으며, kube-state-metrics는 쿠버네티스 클러스터에서 실행됩니다.

클라우드 공급자와 함께 GitLab 러너 자동 확장을 테스트할 수도 있으며, 비용을 줄이기 위해 오프라인 시간을 정의할 수도 있습니다.

대시보드 및 인시던트 관리

기존 모니터링 도구 및 대시보드를 사용하여 CI/CD 파이프라인 모니터링을 통합하거나 처음부터 작성할 수 있습니다. 실행 데이터가 팀에서 실제로 사용 가능하고 유용한지 확인하고 운영/SRE가 문제를 빠르게 식별할 수 있도록 합니다. 인시던트 관리도 여기에 도움을 줄 수 있으며, 채택 가능한 메트릭 차트 및 문제를 분석하는 데 유용한 모든 가치 있는 세부 정보가 포함됩니다.

저장 공간 사용

다음의 저장 공간 사용을 검토하여 비용 및 효율성을 분석하는 데 도움을 줍니다:

파이프라인 구성

파이프라인 구성 시 리소스 사용량을 줄이고 파이프라인 실행 속도를 높이기 위해 신중한 선택을 합니다. 이에는 파이프라인 실행을 더 빠르고 효율적으로 만드는 GitLab CI/CD의 내장 기능을 활용하는 것이 포함됩니다.

작업 실행 빈도 줄이기

모든 상황에서 실행할 필요가 없는 작업을 찾아서 파이프라인 구성을 사용하여 이러한 작업이 실행되지 않도록 합니다:

  • interruptible 키워드를 사용하여 구식 파이프라인이 새로운 파이프라인에 의해 대체될 때 중단합니다.
  • 필요하지 않은 테스트를 건너뛰도록 rules를 사용합니다. 예를 들어, 프런트엔드 코드만 변경된 경우 백엔드 테스트를 건너뜁니다.
  • 비필수 예약된 파이프라인을 덜 자주 실행합니다.
  • cron 스케줄을 시간적으로 고르게 분산합니다.

빠른 실패

CI/CD 파이프라인에서 오류를 초기에 감지하도록 합니다. 매우 오랜 시간이 걸리는 작업은 작업이 완료될 때까지 파이프라인이 실패 상태를 반환하지 못하게 합니다.

작업을 빠른 실패할 수 있도록 디자인하여 가능한 빨리 실행되게 합니다. 예를 들어, 초기 단계를 추가하고 구문, 스타일 린팅, Git 커밋 메시지 확인 등의 작업을 거기로 이동합니다.

중요한 긴 작업이 빠른 작업에서 빠른 피드백을 받은 후 실행되어야 하는지 결정하세요. 초기 실패는 나머지 파이프라인이 실행되지 않아도 된다는 것을 명확히 할 수 있도록 하여 파이프라인 리소스를 절약할 수 있습니다.

needs 키워드

기본 구성에서는 모든 작업이 실행되기 전에 이전 단계의 모든 다른 작업을 기다립니다. 이것은 가장 간단한 구성이지만 대부분의 경우 가장 느립니다. needs 키워드가 있는 파이프라인 및 상위/하위 파이프라인은 유연하고 효율적일 수 있지만 해당 파이프라인을 이해하고 분석하기 어렵게 할 수 있습니다.

캐싱

다른 최적화 방법 중 하나는 종속성을 캐시하는 것입니다. 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 레이어를 줄이고 소프트웨어 설치 단계를 결합합니다.
  • 빌더 패턴을 사용하는 여러 Dockerfile을 하나로 병합하는 다중 단계 빌드를 사용하여 이미지 크기를 줄일 수 있습니다.
  • apt를 사용하는 경우 불필요한 패키지를 피하기 위해 --no-install-recommends를 추가합니다.
  • Debian 및 Ubuntu의 경우 사용하지 않는 캐시 및 파일을 정리합니다. 예를 들어 Debian 및 Ubuntu의 경우 rm -rf /var/lib/apt/lists/*, RHEL 및 CentOS의 경우 yum clean all을 사용합니다.
  • 이미지를 분석하고 축소하는 데 도움이 되는 도구들인 dive 또는 DockerSlim과 같은 도구를 사용합니다.

Docker 이미지 관리를 간소화하기 위해, Docker 이미지를 관리하고 CI/CD 파이프라인으로 테스트하고 빌드하여 배포할 수 있는 전용 그룹을 만들 수 있습니다.

테스트, 문서 작성 및 학습

파이프라인의 개선은 순환적인 과정입니다. 작은 변경 사항을 가하고 효과를 모니터링한 후 다시 반복합니다. 많은 작은 개선 사항이 파이프라인 효율성의 큰 증가로 이어질 수 있습니다.

파이프라인 설계 및 아키텍처에 대한 문서화는 도움이 될 수 있습니다. GitLab 리포지토리 내에서 Markdown의 Mermaid 차트를 사용하여 이를 수행할 수 있습니다.

CI/CD 파이프라인의 문제 및 사건에 대한 문서화 및 해결책에 대한 문서화를 작성할 수 있습니다. 이것은 새로운 팀원을 유입시키는 데 도움이 될 뿐만 아니라 CI 파이프라인 효율성의 반복되는 문제를 식별하는 데도 도움이 됩니다.

관련 주제