Cloud Storage 권장사항

소개

이 페이지에는 Cloud Storage 문서의 다른 페이지에서 가져온 권장사항이 요약되어 있습니다. 여기에 나열된 권장사항을 활용하여 Cloud Storage를 사용하는 애플리케이션을 빌드할 때 유의할 점을 빠르게 참조할 수 있습니다. 상용 애플리케이션을 출시할 때 이 권장사항을 따르세요.

이 페이지는 Cloud Storage의 기본적인 사용법을 안내하지 않으므로 Cloud Storage를 시작한 지 얼마 안 된 사용자에게는 적합하지 않을 수 있습니다. 신규 사용자라면 시작하기: GCP Console 사용 또는 시작하기: gsutil 도구 사용부터 살펴보는 것이 좋습니다.

이름 지정

  • 버킷 네임스페이스는 전체 공개로 표시됩니다. 모든 버킷 이름은 Cloud Storage 네임스페이스 전체에서 고유해야 합니다. 자세한 내용은 버킷 및 객체 이름 지정 가이드라인을 참조하세요.

  • 버킷이 많이 필요한 경우에는 GUID 또는 대응하는 버킷 이름을 사용하고, 이름이 충돌하지 않게 재시도 로직을 코드에 넣고, 버킷을 상호 참조하기 위한 목록을 유지하세요. 또 다른 옵션은 도메인 이름이 지정된 버킷을 사용하고 버킷 이름을 하위 도메인으로 관리하는 것입니다.

  • 누구든지 버킷의 존재를 조사할 수 있기 때문에 사용자 ID, 이메일 주소, 프로젝트 이름, 프로젝트 번호 또는 기타 식별 정보(PII)를 버킷 이름에 사용하지 마세요. 마찬가지로, 객체 이름은 객체의 URL에 나타나기 때문에 객체 이름에 PII를 넣을 때는 매우 신중해야 합니다.

  • 버킷 이름은 CNAME 리디렉션의 일환으로 DNS 레코드에 나타날 수 있기 때문에 표준 DNS 명명 규칙을 따라야 합니다. 버킷 이름 요구사항에 대한 자세한 내용은 버킷 이름 요구사항을 참조하세요.

  • 기본 디렉토리가 지원되지 않기 때문에 객체에 있는 슬래시는 Cloud Storage에서 특별한 의미를 가지지 않습니다. 따라서 슬래시 구분 기호를 사용하는 깊게 중첩된 디렉터리 형태의 구조가 가능하지만, 깊게 중첩된 하위 디렉터리를 나열하는 기본 파일 시스템의 성능을 갖지는 못합니다.

  • 여러 파일을 동시에 업로드하는 경우 타임스탬프 기반 파일 이름과 같은 순차적 파일 이름을 사용하지 마세요. 순차적 이름을 사용하는 파일은 연속적으로 저장되기 때문에 같은 백엔드 서버에 도달할 가능성이 높습니다. 이로 인해 처리량이 제한됩니다. 최적의 처리량을 얻기 위해 순차 번호의 해시를 파일 이름의 일부분으로 추가함으로써 파일 이름을 비순차적으로 만들 수 있습니다. 자세한 내용은 요청 비율 및 액세스 분배 가이드라인을 참조하세요.

트래픽

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

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

    • 대역폭. 해당 기간 동안 얼마나 많은 데이터가 전송될 예정인가요?

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

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

  • Cloud Storage에는 요청 비율 상한이 없지만 높은 요청 비율로 확장할 때 최상의 성능을 얻으려면 요청 비율 및 액세스 분배 가이드라인을 참조하세요.

  • 일부 작업에는 비율 한도가 있으므로 그에 따라 애플리케이션을 설계해야 합니다.

  • 오류가 발생할 경우 지수 백오프를 수행하여 큰 트래픽 폭주로 인한 문제를 방지하세요.

  • 고객이 애플리케이션에 바라는 성능 수준을 파악하세요. 이 정보는 새 버킷을 생성할 때 스토리지 옵션 및 리전을 선택하는 데 도움이 됩니다.

리전 및 데이터 스토리지 옵션

  • 높은 비율과 고가용성으로 처리될 데이터는 표준 스토리지 클래스를 사용해야 합니다. 이 클래스는 최상의 가용성을 제공하지만 가격이 높다는 것이 단점입니다.

  • Nearline Storage 또는 Coldline Storage 클래스를 사용하여 자주 액세스하지 않으며 가용성이 약간 낮아도 되는 데이터를 저장할 수 있습니다.

  • 애플리케이션의 사용자와 가장 가까운 리전에 데이터를 저장하세요. 예를 들어 EU 데이터의 경우 EU 버킷을 선택하고, US 데이터의 경우 US 버킷을 선택할 수 있습니다. 자세한 내용은 버킷 위치를 참조하세요.

  • 사용자 데이터의 위치를 선택할 때 규정 준수 요구사항을 염두에 두세요. 사용자가 데이터를 제공할 위치 주변에 법적 요구사항이 있나요?

