PressPlay從AWS搬家到GCP一年的心得

Raguhn Lee
Jul 12 · 8 min read

PressPlay平台服務在2016年問世,一直放在AWS上,直到2018年中才搬遷至GCP上。至今也一年了,讓我們回顧一下這幾年PressPlay的主機的成長過程吧。

AWS時期

PressPlay草創初期資源有限人力有限,只有一台伺服器運行所有的服務,一台資料庫,主機在東京AWS,CDN是用Cloudflare的CDN,服務也挺單純的,伺服器上只有網站服務,然後用戶上傳圖片也放在這台主機上,裡還有一個跑定期扣款的Cron服務,S3的用途是暫時放上傳的影片,為什麼是暫時呢?因為我們的影片是使用Vimeo服務,所以我們上傳到S3只有一個功用,就是讓Vimeo可以抓影片,過了三天影片就會被刪掉。配置圖大概是長這樣子:

最早期的AWS主機配置

那時候每天大概幾千人造訪而已,機器都應付得來。然後到了2017年3月情況就開始不一樣了。囧星人專案上線帶來一波流量,然後我們在3月下旬作了第一次的改版,流量開始多起來了,高峰期甚至到了一天兩萬多人進站。

2017–01–2017–03 GA數據

我們在2018–01到2018–06搬家之前,平均每天進站人數大約在25,000至30,000人左右,一台Server還蠻緊蹦的,最後決定搬家,搬到Google Cloud Platform(GCP)。這是搬家前最終的伺服器配置。

AWS後期的主機配置

為什麼要搬到GCP

或許有人會問「AWS用得好端端的幹嘛搬家呢?」我們選擇GCP的原因有幾個原因:

  • 價格比AWS便宜
  • 地點在台灣,速度快
  • AWS介面很醜(我承認我是外貌協會)

公司草創時期資金沒有那麼多,選擇機器都是以省錢、高C/P值為目標。PP的機器建在AWS的時候,CDN是Cloudflare,雖然我們買的是Pro方案(USD 20/月)但連線的節點是在洛杉機。也就是說用戶要連線PressPlay的網站,用戶的連線會先台灣出發,到達洛杉機Cloudflare的機房,然後連線到東京AWS機房取資料,然後再經過洛杉機才回到台灣。開個網站就要跑遍大半個地球,再加上PressPlay一開始網站還沒有優化連線數或圖片size,所以以一個從來沒進入過PressPlay的人,從連線到完全跑出網站,要90秒左右😱

GCP的費用大約是AWS的六折左右,而且在AWS都沒有作HA(High Availability),就算有也是人品HA。因此我們常常一爆量主機攤瘓了,光2018上半年就平均1–2月就一起攤瘓事件。GCP的設定簡單,就連我對配置伺服器沒有很熟都可以輕鬆入門,開啟CDN也是一個鍵就完成了,在人力和相關知識都缺乏的情況下,選擇GCP還蠻不錯的。

於是我們在2018年4月的時候,決定搬遷到GCP。

搬遷的困難

就是人!因為公司內部缺乏熟悉伺服器管理的人,於是我們就想找一個人來管理伺服器、調整效能、管理辦公室網路和設備,然後進公司來的第一件事就是協助我們搬伺服器。我們找到一位從業很久的資深工程師,他一進來看到我們公司的網路架構、伺服器架構跟本是初學者等級,來了五天就跑了,說是不想從那麼基礎的東西做起。

那麼怎麼辦呢?只好我硬上了。雖然GCP操作簡單,但是有關Server調校、資料庫調校這些我沒有什麼經驗,而且這一次要大調架構,我的要求:

  • 讓我們可以撐住爆量的時刻,機器不要掛。
  • 並加速網站的運行速度。
  • 伺服器狀態的監控機制。
  • 備援機制,不要伺服器倒一台就服務全死。

因為GCP比AWS便宜多了,所以機器比較能放心的開,為了未來PressPlay發展,我們是以3年內不需要再次優化架構的前提之下去做規劃,原本一台網站主機就可以打天下的配置,擴充成APP、Web各兩台,另外再把負責金流的服務獨立出來,也是做成兩台,然後由Load Balancer來分配流量,就算APP死一台機器還有一台會繼續服務,就算WEB全死,但APP還是可以用。

