할당량 및 한도

이 페이지에서는 Cloud Storage의 할당량 및 요청 한도를 설명합니다.

버킷

  • 프로젝트마다 2초당 작업 약 1개라는 비율 제한이 버킷 생성 및 삭제에 적용되므로 일반적으로 버킷 수는 적고 객체 수가 많도록 계획하는 것이 좋습니다. 예를 들어 일반적인 설계에서는 프로젝트 사용자당 1개의 버킷을 사용합니다. 하지만 초당 많은 사용자를 추가하는 시스템을 설계할 때는 버킷 생성 속도 제한 때문에 병목 현상이 발생하지 않도록 적절한 권한으로 한 버킷에 많은 사용자가 포함되도록 설계하세요.

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

  • 각 버킷에는 초당 1개라는 업데이트 한도가 적용되어 단일 버킷에 대한 빠른 업데이트(예: CORS 구성 변경)가 확장되지 않습니다.

  • 버킷당 기존 IAM 역할을 보유하는 구성원은 100명으로 제한됩니다. 구성원의 예로는 개별 사용자, 그룹, 도메인이 포함됩니다. IAM ID를 참조하세요.

객체

  • Cloud Storage에 저장되는 개별 객체에는 5TB의 최대 크기 한도가 적용됩니다.

  • 각 객체에는 초당 1개라는 업데이트 한도가 적용되어 단일 객체에 대한 빠른 쓰기가 확장되지 않습니다. 자세한 내용은 핵심 용어에서 객체 불변성을 참조하세요.

  • 객체 업로드, 업데이트, 삭제 등 여러 객체에 대한 쓰기에는 제한이 없습니다. 처음에는 버킷에서 초당 약 1,000개의 쓰기를 지원하며 이후 필요에 따라 확장됩니다.

  • 객체 읽기에는 제한이 없습니다. 처음에는 버킷에서 초당 약 5,000개의 객체 읽기를 지원하며 이후 필요에 따라 확장됩니다.

  • 성능은 공개적으로 캐시 가능한 객체에서 훨씬 우수합니다. 객체 하나로 여러 클라이언트를 제어하고 있어 캐싱을 사용 중지하여 최신 데이터를 제공하려는 경우에는 다음을 확인하세요.

    • 객체의 Cache-Control메타데이터max-age가 15~60초인 public으로 설정해 봅니다. 대부분의 애플리케이션에서 1분까지 허용되며 캐시 적중률에 따라 성능이 크게 향상됩니다.

    • 프록시 데이터는 버킷과 같은 위치에 있는 Google App Engine 애플리케이션을 통해 전송됩니다.

    • 객체에 Cache-Control: no-cache를 사용해 에지 캐시의 후속 요청 시 객체를 캐시하지 않는다고 나타냅니다.

    Cache-Control 지시문에 대한 자세한 내용은 RFC 7234: Cache-Control을 참조하세요.

  • 객체당 액세스제어 목록(ACL) 항목은 100개로 제한됩니다. 구성원은 개별 사용자, 그룹 또는 도메인일 수 있습니다. ACL 범위를 참조하세요.

  • 객체 구성:

    • 단일 구성 요청으로 최대 32개의 객체를 구성할 수 있습니다.

    • 복합 객체를 구성하는 구성요소의 수에는 제한이 없지만 복합 객체와 관련된 componentCount 메타데이터는 2,147,483,647에 이르면 포화 상태가 됩니다.

    • Cloud Storage에 저장된 객체에 적용되는 5TB의 전체 크기 한도가 복합 객체에 적용됩니다.

XML API 요청

  • XML API를 통해 요청을 전송할 때는 요청 URL 및 HTTP 헤더를 합친 크기가 16KB로 제한됩니다.

서비스 계정의 HMAC 키

  • HMAC 키는 서비스 계정당 5개로 제한됩니다. 삭제된 키는 한도에 포함되지 않습니다.
이 페이지가 도움이 되었나요? 평가를 부탁드립니다.

다음에 대한 의견 보내기...

도움이 필요하시나요? 지원 페이지를 방문하세요.