이 페이지에는 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 멀티파트 업로드를 사용하여 파일의 여러 부분을 동시에 업로드하면 전체 업로드 완료 시간을 단축할 수 있습니다.
데이터 삭제
데이터 삭제에 대한 가이드라인 및 고려사항은 객체 삭제를 참조하세요. 또한 데이터 수명 주기 관리 기능을 사용하여 애플리케이션 소프트웨어 또는 사용자가 데이터를 잘못 삭제하지 않도록 보호할 수 있습니다.