오토스케일 기능을 사용하면 리소스를 더 탄력적이고 동적인 방식으로 활용할 수 있습니다.

GitLab Runner는 오토스케일할 수 있으므로, 인프라에는 언제든지 필요한 만큼의 빌드 인스턴스만 포함됩니다. GitLab Runner가 오토스케일만 사용하도록 설정하면, GitLab Runner를 호스팅하는 시스템이 생성된 모든 머신의 기반 역할을 합니다. 이 머신을 "Runner Manager"라고 합니다.

Docker Machine 오토스케일러는 limit 및 concurrent 설정에 관계없이 VM당 하나의 컨테이너를 생성합니다.

이 기능이 활성화되고 올바르게 설정되면, 작업은 온디맨드 로 생성된 머신에서 실행됩니다. 해당 머신들은 작업이 완료된 후 다음 작업을 실행하기 위해 대기하거나 설정된 IdleTime 이후에 제거될 수 있습니다. 많은 클라우드 제공업체의 경우, 이 접근 방식은 기존 인스턴스를 활용하여 비용을 절감합니다.

아래에서 GitLab Community Edition 프로젝트에 대해 GitLab.com에서 테스트된 GitLab Runner 오토스케일 기능의 실제 사례를 확인할 수 있습니다:

차트의 각 머신은 Docker 컨테이너 내에서 작업을 실행하는 독립적인 클라우드 인스턴스입니다.

시스템 요구 사항#

오토스케일을 설정하기 전에 다음을 수행해야 합니다:

• 자체 환경 준비.
• 선택적으로 GitLab이 제공하는 포크된 버전의 Docker machine을 사용. 일부 추가 수정 사항이 포함되어 있습니다.

지원되는 클라우드 제공업체#

오토스케일 메커니즘은 Docker Machine을 기반으로 합니다. 지원되는 모든 가상화 및 클라우드 제공업체 파라미터는 GitLab이 관리하는 Docker Machine 포크에서 확인할 수 있습니다.

Runner 설정#

이 섹션에서는 주요 오토스케일 파라미터를 설명합니다. 더 많은 설정 세부 사항은 고급 설정을 참조하세요.

Runner 전역 옵션#

[[runners]] 옵션#

[runners.machine] 옵션#

설정 파라미터 세부 사항은 GitLab Runner - 고급 설정 - [runners.machine] 섹션에서 확인할 수 있습니다.

[runners.cache] 옵션#

설정 파라미터 세부 사항은 GitLab Runner - 고급 설정 - [runners.cache] 섹션에서 확인할 수 있습니다.

추가 설정 정보#

IdleCount = 0으로 설정하는 특수 모드도 있습니다. 이 모드에서는 각 작업 전에 (유휴 상태의 사용 가능한 머신이 없는 경우) 머신이 항상 온디맨드로 생성됩니다. 작업이 완료되면 오토스케일링 알고리즘은 아래에 설명된 것과 동일하게 작동합니다. 머신은 다음 작업을 기다리며, 아무것도 실행되지 않으면 IdleTime 기간 후에 머신이 제거됩니다. 작업이 없으면 유휴 상태의 머신도 없습니다.

IdleCount가 0보다 큰 값으로 설정되면 백그라운드에서 유휴 VM이 생성됩니다. 러너는 새 작업을 요청하기 전에 기존 유휴 VM을 획득합니다.

• 러너에 작업이 할당되면 해당 작업은 이전에 획득한 VM으로 전송됩니다.
• 러너에 작업이 할당되지 않으면 유휴 VM의 잠금이 해제되고 VM이 풀로 반환됩니다.

Docker Machine executor가 생성하는 VM 수 제한#

Docker Machine executor가 생성하는 가상 머신(VM) 수를 제한하려면 config.toml 파일의 [[runners]] 섹션에 있는 limit 파라미터를 사용하세요.

concurrent 파라미터는 VM 수를 제한하지 않습니다.

