數位媒體資源管理及共享

數位媒體是網際網路成長速度最快的領域之一。根據 Informa Telecoms & Media 在 2012 年進行的市調結果,單看全球線上影片的經濟規模,預計 2017 年將達到 370 億美元1。其他流行的媒體類型包括圖片、音樂與數位文件。琳瑯滿目的行動裝置配備了更高解析度的相機、更大的螢幕以及更快速的資料連線,各種實用功能也是推動這波熱潮的原因之一。因此,媒體內容製作和消費需求勢必必大幅增加。另一個推動這波熱潮的原因,則是許多社交網路都開始將媒體分享納入自家的核心系統功能。同時,還有無數的新創公司想在這個市場上佔有一席之地。

本文件會介紹一個應用範例,深度探討如何利用 Google Cloud Platform 架設一套數位媒體資產管理和共享系統。

範例情境 - Photofeed

Photofeed 是一家新成立的虛構公司,他們想設計一款相片共享應用程式,允許使用者上傳相片,相互交流意見。這款應用程式也包含社交功能,可讓使用者對相片張貼留言。Photofeed 的產品開發團隊認為要在這一行打敗競爭對手,產品一定要讓使用者可以快速上傳、查看及編輯相片,而且要考慮到安全問題,贏得消費者的信賴。另外,當使用者人數和相片數量增加時,這個應用程式也可以輕鬆應付。為了達到上述目標,這套系統也必須擁有足夠的管道負責提供各種相片處理功能,例如調整大小、裁剪及產生縮圖。隨著業務量的增加,開發團隊必須在很短的時間內在系統中引進新的功能。

擴充式數位媒體系統遇到的設計難題

要想設計一套全新的擴充式數位媒體系統,又要可以支援大量的使用者並儲存海量的媒體內容,可是一項艱鉅的任務。以下清單列出設計擴充式數位媒體系統時,必須克服的各種技術障礙:

  • 資料匯整
    • 系統必須可以讓使用者快速、安全上傳媒體物件,而且使用者在操作的時候,感覺到十分好用。
    • 匯整媒體物件的中繼資料,萬一媒體物件已被修改或重新匯整裡面的中繼資料,則必須進行同步處理。
    • 資料匯整工作流程會定義所有相關元件之間的通訊,一定要進行控管。
  • 儲存空間
    • 真正做到儲存設備可以儲存任何大小、格式的媒體內容,而且儲存設備必須可靠、世界任何地方都可以使用,而且便宜實惠2
  • 內容處理
    • 處理媒體時需要擴充式計算資源,例如文件格式轉換、圖片處理與媒體轉碼。
    • 媒體處理工作流程必須受到控管。
  • 內容供應
    • 系統必須可以讓使用者快速、安全下載媒體物件,而且使用者在操作的時候,感覺到十分好用。
    • 內容供應工作流程必須受到控管。
  • 媒體應用程式
    • 這套系統可以整合媒體中繼資料和應用程式特定層面的資料,同時用以開發各種擴充式媒體應用程式,例如資產管理和內容共享。
  • 使用者體驗
    • 使用者可以利用這套系統輕鬆操作多種用戶端,例如瀏覽器、行動裝置與桌上型電腦應用程式。

本文件提供的方案會示範 Google Cloud Platform 如何解決前面提到的一切難題。建議的系統架構一般適用於任何媒體類型。開發人員在 Google Cloud Platform 上建立自己的數位媒體系統時,可以參考這套方案的軟體架構。

方案簡介

App Engine、Cloud Storage 和 Compute Engine 是 Google Cloud Platform 的 3 種功能。就像您在圖 1 看到的一樣,所有產品搭配使用之後,便形成了數位媒體資產管理和共享方案的基礎。

建議方案所包含的重要元件
圖 1:建議的數位媒體資產管理和共享方案重要元件

擷取

Cloud Storage 和 App Engine 在媒體內容匯整中扮演著關鍵角色。媒體內容的上傳路徑是直接從用戶端開始,然後透過分佈全球的 Google 網路傳送到 Cloud Storage。利用 Google 串連全球的高速頻寬,再結合 Cloud Storage 之後,Google 網路可以將內容匯整至儲存設備,而且無論從世界哪個角落上傳資料,幾乎感受不到延遲。Cloud Storage 支援兩種通用的上傳方式:一種是使用簽章式網址的 HTTP POST,另一種是 RESTful API

