할당량 및 한도

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

이름에 점(.)이 포함되어 있으면 222자로 제한됩니다.

대부분의 경우 버킷 수는 적고 객체 수가 많도록 계획합니다. 예를 들어 일반적인 설계에서는 프로젝트 사용자당 1개의 버킷을 사용합니다. 하지만 초당 많은 사용자를 추가하는 시스템을 설계할 때는 버킷 생성 비율 제한 때문에 병목 현상이 발생하지 않도록 적절한 권한으로 한 버킷에 많은 사용자가 포함되도록 설계하세요.

가용성이 높은 애플리케이션은 애플리케이션 주요 경로에서 버킷 생성 또는 삭제에 종속되면 안 됩니다. 버킷 이름은 중앙 글로벌 네임스페이스에 속하므로 이 네임스페이스에 대한 종속으로 인해 애플리케이션의 단일 장애점이 형성됩니다. 이러한 버킷 생성/삭제 한도로 인해 Cloud Storage의 고가용성 서비스를 위해 필요한 모든 버킷을 사전에 생성하는 것이 좋습니다.

모든 IAM 역할의 경우 주 구성원 1,500명

기존 IAM 역할의 경우 주 구성원 100명

이 한도는 객체 구성, 재개 가능한 업로드, 멀티파트 업로드를 비롯한 쓰기 메서드에 관계없이 적용됩니다.

Anywhere Cache로 만든 캐시는 캐시에 저장된 데이터 양에 따라 자동으로 확장됩니다. 캐시 크기는 캐시에 수집된 데이터 양에서 제거된 데이터 양을 뺀 값과 같습니다. 예를 들어 워크로드가 100GiB의 데이터를 수집하는 경우 캐시 크기가 100GiB로 늘어납니다. 이후 50GiB의 데이터가 제거되면 캐시 크기가 50GiB로 줄어듭니다.

프로젝트의 결제 계정 내역에 따라 캐시 크기 제한이 더 낮을 수 있습니다. 리소스가 제한된 경우 캐시 생성이 중지되거나 기존 캐시의 확장이 중지되고 가장 최근에 사용된(LRU) 알고리즘에 따라 데이터가 제거되어 새 데이터를 위한 공간이 확보될 수 있습니다.

캐시 대역폭 한도는 기본값 100Gbps를 기준으로 캐시 저장 데이터의 양에 따라 1TiB당 20Gbps로 캐시 대역폭이 자동으로 확장됩니다.

캐시 대역폭 한도는 프로젝트 및 영역별로 적용되므로 캐시가 서로 다른 버킷에 생성되더라도 동일한 프로젝트 및 영역 내 캐시의 트래픽은 공통 캐시 대역폭 한도에 반영됩니다. 예를 들어 캐시 A가 my-project 프로젝트에 있는 example-bucket-1 버킷의 us-east1-a 영역에서 생성되었다고 가정해 보겠습니다. 캐시 B는 example-bucket-2에 대해 us-east1-a에서 생성되며 이는 my-project에도 있습니다. 캐시 A와 캐시 B는 모두 us-east1-a 및 my-project에 있으므로 두 캐시의 트래픽은 동일한 캐시 대역폭 한도에 반영됩니다.

캐시에 저장되는 데이터의 양을 늘리거나 더 많은 영역에 캐시를 채워 캐시 수를 늘려 총 캐시 대역폭을 늘릴 수 있습니다.

캐시 대역폭 한도는 프로젝트의 최대 대역폭 할당량과 별개입니다. 캐시에서 데이터를 읽으면 한도에 도달할 때까지 캐시 대역폭 한도에 반영되며, 이 시점부터 데이터 읽기가 프로젝트의 대역폭 할당량에 반영되기 시작합니다. 캐시 부적중은 캐시 대역폭 한도에 반영되지 않습니다.

• storagebatchoperations.jobs.get
• storagebatchoperations.jobs.list

Cloud CDN 및 Media CDN으로의 이그레스는 이 할당량에서 제외됩니다.

프로젝트별로 할당량 증가를 요청할 수 있습니다.

