2010年9月2日

傳統的架站方式(非雲端運算/虛擬化環境)要如何應付超大量的流量

前陣子我負責維運的網站由於配合行銷活動的關係,在短時間內湧入超大的流量,而這個系統是用傳統的架構(也就是用多台實體 server 做 load-balance,配合網路的 VIP 設定以 IP-hashing 分流)做的,在應付這種超大流量的時候顯得力不從心,以下紀錄採用如此架構要應付超大流量時,要注意的地方。

流量控管
  1. 應該請行銷人員事先通知系統管理人員何時會發行銷簡訊,以便提早設定 web server 的流量限制 (concurrent sessions),以免瞬間倒台。雖然超出流量限制的 user 無法連線成功,但只要 retry 就可能連的上。這樣的作法可確保 web server 不會倒台,在能力範圍內提供最多的服務。
  2. DB server 倒台時可能要花很長時間才能回復,在這些 downtime 時損失的流量是難以挽回的。
  3. 平常應該透過壓力測試,或者流量分析的歷史紀錄來評估每台 Web server 最多可接受多少個concurrent sessions,以便進行上述的流量限制。
  4. Web server concurrent sessions 的設定應慢慢逐步放寬,以免瞬間超過 server 的負荷量而倒台。
  5. 要注意 Apache httpd.conf 裡面的「MaxClients」設定值,若設定值過高可能造成 server 無法負荷(甚至造成接 console 也無反應,沒有螢幕,必須重開機)。(預設值為256)
硬體設備
  1. 上線前要作 end to end 的測試(包含所有備用機),備用機的狀態應該調整到只要 VIP 一 enable,就會有流量進來的程度,只是在 VIP 設定中暫時 disable,保持隨時可以上線的狀態。本次準備的一台備用機因 OS 環境與正式環境差太多 (如 Apache 版本、Apache modules 版本等),最後無法即時在當天 config 完成並上線提供服務。
  2. 設備的 RAM 應提早估計是否夠用,臨時要調 server 使用的 RAM 相當困難(e.g., 創見門市不賣 server 使用的 RAM,價錢也蠻貴的),頂多只能把閒置的 server 停機來支援 (等到活動結束又要安排時間把 server 組態回復原狀,又要再花時間測試、驗證)。
  3. IBM X3650/X3850 M2 的 RAM 無法讓 IBM X3850 使用。

另外補充一點,MySQL DB 瞬間倒台(RAM 被吃光) 以後,除了緊急擴充 RAM 以外,還討論了以下兩種方案:
  1. 維持 active/standby:如此當 active server 倒台的時候 backup server 可接手服務,資料也比較不會有不一致的問題。但是現況是 backup server 的 RAM 比 active server 還弱!因此若 active server 倒台,backup server 一定撐不住 (而且會更快倒),也就無法發揮「接手服務」的功能。
  2. 將 Web Server & DB Server 分群:如上所述,當倒台時由於 backup server 實際上無法接手 active server 的服務,因此不如設定 n 台 web server 對應 active DB server,另外 m 台 web server 對應到 backup DB server,在兩台 DB Server 資料隨時雙向同步的狀況下,同時讓兩台 DB server 一起提供服務。有的考量是怕資料會不一致,而且萬一某一台 server 倒掉了就沒人接手了。
最後經過討論,仍決定維持方案1 (active/standby),幸好到後來 DB 有撐住。以當天的 loading 來看,若 RAM 沒有擴充可能會撐不住,但研判改寫程式才是 DB loading 能降低的主因(動態網頁-->靜態網頁),也許未來遇到像這次可預期的超大需求的時候可以提早調整程式。


個人的感想是採用方案二可以提供更好的效能,因為發生硬體障礙的機率應該是遠低於把所有的流量都導向 active server 而造成倒台。而且一旦 active server 倒台,服務會完全停擺 (standby server 一接手就會馬上倒),除非把 web server 的流量限制設定的很嚴格,才能讓 DB 維持運作。

若採用分群,則兩台 DB server 的 loading 都不會太高,倒台的機率就會大大降低,但最重要的前提是兩台 server 間的資料可以完美的同步,最後每一筆資料都要能由 timestamp 來排序。

在 MySQL HA Overview 一文中官方也說明了如何提供 HA 的架構,很值得仔細研究。

其他感想
  1. 要擴充實體機器是相當麻煩的,遠比擴充 VM 困難的多,特別是網路設定的部份(設定 IP、VIP 等,不小心還會插錯 switch…而且插錯 switch 挺難查的,可能會造成明明網路有通,但是 apache 接不到 HTTP request 的詭異情況)。
  2. 如果活動真的很盛大,瞬間湧入超大的流量,那麼 DB Server 有可能會瞬間倒台,時間推測在幾十秒到一分鐘之間。假設系統架設在 Amazon EC2 上,能不能在這麼短的時間內 clone 一台新的 server 並且立刻上線提供服務?雖然說在虛擬化環境中可在短短數分鐘內就新增一台 server,相較於擴充實體 server 已經是非常快速,但要應付瞬間如此大量的需求可能還是不足,最理想的狀況是能夠在數秒鐘,或者 10 秒內就擴充第一台 server,讓整個 DB cluster 能夠撐下去,之後就比較有餘裕來進一步擴充了。




參考資料
  1. Apache httpd.conf : MaxClients
  2. MySQL HA Overview

Google Spreadsheet 裡用規則運算式

最近因為工作關係,遇到要用 Google Form 及 Google Sheet 所以研究了 Google Sheet 裡的一些 function 怎麼用 首先,分享一下如何在 Google Sheet 裡用規則運算 :D