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 멀티파트 업로드를 사용하여 파일의 여러 부분을 동시에 업로드하면 전체 업로드 완료 시간을 단축할 수 있습니다.
데이터 삭제
데이터 삭제에 대한 가이드라인 및 고려사항은 객체 삭제를 참조하세요.
또한 데이터 수명 주기 관리 기능을 사용하여 애플리케이션 소프트웨어 또는 사용자가 데이터를 잘못 삭제하지 않도록 보호할 수 있습니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-05(UTC)"],[],[],null,["# Best practices for Cloud Storage\n\nThis page contains an index of best practices for Cloud Storage. You can use\nthe information collected here as a quick reference of what to keep in mind when\nbuilding an application that uses Cloud Storage.\n\nIf you are just starting out with Cloud Storage, this page may not be\nthe best place to start, because it does not teach you the basics of how to use\nCloud Storage. If you are a new user, we suggest that you start with\n[Discover object storage with the Google Cloud console](/storage/docs/discover-object-storage-console) or\n[Discover object storage with the gcloud tool](/storage/docs/discover-object-storage-gcloud).\n\nFor best practices for media workloads, see [Best practices for media workloads](/storage/docs/best-practices-media-workload).\n\nNaming\n------\n\nSee [Bucket naming](/storage/docs/buckets#naming) and [Object naming](/storage/docs/objects#naming) for name requirements\nand considerations.\n\nTraffic\n-------\n\n- Perform a back-of-the-envelope estimation of the amount of traffic that will\n be sent to Cloud Storage. Specifically, think about:\n\n - Operations per second. How many operations per second do you expect, for\n both buckets and objects, and for create, update, and delete operations.\n\n - Bandwidth. How much data will be sent, over what time frame? Consider\n using a tool like [Wolfram Alpha](https://www.wolframalpha.com/input?i=350GB+in+5+minutes)\n to avoid mistakes in your calculations.\n\n - Cache control. Specifying the [`Cache-Control` metadata](/storage/docs/metadata#cache-control) on publicly\n accessible objects will benefit read latency on hot or frequently accessed\n objects.\n See [Viewing and Editing Metadata](/storage/docs/viewing-editing-metadata#edit) for instructions for setting object\n metadata, such as `Cache-Control`.\n\n- Design your application to minimize spikes in traffic. If there are clients of\n your application doing updates, spread them out throughout the day.\n\n- When designing applications for high request rates, be aware of\n [rate limits](/storage/quotas) for certain operations. Know the [bandwidth limits](/storage/quotas#bandwidth) for\n certain types of egress and follow the\n [Request Rate and Access Distribution Guidelines](/storage/docs/request-rate). Be especially aware of\n autoscaling and the need to gradually ramp up request rates for the best\n performance.\n\n- When handling errors:\n\n - Make sure your application uses a [retry strategy](/storage/docs/retry-strategy) in order to\n avoid problems due to large traffic bursts.\n\n - Retry using a new connection and possibly re-resolve the domain name. This\n helps avoid \"server stickiness\", where a retry attempts to go through the\n same path and hits the same unhealthy component that the initial request\n hit.\n\n- If your application is latency sensitive, use hedged requests. Hedged requests\n allow you to retry faster and cut down on tail latency. They do this while not\n reducing your request deadline, which could cause requests to time out\n prematurely. For more information, see\n [The Tail at Scale](https://research.google/pubs/pub40801/).\n\n- Understand the performance level customers expect from your application. This\n information helps you choose a storage option and region when creating new\n buckets. For example, consider colocating your compute resources with your\n Cloud Storage buckets for analytics applications.\n\nLocations and data storage options\n----------------------------------\n\nSee the [Storage class](/storage/docs/storage-classes) and [Bucket location](/storage/docs/locations) topics for guidance on how\nto best store your data.\n\nACLs and access control\n-----------------------\n\n- Cloud Storage requests refer to buckets and objects by their names. As a\n result, even though ACLs prevent unauthorized third parties from operating on\n buckets or objects, a third party can attempt requests with bucket or object\n names and determine their existence by observing the error responses. It can\n then be possible for information in bucket or object names to be leaked. If you\n are concerned about the privacy of your bucket or object names, you should take\n appropriate precautions, such as:\n\n - **Choosing bucket and object names that are difficult to guess.** For\n example, a bucket named `mybucket-gtbytul3` is random enough that\n unauthorized third parties cannot feasibly guess it or enumerate other\n bucket names from it.\n\n - **Avoiding use of sensitive information as part of bucket or object\n names.** For example, instead of naming your bucket\n `mysecretproject-prodbucket`, name it `somemeaninglesscodename-prod`. In\n some applications, you may want to keep sensitive metadata in\n [custom Cloud Storage headers](/storage/docs/metadata#custom-metadata) such as `x-goog-meta`, rather than encoding\n the metadata in object names.\n\n- Using groups is preferable to explicitly listing large numbers of users. Not\n only does it scale better, it also provides a very efficient way to update\n the access control for a large number of objects all at once. Lastly, it's\n cheaper as you don't need to make a request per-object to change the ACLs.\n\n- Review and follow [access control best practices](/storage/docs/access-control/best-practices-access-control).\n\n- The Cloud Storage access control system includes the ability to\n specify that objects are publicly readable. Make sure you intend for any\n objects you write with this permission to be public. Once \"published\", data on\n the Internet can be copied to many places, so it's effectively impossible to\n regain read control over an object written with this permission.\n\n- The Cloud Storage access control system includes the ability to\n specify that buckets are publicly writable. While configuring a bucket this\n way can be convenient for various purposes, we recommend against using this\n permission - it can be abused for distributing illegal content, viruses, and\n other malware, and the bucket owner is legally and financially responsible for\n the content stored in their buckets.\n\n If you need to make content available securely to users who don't have user\n accounts, we recommend you use [signed URLs](/storage/docs/access-control/signed-urls). For example, with signed URLs\n you can provide a link to an object, and your application's customers don't\n need to authenticate with Cloud Storage to access the object. When you\n create a signed URL you control the type (read, write, delete) and duration of\n access.\n\nData uploads\n------------\n\n- If you use XMLHttpRequest (XHR) callbacks to get progress updates, do not\n close and re-open the connection if you detect that progress has stalled.\n Doing so creates a bad positive feedback loop during times of network\n congestion. When the network is congested, XHR callbacks can get backlogged\n behind the acknowledgement (ACK/NACK) activity from the upload stream, and\n closing and reopening the connection when this happens uses more network\n capacity at exactly the time when you can least afford it.\n\n- For upload traffic, we recommend setting reasonably long timeouts. For a good\n end-user experience, you can set a client-side timer that updates the client\n status window with a message (e.g., \"network congestion\") when your\n application hasn't received an XHR callback for a long time. Don't just\n close the connection and try again when this happens.\n\n- An easy and convenient way to reduce the bandwidth needed for each request is\n to enable gzip compression. Although this requires additional CPU time to\n uncompress the results, the trade-off with network costs usually makes it\n very worthwhile.\n\n An object that was uploaded in gzip format can generally be served in gzip\n format as well. However, avoid uploading content that has both\n `content-encoding: gzip` and a `content-type` that is compressed, as this\n may lead to [unexpected behavior](/storage/docs/transcoding#gzip-gzip).\n- We recommend using [resumable uploads](/storage/docs/resumable-uploads), which allow you to resume\n transferring data even when a communication failure has interrupted the flow\n of data. You can also use XML API multipart uploads to upload parts of a file\n in parallel, which potentially reduces the time to complete the overall\n upload.\n\nDeletion of data\n----------------\n\nSee [Delete objects](/storage/docs/deleting-objects) for guidelines and considerations on deleting data.\nYou can also use [features for controlling data lifecycles](/storage/docs/control-data-lifecycles) to help protect\nyour data from getting erroneously deleted by your application software or\nusers."]]
