InfoGrab Docs

작업 실행 속도 향상

요약

이미지와 의존성을 캐싱하여 작업 성능을 향상시킬 수 있습니다. 다음을 사용하여 Docker 이미지 다운로드 시간을 단축할 수 있습니다: 컨테이너 이미지에 더 빠르게 액세스하려면 의존성 프록시를 사용하여 컨테이너 이미지를 프록시할 수 있습니다.

이미지와 의존성을 캐싱하여 작업 성능을 향상시킬 수 있습니다.

컨테이너용 프록시 사용#

다음을 사용하여 Docker 이미지 다운로드 시간을 단축할 수 있습니다:

  • GitLab 의존성 프록시 또는
  • DockerHub 레지스트리 미러
  • 기타 오픈 소스 솔루션

GitLab 의존성 프록시#

컨테이너 이미지에 더 빠르게 액세스하려면 의존성 프록시를 사용하여 컨테이너 이미지를 프록시할 수 있습니다.

Docker Hub 레지스트리 미러#

Docker Hub를 미러링하여 작업이 컨테이너 이미지에 액세스하는 시간을 단축할 수도 있습니다. 이렇게 하면 풀 스루 캐시로서의 레지스트리가 됩니다. 작업 실행 속도 향상 외에도, 미러는 Docker Hub 장애 및 Docker Hub 속도 제한에 대해 인프라를 보다 탄력적으로 만들 수 있습니다.

Docker 데몬이 미러를 사용하도록 설정되면 미러의 실행 중인 인스턴스에서 이미지를 자동으로 확인합니다. 이미지가 없는 경우 공개 Docker 레지스트리에서 이미지를 가져와서 로컬로 저장한 다음 반환합니다.

동일한 이미지에 대한 다음 요청은 로컬 레지스트리에서 가져옵니다.

작동 방식에 대한 자세한 내용은 Docker 데몬 설정 문서를 참조하세요.

Docker Hub 레지스트리 미러 사용#

Docker Hub 레지스트리 미러를 생성하려면:

  1. 프록시 컨테이너 레지스트리가 실행될 전용 머신에 로그인합니다.

  2. 해당 머신에 Docker Engine이 설치되어 있는지 확인합니다.

  3. 새 컨테이너 레지스트리를 생성합니다:

    docker run -d -p 6000:5000 \
    -e REGISTRY_PROXY_REMOTEURL=https://registry-1.docker.io \
    --restart always \
    --name registry registry:2

    포트 번호(6000)를 수정하여 다른 포트에서 레지스트리를 노출할 수 있습니다. 이렇게 하면 http로 서버가 시작됩니다. TLS(https)를 활성화하려면 공식 문서를 따르세요.

  4. 서버의 IP 주소를 확인합니다:

    hostname --ip-address

    프라이빗 네트워크 IP 주소를 선택해야 합니다. 프라이빗 네트워크는 보통 DigitalOcean, AWS, Azure 같은 단일 제공업체에서 머신 간 내부 통신을 위한 가장 빠른 솔루션입니다. 일반적으로 프라이빗 네트워크에서 전송되는 데이터는 월별 대역폭 제한에 포함되지 않습니다.

Docker Hub 레지스트리는 MY_REGISTRY_IP:6000 아래에서 액세스할 수 있습니다.

이제 새 레지스트리 서버를 사용하도록 config.toml을 설정할 수 있습니다.

기타 오픈 소스 솔루션#

  • rpardini/docker-registry-proxy는 GitLab 컨테이너 레지스트리를 포함한 대부분의 컨테이너 레지스트리를 로컬로 프록시할 수 있습니다.

분산 캐시 사용#

캐시를 사용하여 언어 의존성을 다운로드하는 시간을 단축할 수 있습니다.

분산 캐시를 지정하려면, 캐시 서버를 설정한 다음 Runner가 해당 캐시 서버를 사용하도록 설정합니다.

자동 확장을 사용하는 경우 분산 Runner 캐시 기능에 대해 자세히 알아보세요.

