CI 설정 성능

GitLab CI/CD 파이프라인의 성능 최적화 전략(인터럽트 가능 파이프라인, Git fetch 캐싱, 아티팩트 전략 등)을 설명합니다.

인터럽트 가능 파이프라인 # 기본적으로 모든 job은 인터럽트 가능 합니다. 단, dont-interrupt-me job은 예외로, main 에서는 자동으로 실행되고 그 외의 경우에는 manual 로 실행됩니다. 머지 리퀘스트에 새 커밋을 푸시하더라도 실행 중인 파이프라인이 완료되길 원한다면, 푸시하기 전에 반드시 dont-interrupt-me job을 시작하세요. Git fetch 캐싱 # GitLab.com은 pack-objects 캐시 를 사용하므로, 동일한 파이프라인 ref에 대한 동시 Git fetch 요청은 Gitaly 서버에서 중복 제거되며(항상), 캐시에서 제공됩니다(가능한 경우). 이 방식이 효과적인 이유는 다음과 같습니다: GitLab.com의 모든 Gitaly 서버에 pack-objects 캐시가 활성화되어 있습니다. gitlab-org/gitlab 의 CI/CD Git 전략 설정 이 Git clone 으로 설정되어 있어, 모든 job이 동일한 데이터를 fetch하므로 캐시 적중률이 최대화됩니다. shallow clone 을 사용하여 모든 job에서 전체 Git 히스토리를 다운로드하지 않아도 됩니다. Gitaly에서 클론/fetch 대신 아티팩트를 통해 리포지터리 fetch하기 # 최근 Gitaly에서 다음과 같은 오류가 발생하는 사례가 있었습니다: ( 이슈 참고 ) fatal: remote error: GitLab is currently unable to handle this request due to load. GitLab.com이 pack-objects 캐시 를 사용하더라도, 부하가 너무 높아 Gitaly가 처리하지 못하는 경우가 있습니다. 또한 동시에 많은 job이 리포지터리를 클론할 때 thundering herd 문제가 우려될 수 있습니다. Gitaly의 부하를 완화하고 줄이기 위해, 일부 job이 동시에 Gitaly에서 클론하는 방식 대신 job 내에서 아티팩트로부터 리포지터리를 fetch하도록 변경했습니다. 현재 이 방식은 대부분의 파이프라인에서 동시 job이 가장 많은 RSpec job에 적용됩니다. 아티팩트에서 fetch하는 것이 클론보다 약간 더 빠르기 때문에 속도도 소폭 향상되었지만, 각 파이프라인에 더 많은 아티팩트를 저장해야 합니다. 2023-12-20 기준 RSpec job용 아티팩트에서 리포지터리 fetch 의 수치에 따르면, 추가 스토리지 비용은 파이프라인당 약 280M이며, 각 RSpec job에서 15초를 절약할 수 있습니다. 다른 job 의존성이 없는 job에는 이 방식을 적용하지 않습니다. job 시작을 지연시키고 싶지 않기 때문입니다. 이 동작은 변수 CI_FETCH_REPO_GIT_STRATEGY 로 제어할 수 있습니다: none 으로 설정하면 .repo-from-artifacts 를 사용하는 job이 Gitaly에서 클론하는 대신 clone-gitlab-repo job의 아티팩트에서 리포지터리를 fetch합니다. clone 으로 설정하면 .repo-from-artifacts