目前 3 個主要雲端「存儲與內容遞送」服務在心中的順位為

• GCS
• S3/CloudFront
• Azure Storage/CDN

因為公司有一個產品主要是做 video on demand，客戶大多數在台灣。順序是到客戶端的網路品質來排的，其中 Azure 其實是不知道品質，就先列在最後面。我們一開始只使用 CloudFront 來作為客戶端的主要載點，那個時期犯了一個「先入為主」的錯誤，將 AWS 與品質劃上等號，沒有考慮到台灣網路的特殊環境與 log data。

產品由正式運行後，我在計劃著「成本優化」的事情，試著導入了便宜的 VPS 像是 linode 或 digitalocean 這種等級的供應商，本質上這是一種 performance tuning 的活動，那就規矩的蒐集 log 並將它整理起來存入資料庫讓我們方便能後續分析。

一開始只有針對 VPS 的 access log 資料存入 DB 流程，後來順手也將 CloudFront 的 log 也放入處理，由於被其他任務打斷就只做到將 log 存起來一直放著，就再也沒有人去理過 log 了，除了用來計算某區域的流量之外，它沒有發揮到作為 profiling data 的角色。

在這改變的初期，常被抱怨有些時使用「連線非常不順暢」，又剛好遇上什麼種花海纜又斷了，就先當成是一種「原因（藉口）」。不過，連續幾個星期都出現一個比例的使用者連線品質低落，這實在太不合理了！趁著沒有其他 issue 要解的空檔，先弄個圖出來，至少能將使用者分為三組：極好、佳、劣，能一目了然的圖表，令人感到驚訝的是在免費活動大量使用者湧入的時間，有超過三分之一的被分入「劣」的那一組。

實在無法確定是免費吸引了更多網路品質不佳的使用者，或是我們使用了品質不佳的 VPS？不管問題是什麼，都得解決它。在 Server 端做了個開關，可以決定使用者的載點是以 CloudFront 為主或者 VPS 為主，在下一個活動大量人潮擠進服務的期間，試著切換它 15 分鐘一輪，二種載量輪流服務。單純看出圖的結果，走勢不會因為切換載點而有所變更。所以，能有個簡單的概念：CloudFront 沒有想像中的好，VPS 沒有我們想像中的差。

既然二者在台灣的網路環境中比較起來沒有明顯的差異，就得找第三個服務加入比較，一開始鎖定的是 Azure，可是研究後有二個主要原因無法使用它：

• private content 還沒有正式釋出 （signed url 的功能過去有放出來一小段時間，後來又被關起來）
• access log 沒有釋出的時間表（沒有 log 就沒有 profiling data，直接放棄）

那麼，只剩下 GCS 足以成為第 3 人選，為何一開始沒有選擇它呢？這是因為一開始我並不知道 GCS 有 CDN 的效果，直到我在文件上看到 Google Cloud Storage behaves essentially like a Content Delivery Network (CDN) with no work on your part because publicly readable objects are, by default, cached in the Google Cloud Storage network. 才比較有信心能將它當 CDN 使用。

加入了 GCS 後的 log 影響了出圖的比例，連線品質最差的部分大幅減少，這也是為何目前它會排最高的原因。

在 create bucket 的介面多了 nearline 可以選了 :)