지원되는 캐시 서버는 다음과 같습니다:

GitLab CI/CD 캐시 의존성 및 모범 사례에 대해 자세히 알아보세요.

AWS S3 사용#

분산 캐시로 AWS S3를 사용하려면, Runner의 config.toml 파일을 수정하여 S3 위치를 가리키고 연결 자격 증명을 제공합니다. Runner에서 S3 엔드포인트까지의 네트워크 경로가 있는지 확인합니다.

NAT 게이트웨이가 있는 프라이빗 서브넷을 사용하는 경우, 데이터 전송 비용을 절약하기 위해 S3 VPC 엔드포인트를 활성화할 수 있습니다.

MinIO 사용#

AWS S3 대신 자체 캐시 스토리지를 생성할 수 있습니다.

  1. 캐시 서버가 실행될 전용 머신에 로그인합니다.

  2. 해당 머신에 Docker Engine이 설치되어 있는지 확인합니다.

  3. Go로 작성된 간단한 S3 호환 서버인 MinIO를 시작합니다:

    docker run -d --restart always -p 9005:9000 \
        -v /.minio:/root/.minio -v /export:/export \
        -e "MINIO_ROOT_USER=<minio_root_username>" \
        -e "MINIO_ROOT_PASSWORD=<minio_root_password>" \
        --name minio \
        minio/minio:latest server /export

    포트 9005를 수정하여 다른 포트에서 캐시 서버를 노출할 수 있습니다.

  4. 서버의 IP 주소를 확인합니다:

    hostname --ip-address

  5. 캐시 서버는 MY_CACHE_IP:9005에서 사용할 수 있습니다.

  6. Runner가 사용할 버킷을 생성합니다:

    sudo mkdir /export/runner

    이 경우 runner가 버킷 이름입니다. 다른 버킷을 선택하면 이름이 달라집니다. 모든 캐시는 /export 디렉터리에 저장됩니다.

  7. Runner를 설정할 때 Access Key와 Secret Key로 위의 MINIO_ROOT_USER 및 MINIO_ROOT_PASSWORD 값을 사용합니다.

이제 새 캐시 서버를 사용하도록 config.toml을 설정할 수 있습니다.

Google Cloud Storage 사용#

분산 캐시로 Google Cloud Platform을 사용하려면, Runner의 config.toml 파일을 수정하여 GCP 위치를 가리키고 연결 자격 증명을 제공합니다. Runner에서 GCS 엔드포인트까지의 네트워크 경로가 있는지 확인합니다.

Azure Blob 스토리지 사용#

분산 캐시로 Azure Blob 스토리지를 사용하려면, Runner의 config.toml 파일을 수정하여 Azure 위치를 가리키고 연결 자격 증명을 제공합니다. Runner에서 Azure 엔드포인트까지의 네트워크 경로가 있는지 확인합니다.

캐시 및 아티팩트 전송 속도 향상#

다음 옵션으로 캐시 및 아티팩트 업로드 및 다운로드 성능을 향상시킬 수 있습니다.

백엔드별 runner 구성#

각 캐시 백엔드에는 자체 config.toml 섹션이 있습니다. 백엔드에 맞게 최적화하세요:

  • S3 구성: runner와 동일한 리전으로 BucketLocation을 설정합니다. 5GB보다 큰 아카이브를 위해 멀티파트 업로드 활성화에 RoleARN을 사용합니다. 기본 S3 v2 어댑터를 사용합니다(FF_USE_LEGACY_S3_CACHE_ADAPTER=true를 설정하지 마세요). runner가 버킷 리전에서 멀리 있는 경우 선택적으로 AWS S3 전송 가속을 위해 Accelerate = true를 활성화합니다.

  • Google Cloud Storage 구성: runner와 같거나 가장 가까운 리전의 버킷을 사용합니다.

  • Azure Blob 구성: runner와 같거나 가장 가까운 리전의 스토리지 계정을 사용합니다.