프로젝트의 Google 이그레스 한도를 보는 방법은 할당량 보기 및 관리를 참조하세요.

프로젝트의 Google 이그레스 사용량을 보는 방법은 대역폭 모니터링을 참조하세요.

Cloud CDN 및 Media CDN으로의 이그레스는 이 할당량에서 제외됩니다.

프로젝트별로 할당량 증가를 요청할 수 있습니다.

프로젝트의 Google 이그레스 한도를 보는 방법은 할당량 보기 및 관리를 참조하세요.

프로젝트의 Google 이그레스 사용량을 보는 방법은 대역폭 모니터링을 참조하세요.

Cloud CDN 및 Media CDN으로의 이그레스는 이 할당량에서 제외됩니다.

지정된 멀티 리전 내 각 리전에는 별도의 할당량이 있습니다. 예를 들어 my-project 프로젝트는 프로젝트 내의 모든 리전에 대해 멀티 리전 Google 이그레스 대역폭 할당량이 200Gbps라고 가정합니다. 이 시나리오에서 us-east1 리전은 us 멀티 리전에 있는 버킷에서 Google 서비스로의 데이터 이그레스를 지원할 때 대역폭이 200Gbps이며, us-west1 리전은 us 멀티 리전에 있는 버킷에서 Google 서비스로의 데이터 이그레스를 지원할 때 리전의 대역폭이 200Gbps입니다.

프로젝트의 Google 이그레스 한도를 보는 방법은 할당량 보기 및 관리를 참조하세요.

프로젝트의 Google 이그레스 사용량을 보는 방법은 대역폭 모니터링을 참조하세요.

프로젝트별로 할당량 증가를 요청할 수 있습니다. 일반적으로 Google 서비스에 대한 이그레스 요율이 높은 워크로드의 경우 리전 또는 이중 리전에 있는 버킷을 사용해야 합니다. Google 서비스에서 대규모 워크로드를 실행하는 멀티 리전의 기존 버킷의 경우 리전 또는 이중 리전의 버킷으로 Storage Transfer Service를 사용하여 데이터를 이동할 수 있습니다.

캐시 부적중으로 인한 Cloud CDN 및 Media CDN으로의 이그레스는 이 할당량에 포함됩니다.

프로젝트의 인터넷 이그레스 한도를 보는 방법은 할당량 보기 및 관리를 참조하세요.

프로젝트의 인터넷 이그레스 사용량을 보는 방법은 대역폭 모니터링을 참조하세요.

프로젝트별로 할당량 증가를 요청할 수 있습니다.

캐시 부적중으로 인한 Cloud CDN 및 Media CDN으로의 이그레스는 이 할당량에 포함됩니다.

프로젝트의 인터넷 이그레스 한도를 보는 방법은 할당량 보기 및 관리를 참조하세요.

리전별 프로젝트의 인터넷 이그레스 사용량을 보는 방법은 대역폭 모니터링을 참조하세요.

프로젝트별로 할당량 증가를 요청할 수 있습니다.

캐시 부적중으로 인한 Cloud CDN 및 Media CDN으로의 이그레스는 이 할당량에 포함됩니다.

멀티 리전 내 리전에는 별도의 멀티 리전 인터넷 이그레스 할당량이 있습니다. 예를 들어 my-project가 us 멀티 리전에 있는 버킷의 데이터를 전 세계 고객에게 전송한다고 가정해 보겠습니다. 이 시나리오에서는 데이터가 버킷에서 전 세계 여러 지역으로 전송되므로 us 멀티 리전 내의 여러 리전에서 자체 인터넷 이그레스 할당량을 사용합니다. 일반적으로 인터넷 이그레스 할당량은 데이터의 대상에 지리적으로 가장 가까운 리전을 기준으로 계산됩니다.

프로젝트의 인터넷 이그레스 한도를 보는 방법은 할당량 보기 및 관리를 참조하세요.

리전별 프로젝트의 인터넷 이그레스 사용량을 보는 방법은 대역폭 모니터링을 참조하세요.

프로젝트별로 할당량 증가를 요청할 수 있습니다.