Cloud Storage FUSE는 데이터 검색 성능을 향상시키는 데 도움이 되는 네 가지 유형의 캐싱 옵션을 제공합니다.
파일 캐싱 개요
Cloud Storage FUSE 파일 캐시는 개발자가 선택한 더 빠른 캐시 스토리지에서 반복 파일 읽기를 제공하는 클라이언트 기반 읽기 캐시입니다.
파일 캐싱의 이점
성능 향상: 파일 캐싱은 캐시 미디어에서 직접 읽기를 제공하여 지연 시간과 처리량을 개선합니다. 캐시에서 제공하면 소규모 및 임의 I/O 작업이 훨씬 더 빠를 수 있습니다.
기존 용량 사용: 파일 캐싱은 추가 스토리지에 대한 비용 없이 캐시 디렉터리에 대해 기존 프로비저닝된 머신 용량을 사용할 수 있습니다. 여기에는
a2-ultragpu및a3-highgpu같은 Cloud GPU 머신 유형과 함께 번들로 제공되는 로컬 SSD, 각 VM에서 사용되는 부팅 디스크인 Persistent Disk, 또는 인메모리/tmpfs가 포함됩니다.요금 절감: 캐시 적중은 로컬에서 제공되며 Cloud Storage 작업 또는 네트워크 요금이 발생하지 않습니다.
AI 및 ML 학습의 총소유비용 개선: 파일 캐싱은 데이터를 더 빠르게 로드하여 Cloud GPU 및 Cloud TPU 사용률을 높이고 학습 시간을 단축하며 AI 및 ML 학습 워크로드의 가성비를 높입니다.
파일 캐시 사용 설정 및 구성
파일 캐시는 기본적으로 사용 중지되어 있으며 Cloud Storage FUSE 구성 파일을 사용하여 사용 설정하고 구성할 수 있습니다. 캐싱 동작은 다음 필드를 사용하여 제어할 수 있습니다.
max-size-mb: 캐시 디렉터리에서 캐시된 데이터가 차지할 수 있는 최대 용량을 제어합니다. 기본적으로max-size-mb필드는 캐시된 데이터가 캐시 디렉터리의 사용 가능한 용량을 모두 차지할 때까지 커질 수 있도록 설정됩니다.cache-dir: 파일 캐시 데이터를 저장할 디렉터리를 지정합니다. 캐시 디렉터리를 지정하는 것은 파일 캐시를 사용 설정하기 위한 기본 요건입니다.ttl-secs: 캐시된 데이터가 비활성 상태가 되어 Cloud Storage에서 새로고침해야 하는 시점을 결정합니다. 기본적으로ttl-secs필드는 비활성 상태가 60초간 지속되면 만료되고 Cloud Storage에서 새로고침하도록 설정됩니다. 이 값을 늘리는 것이 좋습니다.캐시 데이터 무효화를 제어하는 방법은 캐시 데이터 무효화 구성을 참조하세요. 캐시된 데이터의 제거에 관한 자세한 내용은 제거를 참조하세요.
enable-parallel-downloads: 파일 캐시 디렉터리를 미리 가져오기 버퍼로 사용하여 파일을 동시에 다운로드하도록 여러 작업자를 사용함으로써 처음 읽기를 포함하여 크기가 1GB를 초과하는 대용량 파일의 읽기 성능을 가속화합니다. 제공 및 체크포인트 복원 작업을 위해 동시 다운로드를 사용 설정하는 것이 좋습니다. 동시 다운로드 사용 설정 및 구성에 대한 자세한 내용은 동시 다운로드 구성을 참조하세요.
임의 & 부분 읽기
첫 번째 파일 읽기 작업이 파일 시작 부분인 오프셋 0에서 시작하면 Cloud Storage FUSE 파일 캐시는 좁은 범위의 하위 집합에서만 읽기를 수행 중인 경우에도 전체 파일을 수집하여 캐시에 로드합니다. 이렇게 하면 동일한 객체의 후속 임의 읽기 또는 부분 읽기를 캐시에서 직접 제공할 수 있습니다.
파일의 첫 번째 읽기 작업이 오프셋 0이 아닌 다른 곳에서 시작되는 경우 Cloud Storage FUSE는 기본적으로 비동기 전체 파일 가져오기를 트리거하지 않습니다.
Cloud Storage FUSE가 초기 무작위 읽기 시 파일을 캐시로 수집하도록 이 동작을 변경하려면 cache-file-for-range-read 플래그를 true로 설정하세요. 동일한 객체에서 여러 임의 또는 부분 읽기 작업이 수행되는 경우 cache-file-for-range-read 플래그를 사용 설정하는 것이 좋습니다.
제거
캐시된 메타데이터 및 데이터의 제거는 max-size-mb 한도당 구성된 공간 기준점에 도달하면 시작되는 가장 최근 사용(LRU) 알고리즘을 기반으로 합니다. 항목이 TTL을 기준으로 만료되면 먼저 Cloud Storage로 메타데이터 가져오기 호출이 수행되고 네트워크 지연 시간이 발생합니다. 데이터와 메타데이터는 별도로 관리되므로 한 항목이 제거되거나 무효화될 수 있으며 다른 항목은 제거되지 않을 수 있습니다.
성능
Cloud Storage FUSE 캐싱은 로컬 SSD, Persistent Disk, 인메모리 tmpfs, Filestore 등 사용자가 선택한 스토리지에서 지원하는 모든 사용자 지정 디렉터리에서 작동합니다. Cloud Storage FUSE 캐시 성능은 최소한의 오버헤드로 캐시에서 사용하는 기본 스토리지와 일치합니다.
전체 데이터 세트를 캐시 용량에 적절히 맞춰 최상의 성능을 제공하고 캐시 스래싱을 방지합니다. 또한 캐시 미디어가 제공할 수 있는 최대 용량과 성능도 고려하세요. 프로비저닝된 캐시의 최대 성능, 용량 한도 또는 둘 다에 도달한 경우 Cloud Storage FUSE보다 한도가 훨씬 높은 Cloud Storage에서 직접 읽는 것이 좋습니다.
지속성
Cloud Storage FUSE 캐시는 마운트 해제 및 다시 시작 시 유지되지 않습니다. 파일 캐싱의 경우 캐시에서 파일을 제공하는 데 필요한 메타데이터 항목은 마운트 해제 및 다시 시작 시 제거되지만 파일 캐시의 데이터는 여전히 파일 디렉터리에 있을 수 있습니다. 마운트 해제 또는 다시 시작 후 파일 캐시 디렉터리의 데이터를 삭제해야 합니다.
보안
캐싱을 사용 설정하면 Cloud Storage FUSE는 cache-dir 필드를 사용하여 지정한 캐시 디렉터리를 캐시의 기본 디렉터리로 사용하여 Cloud Storage 버킷의 파일을 암호화되지 않은 형식으로 유지합니다. 이 캐시 디렉터리에 대한 액세스 권한이 있는 모든 사용자 또는 프로세스는 이러한 파일에 액세스할 수 있습니다.
이 디렉터리에 대한 액세스를 제한하는 것이 좋습니다.
파일 캐시에 대한 직접 또는 다중 액세스
Cloud Storage FUSE 이외의 프로세스를 사용하여 캐시 디렉터리의 파일에 액세스하거나 파일을 수정하면 데이터가 손상될 수 있습니다. Cloud Storage FUSE 캐시는 동일하거나 다른 머신에서 실행되는 다양한 Cloud Storage FUSE 프로세스를 인식하지 못한 채 각 Cloud Storage FUSE 실행 프로세스에만 적용됩니다. 따라서 다양한 Cloud Storage FUSE 프로세스에 동일한 캐시 디렉터리를 사용하지 않는 것이 좋습니다.
동일한 머신에서 여러 Cloud Storage FUSE 프로세스를 실행해야 하는 경우 각 Cloud Storage FUSE 프로세스는 고유한 특정 캐시 디렉터리를 가져오거나 다음 방법 중 하나를 사용하여 데이터가 손상되지 않도록 해야 합니다.
공유 캐시로 모든 버킷 마운트: 동적 마운트를 사용하여 공유 캐시에서 단일 프로세스로 액세스할 수 있는 모든 버킷을 마운트합니다. 자세한 내용은 Cloud Storage FUSE 동적 마운트를 참조하세요.
특정 버킷에 캐싱 사용 설정: 정적 마운트를 사용하여 지정된 버킷에만 캐싱을 사용 설정합니다. 자세한 내용은 Cloud Storage FUSE 정적 마운트를 참조하세요.
특정 폴더 또는 디렉터리만 캐시: 전체 버킷을 마운트하는 대신 특정 버킷 수준 폴더만 마운트하고 캐시합니다. 자세한 내용은 버킷 내에 디렉터리 마운트를 참고하세요.
통계 캐싱 개요
Cloud Storage FUSE 통계 캐시는 크기, 수정 시간 또는 권한과 같은 파일 속성 관련 작업에 대한 성능을 향상시켜 주는 객체 메타데이터용 캐시입니다. 통계 캐시를 사용하면 Cloud Storage에 통계 객체 요청을 전송하는 대신 캐시된 데이터를 사용하여 작업을 수행함으로써 지연 시간을 단축시킬 수 있습니다. 통계 캐싱에 관한 자세한 내용은 GitHub의 시맨틱스 문서를 참고하세요.
통계 캐시는 기본적으로 사용 설정되며 Cloud Storage FUSE 구성 파일을 사용하여 구성할 수 있습니다. 캐시의 최대 크기는 기본값이 32(32MB)인 stat-cache-max-size-mb 필드로 제어됩니다. 캐시의 TTL은 기본값은 60(60초)인 ttl-secs 필드로 제어됩니다.
권장사항
통계 캐싱의 경우 워크로드에 파일이 최대 20,000개까지 포함된 경우 stat-cache-max-size-mb 필드에 기본값 32를 사용하는 것이 좋습니다.
워크로드가 파일 20,000개를 초과하면 파일 6,000개가 추가될 때마다 stat-cache-max-size-mb 값을 10씩 늘립니다(파일당 약 1,500바이트).
stat-cache-max-size-mb는 마운트 수준의 한도이며 실제 메모리 사용량은 지정한 값보다 낮을 수 있습니다. 또는 stat-cache-max-size-mb를 -1로 설정하여 통계 캐시에서 필요한 만큼 메모리를 사용하게 할 수 있습니다.
유형 캐싱 개요
Cloud Storage FUSE 유형 캐시는 파일 또는 디렉터리 존재와 관련된 메타데이터 작업의 성능을 가속화하는 메타데이터 캐시입니다. 유형 캐시를 사용하면 이 정보를 로컬에 저장하여 파일이나 디렉터리가 존재하는지 확인하기 위해 Cloud Storage에 요청하는 횟수가 줄어들어 지연 시간이 개선됩니다. 유형 캐싱에 대한 자세한 내용은 GitHub의 시맨틱스 문서를 참조하세요.
유형 캐시는 기본적으로 사용 설정되어 있으며 Cloud Storage FUSE 구성 파일을 사용하여 구성할 수 있습니다. 캐시의 최대 크기는 기본값이 4(4MB)인 type-cache-max-size-mb 필드로 제어됩니다. 캐시의 TTL은 기본값은 60(60초)인 ttl-secs 필드로 제어됩니다.
권장사항
유형 캐싱의 경우 마운트하는 버킷의 단일 디렉터리 내에 있는 최대 파일 수에 파일이 20,000개 이하로 포함되어 있으면 type-cache-max-size-mb 필드에 기본값 4를 사용하는 것이 좋습니다. 마운트하는 단일 디렉터리 내의 최대 파일 수에 파일이 20,000개를 초과하면 파일 5,000개마다 type-cache-max-size-mb 값을 1만큼 늘립니다(약 200바이트).
type-cache-max-size-mb는 마운트 수준 한도이며 실제 메모리 사용량은 지정된 값보다 낮을 수 있습니다. 또는 type-cache-max-size-mb 값을 -1로 설정하여 유형 캐시에서 필요한 만큼 메모리를 사용하도록 할 수 있습니다.
목록 캐싱 개요
Cloud Storage FUSE 목록 캐시는 디렉터리 및 파일 목록, 또는 목록 작업 속도를 개선하는 응답인 ls를 위한 것입니다. 목록 캐싱은 AI/ML 학습 실행과 같이 실행의 일부로 전체 디렉터리 목록을 반복하는 워크로드에 특히 유용합니다.
목록 캐시는 머신의 메모리에 보관되고 Cloud Storage FUSE에 의해 제어되는 통계 및 유형 캐시와 달리 메모리 가용성을 기반으로 커널에 의해 제어되는 페이지 캐시의 메모리에 보관됩니다.
목록 캐싱 사용 설정
목록 캐시는 기본적으로 사용 중지되어 있습니다.
다음 값 중 하나를 가진 kernel-list-cache-ttl-secs 필드를 사용하여 목록 캐싱을 사용 설정할 수 있습니다.
양수 값은 커널의 페이지 캐시에 디렉터리 목록 응답을 유지하기 위한 TTL(수명)을 초 단위로 나타냅니다.
-1값은 항목 만료를 우회하고 사용 가능한 경우 캐시에서 목록 응답을 반환합니다.
목록 캐싱을 사용 설정하고 구성하려면 Cloud Storage FUSE 구성 파일을 참조하세요.
캐시 무효화 구성
다음 섹션에서는 모든 캐시 유형에 대해 캐시 무효화를 구성하는 방법에 대해 설명합니다.
파일, 통계, 유형 캐시 무효화
파일, 통계, 유형 캐시의 경우 ttl-secs 필드는 Cloud Storage에서 가져온 시점부터 만료되어 새로고침해야 하는 시점까지 캐시된 메타데이터가 사용되는 기간인 TTL을 초 단위로 지정합니다.
Cloud Storage FUSE 구성 파일에서 ttl-secs를 구성할 수 있습니다.
ttl-secs 필드는 기본적으로 60으로 설정됩니다.
ttl-secs 값을 0보다 큰 값으로 지정하면 파일 캐시에 대한 메타데이터는 지정한 기간 동안만 유효합니다.
목록 캐싱의 경우 일관성 요구의 균형을 유지하면서 반복 읽기 간의 예상 시간을 기준으로 ttl-secs 값을 늘리는 것이 좋습니다.
데이터 변경의 중요도와 빈도에 따라 워크로드에서 허용하는 만큼 ttl-secs 값을 높게 설정하는 것이 좋습니다. 메타데이터 항목이 유효하지 않게 되면 후속 읽기는 Cloud Storage에서 쿼리됩니다.
캐시된 메타데이터가 만료되어 새로고침해야 하는 시점까지의 특정 TTL을 초 단위로 나타내는 값을 허용하는 것 외에도 다음 값을 사용하여 파일 읽기 방식을 지정할 수 있습니다.
ttl-secs값0: 캐시의 일관성을 유지하기 위해 캐시에서 제공되는 파일을 확인하도록 Cloud Storage에GET메타데이터 호출을 실행하여 가장 최신의 데이터가 포함된 파일을 읽게 합니다. 캐시의 파일이 최신 상태인 경우 캐시에서 직접 제공됩니다.0이외의 값을 지정하면 메타데이터를 먼저 확인하기 위해 항상 Cloud Storage에 호출해야 하므로 성능이 저하될 수 있습니다. 파일이 캐시에 있고 변경되지 않은 경우GET메타데이터 호출 후 일관성 있게 파일이 캐시에서 제공됩니다.ttl-secs값-1: 사용 가능한 경우 일관성을 확인하지 않고 항상 캐시에서 파일을 읽게 합니다. 일관성을 확인하지 않고 파일을 제공하면 일관되지 않은 데이터를 제공할 수 있으며, 변경되지 않는 데이터가 있는 작업에서 실행되는 워크로드에만 일시적으로 사용해야 합니다. 예를 들어-1값 사용은 여러 에포크에 걸쳐 동일한 데이터를 변경 없이 읽어들이는 머신러닝 학습에 유용합니다.
목록 캐시 무효화
목록 캐시 무효화는 kernel-list-cache-ttl-secs 필드를 사용하여 0보다 큰 값을 지정하여 설정됩니다. 디렉터리 목록 응답은 커널의 페이지 캐시에 보관되며 지정한 기간 동안 유효하게 유지됩니다.
기본적으로 목록 캐시는 사용 중지되고 값은 0으로 설정됩니다. -1 값을 지정하면 Cloud Storage FUSE는 목록 캐시 만료를 사용 중지하고, 사용 가능한 경우 캐시에서 목록 응답을 반환합니다.
캐시된 데이터의 읽기 경로
Cloud Storage FUSE 캐시는 캐시에 수집된 후 반복 읽기를 가속화합니다. 처음 읽기와 캐시 부적중은 모두 Cloud Storage로 직접 이동하며, 일반적인 Cloud Storage 네트워크 지연 시간이 적용됩니다.
워크로드를 실행하기 전에 먼저 마운트된 버킷의 파일을 재귀적으로 나열하여 더 빠른 일괄 처리 메서드로 통계 및 유형 캐시를 미리 채우고 최초 실행 시 성능을 개선하는 것이 좋습니다.
ls -R MOUNT_POINT > /dev/null
고려사항
파일 캐싱, 통계 캐싱, 유형 캐싱 또는 목록 캐싱을 사용 설정하면 성능은 향상되지만 일관성이 저하될 수 있으며, 이는 일반적으로 변경 비율이 높은 여러 클라이언트를 사용하여 동일한 버킷에 액세스할 때 발생합니다. 일관성에 미치는 영향을 줄이려면 버킷을 읽기 전용으로 마운트하는 것이 좋습니다. 캐싱 동작에 관한 자세한 내용은 GitHub의 Cloud Storage FUSE 시맨틱스 문서를 참조하세요.
파일 캐시 항목이 아직 TTL을 기준으로 만료되지 않았고 파일이 캐시에 있으면 Cloud Storage에 대해 어떠한 요청 없이 로컬 클라이언트 캐시에서 전체 작업이 제공됩니다.
파일 캐시 항목이 TTL을 기준으로 만료된 경우 먼저 Cloud Storage로 메타데이터 가져오기 호출이 실행되고, 파일이 캐시에 없으면 Cloud Storage에서 파일이 검색됩니다. 두 작업 모두 네트워크 지연 시간이 발생합니다. 메타데이터 항목이 무효화되었지만 파일이 캐시에 있고 객체 생성이 변경되지 않은 경우, 데이터가 유효한지 여부를 확인하기 위해 Get 메타데이터 호출을 수행한 후에만 캐시에서 파일이 제공됩니다.
Cloud Storage FUSE 클라이언트가 캐시된 파일 또는 해당 메타데이터를 수정하는 경우 파일은 즉시 무효화되고 동일한 클라이언트의 다음 읽기에서 일관성이 보장됩니다. 하지만 여러 클라이언트가 동일한 파일이나 메타데이터에 액세스하고 해당 항목이 캐시되는 경우, 파일 또는 메타데이터의 캐시된 버전을 읽지만, 해당 클라이언트의 TTL 설정에 의해 파일이 무효화될 때까지는 업데이트된 버전을 읽지 않습니다.
다음 단계
파일 캐싱 사용 및 구성 알아보기