파이프라인 효율성

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

CI/CD Pipelines는 GitLab CI/CD의 기본 빌딩 블록입니다.
파이프라인을 더 효율적으로 만드는 것은 개발자 시간을 절약하는 데 도움이 됩니다. 이는:

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

새로운 팀이나 프로젝트가 느리고 비효율적인 파이프라인으로 시작하는 것은 일반적이며, 시간이 지나면서 시행착오를 통해 구성을 개선합니다. 더 나은 프로세스는 즉시 효율성을 개선하는 파이프라인 기능을 사용하는 것이며, 더 빠른 소프트웨어 개발 수명 주기를 조기에 가져오는 것입니다.

먼저 GitLab CI/CD 기본을 숙지하고 빠른 시작 가이드를 이해하세요.

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

비효율적인 파이프라인에 대한 가장 쉬운 지표는 잡, 스테이지의 실행 시간, 그리고 파이프라인 자체의 총 실행 시간입니다. 총 파이프라인 소요 시간은 다음 요소들의 영향을 많이 받습니다:

추가적으로 주의해야 할 점은 GitLab Runners와 관련이 있습니다:

  • 러너의 가용성과 그들이 프로비저닝된 리소스.
  • 빌드 종속성, 설치 시간 및 저장 공간 요구 사항.
  • 컨테이너 이미지 크기.
  • 네트워크 지연 및 느린 연결.

불필요하게 자주 실패하는 파이프라인은 개발 수명 주기를 느리게 합니다. 실패한 잡과 관련된 문제 패턴을 찾아야 합니다:

  • 무작위로 실패하거나 신뢰할 수 없는 테스트 결과를 생성하는 불안정한 유닛 테스트.
  • 테스트 커버리지의 감소 및 해당 행동과 관련된 코드 품질.
  • 파이프라인을 중단시키지만 안전하게 무시할 수 있는 실패.
  • 긴 파이프라인의 마지막에서 실패하지만 더 이른 단계에서 발생할 수 있는 테스트로 인하여 피드백이 지연되는 경우.

파이프라인 분석

효율성을 개선할 방법을 찾기 위해 파이프라인 성능을 분석하세요. 분석은 CI/CD 인프라에서 가능한 차단 요소를 식별하는 데 도움이 될 수 있습니다. 여기에는 다음의 분석이 포함됩니다:

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

파이프라인 워크플로우를 이해하고 문서화하는 것이 중요하며, 가능한 조치 및 변경 사항에 대해 논의하세요. 파이프라인 리팩토링은 DevSecOps 수명 주기에서 팀 간의 신중한 상호 작용이 필요할 수 있습니다.

파이프라인 분석은 비용 효율성 문제를 식별하는 데 도움이 될 수 있습니다. 예를 들어, 유료 클라우드 서비스에서 호스팅된 러너는 다음과 같이 프로비저닝될 수 있습니다:

  • CI/CD 파이프라인에 필요 이상으로 더 많은 리소스를 할당하여 돈을 낭비합니다.
  • 리소스가 부족하여 느린 실행 시간을 초래하고 시간을 낭비합니다.

파이프라인 통찰력

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

유닛 테스트, 통합 테스트, 엔드 투 엔드 테스트,
코드 품질 테스트 및 기타 테스트는 CI/CD 파이프라인에서 문제가 자동으로 발견되도록 보장합니다. 긴 실행 시간을 유발하는 많은 파이프라인 스테이지가 있을 수 있습니다.

동일한 단계에서 서로 다른 것을 테스트하는 잡을 병렬로 실행하면 실행 시간을 개선할 수 있습니다. 단점은 병렬 잡을 지원하기 위해 더 많은 러너가 동시에 실행되어야 한다는 점입니다.

GitLab의 테스트 수준은 많은 구성 요소가 관련된 복잡한 테스트 전략의 예를 제공합니다.

needs 의존성 시각화

풀 파이프라인 그래프에서 needs 의존성을 보기하면

