Cloud Storage 的最佳做法

簡介

本頁面包含從 Cloud Storage 說明文件中其他頁面所取得的最佳做法匯總。建構使用 Cloud Storage 的應用程式時,您可以快速參考本文章所列的最佳做法;推出商業應用程式時,則請按照這些最佳做法。

如果您剛開始使用 Cloud Storage,那麼可能不太適合參考本頁面,因為這裡的內容並非說明使用 Cloud Storage 的基本概念。我們建議新的使用者先參閱入門指南:使用 GCP 主控台入門指南:使用 gsutil 工具

命名

  • 值區命名空間是全域性質,並且會公開顯示。整個 Cloud Storage 命名空間中的值區名稱均不得重複。如需瞭解詳情,請參閱值區與物件命名規範

  • 如果您需要大量的值區,請針對值區名稱使用 GUID 或同等項目,在您的程式碼中設置重試邏輯來處理名稱衝突,並且保留一份清單以交叉參照值區。另一個選擇是使用以網域命名的值區,並將值區名稱做為子網域來管理。

  • 請勿將使用者 ID、電子郵件地址、專案名稱、專案編號或任何個人識別資訊 (PII) 包含在值區名稱,因為這樣任何人都可以探測出值區的存在。由於物件名稱會出現在物件的網址中,因此也同樣務必注意是否有將 PII 放入物件名稱。

  • 值區名稱應符合標準 DNS 命名慣例,因為值區名稱會做為 CNAME 重新導向的一部分,而出現在 DNS 記錄中。如需進一步瞭解值區命名規定,請參閱值區命名規定一文。

  • 由於不支援原生目錄,物件中的正斜線在 Cloud Storage 中並沒有特殊意義。因此,具有許多巢狀層級的目錄結構可以使用斜線做為分隔符號,只不過無法呈現與原生檔案系統所列出的多層級巢狀子目錄一樣的效用。

  • 如要平行上傳多個檔案,請避免使用連續的檔案名稱,像是依據時間戳記的檔案名稱等。由於系統會依序儲存具有連續名稱的檔案,因此這些檔案可能會使用相同的後端伺服器,也就代表總處理量會受到限制。為了達到最佳總處理量,您可以在檔案名稱序號中加入斜線,如此即不會形成連續名稱。詳情請參閱要求比率和存取權分配指南

流量

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

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

    • 頻寬。在什麼時間範圍內會傳送多少資料?

    • 快取控制。在熱門物件或頻繁存取的物件上指定 Cache-Control 中繼資料能改善讀取作業的延遲時間。如需設定 Cache-Control 這類物件中繼資料的操作說明,請參閱Cache-Control

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

  • 雖然 Cloud Storage 並沒有設置要求比率的上限,然而為了在擴充至高要求比率時能有最佳效能,請按照要求比率和存取權分配指南

  • 請注意,由於部分作業會有頻率限制,請視情況設計您的應用程式。

  • 如果出現錯誤,請使用指數輪詢以免因流量爆發而發生問題。

  • 瞭解客戶對您的應用程式所期望的效能水準。這項資訊能幫助您在建立新值區時選擇儲存空間選項和地區。

地區與資料儲存空間選項

  • 頻繁提供的高可用性資料應使用 Multi-Regional StorageRegional Storage 級別。這些級別可提供最佳的可用性,但是需要支付較高的價格。

  • 如果資料的存取次數較不頻繁,而且可以接受略低的可用性,那麼您可以使用 Nearline StorageColdline Storage 級別來儲存資料。

  • 將資料儲存在距離應用程式使用者最近的地區。舉例來說,您可以針對歐盟資料選擇 EU 值區;針對美國資料選擇 US 值區。詳情請參閱值區位置

  • 選擇使用者資料的位置時,請謹記法規遵循需求。試想使用者要提供資料的位置是否具有法律要求?

