Google은 AI 기술을 사용하여 콘텐츠를 사용자의 기본 언어로 번역합니다. AI 번역에는 오류가 있을 수 있습니다.

Rapid Cache

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

Rapid Cache는 읽기 집약적인 워크로드 성능을 개선하고 네트워크 비용을 절감하는 데 유용합니다. 자세한 내용은 혜택을 참고하세요.

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

Rapid Cache는 어떻게 작동하나요?

Rapid Cache를 사용하면 워크로드와 동일한 영역에서 캐시를 만들 수 있습니다. 영역에 캐시를 만들 때 영역에서 시작되는 데이터 읽기 요청은 버킷 대신 캐시에서 처리됩니다. 각 캐시는 캐시와 동일한 영역에서 클라이언트에 서비스를 제공합니다.

캐시와 동일한 영역에 있는 VM이 데이터를 읽을 때 버킷의 데이터가 캐시에 수집됩니다. 쓰기 시 수집 동작을 구성하면 버킷에 데이터가 기록될 때 캐시에도 데이터가 수집됩니다.

메타데이터가 캐시되지 않습니다. 객체 메타데이터에 대한 요청은 항상 캐시 대신 버킷에서 처리됩니다.

데이터가 캐시에 수집되는 방식에 대한 자세한 내용은 데이터 수집을 참고하세요. 캐시를 만들거나 업데이트할 때 캐시의 TTL (수명) 및 쓰기 시 수집 동작을 구성할 수 있습니다.

이점

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 버킷에 저장된 데이터를 반복적으로 읽습니다. 워크로드가 실행되는 영역에 캐시를 만들면 더 많은 대역폭을 확보할 수 있고 멀티 리전 버킷에서 데이터를 읽을 때 발생하는 데이터 전송 요금을 줄일 수 있으며, 대규모 확장형 워크로드도 더 효율적으로 실행할 수 있습니다.

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

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를 사용할 수 있습니다. 이러한 영역은 버킷의 위치 유형에 따라 사용할 수 있습니다.

아시아

