스카이프레임

컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.
문제 신고 출처 보기

Bazel의 동시 평가 및 성과 증분 모델

데이터 모델

데이터 모델은 다음 항목으로 구성됩니다.

  • SkyValue: 노드라고도 합니다. SkyValues는 빌드 과정에서 빌드되는 모든 데이터와 빌드의 입력을 포함하는 변경할 수 없는 객체입니다. 예를 들어 입력 파일, 출력 파일, 대상, 구성된 대상이 있습니다.
  • SkyKey: SkyValue을 참조하는 변경할 수 없는 짧은 이름입니다(예: FILECONTENTS:/tmp/foo 또는 PACKAGE://foo).
  • SkyFunction. 키 및 종속 노드를 기준으로 노드를 빌드합니다.
  • 노드 그래프 노드 간의 종속 항목 관계를 포함하는 데이터 구조입니다.
  • Skyframe. Bazel이 기반으로 하는 점진적 평가 프레임워크의 코드 이름입니다.

평가

빌드는 빌드 요청을 나타내는 노드 평가로 구성됩니다 (이 상태가 Google이 추구하는 상태이지만 그 과정에서 많은 레거시 코드가 있습니다). 먼저 최상위 SkyKey의 키를 사용하여 SkyFunction를 찾아 호출합니다. 그런 다음 함수는 리프 노드 (일반적으로 파일 시스템의 입력 파일을 나타내는 노드)에 도달할 때까지 최상위 노드를 평가하는 데 필요한 노드에 대한 평가를 요청합니다. 결과적으로 다른 함수가 호출됩니다. 마지막으로 최상위 SkyValue의 값, 일부 부작용 (예: 파일 시스템의 출력 파일), 빌드와 관련된 노드 간 종속 항목의 방향성 비순환 그래프가 생성됩니다.

SkyFunction는 작업을 실행하는 데 필요한 모든 노드를 미리 알 수 없는 경우 여러 패스에서 SkyKeys을 요청할 수 있습니다. 심볼릭 링크로 판명된 입력 파일 노드를 평가하는 간단한 예시입니다. 함수에서는 파일을 읽으려고 하고 심볼릭 링크임을 깨닫고 심볼릭 링크 대상을 나타내는 파일 시스템 노드를 가져옵니다. 그러나 그 자체는 심볼릭 링크가 될 수 있으며, 이 경우 원래 함수도 타겟을 가져와야 합니다.

함수는 코드에서 SkyFunction 인터페이스로 표현되고 SkyFunction.Environment라는 인터페이스에서 제공하는 서비스입니다. 함수로 수행할 수 있는 작업은 다음과 같습니다.

  • env.getValue를 호출하여 다른 노드의 평가를 요청합니다. 노드를 사용할 수 있으면 값이 반환되고 그렇지 않으면 null가 반환되며 함수 자체가 null을 반환할 것으로 예상됩니다. 후자의 경우 종속 노드가 평가된 후 원래 노드 빌더가 다시 호출되지만, 이번에는 동일한 env.getValue 호출이 null이 아닌 값을 반환합니다.
  • env.getValues()를 호출하여 다른 여러 노드의 평가를 요청합니다. 이는 종속 노드가 병렬로 평가된다는 점을 제외하고 본질적으로 동일합니다.
  • 호출 중에 계산
  • 파일 시스템에 파일을 쓰는 등의 부작용이 있습니다. 두 개의 서로 다른 기능이 서로의 발바닥에 영향을 주지 않도록 주의를 기울여야 합니다. 일반적으로 쓰기 부수 효과 (Bazel이 바깥쪽으로 흐르는 데이터)는 괜찮지만 읽기 부수 효과 (등록된 종속 항목 없이 Bazel 안으로 데이터가 흐르는 경우)는 등록되지 않은 종속 항목이므로 잘못된 증분 빌드가 발생할 수 있습니다.

SkyFunction 구현은 종속 항목을 요청하는 것 이외의 방법 (예: 파일 시스템 직접 읽기)으로 데이터에 액세스해서는 안 됩니다. Bazel이 읽은 파일의 데이터 종속 항목을 등록하지 않아 증분 빌드가 잘못되기 때문입니다.

함수에 작업을 수행할 만큼 충분한 데이터가 있으면 완료를 나타내는 null 이외의 값을 반환해야 합니다.

이 평가 전략은 여러 가지 이점이 있습니다.

  • 밀폐성. 함수가 다른 노드에 따라 입력 데이터만 요청하는 경우 Bazel은 입력 상태가 동일한 경우 동일한 데이터가 반환되도록 보장할 수 있습니다. 모든 Sky 함수가 확정적이면 전체 빌드도 확정적입니다.
  • 정확하고 완벽한 성과 증분을 제공합니다. 모든 함수의 입력 데이터가 모두 기록되면 Bazel은 입력 데이터가 변경될 때 무효화해야 하는 노드 세트만 무효화할 수 있습니다.
  • 동시 로드입니다. 함수는 종속 항목을 요청하는 방법으로만 서로 상호작용할 수 있으므로 서로 종속되지 않는 함수는 병렬로 실행될 수 있으며 Bazel은 결과가 순차적으로 실행되는 경우와 동일하도록 보장할 수 있습니다.

Incrementality

함수는 다른 노드에 따라서만 입력 데이터에 액세스할 수 있으므로 Bazel은 입력 파일에서 출력 파일로의 완전한 데이터 흐름 그래프를 빌드할 수 있으며, 이 정보를 사용하여 실제로 다시 빌드해야 하는 노드, 즉 변경된 입력 파일의 역전이적 클로저를 다시 빌드할 수 있습니다.

구체적으로는 상향식과 하향식 등 두 가지 성과 증분 전략이 있습니다. 어떤 종속 항목이 가장 적합한지는 종속 항목 그래프의 모양에 따라 다릅니다.

  • 상향식 무효화 중에 그래프가 빌드되고 변경된 입력 세트가 알려진 후 변경된 파일이 전이적으로 의존하는 모든 노드가 무효화됩니다. 동일한 최상위 노드가 다시 빌드된다는 것을 알고 있는 경우에 가장 적합합니다. 상향식 무효화를 위해서는 이전 빌드의 모든 입력 파일에서 stat()를 실행하여 변경사항이 적용되었는지 확인해야 합니다. inotify 또는 유사한 메커니즘을 사용하여 변경된 파일에 관해 알아보면 이를 개선할 수 있습니다.

  • 하향식 무효화 중에는 최상위 노드의 전이적 클로저가 확인되며, 이러한 과도한 폐쇄의 상태가 양호한 노드만 유지됩니다. 현재 노드 그래프가 크다는 것을 알면 다음 노드 빌드의 작은 하위 집합만 필요할 때 이 방법을 사용하면 좋습니다. 상향식 무효화는 두 번째 빌드의 작은 그래프를 따라 이동하는 하향식 무효화와 달리 첫 번째 빌드의 큰 그래프를 무효화합니다.

현재 상향식 무효화만 수행하고 있습니다.

증분성을 높이기 위해 변경 프루닝을 사용합니다. 노드가 무효화되었지만 다시 빌드할 때 새 값이 이전 값과 동일한 경우 이 노드의 변경으로 인해 무효화된 노드가 '복구'됩니다.

예를 들어 C++ 파일에서 주석을 변경하면 이 파일에서 생성된 .o 파일이 동일하므로 유용합니다. 따라서 링커를 다시 호출하지 않아도 됩니다.

증분 연결 / 컴파일

이 모델의 주요 제한사항은 노드 무효화가 '전부 아니면 무관'한가라는 점입니다. 종속 항목이 변경되면 종속된 노드는 항상 처음부터 다시 빌드됩니다. 이는 더 나은 알고리즘이 변경사항을 기반으로 변경되어 노드의 기존 값을 변경하더라도 마찬가지입니다. 이것이 유용한 예입니다.

  • 증분 연결
  • .jar에서 단일 .class 파일이 변경되면 이론적으로 .jar 파일을 처음부터 다시 빌드하는 대신 수정할 수 있습니다.

현재 Bazel이 이러한 방식을 원칙적으로 지원하지 않는 이유 (점진적 연결에 대한 지원은 어느 정도 있지만 Skyframe 내에서 구현되지 않음)는 두 가지입니다. 성능상의 이점이 적었고 변형의 결과가 깔끔한 재빌드와 동일하고 Google에서 비트마다 반복 가능한 빌드의 가치를 보장하기가 어렵기 때문입니다.

지금까지는 비용이 많이 드는 빌드 단계를 간단히 분해하고 부분적인 재평가를 달성하여 항상 충분한 성능을 얻을 수 있었습니다. 즉, 앱의 모든 클래스를 여러 그룹으로 분할하고 별도로 덱싱하는 작업을 했습니다. 이렇게 하면 그룹의 클래스가 변경되지 않으면 덱싱을 다시 실행할 필요가 없습니다.

Bazel 개념에 매핑

다음은 Bazel이 빌드를 수행하는 데 사용하는 일부 SkyFunction 구현에 대한 대략적인 개요입니다.

  • FileStateValue를 포함합니다. lstat()의 결과 또한 기존 파일의 경우 파일의 변경사항을 감지하기 위해 추가 정보를 계산합니다. 이는 스카이프레임 그래프에서 가장 낮은 수준의 노드이며 종속 항목이 없습니다.
  • FileValue). 파일의 실제 콘텐츠 또는 확인된 경로에 중요한 사항이 사용됩니다. 상응하는 FileStateValue 및 해결되어야 하는 모든 심볼릭 링크(예: a/bFileValue, a/b의 확인된 경로 및 a/b의 확인된 경로가 필요함)에 따라 다릅니다. FileStateValue를 구분하는 것은 중요한데, 이는 예를 들어 파일 시스템 glob(예: srcs=glob(["*/*.java"]))을 평가하는 경우 파일의 내용이 실제로 필요하지 않기 때문입니다.
  • DirectoryListingValue로 실행합니다. 기본적으로 readdir()의 결과입니다. 디렉터리와 연결된 FileValue에 따라 다릅니다.
  • PackageValue). BUILD 파일의 파싱된 버전을 나타냅니다. 연결된 BUILD 파일의 FileValue에 따라 달라지며, 패키지의 glob을 해결하는 데 사용되는 DirectoryListingValue (전반적으로 BUILD 파일의 콘텐츠를 나타내는 데이터 구조)에 전이됩니다.
  • ConfiguredTargetValue입니다. 타겟을 분석하는 동안 생성된 작업 집합과 이 대상에 종속된 구성된 대상에 제공된 정보의 튜플인 구성된 대상을 나타냅니다. 상응하는 대상이 있는 PackageValue, 직접 종속 항목의 ConfiguredTargetValues, 빌드 구성을 나타내는 특수 노드에 따라 다릅니다.
  • 아티팩트 값. 소스 또는 출력 아티팩트와 같이 빌드에 있는 파일을 나타냅니다. 아티팩트는 파일과 거의 동일하며, 빌드 단계의 실제 실행 중에 파일을 참조하는 데 사용됩니다. 소스 파일의 경우 연결된 노드의 FileValue에 종속되며 출력 아티팩트의 경우 아티팩트를 생성하는 작업의 ActionExecutionValue에 종속됩니다.
  • ActionExecutionValue). 작업 실행을 나타냅니다. 입력 파일의 ArtifactValues에 따라 다릅니다. 실행 중인 작업은 현재 sky 키 내에 포함되어 있으며, 이는 sky 키는 작아야 한다는 개념에 위배됩니다. 이 불일치 문제를 해결하기 위해 노력하고 있습니다. Skyframe에서 실행 단계를 실행하지 않으면 ActionExecutionValueArtifactValue을 사용하지 않습니다.