安全性、ACL、存取權控管

  • 首要的預防措施為:永遠不要分享您的憑證,每個使用者應有個別不同的憑證。

  • 輸出 HTTP 通訊協定的詳細資料時,包含 OAuth 2.0 憑證在內的驗證憑證都會顯示在標頭中。如果您需要將通訊協定詳細資料張貼到留言板,或是需要提供 HTTP 通訊協定詳細資料以進行疑難排解,請務必將輸出結果中出現的憑證清除或撤銷。

  • 盡可能一律使用傳輸層安全標準 (HTTPS) 來傳輸資料,這可確保您的憑證及資料在透過網路傳輸資料時會受到保護。舉例來說,如要存取 Cloud Storage API,您應使用 https://storage.googleapis.com。

  • 確保使用可驗證伺服器憑證的 HTTPS 程式庫。缺少伺服器憑證的驗證機制時,您的應用程式可能會容易遭受到中間人攻擊或其他攻擊。請注意,某些常用實作語言隨附的 HTTPS 程式庫預設不會驗證伺服器憑證。例如,3.2 版以前的 Python 沒有內建支援伺服器憑證驗證機制,或支援功能並不完善,因此您必須使用第三方包裝函式程式庫,才能確保您的應用程式可驗證伺服器憑證。根據預設,boto 外掛程式 內含的程式碼會驗證伺服器憑證。

  • 如果應用程式不再需要存取您的資料,則應該撤銷應用程式的驗證憑證。如為 Google 服務和 API,您可以登入 Google 帳戶權限,並點選不需要的應用程式,然後按一下 [Remove Access] (移除存取權)

  • 確認您以安全的方式儲存憑證。方法會因您的環境和儲存憑證的位置而有所不同。舉例來說,如果將憑證儲存在設定檔中,請確認您已針對該檔案設定適當權限,以防未經授權者擅自存取。如果您使用的是 Google App Engine,請考慮使用 StorageByKeyName 來儲存您的憑證。

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

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

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

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

  • 將物件加入值區前,先檢查預設物件 ACL 是否已設為您的需求。這項設定可讓您在更新個別物件的 ACL 時節省更多時間。

  • 值區和物件的 ACL 彼此獨立,也就是說值區的 ACL 並不影響該值區中物件的 ACL。因此,沒有值區存取權的使用者可以具有該值區中物件的存取權。例如您可以建立值區,並且只讓 GroupA 有權列出值區中的物件,接著將物件上傳至該值區,並讓 GroupB 擁有該物件的 READ 權限。這樣一來,GroupB 就變成可以讀取該物件,但無法查看值區的內容或執行與值區相關的作業。

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

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

    如果您需要以安全的方式向沒有 Google 帳戶的使用者提供內容,我們建議您使用已簽署的網址。例如,您可以使用已簽署的網址來提供物件的連結,而您應用程式的客戶無需向 Cloud Storage 進行驗證就能存取該物件。建立已簽署的網址時,您可以控制存取權的類型 (讀取、寫入、刪除) 和持續時間。

  • 如果您使用的是 gsutil,請參閱這些額外建議

上傳資料

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

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

  • 如要將 Compute Engine 執行個體搭配向 Cloud Storage 發送 POST 的程序,以啟動支援續傳的上傳作業,則應該在與 Cloud Storage 值區相同的位置上使用 Compute Engine 執行個體。您接著可以使用地理 IP 服務,選擇 Compute Engine 地區來接收轉送的客戶要求,這樣有助於將流量保持在本地的地理區域。

  • 對於支援續傳的上傳作業,續傳的工作階段應保留在建立作業的地區中。這樣做可以減少讀取及寫入工作階段狀態時造成的跨地區流量,進而提高續傳作業的上傳效能。

  • 如有可能,請避免將傳輸內容分散成小區塊,而是將整個內容上傳到單一區塊中。避免區塊切割可消除固定延遲時間的費用並提升總處理量,而且能夠減少 Cloud Storage 的 QPS。

    在以下的情況中,您應考慮以區塊的形式進行上傳:您的來源資料是動態產生、您的用戶有要求大小限制 (許多瀏覽器都是如此),或是在沒有先完整將要求載入記憶體的情況下,您的用戶無法在單一要求中串流傳輸位元組。如果您的用戶端收到錯誤,他們可以向伺服器查詢認可位移,並從該位移繼續上傳剩餘的位元組。

  • 如有可能,請避免上傳同時具有 content-encoding: gzip 與壓縮的 content-type,因為這可能會導致意外行為

刪除資料

如果您擔心應用程式軟體或使用者可能會在某些時候錯誤刪除或覆寫物件,Cloud Storage 能夠幫助您保護資料:

物件清單

如果您剛從值區中刪除了大量物件,則物件清單的速度可能會暫時變得非常緩慢。這是因為刪除的記錄不會立即從基礎儲存系統中清除,因此在尋找要傳回的物件時,物件清單需要跳過已刪除的記錄。

刪除的記錄最終會從基礎儲存空間系統中移除,而物件清單的效能會再次恢復正常。通常這會需要幾個小時,但在某些情況下可能會花上幾天的時間。

您應該設計工作負載來意避免列出最近有大量刪除物件的範圍。舉例來說,如果您嘗試以重複列出物件並進行刪除的方式來刪除值區中的物件,您應該使用由物件清單回應所傳回的頁面符記來發出下一個清單要求,而不是針對每個要求均從頭重新啟動清單。當您從頭重新啟動清單時,每個要求都需要跳過剛剛刪除的所有物件,造成物件清單的速度變慢。如果您大量刪除了使用某個前置字串的物件,請儘量避免在刪除後立即列出使用該前置字串的物件。

網站託管

跨源資源共享 (CORS) 主題會說明下列事項:如何允許託管在其他網站上的指令碼存取儲存在 Cloud Storage 值區中的靜態資源。與此相反的情況是,您允許託管在 Cloud Storage 的指令碼存取由 Cloud Storage 以外的網站所代管的靜態資源。在第二種情況中,網站會提供 CORS 標頭,以允許存取在 storage.googleapis.com 上的內容。我們建議您為這類的資料存取提供專屬的特定值區。例如,最好讓網站提供 CORS 標頭 Access-Control-Allow-Origin: https://mybucket.storage.googleapis.com,而不是 Access-Control-Allow-Origin: https://storage.googleapis.com,以防您的網站在無意中將靜態資源過度公開給所有的 storage.googleapis.com

本頁內容對您是否有任何幫助?請提供意見:

傳送您對下列選項的寶貴意見...

這個網頁
Cloud Storage
需要協助嗎?請前往我們的支援網頁