하나의 프로세스가 여러 러너 워커를 관리하도록 설정할 수 있습니다. 자세한 내용은 기본 설정: 러너 매니저 하나, 러너 하나를 참조하세요.

다음 예는 하나의 러너 프로세스에 대해 config.toml 파일에 설정된 값을 보여줍니다:

concurrent = 100

[[runners]]
name = "first"
executor = "shell"
limit = 40
(...)

[[runners]]
name = "second"
executor = "docker+machine"
limit = 30
(...)

[[runners]]
name = "third"
executor = "ssh"
limit = 10

[[runners]]
name = "fourth"
executor = "virtualbox"
limit = 20
(...)

이 설정에서:

• 하나의 러너 프로세스는 서로 다른 실행 환경을 사용하는 4개의 러너 워커를 생성할 수 있습니다.
• concurrent 값은 100으로 설정되므로, 이 러너는 최대 100개의 GitLab CI/CD 작업을 동시에 실행합니다.
• second 러너 워커만 Docker Machine executor를 사용하도록 설정되어 자동으로 VM을 생성할 수 있습니다.
• 30의 limit 설정은 second 러너 워커가 언제든지 오토스케일된 VM에서 최대 30개의 CI/CD 작업을 실행할 수 있음을 의미합니다.
• concurrent가 여러 [[runners]] 워커에 걸친 전역 동시성 제한을 정의하는 반면, limit은 단일 [[runners]] 워커의 최대 동시성을 정의합니다.

이 예에서 러너 프로세스는 다음을 처리합니다:

• 모든 [[runners]] 워커에 걸쳐 최대 100개의 동시 작업.
• first 워커의 경우, shell executor로 실행되는 최대 40개의 작업.
• second 워커의 경우, docker+machine executor로 실행되는 최대 30개의 작업. 또한 Runner는 [runners.machine]의 오토스케일링 설정에 따라 VM을 유지하지만, 모든 상태(유휴, 사용 중, 생성 중, 제거 중)에서 최대 30개의 VM을 유지합니다.
• third 워커의 경우, ssh executor로 실행되는 최대 10개의 작업.
• fourth 워커의 경우, virtualbox executor로 실행되는 최대 20개의 작업.

두 번째 예에서는 docker+machine executor를 사용하도록 설정된 두 개의 [[runners]] 워커가 있습니다. 이 설정에서 각 러너 워커는 limit 파라미터의 값으로 제한되는 별도의 VM 풀을 관리합니다.

concurrent = 100

[[runners]]
name = "first"
executor = "docker+machine"
limit = 80
(...)

[[runners]]
name = "second"
executor = "docker+machine"
limit = 50
(...)

이 예에서:

• 러너는 최대 100개의 작업을 처리합니다(concurrent 값).
• 러너 프로세스는 두 개의 [[runners]] 워커에서 작업을 실행하며, 각각 docker+machine executor를 사용합니다.
• first 러너는 최대 80개의 VM을 생성할 수 있습니다. 따라서 이 러너는 언제든지 최대 80개의 작업을 실행할 수 있습니다.
• second 러너는 최대 50개의 VM을 생성할 수 있습니다. 따라서 이 러너는 언제든지 최대 50개의 작업을 실행할 수 있습니다.

오토스케일링 알고리즘 및 파라미터#

오토스케일링 알고리즘은 다음 파라미터를 기반으로 합니다:

• IdleCount
• IdleCountMin
• IdleScaleFactor
• IdleTime
• MaxGrowthRate
• limit

작업을 실행하지 않는 모든 머신은 유휴 상태로 간주됩니다. GitLab Runner가 오토스케일 모드에 있을 때, 모든 머신을 모니터링하고 항상 IdleCount개의 유휴 머신이 있는지 확인합니다.

