리소스 그룹
기본적으로 GitLab CI/CD에서는 파이프라인이 병렬로 실행됩니다. 병렬 처리는 Merge Request에서 피드백 루프를 개선하는 데 중요한 요소이지만, 배포 작업에서 병렬 처리를 제한하고 순차적으로 실행하고자 하는 경우가 있습니다. 리소스 그룹을 사용하여 작업의 병렬 처리를 전략적으로 제어하여 지속적인 배포 워크플로우를 안전하게 최적화할 수 있습니다.
리소스 그룹 추가
다음과 같은 파이프라인 구성이 있다고 가정합니다(리포지터리의 .gitlab-ci.yml
파일):
build:
stage: build
script: echo "빌드 스크립트"
deploy:
stage: deploy
script: echo "배포 스크립트"
environment: production
브랜치에 새 커밋을 푸시할 때마다 빌드
및 배포
두 작업이 있는 새 파이프라인이 실행됩니다. 그러나 짧은 시간 간격으로 여러 커밋을 푸시하는 경우 여러 파이프라인이 동시에 실행됩니다. 예를 들어,
- 첫 번째 파이프라인은 작업
빌드
->배포
를 실행합니다. - 두 번째 파이프라인은 작업
빌드
->배포
를 실행합니다.
이 경우, 다른 파이프라인의 배포
작업이 동시에 production
환경으로 실행될 수 있습니다. 동일한 인프라에 대해 여러 배포 스크립트를 실행하면 최악의 경우 인스턴스를 손상시키고 오용시킬 수 있습니다.
배포
작업이 한 번에 한 번씩 실행되도록 하려면, 여러분은 병렬 처리에 민감한 작업에 resource_group
키워드를 지정할 수 있습니다:
deploy:
...
resource_group: production
이 구성으로 배포의 안전을 보장하면서도 여전히 빌드
작업을 병렬로 실행하여 파이프라인 효율성을 극대화할 수 있습니다.
전제 조건
- GitLab CI/CD 파이프라인에 대한 기본 지식
- GitLab 환경 및 배포에 대한 기본 지식
- 프로젝트에서 CI/CD 파이프라인을 구성하려면 적어도 개발자 역할이 있어야 합니다.
제한 사항
리소스 그룹에는 리소스가 하나만 연결될 수 있습니다.
프로세스 모드
배포 환경에 대한 작업 병렬 처리를 전략적으로 제어하기 위해 프로세스 모드를 선택할 수 있습니다. 다음과 같은 모드를 지원합니다:
-
순서 없음(
Unordered
): 작업의 병렬 처리를 제한하는 기본 프로세스 모드입니다. 작업의 실행 순서가 중요하지 않을 때 가장 쉽게 사용할 수 있는 옵션입니다. 작업이 실행 준비가 되면 즉시 작업을 처리합니다. -
가장 오래된 것 우선(
Oldest first
): 이 프로세스 모드는 작업의 병렬 처리를 제한합니다. 자원이 사용 가능하면 파이프라인 ID로 오름차순으로 정렬된 다가오는 작업 디렉터리(created
,scheduled
, 또는waiting_for_resource
상태)에서 첫 번째 작업을 선택합니다. 이 모드는 작업이 가장 오래된 파이프라인에서 실행되도록 보장할 때 효율적입니다. 파이프라인 효율성 측면에서순서 없음
모드보다 효율은 낮지만 지속적인 배포를 위해 더 안전합니다. -
가장 최근 것 우선(
Newest first
): 이 프로세스 모드는 작업의 병렬 처리를 제한합니다. 자원이 사용 가능하면 파이프라인 ID로 내림차순으로 정렬된 다가오는 작업 디렉터리(created
,scheduled
, 또는waiting_for_resource
상태)에서 첫 번째 작업을 선택합니다. 이 모드는 작업이 가장 최근 파이프라인에서 실행되도록 보장하고 지난 배포 작업 방지 기능으로 모든 이전 배포 작업을 방지할 때 효율적입니다. 파이프라인 효율성 측면에서 가장 효율적인 옵션이지만 각 배포 작업이 멱등(idempotent)해야 합니다.
프로세스 모드 변경
리소스 그룹의 프로세스 모드를 변경하려면 API를 사용하여 기존 리소스 그룹 편집을 지정하는 요청을 보내야 합니다. 그때 process_mode
를 지정합니다.
unordered
oldest_first
newest_first
프로세스 모드 간의 차이점 예시
다음과 같은 .gitlab-ci.yml
을 고려해보겠습니다. 여기서 두 작업 빌드
및 배포
가 각각 자체 스테이지에서 실행되고, 배포
작업에는 production
리소스 그룹이 설정되어 있습니다:
build:
stage: build
script: echo "빌드 스크립트"
deploy:
stage: deploy
script: echo "배포 스크립트"
environment: production
resource_group: production
프로젝트에 세 개의 커밋이 짧은 간격으로 푸시된다면 거의 동시에 세 개의 파이프라인이 실행됩니다:
- 첫 번째 파이프라인은 작업
빌드
->배포
를 실행합니다. 이 배포 작업을배포-1
이라고 합시다. - 두 번째 파이프라인은 작업
빌드
->배포
를 실행합니다. 이 배포 작업을배포-2
라고 합시다. - 세 번째 파이포라인은 작업
빌드
->배포
를 실행합니다. 이 배포 작업을배포-3
이라고 합시다.
리소스 그룹의 프로세스 모드에 따라:
- 프로세스 모드가
unordered
로 설정되어 있으면:-
배포-1
,배포-2
,배포-3
은 동시에 실행되지 않습니다. - 작업 실행 순서에 대한 보장이 없습니다. 예를 들어,
배포-1
이배포-3
보다 빨리 실행될 수도, 나중에 실행될 수도 있습니다.
-
- 프로세스 모드가
oldest_first
로 설정되어 있으면:-
배포-1
,배포-2
,배포-3
은 동시에 실행되지 않습니다. -
배포-1
이 먼저 실행되고,배포-2
가 두 번째로,배포-3
이 마지막으로 실행됩니다.
-
- 프로세스 모드가
newest_first
로 설정되어 있으면:-
배포-1
,배포-2
,배포-3
은 동시에 실행되지 않습니다. -
배포-3
이 먼저 실행되고,배포-2
가 두 번째로,배포-1
이 마지막으로 실행됩니다.
-
프로젝트 수준에서 교차 프로젝트/상위-하위 파이프라인의 병렬 처리 제어
동시 실행에 민감한 하위 파이프라인에 resource_group
를 정의할 수 있습니다. trigger
키워드는 하위 파이프라인을 트리거하고
resource_group
키워드는 함께 사용할 수 있습니다. resource_group
은 배포 파이프라인의 병렬 처리를 효율적으로 제어하는 데 효과적이며, 다른 작업은 계속해서 병렬로 실행됩니다.
다음 예시에서 하나의 프로젝트에 두 개의 파이프라인 구성이 있습니다. 파이프라인이 실행되면 민감하지 않은 작업이 먼저 실행되고 다른 파이프라인의 병렬 실행에 영향을 받지 않습니다. 그러나 GitLab은 배포(하위) 파이프라인을 트리거하기 전에 다른 배포 파이프라인이 실행되지 않도록 보장합니다. 다른 배포 파이프라인이 실행 중이면 GitLab은 기다렸다가 새로운 파이프라인을 실행시킵니다.
# .gitlab-ci.yml (상위 파이프라인)
build:
stage: build
script: echo "빌드 중..."
test:
stage: test
script: echo "테스트 중..."
deploy:
stage: deploy
trigger:
include: deploy.gitlab-ci.yml
strategy: depend
resource_group: AWS-production
# deploy.gitlab-ci.yml (하위 파이프라인)
stages:
- provision
- deploy
provision:
stage: provision
script: echo "준비 중..."
deployment:
stage: deploy
script: echo "배포 중..."
environment: production
trigger
키워드와 함께 반드시 strategy: depend
를 정의해야 합니다. 이렇게 하면 하위 파이프라인이 끝날 때까지 잠금이 해제되지 않도록 보장합니다.
관련 주제
문제 해결
파이프라인 구성에서 데드락 방지
oldest_first
프로세스 모드는 작업을 파이프라인 순서대로 실행하도록 강제하기 때문에
다른 CI 기능과 잘 작동하지 않는 경우가 있습니다.
예를 들어, 동일한 리소스 그룹이 필요한 하위 파이프라인을 실행할 때 데드락이 발생할 수 있습니다. 다음은 잘못된 설정의 예입니다:
# 나쁨
test:
stage: test
trigger:
include: child-pipeline-requires-production-resource-group.yml
strategy: depend
deploy:
stage: deploy
script: echo
resource_group: production
environment: production
상위 파이프라인에서 test
작업을 실행한 후에 하위 파이프라인을 실행하며,
strategy: depend
옵션 때문에 test
작업은 하위 파이프라인이 완료될 때까지 기다립니다.
상위 파이프라인은 다음 단계에서 production
리소스 그룹에서 리소스를 필요로 하는 deploy
작업을 실행합니다.
만워크플로 모드가 oldest_first
인 경우, 가장 오래된 파이프라인부터 작업을 실행하기 때문에 deploy
작업이 다음에 실행됩니다.
그러나 하위 파이프라인도 production
리소스 그룹에서 리소스를 필요로 합니다.
하위 파이프라인이 상위 파이프라인보다 더 최근에 생성되었기 때문에,
하위 파이프라인은 deploy
작업이 완료될 때까지 기다리는데, 이는 결코 발생하지 않는 상황입니다.
이 경우 상위 파이프라인 구성에서 resource_group
키워드를 명시적으로 지정해야 합니다:
# 좋음
test:
stage: test
trigger:
include: child-pipeline.yml
strategy: depend
resource_group: production # 상위 파이프라인에서 리소스 그룹을 지정
deploy:
stage: deploy
script: echo
resource_group: production
environment: production
작업이 “리소스 대기 중”에 멈추는 경우
가끔 작업이 리소스 대기 중: <resource_group>
메시지와 함께 멈출 수 있습니다. 이를 해결하려면,
먼저 리소스 그룹이 올바르게 작동하는지 확인하세요:
- 작업 세부 정보 페이지로 이동합니다.
-
리소스가 작업에 할당되었는지 확인하기 위해 현재 리소스 사용 중인 작업 보기를 선택하고 작업 상태를 확인합니다.
- 상태가
running
또는pending
인 경우, 해당 기능이 올바르게 작동하는 것입니다. 작업이 완료되고 리소스가 해제될 때까지 기다립니다. - 상태가
created
이고 프로세스 모드가 가장 오래된 것 먼저 또는 가장 최신 것 먼저인 경우, 해당 기능이 올바르게 작동하는 것입니다. 작업을 차단하는 상위 스테이지나 작업이 무엇인지 파이프라인 페이지에서 확인합니다. - 위의 조건 중 어느 것도 만족하지 않는 경우, 해당 기능이 올바르게 작동하지 않을 수 있습니다. GitLab에 문제 신고합니다.
- 상태가
-
만일 현재 리소스 사용 중인 작업 보기가 없다면, 리소스가 작업에 할당되지 않았습니다. 대신, 리소스의 예정된 작업을 확인합니다.
- REST API를 사용하여 리소스의 예정된 작업을 가져옵니다.
- 리소스 그룹의 프로세스 모드가 가장 오래된 것 먼저인지 확인합니다.
- 예정된 작업 디렉터리에서 첫 번째 작업을 찾고, GraphQL을 사용하여 작업 세부 정보를 가져옵니다.
- 첫 번째 작업의 파이프라인이 더 오래된 파이프라인인 경우, 해당 파이프라인 또는 작업 자체를 취소하려고 시도합니다.
- 선택 사항. 다음 예정된 작업이 여전히 더 오래된 파이프라인에 있는 경우 이 프로세스를 반복합니다.
- 문제가 계속되면, GitLab에 문제 신고합니다.
복잡하거나 바쁜 파이프라인에서의 경쟁 조건
위의 해결 방법으로 문제를 해결할 수 없는 경우, 이미 알려진 경쟁 조건 문제에 직면한 것일 수 있습니다. 경쟁 조건은 복잡하거나 바쁜 파이프라인에서 발생할 수 있습니다. 예를 들어, 다음과 같은 경우에 경쟁 조건이 발생할 수 있습니다:
- 여러 하위 파이프라인을 갖는 파이프라인.
- 동시에 여러 파이프라인이 실행되는 단일 프로젝트.
만일 이 문제를 경험 중이라면, GitLab에 문제 신고하고 새로운 문제에 대한 링크와 함께 issue 436988에 댓글을 남깁니다. 문제를 확인하려면 GitLab에서 프로젝트 전체 파이프라인 구성과 같은 추가 정보를 요청할 수 있습니다.
임시 해결 방법으로는 다음을 할 수 있습니다:
- 새로운 파이프라인을 시작합니다.
-
멈춰 있는 작업과 같은 리소스 그룹을 갖는 완료된 작업을 다시 실행합니다.
예를 들어, 동일한 리소스 그룹을 갖는
setup_job
과deploy_job
이 있는 경우,setup_job
이 “리소스 대기 중”에 멈춰 있는 동안setup_job
을 다시 실행하여 전체 프로세스를 다시 시작하고deploy_job
이 완료되도록 할 수 있습니다.
GraphQL을 통해 작업 세부 정보 가져오기
GraphQL API에서 작업 정보를 가져올 수 있습니다. 파이프라인 수준 동시성 제어와 교차 프로젝트/상위-하위 파이프라인을 사용하는 경우 UI에서 트리거 작업에 액세스할 수 없으므로 GraphQL API를 사용해야 합니다.
GraphQL API에서 작업 정보를 가져오려면:
- 파이프라인 세부 정보 페이지로 이동합니다.
- 작업 탭을 선택하고 멈춰 있는 작업의 ID를 찾습니다.
- 대화형 GraphQL 탐색기로 이동합니다.
-
다음 쿼리를 실행합니다:
{ project(fullPath: "<프로젝트의 전체 경로>") { name job(id: "gid://gitlab/Ci::Build/<작업-id>") { name status detailedStatus { action { path buttonTitle } } } } }
job.detailedStatus.action.path
필드는 리소스를 사용하는 작업 ID를 포함합니다. -
다음 쿼리를 실행하고 위의 기준에 따라
job.status
필드를 확인합니다.pipeline.path
필드에서 파이프라인 페이지를 방문할 수도 있습니다.{ project(fullPath: "<프로젝트의 전체 경로>") { name job(id: "gid://gitlab/Ci::Build/<현재 리소스를 사용 중인 작업의-id>") { name status pipeline { path } } } }
문제 신고
다음 정보와 함께 새로운 문제를 엽니다:
- 영향 받는 작업의 ID.
- 작업 상태.
- 문제가 발생하는 빈도.
- 문제를 재현하는 단계.
더 많은 지원이나 개발 팀과 연락하려면 지원에 문의할 수도 있습니다.