利用 App Engine,開發人員可以設計各種擴充式網頁應用程式,即使數百萬使用者同時操作,一樣應付自如。開發人員可以利用 App Engine 設計前端應用程式匯整內容。這個應用程式會負責驗證,只允許授權的使用者上傳內容,還能管理匯整工作流程,並協調用戶端上傳內容到 Cloud Storage。至於瀏覽器用戶端,應用程式也可以提供網頁使用者介面,方便上傳內容。至於行動裝置或桌上型電腦用戶端,使用者介面就在用戶端應用程式中;開發人員可以利用 Cloud Endpoints 產生 RESTfull API,然後顯示 App Engine 中的功能。用戶端應用程式可以呼叫這個 API,要求進行驗證及使用 Google Cloud Storage。

App Engine 應用程式的另一個重要角色是匯整中繼資料,然後與媒體內容保持同步。中繼資料會與應用程式資料一起儲存至 App Engine Datastore 或 Cloud SQL 資料庫。至於選擇哪一種儲存方法,取決於應用程式的性質。目前有一些方法可以同步匯整的中繼資料和媒體內容,例如 (1) 利用 Blobstore 上傳回呼網址、(2) 利用 Cloud Storage 物件變更通知,或 (3) 利用 Cloud Endpoints 從 App Engine 應用程式中顯示合適的 API。

儲存空間

Cloud Storage 可以儲存各種格式、大小的媒體內容,而且成本很低。媒體資料可供備援使用。利用 Google 網路,世界各地的開發人員可以從 App Engine、Compute Engine 取得 Cloud Storage 中的內容,即使不用 Google Cloud Platform 時,也可以透過網際網路取得。

Cloud Storage 提供多種儲存空間級別,可供您視需求選擇。

處理中

在批次計算方面,Compute Engine 擁有絕佳效率。媒體處理 (例如文件格式轉換、轉碼與圖片操控) 最好選用 Compute Engine。在這種情況下,Cloud Storage 可以同時充當媒體處理管道的輸入來源和輸出目的地。由於 Cloud Storage 可以和 Compute Engine 完美整合 (例如透過服務帳戶進行自動驗證),因此可以從 Compute Engine 輕鬆存取 Cloud Storage。

前面提到的 App Engine 應用程式媒體處理工作流程,也會受到 App Engine 的控管。媒體內容上傳到儲存設備之後,App Engine 應用程式會建立媒體處理任務,然後插入至 TaskQueue。Compute Engine 上執行的媒體處理軟體會利用 RESTful API 從佇列中提取任務,然後執行。App Engine 應用程式也會管理媒體內容的處理狀態以及虛擬機器的工作負荷資訊,方便自動擴大 Compute Engine 執行個體的數量。

服務

Cloud Storage 會利用 Google 網路從網際網路提供媒體內容,而且速度很快,也不會不時遇到服務停擺的情況。Google 網路會針對公用內容而自動提供「邊緣快取」(edge caching) 功能,以大幅降低服務成本。

需要匯整資料時,App Engine 應用程式會處理使用者驗證和授權,以及協調各個用戶端存取 Cloud Storage。至於瀏覽器用戶端,App Engine 應用程式會提供網頁使用者介面,方便下載媒體內容。針對行動裝置和桌上型電腦用戶端,用戶端應用程式會實作使用者介面,然後透過利用 Google Cloud Endpoints 顯示的 API 與 App Engine 應用程式進行通訊。

媒體應用程式

由於中繼資料和應用程式資料取得容易,開發人員可以建立不同的媒體應用程式。媒體可以應用在各種領域,常見的例子包括資產管理、內容分享與社交遊戲。App Engine 提供一種擴充式平台,開發人員可以在這個平台上設計各種媒體應用程式。App Engine 應用程式的建置簡單、維護容易,而且可以因應流量和資料儲存量輕鬆擴充。這樣一來,開發人員即可全力投入自己的核心工作,儘快推出新的功能。

使用者體驗

在這套方案中,使用者對於這套系統是否感到滿意或失望,App Engine 是最大的因素。如同前文所述,對於瀏覽器用戶端而言,App Engine 應用程式會提供一個網頁使用者介面,方便匯整資料、供應內容以及進行各種媒體應用。至於行動裝置或桌上型電腦用戶端,App Engine 會利用 Cloud Endpoints 產生一些 API,利用這些 API 就能顯示 App Engine 的功能。用戶端的原生使用者介面就是利用這些 API 實現的。