유휴 머신의 수가 충분하지 않으면 GitLab Runner는 MaxGrowthRate 제한에 따라 새 머신 프로비저닝을 시작합니다. MaxGrowthRate 값을 초과하는 머신 요청은 생성되는 머신 수가 MaxGrowthRate 아래로 떨어질 때까지 보류됩니다.

동시에 GitLab Runner는 각 머신의 유휴 상태 지속 시간을 확인합니다. 시간이 IdleTime 값을 초과하면 머신이 자동으로 제거됩니다.

설정 예시#

다음 오토스케일 파라미터로 설정된 GitLab Runner를 고려해 보세요:

[[runners]]
  limit = 10
  # (...)
  executor = "docker+machine"
  [runners.machine]
    MaxGrowthRate = 1
    IdleCount = 2
    IdleTime = 1800
    # (...)

처음에 대기 중인 작업이 없을 때, GitLab Runner는 두 개의 머신(IdleCount = 2)을 시작하고 유휴 상태로 설정합니다. 또한 IdleTime은 30분(IdleTime = 1800)으로 설정됩니다.

이제 GitLab CI/CD에서 5개의 작업이 대기 중이라고 가정해 봅시다. 처음 두 작업은 현재 두 개의 유휴 머신으로 전송됩니다. GitLab Runner는 유휴 머신 수가 IdleCount(0 < 2)보다 적음을 확인하고 새 머신을 시작합니다. 이 머신들은 MaxGrowthRate를 초과하지 않도록 순차적으로 프로비저닝됩니다.

나머지 세 작업은 준비된 첫 번째 머신에 할당됩니다. 최적화로, 이것은 바쁘다가 이제 작업이 완료된 머신이거나 새로 프로비저닝된 머신일 수 있습니다. 이 예에서는 프로비저닝이 빠르고 이전 작업이 완료되기 전에 새 머신이 준비된다고 가정합니다.

이제 유휴 머신이 하나 있으므로, GitLab Runner는 IdleCount를 충족하기 위해 새 머신을 하나 더 시작합니다. 대기 중인 새 작업이 없으므로 두 머신은 유휴 상태로 유지되고 GitLab Runner는 만족스러운 상태입니다.

발생한 일:

예에서 두 머신이 새 작업을 위해 유휴 상태로 대기 중이었습니다. 5개의 작업이 대기열에 들어온 후 새 머신이 생성됩니다. 따라서 총 7개의 머신이 있습니다: 5개는 작업을 실행 중이고 2개는 다음 작업을 기다리는 유휴 상태입니다.

GitLab Runner는 IdleCount가 충족될 때까지 작업 실행에 사용되는 각 머신에 대해 새 유휴 머신을 생성합니다. 머신은 limit 파라미터로 정의된 수까지 생성됩니다. GitLab Runner가 이 limit에 도달했음을 감지하면 오토스케일링을 중지합니다. 새 작업은 머신이 유휴 상태로 돌아오기 시작할 때까지 작업 대기열에서 대기해야 합니다.

위의 예에서 두 개의 유휴 머신은 항상 사용 가능합니다. IdleTime 파라미터는 숫자가 IdleCount를 초과할 때만 적용됩니다. 이 시점에서 GitLab Runner는 IdleCount에 맞게 머신 수를 줄입니다.

스케일 다운:

작업이 완료되면 머신은 유휴 상태로 설정되고 새 작업이 실행되기를 기다립니다. 대기열에 새 작업이 나타나지 않으면 유휴 머신은 IdleTime으로 지정된 시간 후에 제거됩니다. 이 예에서 모든 머신은 30분의 비활성 시간 후에 제거됩니다(각 머신의 마지막 작업 실행이 종료된 시점부터 측정). GitLab Runner는 예시 시작 시처럼 IdleCount개의 유휴 머신을 실행 상태로 유지합니다.

오토스케일링 알고리즘의 작동 방식:

1. GitLab Runner가 시작됩니다.
2. GitLab Runner가 두 개의 유휴 머신을 생성합니다.
3. GitLab Runner가 작업 하나를 선택합니다.
4. GitLab Runner가 두 개의 유휴 머신을 유지하기 위해 머신 하나를 더 생성합니다.
5. 선택된 작업이 완료되어 세 개의 유휴 머신이 됩니다.
6. 세 개의 유휴 머신 중 하나가 마지막 작업 선택 이후 IdleTime을 초과하면 제거됩니다.
7. GitLab Runner는 항상 빠른 작업 처리를 위해 최소 두 개의 유휴 머신을 유지합니다.

다음 차트는 시간에 따른 머신 및 빌드(작업) 상태를 보여줍니다:

concurrent, limit, IdleCount가 실행 중인 머신의 상한선을 결정하는 방법#

limit 또는 concurrent를 얼마로 설정해야 하는지 알려주는 마법의 공식은 없습니다. 필요에 따라 행동하세요. IdleCount의 유휴 머신은 속도 향상 기능입니다. 인스턴스가 생성되기까지 10초/20초/30초를 기다릴 필요가 없습니다. 하지만 사용자로서 모든 머신(비용을 지불해야 하는)이 유휴 상태로 있는 것이 아니라 작업을 실행하기를 원할 것입니다. 따라서 concurrent와 limit은 지불할 의향이 있는 최대 머신 수를 실행하는 값으로 설정해야 합니다. IdleCount의 경우, 작업 대기열이 비어 있을 때 사용되지 않는 머신의 최소량을 생성하는 값으로 설정해야 합니다.

다음 예를 가정해 봅시다:

concurrent=20

[[runners]]
  limit = 40
  [runners.machine]
    IdleCount = 10

위 시나리오에서 가질 수 있는 총 머신 수는 30입니다. 전체 머신(빌드 중 및 유휴)의 limit은 40일 수 있습니다. 10개의 유휴 머신을 가질 수 있지만 concurrent 작업은 20개입니다. 따라서 총 20개의 동시 작업을 실행하는 머신과 10개의 유휴 머신이 있어 합계 30개가 됩니다.

하지만 limit이 생성될 수 있는 총 머신 수보다 적으면 어떻게 될까요? 아래 예가 그 경우를 설명합니다:

concurrent=20

[[runners]]
  limit = 25
  [runners.machine]
    IdleCount = 10

이 예에서 최대 20개의 동시 작업과 25개의 머신을 가질 수 있습니다. 최악의 경우 limit이 25이기 때문에 10개의 유휴 머신을 가질 수 없고 5개만 가질 수 있습니다.

IdleScaleFactor 전략#

IdleCount 파라미터는 러너가 유지해야 하는 유휴 머신의 정적 수를 정의합니다. 할당하는 값은 사용 사례에 따라 다릅니다.

유휴 상태의 머신 수를 합리적으로 작은 수로 시작하세요. 그런 다음 현재 사용량에 따라 자동으로 더 큰 수로 조정되도록 합니다. 이를 위해 실험적인 IdleScaleFactor 설정을 사용하세요.

이 설정을 사용하면 GitLab Runner는 유휴 상태의 정의된 수의 머신을 유지하려고 시도합니다. 하지만 이 숫자는 더 이상 정적이지 않습니다. IdleCount를 사용하는 대신 GitLab Runner는 사용 중인 머신을 계산하고 그 숫자의 비율로 원하는 유휴 용량을 정의합니다.

사용 중인 머신이 없으면 IdleScaleFactor는 유지할 유휴 머신이 없다고 평가합니다. IdleCount가 0보다 크면(그때만 IdleScaleFactor가 적용 가능), 러너는 처리할 수 있는 유휴 머신이 없으면 작업을 요청하지 않습니다. 새 작업이 없으면 사용 중인 머신 수가 증가하지 않으므로 IdleScaleFactor는 계속 0으로 평가됩니다. 이로 인해 Runner가 사용할 수 없는 상태로 고착됩니다.

따라서 두 번째 설정인 IdleCountMin을 도입했습니다. 이는 IdleScaleFactor가 어떻게 평가되든 유지해야 하는 최소 유휴 머신 수를 정의합니다. IdleScaleFactor를 사용하는 경우 이 설정은 1 미만으로 설정할 수 없습니다. Runner는 자동으로 IdleCountMin을 1로 설정합니다.

IdleCountMin을 사용하여 항상 사용 가능해야 하는 최소 유휴 머신 수를 정의할 수도 있습니다. 이를 통해 대기열에 들어오는 새 작업을 빠르게 시작할 수 있습니다. IdleCount와 마찬가지로 할당하는 값은 사용 사례에 따라 다릅니다.

예:

concurrent=200

[[runners]]
  limit = 200
  [runners.machine]
    IdleCount = 100
    IdleCountMin = 10
    IdleScaleFactor = 1.1

이 경우 Runner가 결정 시점에 도달하면 사용 중인 머신 수를 확인합니다. 예를 들어, 유휴 머신이 5개이고 사용 중인 머신이 10개인 경우. IdleScaleFactor를 곱하면 Runner는 11개의 유휴 머신이 있어야 한다고 결정합니다. 따라서 6개가 더 생성됩니다.

유휴 머신이 90개이고 사용 중인 머신이 100개인 경우, IdleScaleFactor에 따라 GitLab Runner는 100 * 1.1 = 110개의 유휴 머신이 있어야 한다고 판단합니다. 따라서 다시 새 머신 생성을 시작합니다. 하지만 100개의 유휴 머신에 도달하면 이것이 IdleCount로 정의된 상한선이므로 더 이상 유휴 머신을 생성하지 않습니다.

사용 중인 100개의 유휴 머신이 20개로 줄어들면 원하는 유휴 머신 수는 20 * 1.1 = 22개입니다. GitLab Runner는 머신 종료를 시작합니다. 위에서 설명한 바와 같이 GitLab Runner는 IdleTime 동안 사용되지 않은 머신을 제거합니다. 따라서 너무 많은 유휴 VM의 제거는 공격적으로 이루어집니다.

유휴 머신 수가 0으로 줄어들면 원하는 유휴 머신 수는 0 * 1.1 = 0입니다. 하지만 이는 정의된 IdleCountMin 설정보다 작으므로 Runner는 유휴 VM이 10개 남을 때까지 제거를 시작합니다. 그 이후에는 스케일 다운이 중지되고 Runner는 유휴 상태로 10개의 머신을 유지합니다.

오토스케일링 기간 설정#

오토스케일링은 시간대에 따라 다른 값을 갖도록 설정할 수 있습니다. 조직은 작업이 급증하는 정기적인 시간이 있을 수 있고, 작업이 거의 없거나 전혀 없는 시간도 있습니다. 예를 들어, 대부분의 상업 회사들은 월요일부터 금요일까지 오전 10시부터 오후 6시와 같은 고정된 시간에 일합니다. 주 나머지 시간인 밤과 주말에는 파이프라인이 시작되지 않습니다.

이러한 기간은 [[runners.machine.autoscaling]] 섹션의 도움으로 설정할 수 있습니다. 각 섹션은 Periods 집합을 기반으로 IdleCount 및 IdleTime 설정을 지원합니다.

오토스케일링 기간의 작동 방식#

[runners.machine] 설정에서 각자의 IdleCount, IdleTime, Periods 및 Timezone 속성을 가진 여러 [[runners.machine.autoscaling]] 섹션을 추가할 수 있습니다. 섹션은 가장 일반적인 시나리오에서 가장 구체적인 시나리오 순서로 정의해야 합니다.

모든 섹션이 파싱됩니다. 현재 시간과 마지막으로 일치하는 섹션이 활성화됩니다. 일치하는 섹션이 없으면 [runners.machine] 루트의 값이 사용됩니다.

예:

