Cloud Storage 的最佳做法

本頁面包含 Cloud Storage 最佳做法的索引。建構使用 Cloud Storage 的應用程式時，您可以快速參考本文章所列的最佳做法；

如果您剛開始使用 Cloud Storage，那麼可能不太適合參考本頁面，因為這裡的內容並非說明使用 Cloud Storage 的基本概念。如果您是新使用者，建議先參閱使用 Trusted Cloud 控制台探索物件儲存空間或使用 gcloud 工具探索物件儲存空間。

如需媒體工作負載的最佳做法，請參閱媒體工作負載最佳做法。

命名

如需名稱規定和注意事項，請參閱值區命名和物件命名。

流量

  • 針對會傳送到 Cloud Storage 的流量進行簡便計算。具體來說，請將下列項目納入考量：

    • 每秒作業數。對於值區和物件的建立、更新和刪除作業，您預期每秒會執行多少次作業。

    • 頻寬。在什麼時間範圍內會傳送多少資料？建議使用 Wolfram Alpha 等工具，以免計算時發生錯誤。

    • 快取控制。在可公開存取的物件上指定 Cache-Control 中繼資料，能改善熱門物件或頻繁存取物件的讀取延遲時間。如需設定 Cache-Control 這類物件中繼資料的操作說明，請參閱查看及編輯中繼資料一文。

  • 妥善設計您的應用程式以降低流量尖峰的情況。如果您應用程式的用戶端正在進行更新，請將更新作業分散在一天中進行。

  • 為高要求率設計應用程式時，請注意特定作業的頻率限制。瞭解特定類型輸出內容的頻寬限制，並遵循要求比率和存取權分配指南。請特別留意自動調整資源配置，並視需要逐步提高要求率，以獲得最佳效能。

  • 處理錯誤時：

    • 請確保應用程式使用重試策略，以免因流量爆發而發生問題。

    • 請使用新的連線重試，並可能重新解析網域名稱。這有助於避免「伺服器黏著性」，也就是重試嘗試透過相同路徑，並命中初始要求命中的相同不健全元件。

  • 如果您的應用程式對延遲時間很敏感，請使用對沖要求。使用對沖要求，您可以更快重試，並減少尾部延遲。但不會縮短要求期限，否則要求可能會提早逾時。詳情請參閱「The Tail at Scale」。

  • 瞭解顧客對您應用程式的效能期望。這項資訊有助於您在建立新值區時選擇儲存空間選項。

位置和資料儲存空間選項

如需如何以最佳方式儲存資料的指引，請參閱「儲存空間級別」和「值區位置」主題。

存取控制清單和存取權控管

  • Cloud Storage 要求必須透過值區和物件的名稱來參照值區和物件。因此即使 ACL 可防止未經授權的第三方對值區或物件執行作業，但第三方仍可透過值區或物件名稱嘗試發出要求，並藉由觀察錯誤回應來判斷值區和物件是否存在。這樣一來，值區或物件名稱中的資訊就有洩漏之虞。如果您對值區或物件名稱的隱私有所疑慮，則應採取適當的預防措施，如同下列事項：

    • 選用難以猜到的值區和物件名稱。例如像 mybucket-gtbytul3 這樣的值區名稱就具備足夠的隨機性，可讓未經授權的第三方無法輕易猜到該名稱，或是難以從中推導出其他值區名稱。

    • 避免在值區或物件名稱中使用敏感資訊。舉例來說，與其將值區命名為 mysecretproject-prodbucket，不如取名為 somemeaninglesscodename-prod。在某些應用程式中，您也不妨將敏感的中繼資料放在 x-goog-meta 等 自訂 Cloud Storage 標頭中，而不要將這些資訊編入物件名稱中。

  • 盡量使用群組來明確列出大量的使用者。這樣不僅能夠更完善調整，也提供非常有效的方法來同時更新大量物件的存取控管。此外，因為您不需要對每個物件發出更改 ACL 的要求，採取這樣的做法也會比較省錢。

  • 詳閱並遵循存取權控管最佳做法。

  • Cloud Storage 存取權控管系統可指定物件是否可公開讀取。請確認您希望公開透過此權限編寫的任何物件。網際網路上的資料一經「發布」即可複製到許多位置，因此實際上您無法重新取得透過此權限所編寫物件的讀取控制權。

  • Cloud Storage 存取權控管系統可指定值區是否可公開寫入。雖然以這種方式設定值區適用於各種用途，但我們建議不要使用這項權限，因為可能會被濫用於發布非法內容、病毒及其他惡意軟體，值區擁有者對於儲存在其值區中的內容具有法律和財務上的責任。

    如要安全地向沒有使用者帳戶的使用者提供內容，建議使用簽章網址。舉例來說，您可以透過簽章網址提供物件的連結，應用程式客戶不必向 Cloud Storage 驗證身分，即可存取物件。建立已簽署的網址時，您可以控制存取權的類型 (讀取、寫入、刪除) 和持續時間。

資料上傳

  • 如果使用 XMLHttpRequest (XHR) 回呼來取得進度的更新資訊，請不要在偵測到進度停滯時關閉並重新開啟連線。這樣做會在網路擁塞期間產生錯誤的正向意見回饋循環。當網路擁塞時，XHR 回呼可能會積壓在上傳串流的確認 (ACK/NACK) 活動後方，而且發生這種情況時，如果您將連線關閉並重新開啟，則會造成您在最需要網路容量的期間使用更多的網路容量。

  • 我們建議您針對上傳流量，設定合理長度的逾時。如要提供良好的使用者體驗，您可以設定用戶端計時器，在您的應用程式長時間未收到 XHR 回呼時，計時器會透過訊息 (例如「網絡擁擠」) 來更新用戶端狀態視窗。發生這種情況時，請勿關閉連線並再試一次。

  • 要減少每個要求占用的頻寬，最簡便的方法就是使用 gzip 壓縮檔。雖然此方法需要額外的 CPU 作業時間進行解壓縮，但相對可省下可觀的網路成本。

    以 gzip 格式上傳的物件通常也可以 gzip 格式提供。不過，請避免上傳同時具有 content-encoding: gzip 和壓縮的 content-type，因為這可能會導致意外行為。

  • 建議使用可續傳的上傳作業，即使通訊問題導致資料傳輸過程遭到中斷，之後仍可繼續傳輸資料。您也可以使用 XML API 多部分上傳作業，平行上傳檔案的各個部分，這可能會縮短完成整體上傳作業的時間。

資料刪除作業

如要瞭解刪除資料的相關指引和注意事項，請參閱「刪除物件」。您也可以使用控管資料生命週期的功能，防止應用程式軟體或使用者誤刪資料。