還好有在6月有一位資深的後端工程師加入,我和他經過一整個月的試驗、調整、搬遷,上線前一天我召集了幾位工程師一起協助搬資料和測試,老闆還以來辦公室拿東西為藉口送宵夜來,揪甘心~

終於在2018–06–29 正式上線了!!這是搬到GCP時的配置圖:

2018–06–29的主機配置

搬到GCP之後…?

2018–06–29上線早上八點,網站就炸了🤣

原因是主機掛載Google Storage時的參數錯誤,讓所有資料夾和檔案清單必須讀完才能正常服務,半夜搬家在測試時也是小貓兩三隻在測試所以沒什麼問題,早上八點的尖峰時間一到,大量的人潮湧入PressPlay,I/O卡住,導致服務停擺。那兩天我的睡眠時間只有三個小時,不過當一切都搞定且正常運行時,疲憊的感覺全部冒出來了,於是我就伴隨著成就感一起入睡。

換到GCP後,PressPlay有變得比較好嗎?有的,當時我們還做個記錄:

1. 台灣地區網頁讀取速度之影響 6/30日(六) 比較6/2(六)

網頁讀取 時間從3.9秒,提昇至2.78 (台灣地區) ,提昇28.58%

2. Ping值之影響從平均100ms提昇至10ms

3. 完成網站瀏覽取樣報告比較 6/29–6/30 對比上週 6/22–6/23

各式的載入、連線時間、回應時間都大大地的減少。

搬完GCP後從此就高枕無憂了嗎?錯了,挑戰開始來了。

2018–08–23攻擊事件

當天晚上我們受到DDOS攻擊,我們抓到大約200多個國外IP向我們進行攻擊,這些IP應該都是跳板。之後我們在兩個小時之內,把主機關掉、換IP,然後建置fail2ban和nginx的防DDOS機制止血,隔天我們進行了檢討,我們需要更明確的自動監測回報機制。

被攻擊的隔天PressPlay粉絲團所發的聲明

於是我們就建置了監控主機的功能,只要CPU使用量超標,或是一段時間主機沒有回應,都會跳出通知

PressPlay內部監控Channel

後續還有幾次攻擊事件,不過因為前一此的事件我們作了防護措施,所以只是跳跳通知,然後隔天去看Log而已,用戶、工程師和老闆都睡了好覺。

2019–03–31阿滴英文愚人節活動爆衝

PressPlay的GA在2019年有個顯著的peak,就是阿滴英文愚人節活動,在我們沒有準備好的情況之下,當天衝進快十萬人,大約是平常日的4倍量。我記得當天我還在家裡一面吃鹹酥雞一面看動物朋友,然後就看到「救救PressPlay」頻道一直叫,然後老闆一直在戳我,才發現這起事件。

還好架構有規劃好,整個活動順利的結束,Server沒有爆炸,可喜可賀。

因為這次的虛驚,所以我們就立刻進行一個我很想要玩的東西:Auto Scaling。10天後,也就是4月9日,Auto Scaling正式上線。之後我們更能高枕無憂地渡過每一個動畫夜。

這個架構運行至今都沒什麼問題,下面這個是目前PressPlay的主機架構。

現今PressPlay主機架構

PressPlay功能現在與未來

PressPlay目前產品功能是著重在數據開發和應用,今年招募兩位數據背景的RD,開始著手進行訂閱者的行為,為創作者帶來新的收益和減少流失。或許大家會注意到我們網站開始有推薦的版位了,首頁的訂閱專案排名也不是像以前一樣單純用金額去排名,而是透過演算法算出綜合性的指標。我相信創作者們想知道算法是怎麼算的,在這邊只能透露創作者越投入在經營專案、訂閱者的互動越深就能得到更好的排名。

目前我們也在密謀一個對創作者更有實質幫助的功能,預計在八月會問世,還有秘密策劃第三條產品線,也即將在九月和大家見面。

未來PressPlay工程部會持續地深化你所見到的一切,和我們在麥塊中的世界。


最後,歡迎按讚追蹤我們的FB粉專:PP工程日常

本文也同步發在PressPlay專案:https://www.pressplay.cc/link/82A2CAD5C4?oid=829D3F275F

    Raguhn Lee

    Written by

    一名在資訊業打滾多年的工程師,學得愈多發覺不懂的愈多。擔任PressPlay工程總監,兼職解夢師,為了測試開了PressPlay專案,沒想到愈寫愈認真寫了一年多。

    Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
    Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
    Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade