Rapid Cache

이 페이지에서는 Cloud Storage 버킷을 위해 SSD로 지원되는 영역 읽기 캐시를 제공하는 Rapid Cache에 대해 설명합니다. 이를 통해 저장된 데이터의 처리량을 늘리고 지연 시간을 줄일 수 있습니다. Rapid Cache는 필요에 따라 자동으로 확장되거나 축소되는 스토리지 용량 및 대역폭을 제공합니다.

Rapid Cache는 이러한 이점 덕분에 특히 읽기에 집중된 워크로드와 관련된 성능을 개선하고 네트워크 비용을 줄이는 데 도움이 됩니다.

Rapid Cache에서 캐시를 만들고 관리하는 방법은 캐시 만들기 및 관리를 참고하세요.

기본 원리

Rapid Cache를 사용하면 워크로드와 동일한 영역에서 캐시를 만들 수 있습니다. 영역에 캐시를 만들 때 영역에서 시작되는 데이터 읽기 요청은 버킷 대신 캐시에서 처리됩니다. 각 캐시는 캐시와 동일한 영역에서 클라이언트에 서비스를 제공합니다. 캐시와 동일한 영역에 있는 VM이 데이터를 읽을 때만 버킷의 캐시에 데이터가 수집됩니다. 또한 쓰기 시 수집을 구성하면 데이터가 버킷에 기록될 때 데이터를 수집할 수 있습니다. 메타데이터가 캐시되지 않고 객체 메타데이터에 대한 요청은 캐시 대신 버킷에서 처리됩니다.

Rapid Cache는 완전 관리형 서비스이며 항상 일관적인 데이터를 반환합니다.

캐시 크기 및 대역폭 제한 자동 확장

Rapid Cache는 캐시에 저장된 데이터 양에 따라 자동으로 확장 또는 축소되는 임시 스토리지 용량과 대역폭을 제공합니다.

캐시 대역폭 한도는 100Gbps에서 시작하며 저장된 데이터 1TiB당 20Gbps의 비율로 확장됩니다. 캐시에 저장된 데이터 양을 늘리거나, 영역에 더 많은 캐시를 만들거나, 기술계정 관리자 또는 Google 담당자에게 문의하여 시작 대역폭 또는 총 대역폭 한도를 늘릴 수 있습니다.

Rapid Cache의 크기 및 대역폭 제한에 대한 자세한 내용은 Cloud Storage 할당량 및 한도를 참고하세요.

영역에 데이터 캐싱

버킷의 캐시를 만들 때는 버킷 위치 내의 영역에 캐시를 만들어야 합니다. 예를 들어 버킷이 us-east1 리전에 있으면 us-central1-c가 아닌 us-east1-b에서 캐시를 만들 수 있습니다. 버킷이 ASIA 이중 리전에 있으면 asia-east1 및 asia-southeast1 리전을 구성하는 모든 영역에서 캐시를 만들 수 있습니다.

각 버킷에 대해 영역당 최대 하나의 캐시를 만들 수 있습니다. 예를 들어 버킷이 us-east1 리전에 있으면 us-east1-b와 us-east1-c에 캐시를 만들 수 있습니다. 버킷이 us-central1과 us-east1에 걸쳐 있는 멀티 리전에 있으면 us-central1-a와 us-east1-b에 각각 캐시를 만들 수 있습니다.

영역에 사용 가능한 용량이 있는 한 영역에서 캐시를 만들 수 있습니다. 캐시를 만들기 위한 용량이 없는 경우 Rapid Cache는 사용 가능한 용량이 제공될 때까지 또는 사용자가 만들기 프로세스를 취소할 때까지 캐시 만들기를 계속 시도합니다. 용량은 장기간 사용할 수 없는 상태로 유지될 수 있습니다.

다음 영역에서 Rapid Cache를 사용할 수 있습니다. 이러한 영역은 버킷의 위치 유형에 따라 사용할 수 있습니다.

지리적 영역 위치
영역 이름 지역 이중 리전 멀티 리전 커스텀 이중 리전
아시아
asia-east1-a
asia-east1-b
asia-east1-c
asia-northeast1-a
asia-northeast1-b
asia-northeast1-c
asia-south1-a
asia-south1-b
asia-south1-c
asia-southeast1-a
asia-southeast1-b
asia-southeast1-c
유럽
europe-north1-a
europe-north1-b
europe-north1-c
europe-west1-b
europe-west1-c
europe-west1-d
europe-west4-a
europe-west4-b
europe-west4-c
europe-west6-a
europe-west6-b
미국
us-central1-a
us-central1-b
us-central1-c
us-central1-f
us-central1-ai1a (AI 영역)
us-east1-b
us-east1-c
us-east1-d
us-east4-a
us-east4-b
us-east4-c
us-east5-a
us-east5-b
us-east5-c
us-south1-a
us-south1-b
us-south1-c
us-south1-ai1b (AI 영역)
us-west1-a
us-west1-b
us-west1-c
us-west3-a
us-west3-b
us-west3-c
us-west4-a
us-west4-b
us-west4-c

데이터 수집

데이터는 버킷에서 처음 액세스한 후 항상 캐시에 수집됩니다. 첫 번째 읽기는 캐시 누락으로 제공되고 후속 읽기는 캐시 적중으로 제공되어 데이터 읽기를 가속화합니다. 원하는 경우 캐시를 구성하여 쓰기 시 데이터를 수집하여 초기 캐시 누락을 방지할 수 있습니다. 이는 체크포인트 복원 또는 모델 학습을 위한 데이터 파이프라인 준비와 같은 사용 사례에 유용합니다.

캐시에 데이터를 수집할 때 Rapid Cache는 객체를 더 작은 고정 크기 청크로 나눕니다. 객체를 청크로 나누면 특히 특정 부분만 액세스하는 대용량 파일의 경우 더 세부적인 캐싱이 가능합니다.

청크는 2MB 데이터 블록입니다. 객체에 대한 요청이 이루어지면 빠른 캐시는 요청된 바이트 범위를 포함하는 2MB 청크를 식별하고 이러한 청크를 독립적으로 관리합니다.

데이터 수집 동작은 캐시에 수집되는 객체의 크기에 따라 다릅니다.

  • 2MB보다 큰 객체에 대한 읽기 요청의 경우 요청된 바이트 범위를 포함하는 청크만 수집됩니다. 예를 들어 100MB 파일의 처음 1MB를 읽으면 처음 2MB 청크만 인제스트됩니다.

  • 2MB보다 작은 객체 (예: 500KB 이미지)에 대한 읽기 요청의 경우 전체 객체가 캐시에 인제스트됩니다.

캐시 구성

캐시를 구성할 때 다음 속성을 설정할 수 있습니다.

TTL(수명)

TTL은 데이터 청크가 마지막으로 읽은 시점부터 캐시에 존재하는 가장 긴 시간입니다. 예를 들어 TTL이 24시간으로 설정된 경우, 월요일 오전 11시에 데이터 청크를 마지막으로 읽고 이후 읽기가 수행되지 않았으면 화요일 오전 11시에 데이터 캐시가 캐시에서 제거됩니다. TTL은 24시간부터 7일 사이의 값으로 설정할 수 있습니다. 지정하지 않으면 TTL은 기본적으로 24시간입니다.

쓰기에서 수집

객체 쓰기 시 캐시에 데이터를 수집하면 체크포인트 설정 및 학습 작업의 데이터 준비 출력과 같은 쓰기 후 읽기 워크로드가 가속화됩니다. 쓰기 시 데이터를 수집하도록 캐시를 구성하면 버킷에 업로드될 때 데이터가 캐시에 기록됩니다. 이 선제적 접근 방식을 사용하면 초기 캐시 누락이 제거되고 워크로드가 첫 번째 읽기에서 즉각적인 캐시 적중의 이점을 누릴 수 있습니다.

쓰기 시 수집은 기존 캐시의 수집 기준을 업데이트할 때 선택적으로 사용 설정할 수 있습니다. 초기 캐시 생성 중에는 구성할 수 없습니다.

성능에 대한 고려사항

  • 청크 누락: 요청이 여러 청크를 포함하고 일부 청크는 캐시에 있지만 다른 청크는 없는 경우 Rapid Cache는 소스 버킷에서 누락된 청크를 투명하게 가져옵니다.

  • TTL 및 제거: 수명 (TTL) 및 최소 사용 빈도 (LRU) 제거 정책도 청크에서 작동합니다. 큰 파일의 자주 사용되는 부분은 캐시에 남아 있고 자주 사용되지 않는 부분은 삭제될 수 있습니다.

가격 책정

Rapid Cache 사용 가격 책정은 Rapid Cache 가격 책정을 참고하세요.

비용 관리

다음 도움말을 펼쳐 캐시 실행 비용을 최소화하는 방법을 알아보세요.

버킷 선택

캐시하려는 데이터가 포함된 버킷에 대해서만 캐시를 만들어야 합니다.

영역 선택

워크로드가 캐시로 이점을 얻을 수 있는 영역에서만 캐시를 만들어야 합니다.

TTL 설정

캐시에 데이터를 저장하는 데 필요한 최소한의 TTL을 지정해야 합니다. TTL은 서비스 중단 없이 변경할 수 있습니다. 기본값은 1일입니다.

캐시 사용 중지

캐시를 사용 중지하여 서비스에서 캐시를 영구적으로 삭제하고 모든 관련된 캐시 요금이 발생하지 않도록 할 수 있습니다.

이점

Rapid Cache로 데이터를 캐시하면 다음과 같은 이점이 있습니다.

  • 더 빠른 데이터 액세스: Rapid Cache는 컴퓨팅 리소스와 동일한 영역에 데이터를 공동 배치하며 SSD로 완전히 지원됩니다. 이를 통해 워크로드 처리량을 최대 2.5TB/s까지 높이고 지연 시간을 줄여 더 빠른 읽기 속도를 제공합니다.

  • 멀티 리전 데이터 전송 수수료 절감: 캐시에서 읽은 데이터는 멀티 리전 버킷에서 직접 읽은 데이터에 비해 데이터 전송 수수료가 절감됩니다.

  • 검색 수수료 절감: Nearline Storage, Coldline Storage, Archive Storage의 버킷에 대한 검색 수수료는 캐시에서 데이터를 읽는 데 적용되지 않습니다.

  • 읽기 작업 비용 절감: Rapid Cache에서 제공되는 읽기 작업은 Standard Storage의 버킷에서 제공되는 클래스 B 작업보다 가격이 저렴합니다.

  • 캐시 크기 자동 확장: Rapid Cache의 동적 SSD 캐싱은 캐시 크기를 지정하지 않아도 사용량에 따라 자동으로 확장됩니다.

  • 캐시 효율적으로 사용: 기존 애플리케이션이나 API를 변경하지 않고도 기존 버킷에서 Rapid Cache를 사용 설정할 수 있습니다. Rapid Cache에 저장된 데이터는 strong consistency를 가집니다.

가격에 관한 자세한 내용은 Rapid Cache 가격 책정을 참고하세요. 할당량에 대한 자세한 내용은 Rapid Cache 할당량을 참고하세요.

Rapid Cache는 언제 사용해야 하나요?

변경은 드물고 읽기를 자주 수행하는 데이터에 Rapid Cache를 사용하여 분석 워크로드와 AI/ML 모델 학습 및 로딩을 위한 데이터 읽기를 가속화합니다.

많은 Google Kubernetes Engine 노드에서 AI 모델을 학습한다고 가정해 보세요. 이 모든 노드는 동일한 영역에서 실행되며, Cloud Storage 버킷에 저장된 데이터를 반복적으로 읽습니다. 워크로드가 실행되는 영역에 캐시를 만들면 더 많은 대역폭을 확보할 수 있고 멀티 리전 버킷에서 데이터를 읽을 때 발생하는 데이터 전송 요금을 줄일 수 있으며, 대규모 확장형 워크로드도 더 효율적으로 실행할 수 있습니다.

빠른 캐시를 사용하여 BigQuery의 읽기 속도 높이기

Rapid Cache는 BigQuery에서 실행한 객체 읽기 요청에 대한 데이터를 제공하는 데 사용할 수 있습니다. Rapid Cache를 사용하면 비용 효율성을 최적화하면서 애플리케이션의 데이터 읽기를 가속화할 수 있습니다.

BigQuery는 리전 서비스이지만 기본 컴퓨팅 리소스는 부하 분산을 위해 영역 간에 이동할 수 있습니다. 기본 컴퓨팅 리소스가 영역을 변경하는 경우 사용할 수 있는 캐시가 있는지 확인하려면 리전의 모든 영역에서 BigQuery 워크로드에 대해 Rapid Cache를 사용 설정하는 것이 좋습니다. 영역의 캐시를 사용하지 않으면 Rapid Cache는 사용량 기반 요금이므로 추가 비용이 발생하지 않습니다. 워크로드의 리소스가 영역을 변경하면 새 영역의 캐시에서 데이터를 다시 수집해야 하므로 데이터 수집 비용이 일회성으로 증가할 수 있습니다.

Rapid Cache 추천자

Rapid Cache 추천자는 데이터 사용과 스토리지를 분석하여 버킷-영역 쌍에서 캐시 만들기에 대한 권장사항과 인사이트를 제공합니다. 개요 정보 및 Rapid Cache 추천자 사용에 대한 안내는 Rapid Cache 추천자를 참고하세요.

캐시 작업

이 섹션에서는 Rapid Cache 캐시에서 수행할 수 있는 작업에 대해 설명합니다. 일부 작업은 비동기적으로 수행되며 장기 실행 작업을 반환합니다. 다른 작업은 동기적으로 수행되며, 여기서 작업은 즉시 수행되고 AnywhereCache 리소스를 반환합니다.

캐시 만들기

캐시를 만들 때 캐시는 CREATING 상태로 전환되고 실제 실행이 시작되면 RUNNING 상태로 전환됩니다. 캐시 만들기 작업은 최대 48시간까지 걸릴 수 있으며, 이후에는 작업이 타임아웃됩니다.

AnywhereCaches Create API는 비동기적으로 수행됩니다. 만들기 작업을 수행하면 장기 실행 작업이 반환됩니다. 장기 실행 작업은 만들기 작업 상태를 제공하며 완료되기 전에 사용자가 작업을 취소할 수 있습니다.

캐시 업데이트

RUNNING 상태의 캐시에 대해 TTL 또는 수집 동작을 업데이트할 수 있습니다. 캐시가 업데이트되는 동안 pending_update 필드는 true로 평가됩니다. pending_update 필드가 true로 평가되는 동안에는 캐시를 다시 업데이트할 수 없습니다.

CREATING 또는 DISABLED 상태의 캐시는 업데이트할 수 없습니다. AnywhereCaches Update API는 비동기적으로 수행되며 장기 실행 작업을 반환합니다.

캐시의 TTL 업데이트가 완료되면 캐시의 기존 데이터와 새 데이터 모두에 새로운 TTL이 즉시 적용됩니다.

캐시 가져오기

캐시를 가져오면 Rapid Cache가 캐시 인스턴스의 상태와 구성을 반환합니다. AnywhereCaches Get API는 동기적으로 수행되며 AnywhereCache 리소스를 반환합니다.

캐시 나열

특정 버킷의 연관된 캐시 목록을 반환할 수 있습니다. AnywhereCaches List API는 동기적으로 수행되며 페이지로 나누기를 지원합니다.

캐시 사용 중지

캐시를 사용 중지하면 버킷 구성에서 캐시를 영구적으로 삭제할 수 있습니다. 캐시를 사용 중지하면 DISABLED 상태로 전환됩니다. 이 상태에서는 캐시에서 기존 데이터를 계속 읽을 수 있지만 캐시에 새 데이터를 수집할 수 없습니다.

