GCPUG Taiwan Meetup 21 會後心得

今天很幸運地,可以參加 LIVEhouse.in 的分享。

為什麼說幸運?因為昨天才知道這個訊息,當然早就額滿了。在此非常感謝主辦單位特別給我三張票。

活動傳送門

Live Streaming

Browny Lin / LIVEhouse.in

傳送門

這次分享的主要主題是 Streaming ,老實說我對這個領域是完全陌生。但從這次的分享,可以了解一些大方向的架構。

首先講者直接說明一般直播的行為:

  1. 先在 CMS 上建立直播頻道
  2. 取得 token / key
  3. 直播軟體上輸入 token / key ,即可把 streaming 打上去
  4. CMS 可以 preview ,覺得 ok 即可 public

VOD (Video on demand) 的流程大同小異,變成先上傳檔案而已

講者提到使用 Strass.io 的好處:對開發人員,直播的功能都會由 Strass.io 解決,開發人員可以更專心在其他功能上

Strass.io 核心

GitHub 原始碼

Live 通常還是接受 RTMP 居多, VOD 則可以接受很多格式,但輸出都會是 HLS / MP4

流程在簡報的 13 / 14 頁會有圖片說明。從流程圖可以了解, Transcoder 的任務被設計的很單純,就是做轉檔。而任務調配或是錯誤處理等等,都會由 Middleware 處理。在簡報後面有提到它的主要任務:

  • 安排適合的機器做 transcode
  • 斷線重連
  • 上傳影片品質不同,預期會用不同的 transcoder (講者的設計是普通與高效兩種)
  • 備援機制
  • Service 之間的溝通
  • 新舊機器交替
  • 資源回收
  • Monitor & Alert

Stack

這邊講者提到他們使用的 GCP 服務

  • Compute Engine (當然是 Transcoder)
  • Datastore / CloudSQL
  • Storage (放靜態影片檔)
  • PubSub (任務排隊)
  • BigQuery (資料分析,推測應該是做 UX 之類的)

最近在學 AWS 也順便對應一下 AWS 的服務

  • EC2
  • DynamoDB / RDS
  • S3
  • SQS
  • Kinesis Analytics (這個我不大確定,看介紹跟 BigQuery 很像)

接著當然也有 IDC service

  • Metrics / Alert service
  • Billing service
  • Consensus service (有點類似 transcoder 的 lock 功能)
  • Data Analysis service

Summary

最後講者提到了這個架構的特色與未來期望

  • 錯誤處理複雜
  • 頻寬和 transcoder 的平衡
  • 再做更好的模組化
  • 直播很多功能都已經是必備,現在直播的服務重點會在:直播是否能跟外面世界互動

Lighting talk

中國很恐怖!GCP上自建長城保護自己的服務

簡報傳送門

Louie CK / MiTAC Cloud Lead

主題在講防底層的攻擊,這邊只記錄了一些防 DDOS 服務:

CloudFlare 目前範圍還不是很大,所以沒被講者列入

自幹DNS Proxy over GCP

簡報傳送門

Edward Chuang / GCPUG.TW co-organizer

簡單來說,雲端上的機器太多太雜,有時要連線佈署搞不好會連錯台就死定了,所以講者做了一個本機的 DNS port to GCE API

這樣就會有些優點如下

  • 不用更新 zone File
  • 可以寫在程式
  • 也可以找內部 IP

原始碼放在 GitHub

玩大資料不可不知 - Google PubSub簡介

簡報傳送門

Simon Su / GCPUG.TW co-organizer

這是大資料可以使用的服務,它是個 Queue ,聽介紹跟 Amazon SQS 很像

印象中 SQS 如果資料不刪,過一段時間會被刪除。待確認

# 自幹大數據服務
Client -> Infra -> Kafka -> Spark -> Cassandra

# 使用 GCP 服務
Client -> Compute engine -> PubSub -> DataFlow -> BigQuery

使用 PubSub 的方法有 push mode / pull mode ,講者有流程圖,但目前沒得到分享,所以只能 pass 。但重點是它的訊息不會被刪,直到你對 message ack 才會被刪

講者有提到 PubSub 的特色:它不是 FIFO ,跟 Amazon SQS 一樣,但他提到很重要的原因:

大數據的處理,應該是要被設計成非序列處理(或非同步處理),才會有辦法快。或許 PubSub / SQS 這樣設計,也是讓開發人員會不自覺做出符合大數據的可擴展架構。原本還有點嫌棄,但聽到講者這麼說,才知道我是有必要去使用,才能讓程式有一定的可擴展程度。

Finally

個人是比較偏愛 GCP ,因為 UI 好看XD ,但符合公司需求還是要 AWS ,因此工作需求還是會以學習與使用 AWS 為主。

最後,除了我外,兩位朋友也都大有收獲,再次感謝主辦單位贊助!

References

Written on November 2, 2016