媒體工作負載的最佳做法

本頁面說明將 Cloud Storage 用於媒體工作負載的最佳做法。這類工作負載通常包含各種 Google Cloud 產品，例如 Media CDN、Live Stream API、Transcoder API 和 Video Stitcher API。

總覽

Google Cloud 提供解決方案，可最佳化下列類型的媒體工作負載：

  • 媒體製作：包括電影後製等工作負載，例如影片編輯，這類工作需要大量運算資源，且通常會使用 GPU 進行高效能運算。通常，儲存在 Cloud Storage 中的媒體相關資料會由在 Compute Engine 或 Google Kubernetes Engine 中執行的應用程式處理，而這項程序的輸出內容會寫回 Cloud Storage。這些工作負載需要將 Cloud Storage 的匯總讀寫處理量，調度至 GPU 閒置時間較短的運算叢集。此外，他們也需要低讀寫延遲時間，因為這對減少尾端延遲時間至關重要。
  • 媒體資產管理：包括整理媒體素材資源，以便有效率地儲存、擷取及使用。
  • 內容放送和發布：包括向使用者串流播放媒體，例如隨選影片 (VoD) 和直播服務。在隨選影片期間，如果使用者要求的內容未在內容傳遞網路 (CDN) 快取，系統會從 Cloud Storage bucket 擷取內容。如果是直播要求，系統會將內容寫入 Storage bucket，並同時從 CDN 讀取。

媒體工作負載的最佳做法

如要瞭解適用於媒體工作負載的最佳做法，請參閱下列章節。

資料移轉

如要從地端部署來源 (例如攝影機或地端部署儲存空間) 上傳超過 1 TiB 的原始媒體檔案至 Cloud Storage，請使用 Storage 移轉服務。Storage 移轉服務可讓您在物件和檔案儲存系統之間順暢移動資料。如果是較小的移轉作業，請根據移轉情境選擇服務，將資料移轉至 Cloud Storage 或從 Cloud Storage 移轉資料，或是在檔案系統之間移轉。

bucket 位置

如果工作負載需要運算資源 (例如媒體製作)，請在與運算資源相同的區域或雙區域中建立 bucket。這種方法可降低處理工作負載的讀取和寫入延遲時間、成本和頻寬，有助於提升效能。如需選擇值區位置的更多指引，請參閱「值區位置考量事項」。

儲存空間級別

視媒體工作負載類型而定，您應選取的儲存空間級別會有所不同。以下是不同媒體工作負載建議使用的儲存空間級別類型：

  • 如要管理媒體素材資源 (例如封存影片)，bucket 的預設儲存空間級別應為 Archive Storage。您可以為可用性或存取需求不同的物件指定不同的儲存空間級別。
  • 如果是媒體製作和內容提供工作負載，由於資料會經常從 Cloud Storage bucket 讀取，因此應將資料儲存在 Standard Storage。

如要進一步瞭解如何選擇 bucket 的儲存空間級別，請參閱「儲存空間級別」。

資料生命週期管理

如要管理媒體素材資源，請定義生命週期設定，管理 bucket 的物件生命週期。您可以使用物件生命週期管理功能管理資料生命週期，包括設定物件的存留時間 (TTL)、保留非現行版本的物件，以及降低物件的儲存空間級別，藉此管理費用。

如果資料存取模式可預測，您可以為 bucket 設定生命週期設定。如果資料的存取模式不明或無法預測，您可以為 bucket 設定自動調整級別功能。啟用自動調整級別功能後，Cloud Storage 會自動將不常存取的資料移至「較冷」的儲存空間級別。

內容提供和發布工作負載的最佳做法

無論是 VoD 或直播工作負載，目標都是避免在終端使用者的影片播放器上播放影片時，發生任何播放錯誤、播放開始延遲或緩衝情形。這些工作負載也需要擴充讀取作業，以因應大量並行觀看者。在所有情況下，客戶流量讀取作業都應透過 CDN 進行。

如要瞭解適用於內容提供和發布工作負載的最佳做法，請參閱下列各節。

有效運用 CDN