[runners.machine]
  MachineName = "auto-scale-%s"
  MachineDriver = "google"
  IdleCount = 10
  IdleTime = 1800
  [[runners.machine.autoscaling]]
    Periods = ["* * 9-17 * * mon-fri *"]
    IdleCount = 50
    IdleTime = 3600
    Timezone = "UTC"
  [[runners.machine.autoscaling]]
    Periods = ["* * * * * sat,sun *"]
    IdleCount = 5
    IdleTime = 60
    Timezone = "UTC"

이 설정에서 UTC 기준 월요일부터 금요일 오전 9시부터 오후 4시 59분 사이에는 업무 시간 동안의 많은 트래픽을 처리하기 위해 머신이 과잉 프로비저닝됩니다. 주말에는 트래픽 감소를 반영하여 IdleCount가 5로 줄어듭니다. 나머지 시간에는 루트의 기본값인 IdleCount = 10과 IdleTime = 1800이 사용됩니다.

기간의 Timezone을 지정할 수 있습니다(예: "Australia/Sydney"). 지정하지 않으면 모든 러너의 호스트 머신의 시스템 설정이 사용됩니다. 이 기본값은 Timezone = "Local"로 명시적으로 명시할 수 있습니다.

[[runner.machine.autoscaling]] 섹션의 구문에 대한 자세한 내용은 GitLab Runner - 고급 설정 - [runners.machine] 섹션에서 확인할 수 있습니다.

분산 러너 캐싱#

작업 속도를 높이기 위해 GitLab Runner는 선택된 디렉터리 및/또는 파일이 저장되어 이후 작업 간에 공유되는 캐시 메커니즘을 제공합니다.

이 메커니즘은 작업이 동일한 호스트에서 실행될 때 잘 작동합니다. 하지만 GitLab Runner 오토스케일 기능을 사용하기 시작하면 대부분의 작업이 새 (또는 거의 새로운) 호스트에서 실행됩니다. 이 새 호스트는 각 작업을 새 Docker 컨테이너에서 실행합니다. 이 경우 캐시 기능의 이점을 활용할 수 없습니다.

이 문제를 극복하기 위해 오토스케일 기능과 함께 분산 러너 캐시 기능이 도입되었습니다.

이 기능은 설정된 오브젝트 스토리지 서버를 사용하여 사용된 Docker 호스트 간에 캐시를 공유합니다. GitLab Runner는 서버를 쿼리하고 아카이브를 다운로드하여 캐시를 복원하거나 업로드하여 캐시를 아카이브합니다.

분산 캐싱을 활성화하려면 [runners.cache] 지시자를 사용하여 config.toml에서 정의해야 합니다:

[[runners]]
  limit = 10
  executor = "docker+machine"
  [runners.cache]
    Type = "s3"
    Path = "path/to/prefix"
    Shared = false
    [runners.cache.s3]
      ServerAddress = "s3.example.com"
      AccessKey = "access-key"
      SecretKey = "secret-key"
      BucketName = "runner"
      Insecure = false

위 예에서 S3 URL은 http(s)://///runner/<runner-id>/project/<id>/<cache-key> 구조를 따릅니다.

두 개 이상의 러너 간에 캐시를 공유하려면 Shared 플래그를 true로 설정하세요. 이 플래그는 URL에서 러너 토큰(runner/<runner-id>)을 제거하고 설정된 모든 러너가 동일한 캐시를 공유합니다. 캐시 공유가 활성화된 경우 Path를 설정하여 러너 간에 캐시를 분리할 수도 있습니다.

분산 컨테이너 레지스트리 미러링#

Docker 컨테이너 내에서 실행되는 작업 속도를 높이기 위해 Docker 레지스트리 미러링 서비스를 사용할 수 있습니다. 이 서비스는 Docker 머신과 사용된 모든 레지스트리 사이에 프록시를 제공합니다. 이미지는 레지스트리 미러에 의해 한 번 다운로드됩니다. 이미지를 사용할 수 없는 새 호스트 또는 기존 호스트에서 설정된 레지스트리 미러에서 이미지가 다운로드됩니다.

