Cloud Storage 권장사항

이 페이지에는 Cloud Storage 권장사항의 색인이 포함되어 있습니다. 여기에서 수집한 정보를 활용하여 Cloud Storage를 사용하는 애플리케이션을 빌드할 때 유의할 점을 빠르게 참조할 수 있습니다.

이 페이지는 Cloud Storage의 기본적인 사용법을 안내하지 않으므로 Cloud Storage를 시작한 지 얼마 안 되는 사용자에게는 적합하지 않을 수 있습니다. 신규 사용자라면 Google Cloud 콘솔을 사용하여 객체 스토리지 탐색 또는 gcloud 도구로 객체 스토리지 탐색부터 살펴보는 것이 좋습니다.

이름 지정

이름 요구사항 및 고려사항은 버킷 이름 지정 및 객체 이름 지정을 참조하세요.

트래픽

• Cloud Storage로 전송될 트래픽 양을 어림잡아 계산하세요. 특히 다음을 고려하세요.

  • 초당 작업 수. 버킷과 객체 모두에 대해 그리고 생성, 업데이트, 삭제 작업에 대해 초당 몇 개의 작업을 예상하세요?

  • 대역폭. 해당 기간 동안 얼마나 많은 데이터가 전송될 예정인가요? 계산 실수를 방지하려면 Wolfram Alpha와 같은 도구를 사용하는 것이 좋습니다.

  • 캐시 제어. 공개적으로 액세스할 수 있는 객체에서 Cache-Control 메타데이터를 지정하면 사용량이 많거나 자주 액세스하는 객체에서 읽기 지연 시간이 줄어듭니다. Cache-Control과 같은 객체 메타데이터를 설정하는 방법은 메타데이터 보기 및 수정을 참조하세요.

• 트래픽 급증이 최소화되도록 애플리케이션을 설계하세요. 업데이트를 수행 중인 애플리케이션 클라이언트가 있는 경우에는 특정 시간대에 몰리지 않게 고르게 분포시키세요.

• 요청 비율이 높은 애플리케이션을 설계할 때는 특정 작업의 비율 제한에 주의해야 합니다. 특정 유형의 이그레스에 대한 대역폭 한도를 파악하고 요청 비율 및 액세스 분배 가이드라인을 따르세요. 특히 자동 확장을 지원하고 최고 성능을 위해 요청 비율을 점진적으로 늘려야 할 필요가 있습니다.

• 오류 처리 시:

  • 대규모 트래픽 버스트로 인한 문제를 방지하려면 애플리케이션에서 재시도 전략을 사용해야 합니다.

  • 새 연결을 사용하여 다시 시도하고 도메인 이름을 다시 확인합니다. 이는 재시도 시 첫 요청 때와 동일한 경로를 거쳐 동일한 비정상 구성요소에 도달하게 되는 '서버 고정'을 방지하기 위한 것입니다.

• 애플리케이션이 지연 시간에 민감한 경우 헤지된 요청을 사용합니다. 헤지된 요청을 사용하면 더 빨리 다시 시도하고 꼬리 지연 시간을 줄일 수 있습니다. 하지만 요청 최종 기한은 단축되지 않기 때문에 요청이 조기에 시간 초과될 수 있습니다. 자세한 내용은 The Tail at Scale을 참조하세요.

• 고객이 애플리케이션에 바라는 성능 수준을 파악합니다. 이 정보는 새 버킷을 생성할 때 스토리지 옵션과 리전을 선택하는 데 도움이 됩니다. 예를 들어 분석 애플리케이션을 위해 Cloud Storage 버킷과 함께 컴퓨팅 리소스를 배치하는 것이 좋습니다.

위치 및 데이터 스토리지 옵션

데이터를 가장 잘 저장하는 방법에 대한 안내는 스토리지 클래스 및 버킷 위치 주제를 참조하세요.

ACL 및 액세스 제어

• Cloud Storage 요청은 버킷 및 객체를 이름으로 참조합니다. 따라서 권한이 없는 제3자가 버킷이나 객체를 사용하는 것을 ACL이 방지하더라도, 제3자는 버킷 또는 객체 이름을 통해 요청을 시도하고 오류 응답을 관찰함으로써 그러한 버킷이나 객체가 존재하는 것을 파악할 수 있습니다. 그러면 버킷 또는 객체 이름에 있는 정보가 유출될 수 있습니다. 버킷 또는 객체 이름의 개인정보 보호에 대해 걱정이 되면 다음과 같은 적절한 예방 조치를 취해야 합니다.

  • 추측하기 어려운 버킷 및 객체 이름을 선택합니다. 예를 들어 mybucket-gtbytul3라는 버킷 이름은 권한이 없는 제3자가 쉽게 알아내거나 이로부터 다른 버킷 이름을 열거하기 어려울 정도로 충분히 임의적입니다.

  • 민감한 정보를 버킷 또는 객체 이름의 일부분으로 사용하는 것을 피합니다. 예를 들어 버킷 이름을 mysecretproject-prodbucket으로 지정하는 대신 somemeaninglesscodename-prod로 지정하세요. 일부 애플리케이션에서는 객체 이름에 메타데이터를 인코딩하지 않고 x-goog-meta와 같은 커스텀 Cloud Storage 헤더에 민감한 메타데이터를 보관할 수 있습니다.

