캐시여부 결정하기

모노레포를 구축할 때는 이전에 실행한 태스크를 기반으로 태스크를 건너뛸 수 있는지 여부를 태스크별로 결정해야 한다. 이 동작은 turbo.json 내부의 pipeline.<task>.cache 를 통해 제어할 수 있다:

{
  "$schema": "https://turbo.build/schema.json",
  "pipeline": {
    "lint": {
      "cache": true
    }
  }
}

터보레포의 기본값은 "cache": true 이므로 이 값을 명시적으로 지정할 필요는 없다:

{
  "$schema": "https://turbo.build/schema.json",
  "pipeline": {
    "lint": {}
  }
}

이 예제에서는 터보레포에 lint 태스크를 캐시하도록 지시했다. 하지만 cache 키만 지정했기 때문에 캐시되는 것은 터미널 출력뿐이다. lint 나 test 와 같은 일부 유형의 작업의 경우 이러한 유형의 최소 구성이 적합하다!

그러나 대부분의 작업에서는 캐시할 대상과 캐시가 유효하기 위해 일치해야 하는 파일 및 환경 변수도 지정해야 한다.

캐시를 사용하지 않는 경우

캐싱은 기본 동작이며 대부분의 상황에서 이상적이기 때문에 언제 캐싱을 해제해야 하는지 아는 것이 중요하다.

1. 매우 빠르게 실행되는 태스크. 원격 캐시를 사용하려는 태스크가 네트워크 왕복 시간(예: 100밀리초) 이내에 실행될 수 있다면 작업을 캐시하지 않는 것이 좋다.
2. 출력 에셋이 방대한 태스크. 태스크 실행의 결과로 Docker 컨테이너가 생성되는 경우 캐시 아티팩트를 생성하고, 업로드하고, 다운로드하는 데 소요되는 시간이 재생성하는 시간을 초과할 수 있다.
3. 비변형 파일 시스템 태스크. "한 디렉토리에서 다른 디렉토리로 이미지 전체를 이동"하는 태스크의 경우 시간이 오래 걸릴 수 있지만 로컬에서 수행하는 프로세스가 이동한 자산을 캐싱하고 복원하는 것보다 항상 빠르다.
4. 자체 애플리케이션 동작 인식 캐시를 구현하는 태스크. 예를 들어 Docker의 레이어 캐시처럼 일부 작업에는 자체 내부 캐싱 동작이 있다. 대부분의 경우 이러한 보조 캐시는 터보레포와 함께 작동하지만 경우에 따라 구성이 매우 복잡해질 수 있다.

터보레포에 익숙해지면 이러한 지침 중 일부가 다른 환경에서 실행할 때 예상치 못한 장단점이 있다는 것을 알게 될 것이다. 예를 들어, 지속적 통합(CI) 서비스에서 디스크 읽기가 네트워크 읽기보다 훨씬 느린 경우가 있다. 자체 프로젝트에서 동작을 테스트하여 캐싱을 하지 않아도 성능에 이점이 있는지 확인해야 한다.