作品詳細資訊

下一節逐步講解建議的數位媒體方案作品。一開始介紹系統的關鍵元件,最後具體描述系統的三個重要工作流程:媒體匯整工作流程、媒體處理工作流程,以及媒體供應工作流程。

系統元件

  • App Engine 上執行的前端和媒體應用程式
    • 驗證及授權使用者並協調存取 Cloud Storage。
    • 為瀏覽用戶端實作使用者介面,並/或利用 Cloud Endpoints 在行動裝置和桌上型電腦用戶端顯示 API。
    • 扮演系統控管員的角色並負責管理媒體匯整、資料供應與資料處理等三個工作流程。
    • 擴充式媒體應用程式是靠 App Engine 實現的,具備內建的工作負載平衡與自動擴充功能。
  • Cloud Datastore
    • 儲存媒體內容中繼資料與應用程式資料模型。
  • Cloud SQL
    • 儲存媒體內容中繼資料和應用程式模型,做為 Cloud Datastore 的備案。
  • App Engine Task Queue
    • 整合 App Engine 應用程式以及 Compute Engine 上執行的媒體處理軟體。
  • Image Services
    • 為 App Engine 應用程式提供動態圖片處理服務,例如產生縮圖、調整大小及裁剪。
  • Cloud Storage
    • 提供擴充式以及近乎零故障的儲存設備,用於儲存媒體內容。利用 RESTful API 和/或簽章的網址,即可存取儲存設備。
    • 利用 Google 網路即可體驗以下優點:(1) 快速、安全將內容匯整至儲存設備,然後從儲存設備提供內容,(2) 提供「邊緣快取」功能,用於儲存公開內容降低供應費用。
  • 媒體處理伺服器
    • 在 Compute Engine 處理媒體。

媒體匯整工作流程和媒體處理工作流程

媒體匯整工作流程和媒體處理工作流程通常是一併執行。圖 2 的元件通訊圖就顯示了這兩個工作流程。

媒體匯整和媒體處理工作流程
圖 2:媒體匯整和媒體處理工作流程
  1. 用戶端會使用 App Engine 應用程式開始上傳內容。根據用戶端的類型,這個要求可以是:(1) 瀏覽器發出的 HTTP 簡單要求或 (2) 行動裝置或桌上型電腦應用程式呼叫 App Engine 應用程式實現的端點,例如批次上傳程式。App Engine 應用程式負責驗證用戶端/使用者及協調存取 Google Cloud Storage。
  2. 如果用戶端是一個瀏覽器,應用程式可以產生簽章上傳網址,然後傳送至 HTTP POST 表單中內嵌的 Google Cloud Storage。如果用戶端是行動裝置或桌上型電腦應用程式,網路應用程式會傳回 Google Cloud Storage 存取資訊,回應端點呼叫。
  3. 無論是哪一種用戶端,媒體檔案都會透過網路表單或 Cloud Storage RESTful API,直接上傳至 Google Cloud Storage。
  4. Cloud Storage 會回應用戶端。視步驟 3 使用的上傳機制而定,可能是一個 HTTP 回應 (表單式上傳) 或 RESTful API 回應
  5. 如果上傳成功,媒體中繼資料必須推送至 App Engine 應用程式。目前有幾個方法可加速整個過程:
    1. 如果瀏覽器用戶端利用上傳表單,則會在上傳網址中指定回呼網址。根據回應,瀏覽器可以被重新導向至這個網址,而且在回呼網址中會嵌入有限的中繼資料資訊。
    2. 上傳成功時,Cloud Storage 會利用 Cloud Storage 的「物件變更通知」功能,通知 App Engine 應用程式[1]. 這個通知會包含目前上傳的媒體物件中繼資料。
    3. 根據 Cloud Storage 傳回的內容上傳回應,用戶端也可以直接呼叫 Cloud Endpoints (一種 App Engine 應用程式),以上傳任何中繼資料。
  6. App Engine 應用程式會將中繼資料儲存至永久存放區中。根據安裝的應用程式,目前有兩種資料存放區選項:(1) App Engine NoSQL Datastore 或 (2) Cloud SQL。
  7. 如果必須處理媒體,App Engine 應用程式會在工作佇列中建立一項任務,然後啟動媒體處理工作流程。根據要求的工作負荷,App Engine 應用程式也可以啟動或關閉虛擬機器。
  8. Compute Engine 上執行的媒體處理軟體會從佇列中取任務,然後執行必要的程序。
  9. 媒體處理軟體會從 Google Cloud Storage 讀取媒體內容,經過處理後再儲存回 Google Cloud Storage。