• 많은 수의 사용자를 명시적으로 나열하려면 그룹을 사용하는 것이 좋습니다. 그룹은 확장성이 더 뛰어날 뿐만 아니라 다수의 객체에 대한 액세스 제어를 한 번에 모두 업데이트할 수 있는 매우 효율적인 방법입니다. 마지막으로 ACL을 변경하기 위해 객체별로 요청할 필요가 없기 때문에 비용도 덜 듭니다.

• 액세스 제어 권장사항을 검토하고 따릅니다.

• Cloud Storage 액세스 제어 시스템에서는 객체를 공개적으로 읽을 수 있는지 여부를 지정할 수 있습니다. 이 권한을 사용하여 작성하는 객체가 공개되어도 괜찮은지를 확인해야 합니다. 인터넷의 데이터는 일단 '게시된' 이후에는 여러 곳에 복사될 수 있기 때문에 이 권한을 사용하여 작성한 객체에 대해 읽기를 다시 통제하는 것은 사실상 불가능합니다.

• Cloud Storage 액세스 제어 시스템에서는 버킷을 공개적으로 작성할 수 있는지 여부를 지정할 수 있습니다. 공개적으로 작성할 수 있도록 버킷을 구성하는 것이 여러 가지 용도에서 편리할 수 있지만 이 권한을 사용하는 것은 바람직하지 않습니다. 불법적인 콘텐츠 바이러스나 기타 멀웨어를 유포하는 데 악용될 수 있으며, 버킷 소유자가 버킷에 저장된 콘텐츠에 대해 법적 및 재정적 책임을 져야 하기 때문입니다.

  사용자 계정이 없는 사용자에게 콘텐츠를 안전하게 제공해야 하는 경우에는 서명된 URL을 사용하는 것이 좋습니다. 예를 들어 서명된 URL을 사용하면 객체에 대한 링크를 제공할 수 있으므로 애플리케이션 고객이 Cloud Storage에 인증하지도 않고 객체에 액세스할 수 있습니다. 서명된 URL을 만들 때 유형(읽기, 쓰기, 삭제)와 액세스 기간을 제어합니다.

데이터 업로드

• XMLHttpRequest(XHR) 콜백을 사용하여 진행 상황 업데이트를 받을 때 진행이 멈춘 것으로 감지될 경우 연결을 닫았다가 다시 열지 마세요. 연결을 닫았다가 다시 열면 네트워크 정체 중에 거짓 양성 피드백 루프가 발생합니다. 네트워크가 정체될 때 XHR 콜백은 업로드 스트림에서 승인(ACK/NACK) 활동 뒤에 백로그될 수 있습니다. 이때 연결을 닫았다가 다시 열면 사용할 수 있게 되는 순간에 더 많은 네트워크 용량을 사용하게 됩니다.

• 업로드 트래픽의 경우 적당히 긴 시간 제한을 설정하는 것이 좋습니다. 우수한 최종 사용자 환경을 위해 애플리케이션이 장시간 동안 XHR 콜백을 받지 않았을 때 메시지(예: '네트워크 정체')와 함께 클라이언트 상태 창을 업데이트하는 클라이언트 측 타이머를 설정할 수 있습니다. 이런 상황이 발생할 때 그냥 연결을 닫고 다시 시도해서는 안 됩니다.

• 각 요청에 필요한 대역폭을 줄이는 쉽고 편리한 한 가지 방법은 gzip 압축을 사용하는 것입니다. 이 경우 결과를 압축 해제하려면 CPU 시간이 추가로 필요하기는 하지만 대신에 네트워크 비용을 절감할 수 있다는 장점이 있습니다.

  gzip 형식으로 업로드된 객체는 일반적으로 gzip 형식으로도 제공됩니다. 하지만 압축된 content-encoding: gzip과 content-type이 모두 있는 콘텐츠를 업로드하지 마세요. 업로드하면 예기치 않은 동작이 발생할 수 있습니다.

• 통신 장애로 인해 데이터 흐름이 중단된 경우에도 데이터 전송을 재개할 수 있는 재개 가능한 업로드를 사용하는 것이 좋습니다. 또한 XML API 멀티파트 업로드를 사용하여 파일의 여러 부분을 동시에 업로드하면 전체 업로드 완료 시간을 단축할 수 있습니다.

데이터 삭제

데이터 삭제에 대한 가이드라인 및 고려사항은 객체 삭제를 참조하세요. 또한 데이터 수명 주기 관리 기능을 사용하여 애플리케이션 소프트웨어 또는 사용자가 데이터를 잘못 삭제하지 않도록 보호할 수 있습니다.