코드베이스가 클 경우 종속 항목 체인이 매우 길어질 수 있습니다. 간단한 바이너리조차도 수만 개의 빌드 타겟에 종속되는 경우가 많습니다. 이 규모에서는 단일 머신에서 합당한 시간 내에 빌드를 완료하는 것이 불가능합니다. 어떤 빌드 시스템도 머신의 하드웨어에 부과된 기본 물리 법칙을 우회할 수 없습니다. 이를 실행하는 유일한 방법은 시스템에서 실행되는 작업 단위가 임의의 확장 가능한 수의 머신에 분산되는 분산 빌드를 지원하는 빌드 시스템을 사용하는 것입니다. 시스템 작업을 충분히 작은 단위로 분할했다고 가정하면 (자세한 내용은 나중에 설명) 비용을 지불할 의향이 있는 한 어떤 크기의 빌드든지 최대한 빨리 완료할 수 있습니다. 이러한 확장성은 아티팩트 기반 빌드 시스템을 정의하기 위해 노력해 온 핵심 목표입니다.
원격 캐싱
가장 간단한 유형의 분산 빌드는 그림 1과 같이 원격 캐싱만 활용하는 빌드입니다.
그림 1. 원격 캐싱을 보여주는 분산 빌드
개발자 워크스테이션과 지속적인 통합 시스템을 비롯하여 빌드를 실행하는 모든 시스템은 공통 원격 캐시 서비스에 대한 참조를 공유합니다. 이 서비스는 Redis와 같은 빠르고 로컬인 단기 저장소 시스템이거나 Google Cloud Storage와 같은 클라우드 서비스일 수 있습니다. 사용자가 직접 또는 종속 항목으로 아티팩트를 빌드해야 할 때마다 시스템은 먼저 원격 캐시에서 해당 아티팩트가 이미 있는지 확인합니다. 이 경우 아티팩트를 빌드하는 대신 다운로드할 수 있습니다. 그렇지 않으면 시스템이 아티팩트를 직접 빌드하고 결과를 캐시로 다시 업로드합니다. 즉, 자주 변경되지 않는 하위 수준 종속 항목은 각 사용자가 다시 빌드할 필요 없이 한 번 빌드하고 여러 사용자와 공유할 수 있습니다. Google에서는 많은 아티팩트가 처음부터 빌드되는 대신 캐시에서 제공되므로 빌드 시스템을 실행하는 데 드는 비용이 크게 줄어듭니다.
원격 캐싱 시스템이 작동하려면 빌드 시스템에서 빌드를 완전히 재현할 수 있어야 합니다. 즉, 모든 빌드 타겟의 경우 동일한 입력 세트가 모든 머신에서 정확히 동일한 출력을 생성하도록 해당 타겟의 입력 세트를 결정할 수 있어야 합니다. 이는 아티팩트 다운로드 결과가 직접 빌드한 결과와 동일한지 확인하는 유일한 방법입니다. 이렇게 하려면 캐시의 각 아티팩트가 타겟과 입력의 해시를 모두 기준으로 키를 지정해야 합니다. 이렇게 하면 여러 엔지니어가 동시에 동일한 타겟을 다르게 수정할 수 있고 원격 캐시가 결과물인 모든 아티팩트를 저장하고 충돌 없이 적절하게 제공할 수 있습니다.
물론 원격 캐시의 이점을 누리려면 아티팩트를 다운로드하는 속도가 빌드하는 속도보다 빠르게 이루어져야 합니다. 하지만 항상 그런 것은 아닙니다. 특히 캐시 서버가 빌드를 실행하는 머신에서 멀리 떨어져 있는 경우에는 더욱 그렇습니다. Google의 네트워크 및 빌드 시스템은 빌드 결과를 빠르게 공유할 수 있도록 신중하게 조정됩니다.
원격 실행
원격 캐싱은 진정한 분산 빌드가 아닙니다. 캐시가 손실되거나 모든 것을 다시 빌드해야 하는 하위 수준 변경사항을 적용하는 경우에도 머신에서 전체 빌드를 로컬로 실행해야 합니다. 진정한 목표는 빌드 작업을 여러 작업자 간에 분산할 수 있는 원격 실행을 지원하는 것입니다. 그림 2는 원격 실행 시스템을 보여줍니다.
그림 2. 원격 실행 시스템
각 사용자의 머신에서 실행되는 빌드 도구 (사용자가 인간 엔지니어 또는 자동화된 빌드 시스템인 경우)는 중앙 빌드 마스터에 요청을 전송합니다. 빌드 마스터는 요청을 구성요소 작업으로 분할하고 확장 가능한 작업자 풀을 통해 이러한 작업의 실행을 예약합니다. 각 작업자는 사용자가 지정한 입력으로 요청된 작업을 실행하고 결과 아티팩트를 작성합니다. 이러한 아티팩트는 최종 출력을 생성하여 사용자에게 전송할 수 있을 때까지 이러한 아티팩트가 필요한 작업을 실행하는 다른 머신 간에 공유됩니다.
이러한 시스템을 구현할 때 가장 까다로운 부분은 작업자, 마스터, 사용자의 로컬 머신 간의 통신을 관리하는 것입니다. 작업자는 다른 작업자가 생성한 중간 아티팩트에 종속될 수 있으며 최종 출력은 사용자의 로컬 머신으로 다시 전송되어야 합니다. 이렇게 하려면 각 작업자가 결과를 캐시에 쓰고 종속 항목을 캐시에서 읽도록 하여 이전에 설명한 분산 캐시를 기반으로 빌드하면 됩니다. 마스터는 종속 항목이 모두 완료될 때까지 작업자가 진행되지 않도록 차단합니다. 이 경우 작업자는 캐시에서 입력을 읽을 수 있습니다. 최종 제품도 캐시되므로 로컬 머신에서 다운로드할 수 있습니다. 또한 작업자가 빌드하기 전에 이러한 변경사항을 적용할 수 있도록 사용자의 소스 트리에서 로컬 변경사항을 내보내는 별도의 수단이 필요합니다.
이렇게 하려면 앞에서 설명한 아티팩트 기반 빌드 시스템의 모든 부분이 함께 작동해야 합니다. 빌드 환경은 사람이 개입하지 않고도 작업자를 스핀업할 수 있도록 완전히 자체 설명형이어야 합니다. 각 단계가 다른 머신에서 실행될 수 있으므로 빌드 프로세스 자체는 완전히 독립형이어야 합니다. 각 작업자가 다른 작업자로부터 수신한 결과를 신뢰할 수 있도록 출력은 완전히 결정론적이어야 합니다. 이러한 보장은 작업 기반 시스템에서 제공하기가 매우 어렵기 때문에 작업 기반 시스템을 기반으로 안정적인 원격 실행 시스템을 빌드하는 것은 거의 불가능합니다.
Google에서 배포된 빌드
Google은 2008년부터 원격 캐싱과 원격 실행을 모두 사용하는 분산 빌드 시스템을 사용해 왔습니다(그림 3 참고).
그림 3. Google의 분산 빌드 시스템
Google의 원격 캐시는 ObjFS라고 합니다. 빌드 출력을 프로덕션 머신 전체에 배포된 Bigtable에 저장하는 백엔드와 각 개발자의 머신에서 실행되는 objfsd라는 프런트엔드 FUSE 데몬으로 구성됩니다. FUSE 데몬을 사용하면 엔지니어가 빌드 출력을 워크스테이션에 저장된 일반 파일인 것처럼 탐색할 수 있지만, 사용자가 직접 요청한 일부 파일의 경우에만 파일 콘텐츠가 주문형으로 다운로드됩니다. 파일 콘텐츠를 주문형으로 제공하면 네트워크 및 디스크 사용량이 크게 줄어들고 시스템은 모든 빌드 출력을 개발자의 로컬 디스크에 저장할 때보다 두 배 빠르게 빌드할 수 있습니다.
Google의 원격 실행 시스템은 Forge라고 합니다. Blaze(Bazel의 내부 등가 항목)의 Forge 클라이언트인 배급자는 각 작업에 대한 요청을 Scheduler(예약 도구)라는 데이터 센터에서 실행 중인 작업에 전송합니다. Scheduler는 작업 결과의 캐시를 유지하므로 시스템의 다른 사용자가 이미 작업을 만들었으면 즉시 응답을 반환할 수 있습니다. 그렇지 않으면 작업을 큐에 추가합니다. 대규모 Executor 작업 풀이 이 대기열에서 작업을 지속적으로 읽고 실행한 후 결과를 ObjFS Bigtable에 직접 저장합니다. 이러한 결과는 향후 작업을 위해 실행자가 사용할 수 있거나 최종 사용자가 objfsd를 통해 다운로드할 수 있습니다.
그 결과 Google에서 실행되는 모든 빌드를 효율적으로 지원하도록 확장되는 시스템이 탄생했습니다. Google의 빌드 규모는 정말 엄청납니다. Google은 매일 수백만 개의 테스트 사례를 실행하고 수십억 줄의 소스 코드에서 페타바이트의 빌드 출력을 생성하는 수백만 개의 빌드를 실행합니다. 이러한 시스템을 통해 엔지니어는 복잡한 코드베이스를 빠르게 빌드할 수 있을 뿐만 아니라 빌드를 사용하는 수많은 자동화 도구와 시스템을 구현할 수 있습니다.