캐시 압축#

캐시 아카이브 및 다운로드 속도를 높이기 위해 더 빠른 압축을 사용합니다. 이로 인해 더 큰 아카이브가 생성됩니다. 작업 또는 CI/CD 변수에서 압축 옵션을 설정하세요:

변수 속도를 위한 권장 설정 설명
CACHE_COMPRESSION_LEVEL fastest 또는 fast CPU 사용량을 줄이고 업로드 또는 다운로드 속도를 향상시킵니다. 아카이브가 더 커집니다. 기본값은 default입니다.
CACHE_COMPRESSION_FORMAT zip zip은 보통 생성 속도가 더 빠릅니다. tarzstd는 압축률이 더 좋지만 속도가 느릴 수 있습니다.

.gitlab-ci.yml의 예시 구성:

variables:
  CACHE_COMPRESSION_LEVEL: fastest
  CACHE_COMPRESSION_FORMAT: zip

캐시 요청 타임아웃#

큰 캐시에서 타임아웃이 발생하는 경우 CACHE_REQUEST_TIMEOUT CI/CD 변수로 제한을 늘립니다(분 단위). 기본값은 10입니다. 이 설정은 전송 속도를 높이지 않지만 느리거나 큰 업로드 및 다운로드에서 실패를 방지합니다.

캐시 전송 버퍼 크기(처리량)#

캐시 다운로드 및 업로드는 단일 스트리밍 버퍼를 사용합니다. 더 큰 버퍼는 시스템 호출을 줄이고 처리량을 향상시킵니다. 특히 전송이 20~30 MB/s로 제한될 때 효과적입니다.

작업 환경 또는 CI/CD 변수에서 CACHE_TRANSFER_BUFFER_SIZE(바이트 단위)를 설정합니다. 기본값은 4 MiB(4194304)입니다.

8 MiB 예시 구성:

variables:
  CACHE_TRANSFER_BUFFER_SIZE: "8388608"

작업 실행 속도 향상

Tier: Free, Premium, Ultimate
Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated
원문 보기
요약

이미지와 의존성을 캐싱하여 작업 성능을 향상시킬 수 있습니다. 다음을 사용하여 Docker 이미지 다운로드 시간을 단축할 수 있습니다: 컨테이너 이미지에 더 빠르게 액세스하려면 의존성 프록시를 사용하여 컨테이너 이미지를 프록시할 수 있습니다.

이미지와 의존성을 캐싱하여 작업 성능을 향상시킬 수 있습니다.

컨테이너용 프록시 사용#

다음을 사용하여 Docker 이미지 다운로드 시간을 단축할 수 있습니다:

  • GitLab 의존성 프록시 또는
  • DockerHub 레지스트리 미러
  • 기타 오픈 소스 솔루션

GitLab 의존성 프록시#

컨테이너 이미지에 더 빠르게 액세스하려면 의존성 프록시를 사용하여 컨테이너 이미지를 프록시할 수 있습니다.

Docker Hub 레지스트리 미러#

Docker Hub를 미러링하여 작업이 컨테이너 이미지에 액세스하는 시간을 단축할 수도 있습니다. 이렇게 하면 풀 스루 캐시로서의 레지스트리가 됩니다. 작업 실행 속도 향상 외에도, 미러는 Docker Hub 장애 및 Docker Hub 속도 제한에 대해 인프라를 보다 탄력적으로 만들 수 있습니다.

Docker 데몬이 미러를 사용하도록 설정되면 미러의 실행 중인 인스턴스에서 이미지를 자동으로 확인합니다. 이미지가 없는 경우 공개 Docker 레지스트리에서 이미지를 가져와서 로컬로 저장한 다음 반환합니다.

동일한 이미지에 대한 다음 요청은 로컬 레지스트리에서 가져옵니다.

작동 방식에 대한 자세한 내용은 Docker 데몬 설정 문서를 참조하세요.

Docker Hub 레지스트리 미러 사용#