보안, ACL, 액세스 제어

  • 절대로 사용자 인증 정보를 공유하지 않는 것이 첫 번째이자 가장 중요한 예방 조치입니다. 각 사용자마다 개별적인 사용자 인증 정보를 가지고 있어야 합니다.

  • HTTP 프로토콜 세부정보를 출력할 때 OAuth 2.0 토큰 같은 사용자 인증 정보는 헤더에 표시됩니다. 프로토콜 세부정보를 게시판에 게시해야 하거나 문제 해결을 위해 HTTP 프로토콜 세부정보를 제공해야 하는 경우에는 출력에 포함되어 표시되는 모든 사용자 인증 정보를 삭제하거나 취소해야 합니다.

  • 가능하면 항상 TLS(HTTPS)를 사용하여 데이터를 전송하세요. 그러면 네트워크를 거쳐 데이터를 전송하는 동안 사용자 인증 정보는 물론 데이터까지도 보호할 수 있습니다. 예를 들어 Cloud Storage API에 액세스하려면 https://storage.googleapis.com을 사용해야 합니다.

  • 서버 인증서의 유효성을 검사하는 HTTPS 라이브러리를 사용해야 합니다. 서버 인증서의 유효성을 검사하지 않으면 애플리케이션이 중간자 공격이나 기타 공격에 취약해집니다. 흔히 사용되는 특정 구현 언어와 함께 제공되는 HTTPS 라이브러리는 기본적으로 서버 인증서를 확인하지 않는다는 점에 유의하세요. 예를 들어 버전 3.2 이전의 Python에서는 서버 인증서 유효성 검사가 기본적으로 또는 완전하게 지원되지 않기 때문에 애플리케이션에서 서버 인증서의 유효성을 검사하도록 타사 래퍼 라이브러리를 사용해야 합니다. Boto 플러그인에는 서버 인증서의 유효성을 검사하는 코드가 기본적으로 포함되어 있습니다.

  • 애플리케이션이 더 이상 데이터에 액세스할 필요가 없으면 해당 사용자 인증 정보를 취소해야 합니다. Google 서비스 및 API의 경우에는 Google 계정 권한에 로그인하고 불필요한 애플리케이션을 클릭한 후 액세스 삭제를 클릭하면 됩니다.

  • 사용자 인증 정보를 안전하게 보관해야 합니다. 작업 환경에 따라 그리고 사용자 인증 정보를 저장하는 곳에 따라 방법은 다양합니다. 예를 들어 사용자 인증 정보를 구성 파일에 저장하는 경우에는 무단 액세스를 방지하기 위해 해당 파일에 적절한 권한을 설정해야 합니다. Google App Engine을 사용하는 경우 StorageByKeyName을 사용하여 사용자 인증 정보를 저장하는 것이 좋습니다.

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

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

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

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

  • 객체를 버킷에 추가하기 전에 먼저 기본 객체 ACL이 요구사항에 맞게 설정되었는지 확인하세요. 그러면 개별 객체의 ACL을 업데이트하는 데 걸리는 시간을 크게 절약할 수 있습니다.

  • 버킷 및 객체 ACL은 서로 간에 독립적입니다. 즉, 버킷의 ACL이 해당 버킷 안에 있는 객체의 ACL에 영향을 미치지 않습니다. 버킷에 대한 권한이 없는 사용자가 해당 버킷 안의 객체에 대한 권한을 갖는 것이 가능합니다. 예를 들어 GroupA만 버킷 안에 객체를 나열할 수 있는 권한을 가진 버킷을 만들고 이후에 GroupB에게 객체에 대한 READ 액세스 권한을 허용하는 버킷을 만들어 해당 버킷으로 객체를 업로드할 수 있습니다. 그러면 GroupB는 객체를 읽을 수는 있지만 버킷의 내용을 보거나 버킷 관련 작업을 수행할 수 없습니다.

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

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

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

  • gsutil을 사용하는 경우에는 추가 권장사항을 참조하세요.

