코드베이스가 크면 종속 항목 체인이 매우 심해질 수 있습니다. 단순한 바이너리도 수만 개의 빌드 대상에 종종 종속될 수 있습니다. 위치 적당한 시간 내에 빌드를 완료하는 것은 시간이 오래 걸리기 때문에 어떤 빌드 시스템도 근본적인 물리학 법칙을 적용합니다. 이 문제를 해결할 수 있는 유일한 방법은 분산 빌드를 지원하는 빌드 시스템을 사용합니다. 시스템에서 수행하는 작업이 임의적이고 확장 가능한 가상 머신을 만들 수 있습니다 시스템의 작업을 작은 규모로 분할했다고 가정하고 이 방법은 나중에 자세히 설명하겠습니다. 이를 통해 최대한 빠르게 최적화할 수 있습니다 이러한 확장성은 아티팩트 기반 빌드 시스템을 정의해 왔습니다.
원격 캐싱
가장 단순한 유형의 분산 빌드는 remote 캐싱을 사용할 수 있습니다.
그림 1. 원격 캐싱을 보여주는 분산 빌드
개발자 워크스테이션과 API를 비롯하여 빌드를 수행하는 모든 시스템 지속적 통합 시스템, 공통 원격 캐시에 대한 참조를 공유합니다. 있습니다. 이 서비스는 Redis 또는 Google Cloud Storage와 같은 클라우드 서비스 사용자가 아티팩트를 빌드하든지 아니면 종속 항목으로서 빌드하든, 시스템은 먼저 원격 캐시에 해당 아티팩트가 이미 있는지 확인합니다. 그렇다면 아티팩트를 빌드하는 대신 다운로드할 수 있습니다. 그러지 않으면 시스템에서 결과를 캐시에 다시 업로드합니다. 즉, 자주 변경되지 않는 하위 수준의 종속 항목은 한 번만 빌드하여 공유할 수 있습니다. 각 사용자가 다시 빌드하지 않아도 됩니다. Google에서는 아티팩트는 처음부터 빌드되지 않고 캐시에서 서빙됩니다. 빌드 시스템 실행 비용을 줄일 수 있습니다.
원격 캐싱 시스템이 작동하려면 빌드 시스템이 완벽하게 재현 가능합니다. 즉, 모든 빌드 대상에 대해 타겟에 대한 입력 세트를 결정하여 동일한 입력 세트가 모든 머신에서 정확히 동일한 출력을 생성합니다. 이것이 아티팩트를 다운로드한 결과가 이 항목의 결과와 같아야 함 구축하게 되는 거죠. 이를 위해서는 캐시의 각 아티팩트가 대상과 입력 해시에 모두 키가 지정되어야 하므로 엔지니어가 같은 표적에 다른 수정사항을 적용하더라도 원격 캐시는 모든 결과 아티팩트를 저장하고 갈등 없이 적절하게 적용할 수 있어야 합니다
물론 원격 캐시의 이점을 활용하려면 빌드보다 더 빨라야 합니다. 항상 그런 것은 아니며 특히 캐시 서버가 빌드를 수행하는 컴퓨터에서 멀리 떨어져 있을 때 발생합니다. Google의 빌드 시스템은 다른 사용자들과 빠르게 공유할 수 있도록 있습니다.
원격 실행
원격 캐싱은 진정한 배포 빌드가 아닙니다. 캐시가 손실되거나 모든 것을 재구축해야 하는 하위 수준의 변경을 수행하지만 전체 빌드를 머신에서 로컬로 수행합니다 진정한 목표는 빌드 실행의 실제 작업이 다른 배포 환경에 지정할 수 있습니다 그림 2는 원격 실행 시스템을 보여줍니다.
그림 2. 원격 실행 시스템
각 사용자의 컴퓨터에서 실행되는 빌드 도구 (사용자가 사람 또는 사람) 엔지니어 또는 자동화된 빌드 시스템)이 요청을 중앙 빌드 마스터로 보냅니다. 빌드 마스터가 요청을 구성요소 작업 및 일정으로 세분화 이러한 작업을 수행하는 데 도움이 됩니다. 각 작업자 사용자가 지정한 입력으로 요청한 작업을 수행하고 결과 아티팩트를 작성합니다 이러한 아티팩트는 다른 애플리케이션과 최종 출력이 필요할 때까지 머신이 필요로 하는 작업을 실행하는 사용자에게 전송됩니다
이러한 시스템을 구현하는 데 있어서 가장 까다로운 부분은 사용자의 로컬 머신 간에 분할할 수 있습니다 작업자는 다른 작업자가 생성한 중간 아티팩트 및 최종 출력에 따라 사용자의 로컬 시스템으로 다시 보내야 합니다. 이를 위해 각 작업자가 쓰기 작업을 수행하도록 하여 앞에서 설명한 분산 캐시의 최상위에 배치 캐시에서 종속 항목을 읽을 수 있습니다 마스터 블록은 작업자들은 자신이 의존하는 모든 것이 완료될 때까지 진행하지 않을 것입니다. 이 경우 캐시에서 입력을 읽을 수 있습니다. 최종 결과물은 로컬 컴퓨터에서 다운로드할 수 있도록 합니다. 또한 사용자의 소스 트리에 있는 로컬 변경사항을 내보내는 별도의 수단을 제공하여 작업자는 빌드 전에 이러한 변경사항을 적용할 수 있습니다.
이를 위해 지금까지 설명한 아티팩트 기반 빌드 시스템의 모든 부분을 함께 논의해야 합니다. 빌드 환경은 인간의 개입 없이 작업자를 가동할 수 있도록 합니다. 빌드 프로세스 자체는 완전히 독립적이어야 합니다. 왜냐하면 각 단계는 다른 머신에서 실행될 수 있습니다 출력은 완전히 확정적이어야 하므로 각 작업자는 다른 작업자로부터 받은 결과를 신뢰할 수 있습니다. 이러한 보장은 작업 기반 시스템이 제공하기가 매우 어려운데, 따라서 가상 머신 인터페이스를 기반으로 신뢰할 수 있는 원격 실행 시스템을 있습니다
Google의 배포 빌드
2008년부터 Google은 Android 및 iOS 개발자용 애플리케이션인 원격 캐싱과 원격 실행이 있습니다(그림 3 참조).
그림 3. Google의 분산 빌드 시스템
Google의 원격 캐시를 ObjFS라고 합니다. 이 서비스는 데이터를 저장하는 백엔드로 프로덕션 제품군 전반에 분산된 Bigtable의 빌드 출력 objfsd라는 이름의 프런트엔드 FUSE 데몬이 포함되어 있어 가상 머신을 만드는 법을 배웠습니다 FUSE 데몬을 사용하면 엔지니어가 워크스테이션에 저장된 정상적인 파일이지만 파일 콘텐츠가 Google Cloud Platform에서 직접 요청한 일부 파일에 대해서만 있습니다. 요청 시 파일 콘텐츠를 제공하면 네트워크와 디스크 모두 대폭 감소 시스템을 저장했을 때보다 두 배나 빠르게 개발자의 로컬 디스크에 저장됩니다.
Google의 원격 실행 시스템은 Forge입니다. Blaze의 Forge 클라이언트 (Bazel의 내부에서 상응하는 항목) 공급업체는 각 작업에 대한 요청을 데이터 센터로 라우팅됩니다 스케줄러는 작업 캐시 유지 결과를 표시하여 작업이 이미 완료된 경우 즉시 응답을 반환하도록 할 수 있습니다. 시스템의 다른 사용자에 의해 생성된 모든 URL입니다. 그렇지 않으면 작업이 할 수 있습니다 큰 실행자 작업 풀은 계속해서 이 큐의 작업을 읽고 실행하고 그 결과를 ObjFS Bigtable에 직접 저장해야 합니다. 이러한 실행자가 향후 작업을 위해 결과를 사용하거나 최종 사용자가 objfsd를 통해 지정할 수 있습니다
결과적으로 모든 빌드를 효율적으로 지원하도록 확장되는 시스템을 구축할 수 있습니다. 일하고 있습니다. 그리고 Google 빌드의 규모는 실로 엄청납니다. 수백만 개의 빌드를 실행하여 수백만 건의 테스트 사례를 실행하며 페타바이트 규모의 생산 매일 수십억 줄의 소스 코드에서 빌드 출력의 정확도를 높입니다. 뿐만 아니라 이러한 시스템을 통해 우리 엔지니어들은 복잡한 코드베이스를 신속하게 빌드할 수 있었고, 수많은 자동화 도구와 시스템을 구현할 수 있었습니다. 있습니다.