Docker Hub 레지스트리 미러를 생성하려면:

  1. 프록시 컨테이너 레지스트리가 실행될 전용 머신에 로그인합니다.

  2. 해당 머신에 Docker Engine이 설치되어 있는지 확인합니다.

  3. 새 컨테이너 레지스트리를 생성합니다:

    docker run -d -p 6000:5000 \
    -e REGISTRY_PROXY_REMOTEURL=https://registry-1.docker.io \
    --restart always \
    --name registry registry:2

    포트 번호(6000)를 수정하여 다른 포트에서 레지스트리를 노출할 수 있습니다. 이렇게 하면 http로 서버가 시작됩니다. TLS(https)를 활성화하려면 공식 문서를 따르세요.

  4. 서버의 IP 주소를 확인합니다:

    hostname --ip-address

    프라이빗 네트워크 IP 주소를 선택해야 합니다. 프라이빗 네트워크는 보통 DigitalOcean, AWS, Azure 같은 단일 제공업체에서 머신 간 내부 통신을 위한 가장 빠른 솔루션입니다. 일반적으로 프라이빗 네트워크에서 전송되는 데이터는 월별 대역폭 제한에 포함되지 않습니다.

Docker Hub 레지스트리는 MY_REGISTRY_IP:6000 아래에서 액세스할 수 있습니다.

이제 새 레지스트리 서버를 사용하도록 config.toml을 설정할 수 있습니다.

기타 오픈 소스 솔루션#

  • rpardini/docker-registry-proxy는 GitLab 컨테이너 레지스트리를 포함한 대부분의 컨테이너 레지스트리를 로컬로 프록시할 수 있습니다.

분산 캐시 사용#

캐시를 사용하여 언어 의존성을 다운로드하는 시간을 단축할 수 있습니다.

분산 캐시를 지정하려면, 캐시 서버를 설정한 다음 Runner가 해당 캐시 서버를 사용하도록 설정합니다.

자동 확장을 사용하는 경우 분산 Runner 캐시 기능에 대해 자세히 알아보세요.

지원되는 캐시 서버는 다음과 같습니다:

GitLab CI/CD 캐시 의존성 및 모범 사례에 대해 자세히 알아보세요.

AWS S3 사용#

분산 캐시로 AWS S3를 사용하려면, Runner의 config.toml 파일을 수정하여 S3 위치를 가리키고 연결 자격 증명을 제공합니다. Runner에서 S3 엔드포인트까지의 네트워크 경로가 있는지 확인합니다.

NAT 게이트웨이가 있는 프라이빗 서브넷을 사용하는 경우, 데이터 전송 비용을 절약하기 위해 S3 VPC 엔드포인트를 활성화할 수 있습니다.

MinIO 사용#

AWS S3 대신 자체 캐시 스토리지를 생성할 수 있습니다.

  1. 캐시 서버가 실행될 전용 머신에 로그인합니다.

  2. 해당 머신에 Docker Engine이 설치되어 있는지 확인합니다.

  3. Go로 작성된 간단한 S3 호환 서버인 MinIO를 시작합니다:

    docker run -d --restart always -p 9005:9000 \
        -v /.minio:/root/.minio -v /export:/export \
        -e "MINIO_ROOT_USER=<minio_root_username>" \
        -e "MINIO_ROOT_PASSWORD=<minio_root_password>" \
        --name minio \
        minio/minio:latest server /export

    포트 9005를 수정하여 다른 포트에서 캐시 서버를 노출할 수 있습니다.

  4. 서버의 IP 주소를 확인합니다:

    hostname --ip-address

  5. 캐시 서버는 MY_CACHE_IP:9005에서 사용할 수 있습니다.

  6. Runner가 사용할 버킷을 생성합니다:

    sudo mkdir /export/runner

    이 경우 runner가 버킷 이름입니다. 다른 버킷을 선택하면 이름이 달라집니다. 모든 캐시는 /export 디렉터리에 저장됩니다.

  7. Runner를 설정할 때 Access Key와 Secret Key로 위의 MINIO_ROOT_USER 및 MINIO_ROOT_PASSWORD 값을 사용합니다.