데이터 업로드

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

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

  • Compute Engine 인스턴스를 Cloud Storage에 POST하는 프로세스와 함께 사용하여 재개 가능한 업로드를 시작하는 경우에는 Compute Engine 버킷과 동일한 위치에서 Cloud Storage 인스턴스를 사용해야 합니다. 그런 다음에 지역 IP 서비스를 사용하여 고객 요청을 라우팅할 Compute Engine 리전을 선택할 수 있습니다. 이렇게 하면 트래픽을 리전에 맞게 현지화하는 데 도움이 됩니다.

  • 재개 가능한 업로드의 경우 재개 가능한 세션이 생성된 리전에 그대로 있어야 합니다. 그러면 세션 상태를 읽고 쓸 때 발생하는 지역 간 트래픽이 줄어들어 재개 가능한 업로드의 성능이 향상됩니다.

  • 가능하면 전송을 보다 작은 청크로 나누는 것을 피하고, 대신 전체 콘텐츠를 단일 청크에 업로드하세요. 청크 생성을 방지하면 고정된 지연 시간 비용이 절감되고 처리량이 향상될 뿐만 아니라 Cloud Storage에 대한 QPS도 줄어듭니다.

    청크로 업로드하는 것을 고려해야 하는 상황으로는 소스 데이터가 동적으로 생성될 때, 클라이언트에 요청 크기 제한이 있을 때(많은 브라우저가 이에 해당함), 클라이언트가 전체 요청을 메모리에 먼저 로드하지 않고서는 단일 요청에서 바이트를 스트리밍할 수 없을 때 등이 있습니다. 클라이언트가 오류를 수신한 경우 커밋 오프셋을 위해 서버를 쿼리하고 해당 오프셋부터 나머지 바이트의 업로드를 재개할 수 있습니다.

  • 가능하면 압축된 content-encoding: gzipcontent-type이 모두 있는 콘텐츠를 업로드하지 마세요. 업로드하면 예기치 않은 동작이 발생할 수 있습니다.

데이터 삭제

애플리케이션 소프트웨어 또는 사용자가 특정 시점에 실수로 객체를 삭제하거나 덮어쓸 위험이 있는 경우 Cloud Storage에서 제공되는 데이터 보호 기능을 사용하면 도움이 됩니다.

  • 보관 기간을 지정하는 보관 정책버킷에 적용할 수 있습니다. 그러면 지정된 기간에 도달할 때까지 해당 버킷의 객체를 삭제하거나 덮어쓸 수 없습니다.

  • 객체 보존 조치개별 객체에 적용하여 보존 조치가 삭제될 때까지는 아무도 객체를 삭제하거나 덮어쓰지 못하게 할 수 있습니다.

  • 객체를 삭제하거나 덮어쓸 때 이전 버전의 객체를 보관하도록 버킷에 객체 버전 관리를 사용 설정할 수 있습니다. 객체 버전 관리를 사용 설정하면 스토리지 비용이 증가할 수 있지만 오래된 객체 버전을 삭제하도록 객체 수명 주기 관리를 구성하면 이를 일부 완화할 수 있습니다.

객체 나열

방금 버킷에서 다수의 객체를 삭제한 경우에는 객체 등록이 일시적으로 매우 느려질 수 있습니다. 그 이유는 삭제된 레코드가 기본 저장소 시스템에서 즉시 삭제되지 않아 객체 등록이 반환할 객체를 찾을 때 삭제된 레코드를 건너뛰어야 하기 때문입니다.

시간이 지나면 삭제된 레코드가 기본 저장소 시스템에서 결국 삭제되며, 이때부터는 객체 등록 성능이 다시 정상이 됩니다. 이 과정은 일반적으로 몇 시간이 걸리지만, 때로는 며칠이 걸릴 수도 있습니다.

최근에 많은 항목이 삭제된 객체 범위를 나열하지 않도록 워크로드를 설계해야 합니다. 예를 들어 반복적으로 객체를 나열했다 삭제함으로써 버킷에서 객체를 삭제하려는 경우에는 각 요청을 시작할 때마다 나열을 다시 시작하는 대신 객체 나열 응답에 의해 반환되는 페이지 토큰을 사용하여 다음 나열 요청을 실행해야 합니다. 처음부터 다시 나열을 시작하면 각 요청이 방금 삭제된 모든 객체를 건너뛰어야 하기 때문에 객체 나열이 느려집니다. 특정 프리픽스 아래에서 많은 객체를 삭제한 경우에는 삭제 직후에 해당 프리픽스 아래에서 객체를 나열하지 마세요.

웹사이트 호스팅

CORS(Cross-Origin Resource Sharing) 주제에서는 다른 웹사이트에서 호스팅되는 스크립트가 Cloud Storage 버킷에 저장된 정적 리소스에 액세스할 수 있도록 허용하는 방법에 대해 설명합니다. 반대의 시나리오는 Cloud Storage에서 호스팅되는 스크립트가 Cloud Storage 외부의 웹사이트에서 호스팅되는 정적 리소스에 액세스할 수 있도록 허용하는 것입니다. 후자의 경우, 해당 웹사이트는 storage.googleapis.com의 콘텐츠에 액세스를 허용할 수 있도록 CORS 헤더를 사용합니다. 이 데이터 액세스에 전용 버킷을 사용하는 것이 좋습니다. 예를 들어 웹사이트에서 Access-Control-Allow-Origin: https://storage.googleapis.com 대신 CORS 헤더 Access-Control-Allow-Origin: https://mybucket.storage.googleapis.com을 사용하도록 하는 것이 좋습니다. 이 방식은 사이트에 있는 정적 리소스가 실수로 모든 storage.googleapis.com에 과도하게 노출되는 것을 방지합니다.

이 페이지가 도움이 되었나요? 평가를 부탁드립니다.

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

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