在 Cloud Storage bucket 前方使用內容傳遞網路 (CDN)，可讓 CDN 快取內容，進而降低延遲並提高頻寬效率，提升使用者體驗。CDN 可降低頻寬成本、最佳化資源使用率及提升效能，進而降低總持有成本 (TCO)。使用 Media CDN 可降低向使用者提供內容的總持有成本，因為 Media CDN 的快取填補費用為零。您可以使用 Media CDN 做為其他第三方 CDN 的來源。如果使用其他 CDN，從這個 Media CDN 快取 (而非來源) 提供內容時，仍可降低部分總持有成本。

如果您使用第三方 CDN，CDN Interconnect 可讓選定的供應商在不同地點與 Google 的邊緣網路建立直接對接連結。您的網路流量透過其中一個連結從 Google Cloud輸出，可享有與支援的 CDN 供應商直接連線的好處，並會自動以較低的價格計費。如需核准供應商清單，請參閱「Google 核准的服務供應商」。

以下列出設定 CDN 時可調整的選項：

選取來源防護機制位置

來源盾牌位置是 CDN 和 Cloud Storage 之間的快取。如果 CDN 允許選取來源防護位置，請按照 CDN 指南，判斷是否建議選擇靠近 Cloud Storage bucket 區域或使用者流量集中位置的來源防護。來源防護機制可保護原始伺服器，避免超載。具備來源防護功能的 CDN 會在來源和 CDN 之間新增額外快取，提高來源卸載率。舉例來說，Media CDN 提供多層式邊緣基礎架構，目的是盡可能主動減少快取填充作業。

啟用要求合併

請確認 CDN 已啟用要求收合功能。將多個要求收合成單一要求，可降低 Cloud Storage B 類作業費用。CDN 部署了分散式快取，但提供一種方法，可將多個使用者要求合併為單一要求，傳送至來源。舉例來說，媒體 CDN 會主動將相同快取鍵的多個使用者導向快取填補要求，依照各邊緣節點收合成單一來源要求，進而減少對 bucket 提出的要求數量。

設定 CDN 的重試行為

請務必在 CDN 上，為任何傳回 HTTP 5xx 回應代碼 (502、503、504) 的伺服器問題設定重試機制。CDN 支援來源重試，可重試傳送至來源但失敗的要求。大多數 CDN 都可讓您指定目前來源的重試次數。如要瞭解如何在 Media CDN 中重試原始要求，請參閱「重試原始要求」。

內容發布位置選項

如果工作負載從 Cloud Storage 讀取的資料未快取在 CDN 上，例如提供內容服務和發布 VoD 類型內容，請在選取 bucket 位置時考量下列因素：

  • 如要盡量降低成本，在單一區域建立的 bucket 儲存費用最低。
  • 如要盡量提高供應量，請考慮下列事項：
    • 對於大多數媒體工作負載，建議使用雙區域 bucket，因為這類 bucket 會在兩個區域複製物件，提高可用性。
    • 如果用途需要提供內容和數據分析，且具備異地備援功能，請使用多區域中的 bucket，以達到最高可用性。
  • 如要縮短延遲時間並降低網路費用，請考量下列事項：
    • 如果是隨選影片，請選擇最靠近多數使用者所在位置的區域，或流量最集中的區域。
    • 直播期間，儲存空間會收到轉碼器的寫入要求，以及 CDN 的讀取要求，CDN 會快取內容並發布給使用者。如要提升串流效能，請選擇與用於轉碼的運算資源位於同一位置的區域儲存空間。

最佳化直播的影片片段長度

如果是直播，建議的片段大小下限為兩秒，因為短影片片段對長尾寫入延遲時間較為敏感。長尾寫入延遲時間是指不常存取或要求量低的內容，寫入作業緩慢或延遲。

bucket 位置與使用者播放位置之間的實際距離會影響傳輸時間。如果使用者距離 bucket 位置較遠，建議您設定較長的影片片段大小。

為提供觀眾最佳體驗，建議使用重試策略和要求避險，以便在轉碼器上寫入資料，減少寫入 Cloud Storage 時超過兩秒的長尾延遲，並嘗試約十秒的較長緩衝時間。

逐步提高 QPS

Cloud Storage bucket 的初始 IO 容量為每秒 1,000 次物件寫入和 5,000 次物件讀取。如果是直播工作負載，建議您逐步調度要求，一開始每秒寫入 1,000 次、每秒讀取 5,000 次，然後每 20 分鐘將要求比率提高一倍。這個方法可讓 Cloud Storage 在多部伺服器之間重新分配負載，並減少播放問題，進而提升 bucket 的可用性和降低延遲。