캐시를 사용 중지한 후에는 1시간의 유예 기간 동안 캐시를 재개하여 사용 중지를 취소할 수 있습니다. 이러한 1시간 유예 기간이 지나면 캐시가 삭제됩니다. 캐시가 삭제되면 캐시 내의 모든 데이터가 제거되고 버킷에서 캐시가 삭제됩니다.

캐시가 삭제되기 전 1시간 동안 캐시를 재개하여 DISABLED 상태를 되돌릴 수 있으며, 그러면 이 때 RUNNING 상태로 캐시가 재개됩니다.

AnywhereCaches DisableAPI는 비동기적으로 수행되며 AnywhereCache 리소스를 반환합니다.

캐시 재개

사용 중지된 캐시가 1시간 유예 기간 내에 있으면 DISABLED 상태의 캐시를 재개할 수 있습니다. 1시간 유예 기간이 지나면 캐시가 언제든 삭제될 수 있으므로 재개 작업은 가능한 경우에만 시도됩니다. 캐시가 재개되면 RUNNING 상태로 전환됩니다.

AnywhereCaches Resume API는 비동기적으로 수행되며 AnywhereCache 리소스를 반환합니다.

제한 및 제약사항

  • 버킷을 삭제하려면 먼저 연결된 모든 캐시를 삭제해야 합니다. 유일한 예외는 Google Cloud 콘솔을 사용하여 버킷을 삭제하는 경우입니다. 이 경우 버킷과 함께 연결된 모든 캐시가 삭제됩니다.

  • 캐시 생성, 사용 중지, 재개 또는 업데이트 작업을 실행할 때는 작업 속도를 초당 작업 1개 이하로 제한하세요. 초당 두 개 이상의 작업을 수행하면 오류가 발생할 수 있습니다.

  • Rapid Cache는 내구성 있는 스토리지가 아니며 여러 시나리오에 따라 캐시에서 데이터가 삭제될 수 있습니다. 어떤 시나리오에서는 워크로드에 충분한 리소스가 제공되도록 보장하기 위해 캐시 크기가 자동으로 조정됩니다. 이 시나리오에서는 Rapid Cache 서비스가 캐시 크기 확장을 완료할 때까지, 가장 오래 사용된 데이터부터 (LRU) 알고리즘에 따라 일부 데이터가 캐시에서 제거될 수 있습니다.

    어떠한 경우에도 데이터는 소스 버킷에 안전하게 저장된 상태로 유지됩니다. TTL 만료 외에도 다양한 이유로 캐시에서 데이터가 제거될 때 Rapid Cache 서비스는 캐시에 데이터를 투명하게 다시 수집하려고 시도하며, 비용이 발생하지 않습니다. 데이터를 투명하게 다시 수집할 수 없거나 TTL 만료로 인해 제거되었으면 Rapid Cache 서비스가 첫 번째 읽기 시에 데이터를 다시 수집합니다.

  • Rapid Cache 추천자가 생성한 추천 및 통계는 BigQuery를 사용하여 읽을 수 없습니다.

일시적인 리소스 부족 문제 해결

다음 섹션에서는 지정된 영역에서 캐시를 만들거나, 캐시 크기를 늘리거나, 캐시 대역폭 한도를 늘릴 수 있는 SSD 용량이나 서비스 처리 용량이 부족한 등, 일시적인 리소스 부족 상황에서 문제를 해결하는 방법을 설명합니다.

새 캐시 만들기 실패

Rapid Cache는 SSD 용량 또는 서비스 처리 리소스 부족으로 인해 특정 영역에서 새 캐시 만들기가 실패할 수 있으며, 그 결과 일시적인 리소스 부족으로 이어질 수 있습니다. 이 기간 동안 Rapid Cache는 최대 48시간 동안 새 캐시를 만들려고 시도합니다. 48시간 내에 리소스를 사용할 수 있게 되면 Rapid Cache의 캐시 만들기 요청이 성공적으로 완료됩니다. 48시간 내에 리소스를 사용할 수 없으면 캐시 만들기 요청이 실패합니다.

