Nginx

2014Q3 工作心得 (2)

Amazon 的雲端服務越來越方便,身為工程師常常會想要所有服務都自建才會有成就感,但卻忽略最重要的可用性 (Availability) 與延展性 (Scalability) 的問題。

針對可用性的問題,我們曾經嘗試使用 AWS EC2 上運行資料庫伺服器 (MongoDB) 取代 AWS RDS 資料庫雲端服務,AWS EC2 當預設 EBS 大小為 8 GB ,所以當資料內容佔儲存空間的 90% 時,就必需要進行擴充,最基本的問題則是如何在維持可用性的情況下進行資料庫大小的調整,此時 AWS RDS 資料庫雲端服務只需透過簡單的設定就能完成上述需求,反之自建則需要很複雜的流程才能在維持可用性的情況下進行資料庫大小的調整。

針對延展性的問題,我們曾經嘗試使用 AWS EC2 上運行負載平衡器伺服器 (Ngnix) 取代 AWS ELB 負載平衡雲端服務,最基本的問題則是如何當在每台 AWS EC2 的負載在特定條件時會自動進行伺服器的延展,此時 AWS ELB 負載平衡雲端服務,只需搭配 AWS Auto Scaling 自動延展雲端服務只需透過簡單的設定就能完成上述需求,反之自建需要很複雜的流程才能在特定條件時會自動進行伺服器的延展。

(註: Node.js 伺服器程式可以搭配 PM2 達到開機自動啟動,接著打包成 AMI 檔案就能夠套用至自動延展的流程之中。)

最後透過 AWS CloudWatch 資源監控服務,就能即時監控所有 AWS 雲端服務的運作情況,同時搭配 AWS SNS 推播通知雲端服務就能在緊緊事件發生的第一時間寄信給管理者進行危機處理。

2014Q1 工作心得 (2)

我們主要是透過 REST API 的方式,因此在上線之後可能會面臨資訊安全的問題,根據 REST Security Cheat Sheet 的分類主要可以分成五大類分別為驗證身份、授權使用、輸入驗證、輸出編碼和加密處理,因為我們主要是內容為主的 App,因此當我們會請編輯花費許多的時間確保內容品質,提供最高品質的資訊給使用者。

當編輯整理之後的資料非常有價值時,就會發生獨立開發者直接使用我們 API 進行同類型影音 App 的開發成為競爭者,直接對於我們造成直接的影響,我們為了解決此問題主要透過 nginx 的存取記錄,透過指令 cat [nginx log file] | cut -d’ ‘ -f1 | sort | uniq -c | sort -n 追蹤異常大量存取 API 的 IP 位址,嘗試透過 IP 和 User-agent 進行阻擋。

但是發現問題一樣存在,因此我們最後只好在犧牲不打算更新版本的 App 者進行 AES 256 bits 的加密處理,主要是將 Node.js 產生有價值的資訊透過 AES 256 bits 的加密之後再以 API 的方式回傳給 iOS 和 Android 的 App 進行有價值的資訊解密,呈現最完整的內容給使用者。