이제 새 캐시 서버를 사용하도록 config.toml을 설정할 수 있습니다.

Google Cloud Storage 사용#

분산 캐시로 Google Cloud Platform을 사용하려면, Runner의 config.toml 파일을 수정하여 GCP 위치를 가리키고 연결 자격 증명을 제공합니다. Runner에서 GCS 엔드포인트까지의 네트워크 경로가 있는지 확인합니다.

Azure Blob 스토리지 사용#

분산 캐시로 Azure Blob 스토리지를 사용하려면, Runner의 config.toml 파일을 수정하여 Azure 위치를 가리키고 연결 자격 증명을 제공합니다. Runner에서 Azure 엔드포인트까지의 네트워크 경로가 있는지 확인합니다.

캐시 및 아티팩트 전송 속도 향상#

다음 옵션으로 캐시 및 아티팩트 업로드 및 다운로드 성능을 향상시킬 수 있습니다.

백엔드별 runner 구성#

각 캐시 백엔드에는 자체 config.toml 섹션이 있습니다. 백엔드에 맞게 최적화하세요:

  • S3 구성: runner와 동일한 리전으로 BucketLocation을 설정합니다. 5GB보다 큰 아카이브를 위해 멀티파트 업로드 활성화에 RoleARN을 사용합니다. 기본 S3 v2 어댑터를 사용합니다(FF_USE_LEGACY_S3_CACHE_ADAPTER=true를 설정하지 마세요). runner가 버킷 리전에서 멀리 있는 경우 선택적으로 AWS S3 전송 가속을 위해 Accelerate = true를 활성화합니다.

  • Google Cloud Storage 구성: runner와 같거나 가장 가까운 리전의 버킷을 사용합니다.

  • Azure Blob 구성: runner와 같거나 가장 가까운 리전의 스토리지 계정을 사용합니다.

캐시 압축#

캐시 아카이브 및 다운로드 속도를 높이기 위해 더 빠른 압축을 사용합니다. 이로 인해 더 큰 아카이브가 생성됩니다. 작업 또는 CI/CD 변수에서 압축 옵션을 설정하세요:

변수 속도를 위한 권장 설정 설명
CACHE_COMPRESSION_LEVEL fastest 또는 fast CPU 사용량을 줄이고 업로드 또는 다운로드 속도를 향상시킵니다. 아카이브가 더 커집니다. 기본값은 default입니다.
CACHE_COMPRESSION_FORMAT zip zip은 보통 생성 속도가 더 빠릅니다. tarzstd는 압축률이 더 좋지만 속도가 느릴 수 있습니다.

.gitlab-ci.yml의 예시 구성:

variables:
  CACHE_COMPRESSION_LEVEL: fastest
  CACHE_COMPRESSION_FORMAT: zip

캐시 요청 타임아웃#

큰 캐시에서 타임아웃이 발생하는 경우 CACHE_REQUEST_TIMEOUT CI/CD 변수로 제한을 늘립니다(분 단위). 기본값은 10입니다. 이 설정은 전송 속도를 높이지 않지만 느리거나 큰 업로드 및 다운로드에서 실패를 방지합니다.

캐시 전송 버퍼 크기(처리량)#

캐시 다운로드 및 업로드는 단일 스트리밍 버퍼를 사용합니다. 더 큰 버퍼는 시스템 호출을 줄이고 처리량을 향상시킵니다. 특히 전송이 20~30 MB/s로 제한될 때 효과적입니다.

작업 환경 또는 CI/CD 변수에서 CACHE_TRANSFER_BUFFER_SIZE(바이트 단위)를 설정합니다. 기본값은 4 MiB(4194304)입니다.

8 MiB 예시 구성:

variables:
  CACHE_TRANSFER_BUFFER_SIZE: "8388608"