문제 해결 방법: 캐싱 중단을 방지하기 위해서는 캐시 만들기 작업을 수동으로 취소하고 사용 가능한 용량이 있는 다른 영역에서 새 캐시를 만들 수 있습니다. 캐시 생성 작업을 모니터링하거나 취소하려면 장기 실행 작업 사용을 참고하세요.

캐시 크기 증가 실패

캐시의 영역에서 필요한 SSD 용량을 사용할 수 없는 경우 Rapid Cache가 캐시 크기를 늘리지 못할 수 있습니다.

Rapid Cache는 필요에 따라 캐시 크기를 자동으로 증가시키지만, 이러한 캐시 크기 증가는 SSD 용량의 가용성에 따라 달라집니다. 자동 캐시 크기 증가 요청이 수행될 때 사용 가능한 SSD 용량이 없으면 일시적인 리소스 부족이 종료될 때까지 또는 캐시 크기 증가가 더 이상 필요하지 않을 때까지 Rapid Cache가 요청을 계속 제출합니다.

일시적인 리소스 부족 시에는 새 데이터가 수집되고 캐시의 기존 데이터가 가장 오래 사용된 데이터부터 기준에 따라 제거됩니다. 대부분의 핫 데이터를 저장하기에 충분히 큰 캐시는 캐시 측정항목에 미치는 영향을 최소화합니다. 핫 데이터 양보다 용량이 적은 캐시를 사용할 때는 리소스 부족의 영향을 받지 않는 캐시를 사용할 때와 비교해서 데이터를 삭제하고 동일한 데이터를 다시 수집하는 빈도가 높을 수 있습니다. 캐시의 실제 크기가 필요한 용량보다 훨씬 작으면 다음과 같이 리소스 부족과 관련된 동작이 발생할 수 있습니다.

  • 낮은 캐시 대역폭 제한, 낮은 캐시 처리량, 높은 데이터 전송 대역폭 할당량 소비, 다른 측정항목에 영향을 미칠 가능성.
  • 결제에는 다음과 같은 방식으로 영향을 미칠 수 있습니다.
    • 캐시 수집 요금으로 인한 비용 증가
    • 캐시 스토리지 요금으로 인한 비용 감소
    • 캐시 데이터 전송 아웃 요금으로 인한 비용 감소
    • 캐시 데이터 아웃바운드 전송 작업 요금으로 인한 비용 감소
    • 멀티 리전 데이터 전송 요금으로 인한 비용 증가
    • 클래스 B 작업 사용으로 인한 비용 증가

이러한 수수료에 대한 자세한 내용은 Rapid Cache 가격 책정을 참고하세요.

문제 해결 방법: 일시적인 리소스 부족 중에도 최상의 결과를 얻기 위해서는 캐시를 모니터링하고 필요에 따라 불필요한 캐시 또는 워크로드를 사용 중지하는 것이 좋습니다.

캐시의 대역폭 한도를 확장하지 못함

캐시 크기를 늘리는 동안 특정 영역의 서비스 처리 리소스가 부족하여 기존 캐시의 대역폭 한도를 TiB당 20Gbps로 확장하지 못해 캐시 대역폭 한도 부족 현상이 일시적으로 발생할 수 있습니다. 사용 가능한 캐시 대역폭이 부족한 동안에는 Rapid Cache에서 데이터 TiB당 20Gbps로 캐시 대역폭 한도 확장이 허용되지 않지만, 캐시가 계속 읽기 요청을 처리합니다. 기술계정 관리자 또는 Google 담당자에게 문의하여 캐시 대역폭을 추가로 요청할 수 있습니다. 사용 가능한 캐시 대역폭이 부족한 동안에는 버킷의 데이터 이그레스 대역폭 소비가 증가할 수 있습니다.

문제 해결 방법: 일시적인 리소스 부족 중에도 최상의 결과를 얻기 위해서는 캐시를 모니터링하고 필요에 따라 불필요한 캐시 또는 워크로드를 사용 중지하는 것이 좋습니다.

다음 단계