如果直播活動的 QPS 較高，請預熱 bucket 或啟用階層命名空間，對 bucket 進行資源調度。對 bucket 實作資源調度前，請先執行下列工作：

估算來源的 QPS

假設直播有一百萬名觀眾，CDN 每秒會收到一百萬個查詢。假設 CDN 的快取命中率為 99.0%，則傳送至 Cloud Storage 的流量將為 1%。QPS 將是總觀眾人數 (100 萬) 的 1%，也就是 10,000 QPS。這個值高於初始 IO 容量。

監控 QPS 並排解任何資源調度錯誤

請監控 QPS，並排解任何資源調度錯誤。詳情請參閱「Cloud Storage 監控總覽 」。如要監控讀取和寫入要求，請在Google Cloud 控制台中，分別查看「Total read/list/GET request count」(讀取/列出/GET 要求總數) 圖表和「Total write request count」(寫入要求總數) 圖表。如果 bucket 的 QPS 擴充速度超過上一節所述的指定增加速度，可能會發生「429 Too many requests」錯誤。瞭解如何解決「429 Too many requests」錯誤。

估算來源的 QPS 後，請參閱下列章節，瞭解如何擴充 bucket，以提高 QPS。

預先暖機 bucket，在 bucket 上實作 QPS 擴縮

您可以在直播活動前預熱 bucket，加快資源調度程序。在直播活動開始前，請先產生合成流量，並傳送至 bucket。流量應符合 CDN 原始伺服器預期會收到的最大 QPS，再加上 50% 的緩衝，以考量 CDN 的預期快取命中率。舉例來說，如果您預估來源的 QPS 為 10,000，則模擬流量應指定每秒 15,000 次要求，讓來源做好準備。

如要模擬流量，可以使用先前活動的現行動態饋給檔案 (例如片段和資訊清單) 或測試檔案。請確保在整個暖機過程中，檔案不重複。

產生模擬流量時，請採取漸進式擴充做法，從每秒 5,000 個要求開始，逐步增加至目標值。請在活動開始前預留足夠時間，以達到預估負載。舉例來說，如果每秒要求數從 5,000 開始，每 20 分鐘增加一倍，達到每秒 15,000 個要求，大約需要 30 分鐘。

原始伺服器會維持容量，直到流量穩定為止。原始伺服器的容量會在 24 小時內逐漸降低至基準水準。如果原始伺服器在直播活動之間有數小時的空檔，建議您在每場活動前模擬流量。

使用啟用階層命名空間的 bucket，以獲得高初始 QPS

相較於未啟用 HNS 的 bucket，啟用階層命名空間的 Cloud Storage bucket 可提供高達八倍的初始 QPS。初始 QPS 越高，就越容易擴充資料密集型工作負載，並提高處理量。如要瞭解啟用階層式命名空間的 bucket 限制，請參閱「限制」一節。

避免為影片片段使用依序名稱，以便調度 QPS

透過 QPS 資源調度，要求會重新分配到多個伺服器。不過，如果所有物件都使用非隨機或依序的前置字串，可能會遇到效能瓶頸。使用完全隨機的名稱，而非連續名稱，可達到最佳負載分配效果。不過，如要使用序號或時間戳記做為物件名稱的一部分，請在序號或時間戳記前加入雜湊值，為物件名稱加入隨機性。舉例來說，如果您要使用的原始物件名稱是 my-bucket/2016-05-10-12-00-00/file1，可以計算原始物件名稱的 MD5 雜湊，並將雜湊的前六個字元新增為物件名稱的前置字串。新物件會變成 my-bucket/2fa764-2016-05-10-12-00-00/file1.。詳情請參閱「使用命名慣例，在金鑰範圍內平均分配負載」。如果無法避免影片片段的連續命名，請使用啟用階層命名空間的 bucket，以取得更高的 QPS。

為每個直播使用不同的值區

如要同時進行多場直播，請為每場直播使用不同的 bucket，這樣就能有效調度讀取和寫入負載，不會達到 bucket 的 IO 限制。為每個直播使用不同的 bucket，可減少因延遲擴展而造成的大型離群延遲。

後續步驟