2026 크로스 리전 병렬 클러스터
Nomad 친화, 빌드 락, 디스크 확장 수위

Nomad만으로는 부족한 이유

베어메탈 Mac에 Nomad client를 올리고 batch 빌드와 promote를 한 오케스트레이션에 묶는 팀을 대상으로 합니다. 고정 슬러그: 2026-clustervps-mac-mini-m4-nomad-affinity-build-lock.html. 팬아웃 파라미터·타임아웃·rsync 매트릭스는 자매 글 《2026 멀티리전 Mac mini M4: rsync·빌드 락·1TB/2TB》을 기준으로 하고, 제어 DNS·내부 오리진 분할은 《분할 DNS·아티팩트 레지스트리 매트릭스》를 보세요. 목록은 기술 블로그 홈에서 이어집니다.

• 친화 오배치: CPU 집약 아카이브 job이 「골든 팬아웃」 노드로 가 rsync 읽기 대역을 잡아먹습니다.
• 이중 락: Nomad max_parallel과 셸 flock 의미가 어긋나 가짜 병렬 쓰기가 납니다.
• 수위 맹목: 1TB 플랜이 85%인데도 dispatch를 제한 없이 돌리면 APFS 스냅샷·캐시가 마지막 여유를 삼킵니다.

의사결정 매트릭스: 친화 × 빌드 락 × 디스크

Nomad는 batch를 맞는 Mac Mini M4에 붙이고, 병렬은 처리량을 올리지만 IO 경합을 키웁니다. 빌드 락은 promote 트리의 단일 작성자를 보장하고, 확장 수위는 1TB에서 2TB로 올릴지·동시성을 줄일지 판단합니다.

실행 가능한 job 제약 예시(HCL 단위 설명)

아래는 nomad job run으로 디버깅할 수 있는 뼈대입니다. 프로덕션에서는 바이너리 경로·메타·스크립트를 교체하세요. 블록 구조를 먼저 훑고 설명과 대조하면 됩니다.

job "mac-m4-batch-promote" {
  type = "batch"

  group "promote" {
    count = 1

    constraint {
      attribute = "${meta.build_zone}"
      operator  = "="
      value     = "apac-golden"
    }

    constraint {
      operator = "distinct_hosts"
      value    = "true"
    }

    task "gate" {
      driver = "exec"

      config {
        command = "/bin/bash"
        args = ["-c", "flock -n /var/tmp/ci-promote.lock -c /local/bin/promote.sh"]
      }

      resources {
        cpu    = 2000
        memory = 4096
      }
    }
  }
}

최상위 job와 type = "batch": 짧은 수명 작업을 선언해 끝나면 할당을 풀기 좋고 promote·검증 스크립트에 맞습니다. group: 네트워크·재시작 정책을 묶습니다. count = 1은 promote 단일 작성자와 맞고, 다중 병렬 컴파일은 다른 job으로 쪼개세요. 첫 constraint: 클라이언트 meta의 build_zone이 apac-golden과 같게 해 아태 골든 팬아웃기에 고정합니다(agent에 동일 meta 필요). 두 번째 constraint: distinct_hosts로 여러 사본이 한 Mac에 쌓여 디스크를 쓰는 일을 막습니다. task와 driver = "exec": 로컬 bash를 직접 호출해 macOS에서 컨테이너 오버헤드를 줄입니다. args의 flock: 자매 글 스크립트 락과 동일한 계층입니다. 스케줄러는 배치를 시도했을 뿐이고, 상호 배제는 OS 파일 락이 담당합니다. resources: promote에 CPU·메모리 상한을 두어 컴파일형 batch와 풀을 나눕니다.

rsync 아티팩트 동기와의 연결 순서

권장 파이프라인: Nomad batch로 컴파일 완료 → 로컬 promote(flock)로 승격 트리에 기록 → 골든 머신이 프로파일별 rsync 팬아웃(플래그 표는 위 rsync 글). promote가 닫히기 전에 하류 --delete 동기를 돌리면 워커가 잠깐 반쪽 트리를 봅니다. 리전 간 속도 제한이 필요하면 rsync를 두 번째 Nomad batch로 감싸 constraint를 「릴레이」 meta에 두고 promote job의 meta.build_zone과 시간대를 어긋나게 하세요.

1TB / 2TB 확장 수위 의사결정표

클러스터에서는 평균이 아니라 「가장 찬 노드」로 알람을 겁니다. 병렬 노드가 많을수록 한 노드 디스크가 promote 체인 전체를 끌어내리지 않게 하세요.

자주 묻는 질문

Nomad 동시성으로 flock을 대체할 수 있나요? 비권장입니다. max_parallel은 「동시 실행」만 막고 수동 스크립트나 크래시 재기동 재진입은 막지 못합니다. promote 최종 방어는 OS 락입니다.

meta 라벨을 랙·AZ와 어떻게 맞출까요? agent에 meta.build_zone, meta.az를 넣고 DNS 분할 매트릭스의 뷰 이름과 같게 하면 온콜 매핑 비용이 줄어듭니다.

batch를 long-running으로 둘까요? 컴파일은 여러 batch로 쪼개고, 장기 데몬형 동기는 service job으로 두어 batch 완료 정책에 의해 죽는 일을 피하세요.