파이프라인의 주요 경로를 분석하고 가능한 차단 요소를 이해하는 데 도움이 됩니다.

파이프라인 모니터링

전 세계 파이프라인 건강은 작업 및 파이프라인 소요 시간과 함께 모니터링해야 할 주요 지표입니다.

CI/CD 분석은 파이프라인 건강에 대한 시각적 표현을 제공합니다.

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

특정 파이프라인 건강 지표를 API에서 가져올 수 있습니다.

외부 모니터링 도구는 API를 폴링하여 파이프라인 건강을 확인하거나

장기 SLA 분석을 위한 지표를 수집할 수 있습니다.

예를 들어, GitLab CI Pipelines Exporter는

Prometheus에 대한 지표를 API 및 파이프라인 이벤트에서 가져옵니다.

이 도구는 프로젝트 내에서 브랜치를 자동으로 체크하고 파이프라인 상태와 소요 시간을 얻을 수 있습니다.

Grafana 대시보드와 결합하면,

운영 팀을 위한 실행 가능한 뷰를 구축하는 데 도움이 됩니다. 메트릭 그래프는 또한

사고에 삽입될 수 있어 문제 해결을 쉽게 만듭니다. 또한 작업 및 환경에 대한 지표도 내보낼 수 있습니다.

GitLab CI Pipelines Exporter를 사용하는 경우, 예제 구성으로 시작해야 합니다.

GitLab CI Pipelines Prometheus Exporter를 위한 Grafana 대시보드

대안으로 check_gitlab와 같이 스크립트를 실행할 수 있는 모니터링 도구를 사용할 수 있습니다.

러너 모니터링

호스트 시스템이나 Kubernetes와 같은 클러스터에서 CI 러너를 모니터링할 수도 있습니다.

여기에는 다음을 확인하는 것이 포함됩니다:

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

Prometheus Node Exporter는 리눅스 호스트에서 러너를 모니터링할 수 있으며,

kube-state-metrics는 Kubernetes 클러스터에서 실행됩니다.

클라우드 제공업체와 함께 GitLab 러너 자동 스케일링을 테스트하고

비용을 줄이기 위해 오프라인 시간을 정의할 수 있습니다.

대시보드 및 사고 관리

기존 모니터링 도구와 대시보드를 사용하여 CI/CD 파이프라인 모니터링을 통합하거나,

처음부터 새로 구축하세요. 실행 시간 데이터가 팀에서 실행 가능하고 유용하며

운영/사고 대응 팀(SRE)이 문제를 조기에 파악할 수 있도록 해야 합니다.

사고 관리도 여기에서 도움이 될 수 있으며,

통합된 메트릭 차트와 문제 분석에 필요한 모든 세부 정보를 제공합니다.

저장소 사용

비용과 효율성을 분석하는 데 도움이 되도록 다음의 저장소 사용을 검토하세요:

파이프라인 구성

파이프라인을 구성할 때 신중한 선택을 하여 파이프라인 속도를 높이고

자원 사용을 줄이세요. 여기에는 파이프라인을 더 빠르고 효율적으로 실행할 수 있게 해주는 GitLab CI/CD의 내장 기능을 활용하는 것이 포함됩니다.

작업 실행 빈도 줄이기

모든 상황에서 실행할 필요가 없는 작업을 찾아, 파이프라인 구성을 사용하여 실행을 중지하세요:

  • interruptible 키워드를 사용하여 더 새로운 파이프라인에 의해 대체될 때 이전 파이프라인을 중지합니다.

  • 필요한 테스트를 건너뛰기 위해 rules를 사용합니다. 예를 들어, 프론트엔드 코드가 변경된 경우 백엔드 테스트를 건너뜁니다.

  • 비필수 예약된 파이프라인을 덜 자주 실행합니다.

  • cron schedules를 시간에 맞게 고르게 분배합니다.

빠른 실패

