PressPlay從AWS搬家到GCP一年的心得
PressPlay平台服務在2016年問世，一直放在AWS上，直到2018年中才搬遷至GCP上。至今也一年了，讓我們回顧一下這幾年PressPlay的主機的成長過程吧。
AWS時期
PressPlay草創初期資源有限人力有限，只有一台伺服器運行所有的服務，一台資料庫，主機在東京AWS，CDN是用Cloudflare的CDN，服務也挺單純的，伺服器上只有網站服務，然後用戶上傳圖片也放在這台主機上，裡還有一個跑定期扣款的Cron服務，S3的用途是暫時放上傳的影片，為什麼是暫時呢？因為我們的影片是使用Vimeo服務，所以我們上傳到S3只有一個功用，就是讓Vimeo可以抓影片，過了三天影片就會被刪掉。配置圖大概是長這樣子：
那時候每天大概幾千人造訪而已，機器都應付得來。然後到了2017年3月情況就開始不一樣了。囧星人專案上線帶來一波流量，然後我們在3月下旬作了第一次的改版，流量開始多起來了，高峰期甚至到了一天兩萬多人進站。
我們在2018–01到2018–06搬家之前，平均每天進站人數大約在25,000至30,000人左右，一台Server還蠻緊蹦的，最後決定搬家，搬到Google Cloud Platform(GCP)。這是搬家前最終的伺服器配置。
為什麼要搬到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時的配置圖：
搬到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機制止血，隔天我們進行了檢討，我們需要更明確的自動監測回報機制。
於是我們就建置了監控主機的功能，只要CPU使用量超標，或是一段時間主機沒有回應，都會跳出通知
後續還有幾次攻擊事件，不過因為前一此的事件我們作了防護措施，所以只是跳跳通知，然後隔天去看Log而已，用戶、工程師和老闆都睡了好覺。
2019–03–31阿滴英文愚人節活動爆衝
PressPlay的GA在2019年有個顯著的peak，就是阿滴英文愚人節活動，在我們沒有準備好的情況之下，當天衝進快十萬人，大約是平常日的4倍量。我記得當天我還在家裡一面吃鹹酥雞一面看動物朋友，然後就看到「救救PressPlay」頻道一直叫，然後老闆一直在戳我，才發現這起事件。
還好架構有規劃好，整個活動順利的結束，Server沒有爆炸，可喜可賀。
因為這次的虛驚，所以我們就立刻進行一個我很想要玩的東西：Auto Scaling。10天後，也就是4月9日，Auto Scaling正式上線。之後我們更能高枕無憂地渡過每一個動畫夜。
這個架構運行至今都沒什麼問題，下面這個是目前PressPlay的主機架構。
PressPlay功能現在與未來
PressPlay目前產品功能是著重在數據開發和應用，今年招募兩位數據背景的RD，開始著手進行訂閱者的行為，為創作者帶來新的收益和減少流失。或許大家會注意到我們網站開始有推薦的版位了，首頁的訂閱專案排名也不是像以前一樣單純用金額去排名，而是透過演算法算出綜合性的指標。我相信創作者們想知道算法是怎麼算的，在這邊只能透露創作者越投入在經營專案、訂閱者的互動越深就能得到更好的排名。
目前我們也在密謀一個對創作者更有實質幫助的功能，預計在八月會問世，還有秘密策劃第三條產品線，也即將在九月和大家見面。
未來PressPlay工程部會持續地深化你所見到的一切，和我們在麥塊中的世界。
最後，歡迎按讚追蹤我們的FB粉專：PP工程日常
本文也同步發在PressPlay專案：https://www.pressplay.cc/link/82A2CAD5C4?oid=829D3F275F