Docker 머신의 LAN에 미러가 있는 경우 각 호스트에서 이미지 다운로드 단계가 훨씬 빨라야 합니다.

Docker 레지스트리 미러링을 설정하려면 config.toml의 설정에 MachineOptions를 추가해야 합니다:

[[runners]]
  limit = 10
  executor = "docker+machine"
  [runners.machine]
    (...)
    MachineOptions = [
      (...)
      "engine-registry-mirror=http://10.11.12.13:12345"
    ]

여기서 10.11.12.13:12345는 레지스트리 미러가 Docker 서비스의 연결을 수신 대기하는 IP 주소와 포트입니다. Docker Machine이 생성한 각 호스트에서 접근 가능해야 합니다.

컨테이너에 프록시 사용에 대해 자세히 읽어보세요.

config.toml의 완전한 예시#

아래 config.toml은 google Docker Machine 드라이버를 사용합니다:

concurrent = 50   # All registered runners can run up to 50 concurrent jobs

[[runners]]
  url = "https://gitlab.com"
  token = "RUNNER_TOKEN"             # Note this is different from the registration token used by `gitlab-runner register`
  name = "autoscale-runner"
  executor = "docker+machine"        # This runner is using the 'docker+machine' executor
  limit = 10                         # This runner can execute up to 10 jobs (created machines)
  [runners.docker]
    image = "ruby:3.3"               # The default image used for jobs is 'ruby:3.3'
  [runners.machine]
    IdleCount = 5                    # There must be 5 machines in Idle state - when Off Peak time mode is off
    IdleTime = 600                   # Each machine can be in Idle state up to 600 seconds (after this it will be removed) - when Off Peak time mode is off
    MaxBuilds = 100                  # Each machine can handle up to 100 jobs in a row (after this it will be removed)
    MachineName = "auto-scale-%s"    # Each machine will have a unique name ('%s' is required)
    MachineDriver = "google" # Refer to Docker Machine docs on how to authenticate: https://docs.docker.com/machine/drivers/gce/#credentials
    MachineOptions = [
      "google-project=GOOGLE-PROJECT-ID",
      "google-zone=GOOGLE-ZONE", # e.g. 'us-west1'
      "google-machine-type=GOOGLE-MACHINE-TYPE", # e.g. 'n1-standard-8'
      "google-machine-image=ubuntu-os-cloud/global/images/family/ubuntu-1804-lts",
      "google-username=root",
      "google-use-internal-ip",
      "engine-registry-mirror=https://mirror.gcr.io"
    ]
    [[runners.machine.autoscaling]]  # Define periods with different settings
      Periods = ["* * 9-17 * * mon-fri *"] # Every workday between 9 and 17 UTC
      IdleCount = 50
      IdleCountMin = 5
      IdleScaleFactor = 1.5 # Means that current number of Idle machines will be 1.5*in-use machines,
                            # no more than 50 (the value of IdleCount) and no less than 5 (the value of IdleCountMin)
      IdleTime = 3600
      Timezone = "UTC"
    [[runners.machine.autoscaling]]
      Periods = ["* * * * * sat,sun *"] # During the weekends
      IdleCount = 5
      IdleTime = 60
      Timezone = "UTC"
  [runners.cache]
    Type = "s3"
    [runners.cache.s3]
      ServerAddress = "s3.eu-west-1.amazonaws.com"
      AccessKey = "AMAZON_S3_ACCESS_KEY"
      SecretKey = "AMAZON_S3_SECRET_KEY"
      BucketName = "runner"
      Insecure = false

MachineOptions 파라미터는 Docker Machine이 Google Compute Engine에서 머신을 생성하는 데 사용하는 google 드라이버의 옵션과 Docker Machine 자체(engine-registry-mirror)의 옵션을 포함합니다.