다음 표에는 아시아 지리적 영역에서 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`

유럽

다음 표에는 유럽 지역에서 Rapid Cache에 사용할 수 있는 영역과 위치 유형이 나와 있습니다.

영역 이름	지역	이중 리전	멀티 리전	커스텀 이중 리전
`europe-north1-a`
`europe-north1-b`
`europe-north1-c`
`europe-west1-b`
`europe-west1-c`
`europe-west1-d`
`europe-west3-a`
`europe-west3-b`
`europe-west3-c`
`europe-west4-a`
`europe-west4-b`
`europe-west4-c`
`europe-west4-ai1a` (AI 영역)
`europe-west6-a`
`europe-west6-b`

미국

다음 표에는 미국 지리적 영역에서 Rapid Cache에 사용할 수 있는 영역과 위치 유형이 나와 있습니다.

영역 이름	지역	이중 리전	멀티 리전	커스텀 이중 리전
`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-west2-a`
`us-west3-a`
`us-west3-b`
`us-west3-c`
`us-west4-a`
`us-west4-b`
`us-west4-c`

캐시용 데이터 수집

기본적으로 데이터는 처음 요청된 후 캐시에 수집됩니다.

이 초기 요청이 도착할 때 캐시가 비어 있으므로 캐시 내에서 아직 데이터를 찾을 수 없습니다. 이로 인해 시스템이 지원 Cloud Storage 버킷에서 데이터를 대신 가져오는 초기 캐시 부적중이 발생합니다. 시스템이 검색된 데이터를 사용자에게 제공하는 동시에 데이터를 캐시에 수집합니다.

이 첫 번째 요청이 완료되면 데이터가 캐시에 상주하므로 이후의 모든 읽기는 캐시에서 직접 고속 캐시 적중으로 제공될 수 있습니다. 이 동작은 읽기 지연 시간을 크게 줄이고 데이터 검색을 가속화합니다. 수집된 데이터는 TTL이 만료될 때까지 캐시에 상주하며, 이후 데이터는 캐시에서 삭제됩니다.

초기 요청이 느려지는 것을 완전히 방지하려면 첫 번째 읽기 후 데이터를 수집하는 것 외에도 쓰기 시 데이터를 수집하도록 캐시를 구성하면 됩니다.

청크로 데이터 수집

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

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

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

2MB보다 큰 객체에 대한 읽기 요청의 경우 요청된 바이트 범위를 포함하는 청크만 수집됩니다. 예를 들어 100MB 파일의 처음 1MB를 읽으면 처음 2MB 청크만 인그레스됩니다.
2MB보다 작은 객체 (예: 500KB 이미지)에 대한 읽기 요청의 경우 전체 객체가 캐시에 인제스트됩니다.

쓰기에서 데이터 수집

쓰기 시 데이터를 수집하도록 캐시를 사용 설정하면 버킷에 작성되는 순간 데이터가 캐시로 수집됩니다. 이 동작은 초기 읽기 후 데이터를 수집하는 기본 캐시 동작 외에 선택적으로 사용 설정할 수 있습니다.

쓰기 시 수집 기능을 사용하면 초기 캐시 부적중이 제거되고 워크로드가 첫 번째 데이터 읽기에서 즉시 캐시 적중의 이점을 누릴 수 있습니다. 쓰기 시 데이터를 수집하면 시스템 체크포인트를 복원하거나 모델 학습을 위한 데이터 파이프라인을 준비하는 등 쓰기 후 읽기 워크로드가 가속화됩니다.

캐시를 만들거나 업데이트할 때 쓰기 시 데이터를 수집하도록 캐시를 사용 설정할 수 있습니다. 버킷에 기록된 모든 객체를 수집하도록 캐시를 구성하거나('버킷 수준 쓰기 시 수집'이라고도 함) 지정된 관리 폴더 아래 버킷에 기록된 객체를 선택적으로 수집할 수 있습니다('접두사 수준 쓰기 시 수집'이라고도 함).

예를 들어 이름에 red/ 접두사가 있는 my-bucket 버킷의 객체에 대해 접두사 수준 쓰기 시 수집을 실행하도록 캐시를 사용 설정한다고 가정해 보겠습니다. 그런 다음 my-bucket에 red/my-dog.png, blue/my-cat.png, red/my-goldfish.png 객체를 업로드합니다. 따라서 my-bucket에 업로드되면 red/my-dog.png 및 red/my-goldfish.png 객체만 캐시에 수집됩니다.

특정 도구 (예:Google Cloud 콘솔)를 사용하여 접두사 수준 쓰기 시 수집을 구성할 때 기존 관리형 폴더의 이름이 아닌 접두사를 지정하면 새 관리형 폴더가 자동으로 생성됩니다. 하지만 JSON API를 사용할 때는 관리형 폴더를 수동으로 만들고 각 캐시 영역에 ingestOnWrite 설정을 적용해야 합니다. 각 도구를 사용하여 쓰기 시 수집을 사용 설정하거나 중지하는 방법은 Rapid Cache 사용을 참고하세요.

JSON API를 사용할 때 버킷 또는 접두사 수준에서 쓰기 시 수집을 사용 설정하거나 중지하는 방법을 알아보려면 쓰기 시 수집 사용 설정 방법 이해 섹션을 펼치세요. 이 섹션의 정보는 주로 JSON API에만 적용됩니다.Google Cloud 콘솔과 같은 다른 도구는 쓰기 시 수집을 더 쉽게 사용 설정하고 관리할 수 있도록 일부 설정을 난독화합니다.

쓰기 시 수집을 사용 설정하는 방법 이해하기

이 섹션에서는 버킷에 작성된 모든 객체 또는 관리형 폴더 접두사 아래 버킷에 작성된 선택된 객체에만 쓰기 시 수집을 사용 설정하는 데 사용할 JSON API 설정을 설명합니다.

캐시가 버킷의 모든 객체 또는 프리픽스 아래의 선택적 객체에 대해 쓰기 시 데이터를 수집하는지 여부를 제어하는 설정에는 두 가지가 있습니다.

쓰기 시 수집의 버킷 수준 사용 설정은 캐시 리소스의 ingestOnWrite 필드를 사용하여 이루어집니다. 필드는 다음과 같이 표시됩니다.
```
{
"zone": "us-east1-a",
"ttl": "24h",
"ingestOnWrite": true
}
```
- true로 설정하면 버킷에 작성된 모든 객체에 대해 쓰기 시 수집이 사용 설정됩니다. 이렇게 하면 접두사별로 선택한 객체에 대해 쓰기 시 수집을 사용 설정하는 관리형 폴더 수준 설정이 재정의됩니다.
- false로 설정하면 버킷 전체 객체에서 쓰기 시 수집이 사용 중지됩니다. 이 설정을 사용하면 관리형 폴더 설정을 통해 선택적 객체의 쓰기 시 수집을 사용 설정할 수 있습니다(접두사별).
쓰기 시 수집의 접두사 수준 사용 설정은 후행 슬래시로 끝나는 접두사 경로를 나타내는 관리형 폴더를 사용하여 이루어집니다 (예: my-prefix/). 접두사 수준 쓰기 시 수집이 사용 설정되면 캐시는 객체 이름에 접두사가 있는 경우에만 쓰기 시 객체를 선택적으로 수집합니다.

접두사 수준 쓰기 시 수집은 관리형 폴더 리소스의 rapidCacheConfig.policies 매핑의 ingestOnWrite 필드를 통해 제어됩니다. 캐시 인스턴스는 rapidCacheConfig.policies 매핑에 지정되기 위해 존재해야 합니다.

관리 폴더의 rapidCacheConfig.policies 매핑은 다음과 같습니다.
```
"rapidCacheConfig": {
  "policies": {
    "us-east1-a": {
      "rapidCacheId": "us-east1-a",
      "ingestOnWrite": "unspecified"
    }
    "us-east1-b": {
      ...,
      ...
    }
  }
}
```
- policies 매핑에 지정된 캐시 인스턴스는 쓰기 시 접두사 수준 수집이 작동하려면 이미 있어야 합니다. 예를 들어 policies 매핑에서 rapidCacheId: "us-east1-a"를 지정하려면 먼저 영역 us-east1-a의 캐시가 있어야 합니다.
- 단일 API 호출에서 policies 매핑에 지정된 여러 캐시 인스턴스를 업데이트할 수 있습니다.
- ingestOnWrite이 enabled로 설정된 경우 이 관리형 폴더 접두사 아래 버킷에 작성된 모든 객체에 대해 쓰기 시 수집이 사용 설정됩니다. 쓰기 시 수집은 캐시 리소스의 ingestOnWrite 필드가 false인 경우에만 사용 설정할 수 있습니다.
- unspecified (기본값)로 설정된 경우 쓰기 시 수집 사용 설정은 상위 관리형 폴더 또는 관리형 폴더 자체를 포함하는 버킷일 수 있는 직계 상위 리소스에서 상속됩니다.
- 정책 매핑에 지정되지 않은 캐시는 ingestOnWrite 설정이 unspecified로 설정된 것처럼 처리됩니다.

다음은 버킷 수준 또는 접두사 수준에서 쓰기 시 수집을 사용 설정하거나 중지하기 위해 캐시 및 관리 폴더 리소스를 구성하는 방법을 요약한 것입니다.

버킷 수준 쓰기 시 수집 사용 설정 (접두사 수준 아님)
- 구성: 캐시 리소스의 ingestOnWrite 필드를 true로 설정합니다.
- 동작: 버킷에 작성된 모든 객체에 대해 쓰기 시 수집이 사용 설정됩니다. 이 버킷 전체 설정은 관리 폴더 수준 구성을 재정의합니다. 즉, 선택적 접두사 수준 구성이 무시됩니다.
접두사 수준 쓰기 시 수집 사용 설정 (버킷 수준 아님)
- 설정:
  1. 캐시 리소스의 ingestOnWrite 필드를 false로 설정합니다.
  2. 관리 폴더 리소스에서 유효한 policies 매핑 (null 아님)을 구성합니다.
  3. 관리형 폴더의 ingestOnWrite 필드를 enabled로 설정합니다 (또는 사용 설정된 상위 관리형 폴더에서 enabled를 상속하는 하위 폴더인 경우 unspecified로 설정).
- 동작: 쓰기 시 수집은 일치하는 관리형 폴더 접두사 아래에 작성된 객체에만 발생합니다.
상위 관리형 폴더와 하위 관리형 폴더 간 접두사 수준 쓰기 시 수집 사용 설정

상위 관리형 폴더에서 쓰기 시 수집을 사용 설정하지 않고 하위 관리형 폴더에서 쓰기 시 수집을 사용 설정할 수는 없습니다.
버킷과 접두사 모두 쓰기 시 수집 사용 중지
- 설정:
  1. 캐시 리소스의 ingestOnWrite 필드를 false로 설정합니다.
  2. 모든 관리 폴더의 ingestOnWrite 필드를 unspecified로 설정하여 상위 관리 폴더의 ingestOnWrite 필드가 enabled이 되지 않도록 합니다.
    
    또는 policies 맵 null을 그대로 두거나 rapidCacheConfig 구성을 완전히 생략하여 정책을 구성하지 않습니다.
- 동작: 쓰기 시 수집이 버킷과 모든 접두사에 대해 전역적으로 사용 중지됩니다.

상위 관리형 폴더에서 접두사 수준 쓰기 시 수집을 사용 설정하면 상위 관리형 폴더 아래에 중첩된 모든 하위 관리형 폴더에 쓰기 시 수집이 사용 설정됩니다. 리소스가 쓰기 시 수집 사용 설정 및 사용 중지를 상속하는 방법을 자세히 알아보려면 쓰기 시 수집 상속 작동 방식 섹션을 펼치세요.

쓰기 시 수집 상속 작동 방식

관리형 폴더에서 쓰기 시 수집을 명시적으로 사용 설정하지 않으면(관리형 폴더의 ingestOnWrite 필드가 unspecified로 설정됨) 캐시의 쓰기 시 수집 동작은 버킷 또는 상위 관리형 폴더에서 관리형 폴더의 상위 리소스에서 상속됩니다.

접두사 수준에서 쓰기 시 수집을 사용하는 경우 상위 관리형 폴더에서 구성한 쓰기 시 수집 설정이 모든 하위 관리형 폴더에 상속됩니다.

예를 들어 다음 시나리오를 고려해 보세요.

상위 리소스가 버킷 my-bucket인 관리 폴더 a/가 있습니다.
my-bucket 내의 관리 폴더 a/이 상위 리소스인 관리 폴더 a/b/가 있습니다.

a/b/info.txt라는 객체가 작성되면 Rapid Cache는 위에서 아래로 구성 계층 구조를 평가합니다.

직접 관리형 폴더 확인: a/b/이 enabled로 설정된 경우 a/b/ 아래에 작성된 객체에 대해 접두사 수준 쓰기 시 수집이 사용 설정됩니다. a/b/이 unspecified로 설정된 경우 Rapid Cache는 관리형 폴더 a/인 직계 상위 리소스를 확인합니다.
상위 관리형 폴더 확인: a/이 enabled로 설정된 경우 a/ 및 a/b/에 대해 접두사 수준 쓰기 시 수집이 사용 설정됩니다. a/이 unspecified로 설정되면 Rapid Cache가 상위 버킷을 확인합니다.
버킷의 캐시 수준 ingestOnWrite 설정 확인: 캐시의 ingestOnWrite 필드가 true로 설정된 경우 버킷 수준 쓰기 시 수집이 사용 설정되어 있으며 접두사 수준 쓰기 시 수집이 구성된 관리형 폴더를 재정의합니다. 캐시의 ingestOnWrite 필드가 false이고 상위 및 하위 관리형 폴더의 ingestOnWrite 필드가 모두 unspecified인 경우 상위 및 하위 관리형 폴더에 속하는 버킷의 객체에 대해 쓰기 시 수집이 사용 중지됩니다. 이 시나리오에서 쓰기 시 수집이 구성된 버킷에 다른 관리형 폴더가 없으면 버킷의 모든 객체에 대해 쓰기 시 수집이 사용 중지됩니다.

TTL(수명)

캐시의 TTL은 데이터가 삭제되기 전에 캐시에 데이터가 유지되는 기간을 관리합니다. TTL은 마지막으로 읽은 시점부터 데이터가 캐시에 남아 있는 기간입니다. 예를 들어 TTL이 24시간으로 설정된 경우, 월요일 오전 11시에 데이터 청크를 마지막으로 읽고 이후 읽기가 수행되지 않았으면 화요일 오전 11시에 데이터 캐시가 캐시에서 제거됩니다.

캐시를 만들거나 업데이트할 때 캐시의 TTL을 설정할 수 있습니다. 캐시의 TTL은 24시간에서 7일 사이의 값으로 설정할 수 있습니다. 지정하지 않으면 TTL은 기본적으로 24시간입니다.

캐시 작업

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

캐시 만들기

캐시를 만들 때 캐시의 위치, TTL, 데이터 수집 동작을 설정할 수 있습니다. 캐시는 생성될 때 CREATING 상태로 전환되고 실제 실행이 시작되면 RUNNING 상태로 전환됩니다. 캐시 만들기 작업은 최대 48시간까지 걸릴 수 있으며, 이후에는 작업이 타임아웃됩니다.

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

캐시 업데이트

캐시를 업데이트할 때 캐시의 TTL 또는 데이터 수집 동작을 설정할 수 있습니다. RUNNING 상태의 캐시만 업데이트할 수 있습니다. CREATING 또는 DISABLED 상태의 캐시는 업데이트할 수 없습니다.

캐시가 업데이트되는 동안 pending_update 필드는 true로 평가됩니다. pending_update 필드가 true로 평가되는 동안에는 캐시를 다시 업데이트할 수 없습니다. 캐시의 TTL 업데이트가 완료되면 캐시의 기존 데이터와 새 데이터 모두에 새로운 TTL이 즉시 적용됩니다.

AnywhereCaches Update API는 비동기적으로 수행되며 장기 실행 작업을 반환합니다.

캐시 가져오기

캐시를 가져오면 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 리소스를 반환합니다.

Rapid Cache 추천자

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

Rapid Cache를 사용하여 BigQuery의 읽기 가속화

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

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

캐시된 데이터 암호화

데이터는 데이터의 원래 서버 측 암호화 형식으로 캐시에 저장되므로 Cloud Storage에서 지원하는 암호화 옵션과 호환됩니다.

제한 및 제약사항

버킷을 삭제하려면 먼저 연결된 모든 캐시를 삭제해야 합니다. 유일한 예외는 Google Cloud 콘솔을 사용하여 버킷을 삭제하는 경우입니다. 이 경우 버킷과 함께 연결된 모든 캐시가 삭제됩니다.
캐시 생성, 사용 중지, 재개 또는 업데이트 작업을 실행할 때는 작업 비율을 초당 작업 1개 이하로 제한하세요. 초당 두 개 이상의 작업을 수행하면 오류가 발생할 수 있습니다.
Rapid Cache는 내구성 있는 스토리지가 아니며 여러 시나리오에 따라 캐시에서 데이터가 삭제될 수 있습니다. 어떤 시나리오에서는 워크로드에 충분한 리소스가 제공되도록 보장하기 위해 캐시 크기가 자동으로 조정됩니다. 이 시나리오에서는 Rapid Cache 서비스가 캐시 크기 확장을 완료할 때까지, 가장 오래 사용된 데이터부터 (LRU) 알고리즘에 따라 일부 데이터가 캐시에서 제거될 수 있습니다.

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

성능에 대한 고려사항

청크 누락: 요청이 여러 청크를 포함하고 일부 청크는 캐시에 있지만 다른 청크는 없는 경우 Rapid Cache는 누락된 청크를 소스 버킷에서 투명하게 가져옵니다.
TTL 및 제거: 수명 (TTL) 및 최소 사용 빈도 (LRU) 제거 정책도 청크에서 작동합니다. 큰 파일의 자주 사용되는 부분은 캐시에 남아 있고 자주 사용되지 않는 부분은 삭제될 수 있습니다.

가격 책정

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

비용 관리

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

버킷 선택

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

영역 선택

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

TTL 설정

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

캐시 사용 중지

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

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

다음 섹션에서는 지정된 영역에서 캐시를 만들거나, 캐시 크기를 늘리거나, 캐시 대역폭 한도를 늘릴 만큼 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 담당자에게 문의하여 캐시 대역폭을 추가로 요청할 수 있습니다. 사용 가능한 캐시 대역폭이 부족한 동안에는 버킷의 데이터 이그레스 대역폭 소비가 증가할 수 있습니다.

다음 단계

캐시 만들기 및 관리

Rapid Cache 컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.

Rapid Cache는 어떻게 작동하나요?

이점

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

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

영역에 데이터 캐싱

아시아

유럽

미국

캐시용 데이터 수집

청크로 데이터 수집

쓰기에서 데이터 수집

쓰기 시 수집을 사용 설정하는 방법 이해하기

쓰기 시 수집 상속 작동 방식

TTL(수명)

캐시 작업

캐시 만들기

캐시 업데이트

캐시 가져오기

캐시 나열

캐시 사용 중지

캐시 재개

Rapid Cache 추천자

Rapid Cache를 사용하여 BigQuery의 읽기 가속화

캐시된 데이터 암호화

제한 및 제약사항

성능에 대한 고려사항

가격 책정

비용 관리

버킷 선택

영역 선택

TTL 설정

캐시 사용 중지

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

새 캐시 만들기 실패

캐시 크기 증가 실패

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

다음 단계

Rapid Cache