媒體供應和下載工作流程

圖 3 描述媒體供應和下載工作流程以及詳細的說明。

媒體供應和下載工作流程
圖 3:媒體供應和下載工作流程
  1. 用戶端連繫 App Engine 應用程式後開始下載媒體,此時 App Engine 會驗證和授權用戶端,也會允許瀏覽及搜尋特定的媒體內容。開發人員可以為瀏覽器用戶端提供一個網頁使用者介面;透過 APP Engine 應用程式利用 Cloud Endpoints 產生的 RESTful API,同樣可以提供一個網頁使用者介面。
  2. 根據 Datastore 或 Cloud SQL 中的媒體中繼資料和應用程式資料,App Engine 應用程式可以檢查應用程式中定義的內容共享規則,以及查詢 Cloud Storage 所儲存的內容可供誰存取。
  3. 為了從 Cloud Storage 安全下載內容,App Engine 應用程式可以產生一個簽章的網址,或者提供 OAuth 使用許可證,然後連同 Cloud Storage 值區和物件名稱一起傳送至用戶端。至於瀏覽器,相關資訊是內嵌到網頁使用者介面中。至於行動裝置和桌上型電腦用戶端,相關資訊會回傳,以回應步驟 1 中提到的 RESTful API。
  4. 用戶端會傳送 HTTP 或呼叫 RESTful API,向 Cloud Storage 發出下載內容要求。Cloud Storage 可以利用 Google 網路的快取功能儲存公開的內容。如果快取中已經有內容,則會從快取傳回內容。否則會發生以下狀況:
    1. 從 Cloud Storage 取回內容,然後填到快取中。
    2. 從 Cloud Storage 取回的內容,App Engine 允許交由 App Engine Image Services 代為處理,這樣就可以即時調整圖片大小及裁切圖片。
  5. 媒體內容會提供給用戶端。

作品注意事項

  • 媒體內容的中繼資料可以連同應用程式資料一起儲存至 App Engine Datastore 或 Cloud SQL。至於要選擇哪一種,取決於資料的大小、整體資料模型的特性以及開發團隊的專長。舉例來說,如果資料關聯度相當高,可以選擇 Cloud SQL。或者,如果要將非標準化資料擴大成巨型的資料集,可以選擇 App Engine Datastore。2012 年 Google IO 大會的「SQL 與 NoSQL:後端的爭戰」講座討論了兩種方法之間的取捨。
  • 提供的方案會採用 Compute Engine 處理媒體。Compute Engine 允許在支援的作業系統上執行自訂的軟體和套件。這個平台適用一般的媒體處理用途。至於簡單的圖片和相片操控,App Engine 所提供的圖片服務可即時處理圖片。

範例應用程式

相片共享應用程式範例3可以示範如何實現一款媒體資產管理和共享方案,例如本案例稍早提到的方案。相片共享應用程式允許使用者上傳相片,然後開放給其他使用者欣賞。使用者也可以針對上傳的相片發表評論。以下詳列本應用案例的重要元件:

  • 使用者必須使用有效的 Google 帳戶登入,才能使用應用程式。
  • 使用者從本機硬碟上傳相片和說明。
  • 所有上傳到相片共享應用程式中的相片,會按照時間先後顯示。
  • 使用者針對任何相片發表評論,而且所有人都看得到。
  • 顯示相片時,可以調整相片大小及裁切,以便正常顯示在使用者介面中。

原始程式碼保存在 GitHub

結論

Google Cloud Platform 可以讓開發人員快速建立一套數位媒體資產管理和共享方案,就算使用者人數高達數百萬人、資料量達數 PB,同樣應付自如。本文件提供的方案,結合了 App Engine、Compute Engine 以及 Cloud Storage,可以解決數位媒體系統遇到的技術挑戰。


附註

[1]「物件變更通知」功能目前仍是「信任的測試人員」計劃中的功能。

參考資料

1 OTT Video Revenue Forecasts,2011-2017,作者 Informa Telecoms & Media,2012 年 11 月。

2 Garnter: Consumers Will Drive Huge Growth for Cloud Storage,作者 Colleen Miller,2012 年 7 月。

3 Photo Sharing Sample Application,作者 Michael Tang,2012 年 10 月。

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

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

這個網頁
解決方案