CI/CD 파이프라인에서 오류가 조기에 감지되도록 합니다. 완료하는 데 너무 오랜 시간이 걸리는 작업은 작업이 완료될 때까지 파이프라인이 실패 상태로 돌아갈 수 없게 합니다.

빠른 실패를 할 수 있는 작업이 더 빨리 실행되도록 파이프라인을 설계하세요. 예를 들어, 초기 단계를 추가하고 문법, 스타일 린팅, Git 커밋 메시지 검증 및 유사한 작업을 그곳으로 이동합니다.

긴 작업이 빠른 작업의 피드백 전에 조기에 실행되는 것이 중요한지 결정합니다. 초기 실패는 나머지 파이프라인이 실행되지 않아야 함을 명확하게 할 수 있으며, 파이프라인 자원을 절약합니다.

needs 키워드

기본 구성에서는 작업이 항상 이전 단계의 모든 다른 작업이 완료될 때까지 기다립니다. 이는 가장 간단한 구성 방법이지만 대부분의 경우 가장 느린 방법이기도 합니다. needs 키워드가 있는 파이프라인과 부모/자식 파이프라인은 더 유연하고 효율적일 수 있지만, 파이프라인을 이해하고 분석하는 것을 더 어렵게 만들 수 있습니다.

캐싱

또 다른 최적화 방법은 의존성을 캐시하는 것입니다. 만약 당신의 의존성이 드물게 변경된다면, NodeJS /node_modules와 같이 캐싱은 파이프라인 실행을 훨씬 빠르게 만들 수 있습니다.

작업이 실패해도 다운로드된 의존성을 캐시하려면 cache:when를 사용할 수 있습니다.

도커 이미지

도커 이미지를 다운로드하고 초기화하는 것은 작업의 전체 실행 시간의 큰 부분이 될 수 있습니다.

도커 이미지가 작업 실행 속도를 늦추고 있다면, базового изображения 크기와 레지스트리에 대한 네트워크 연결을 분석하세요. GitLab이 클라우드에서 실행되고 있다면, 공급자가 제공하는 클라우드 컨테이너 레지스트리를 찾으세요. 또한, GitLab 인스턴스에서 다른 레지스트리보다 빠르게 액세스할 수 있는 GitLab 컨테이너 레지스트리를 활용할 수 있습니다.

도커 이미지 최적화

대형 도커 이미지는 많은 공간을 차지하고 느린 연결 속도에서 다운로드하는 데 오랜 시간이 걸리므로 최적화된 도커 이미지를 빌드하세요. 가능하다면, 모든 작업에 대해 하나의 대형 이미지를 사용하는 것을 피하십시오. 각각 특정 작업을 위해 여러 개의 더 작은 이미지를 사용하여 더 빨리 다운로드하고 실행하도록 합니다.

사전 설치된 소프트웨어가 포함된 커스텀 도커 이미지를 사용하는 것이 좋습니다. 일반 이미지를 사용하고 매번 그 위에 소프트웨어를 설치하는 것보다 미리 구성된 대형 이미지를 다운로드하는 것이 훨씬 빠릅니다. 도커 Dockerfiles 작성 시 모범 사례에 대한 기사를 통해 효율적인 도커 이미지를 제작하는 방법에 대한 더 많은 정보를 확인할 수 있습니다.

도커 이미지 크기를 줄이는 방법:

  • 작은 기본 이미지를 사용하세요. 예: debian-slim.

  • 엄격하게 필요하지 않은 경우 vim 또는 curl과 같은 편의 도구는 설치하지 마세요.

  • 전용 개발 이미지를 생성하세요.

  • 공간을 절약하기 위해 패키지에 의해 설치된 매뉴얼 페이지와 문서를 비활성화하세요.

  • RUN 레이어를 줄이고 소프트웨어 설치 단계를 결합하세요.

  • 여러 도커파일을 통합하기 위해 다중 단계 빌드를 사용하여 이미지를 줄일 수 있습니다.

  • 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 파이프라인 효율성과 관련된 반복 문제를 식별하는 데에도 도움을 줍니다.

관련 주제