AWS_Performance

最近時間過得特別快,因為同時在忙著幾件不同的案子,所以很少上來分享一些心得,還請大家見諒!

「MobileCare手機保姆」的服務由於媒體的報導,已經有越來越多人知道並持續在使用中,也因此資料量成長得十分快速,在5月就已經破百萬筆,而且每天都有數萬筆的記錄在持續產生中...

這是很令我們振奮的事,但相對而來的便是營運上的壓力及日常維運等議題,而首先碰到的就是:效能問題!

我相信有很多網路創業的朋友們或企業主們都會誤認為只要採用AWS雲端後就不必擔心資料備援、運作效能等,實際上用得夠久的朋友應該都會發現:

AWS是IaaS的服務,而不是PaaS的服務(如GAE、Azure或其它新興的PaaS平台)。而這也代表在AWS上,所有該做的事還是要自己做,不論是備援、擴展或是效能調校等各種基本需求!

以下是我們最近遇到的問題及實際的處理,歡迎享用~

備援.備援.備援

前陣子AWS(Amazon雲端服務)因為EBS、RDS的問題而使得很多公司或網站服務受到很大的影響,花了三天才整個處理完畢,事實上,我們的網站雖然EBS出現問題,但網站營運卻一切正常,這是因為我們有做好事前的規劃,所以能夠不受到此次事件的影響(多年前也曾遇過,自那時以後就特別重視架構規劃),下面是幾個我們經常推薦的架構:

AWS基本架構

除了EC2之外,並使用S3及EBS來搭配使用,主要是在資料的備援處理(週期備份、即時備份、災難復原)

AWS基本架構

 

AWS進階架構(一)

與基本架構不同的地方在於增加了異地備援及DB Replication的機制,這是企業最喜歡、也至少要用的架構

AWS進階架構一

 

AWS進階架構(二)

這個架構已經略有水平擴展的基礎模式,主要是增加了http loading banlance、MySQL loading balance的處理,並兼顧異地備援的需求,當然成本上就會大大增加,因此若是遇到效能上的問題時,建議先找出實際的運作瓶頸後,再針對該問題加以處理,這樣才能看得到增加成本後真的得到了明顯的效益。

AWS進階架構二

 

其實備援的問題是老生常談,我相信在所有講雲端技術的Blog或Forum中,只有我們最最最重視備援的議題(實在是沒遇過的人真的沒在怕的啊~ Orz ),每每在場子或技術討論中講到AWS雲端時,總是一再提醒:備援、備援、備援!因為只要資料沒有問題,網站隨時都可以復活的啊(當然別忘了要針對備援的資料進行災難復原的測試,免得花了很多錢備份,結果資料卻是有問題而無法還原,那就糗大了)!!

而在AWS中,雖然強調有幾個9的SLA,但遇到狀況的時候,AWS頂多也只會賠個免費的幾天服務,而經營網站服務的苦主們卻得要想辦法去拉住不耐煩的廣大網友、客戶們,這些損失絕不是Amazon、Google、Microsoft等雲端服務商會幫忙承擔的,因此請務必要做好:備援、備援、備援!

有很多網路創業的朋友們經常會問我關於AWS的問題,也因此得知大部份的朋友都還在使用VPS來提供服務給客戶,而我也常常不怕被誤會在拉生意的建議他們用AWS比較好,主要就是因為AWS在備援的部份有超好用的S3及EBS可以交叉搭配,讓備援工作可以更有效率、更不會有萬一;雖然朋友們往往會說怕成本太貴而暫用VPS,但想想看,每天少喝一杯百元以上的咖啡(像星巴克、西雅圖的…),拿來換取網站營運上的穩定不是很划算嗎?!怎麼反倒大家寧願喝咖啡,而去省下網站基本營運的費用?!

當然,也有很多朋友是使用AWS的Free Tier(Micro Instance)來運作網站,如果是個人的Blog或小服務那就絕對綽綽有餘;但若是要玩正式的網站服務,建議還是別省這個錢,否則絕對會得不償失的!至於要如何做好備援的處理,就必須視網站本身的程式架構、採用的系統、資料庫的選定等等而會有所不同,上述的圖僅是概略的架構圖,僅供大家做為參考!

 

 

效能.效能.效能

網站的穩定度夠了,接下來要談的就是效能的問題了!其實以AWS來說,還特別分了十多種不同的Instance供不同需求的朋友使用,重要是:要知道網站的效能瓶頸確切問題所在,這樣才能花最少的成本得到最大的效益!

對外頻寬

還在Co-Loctation、自有主機、虛擬主機的模式經營站最先遇到的瓶頸往往不是在主機本身,而是在對外頻寬的不足,以一個512K的首頁來說,若希望能同時承載1000人連線,以簡單概略計算就需要:

512K(檔案大小) x 1000(人) = 500M (所需頻寬)

是的,您沒看錯,就是要有500M,在以往的做法想當然爾只有Co-Location才能滿足,然而成本卻是十分驚人:以現在較便宜的機房行情來算,1M也要2000元,所以一個月頻寬費用就要100萬(500 x 2000)!

這也是為何以往經營網站服務的公司都被說是在燒錢,真的是啊~ Orz

各種連網設備

然而有了雲端之後,對外頻寬往往都不是效能瓶頸的所在,反而大部份是用戶端的電腦太慢(如需要精美動畫的遊戲都很需要)、網路頻寬太慢(也許是拿來BT下載,或是有中毒、被當做傀儡機而不自知);如果排除掉用戶端設備及網路頻寬的問題(因為那也不是我們可以解決的),接下來就要談在AWS上的伺服器效能相關議題了!

 

手機保姆-系統架構

上圖是「MobileCare手機保姆」的系統架構,可以清楚的了解在AWS上的伺服器中有幾個重要模組:

 

作業系統:

系統的底層負責記憶體、CPU、網路等資源管控分配,在AWS上雖然一切都是虛擬化(所以CPU效能會比實體的CPU差些),但和實體伺服器一樣都可以進行調整,尤其是一些不必要的Daemon務必要將其關閉,以有效節省系統資源(呃,觀眾問到用Windows系統時怎麼辦?一般我都直接建議用Microsoft的Azure,不要找我 :P)。

 

資料庫:

一般來說網站服務都會有資料庫的存在,這方面的學問可也是博大精深的(君不見有眾多DBA市場的存在需求,這方面我們不是專家,歡迎專家與我們聯絡 😀 ),大致來說有幾個重點:

1.要使用RDS(relational database)或是NoSQL (key-value)的資料庫,會影響日後維運及擴展的規劃。

2.資料庫本身的參數設定(如cache、connections、buffer、thread等)。

3.SQL指令的語法(是的,這點最便宜,但最多人忽略它),儘量去試可以達到同樣結果但執行效能最好的SQL語法(這和使用的資料庫類型也有很大的關係),幾萬筆資料可能沒感覺,但一旦有百萬筆資料時就知道差異了,若本身無法做到,可以適當地分工給中介程式去處理(如php等)。

4.依照實際的需求去評估三階段正規化的必要性,越簡單越好,效能就會越快;此外當資料大到一定程度時,就要做適當的分割(sharding),讓單一Table中的資料可以在百萬筆以下是最好的。

5.千萬記得,寧願為了備援去犠牲效能,也不要為了效能而不做備援!

 

中介程式:

這層可以說是最多朋友在鑽研的一塊了,寫網站的程式設計師絕對都是會先碰到這塊,之後才會延伸去搞資料庫、系統、網路、雲端等等。而中介程式主要是受系統的支援度而有所不同,當然也會有跨平台的中介程式是最常被選用的,如Java、Php、Rail等等…

簡單來說有幾個要點:

1.若是用現有的Open Source系統(如WordPress、XOOPS、Joomla、Drupal、OSCommerce…等),建議直接使用現有的模組,或是花時間去了解模組的開發,日後可視自己的需求增加模組即可;但缺點就是核心系統一旦要變動時,絕對絕對是超乎想像的大工程。

2.若是不用OpenSource系統,且網站需要長時間經營或進行更動的,儘量找個framework來用,如Php的Zend、Codeigniter(一般稱CI)、CakePHP等等(在Java、Rail等也都有好用的framework,自己去問google大神囉~)。

3.若是網站實在很小或很單純,也許用幾支PHP或Java程式就可以做完時,那就用有物件導向的程式語言去寫(Php 5、Java、Rail都是),只要好維護、效能夠,還有可以防SQL Injection的攻擊就好了。

 

網站服務:

這個部份是指像apache、lighttpd、nginx等提供Web Service的套件(抱歉,用IIS的朋友請勿來信抗議~ 請恕我們僅提供Linux的服務),針對其特性還可用來做不同的搭配,例如用nginx或lighttpd來做分流(Web loading balance),其它台則是用apache等來負責實際的連線服務。

一般來說在架站時都會做個「簡單」的壓力測試,以調校出最佳的效能(都有參數直接來進行調整、設定),不過大部份現有的設定都是調整好的,除非有特別需求,不然用預設值就有很不錯的表現!

 

當然整體效能的優化不止於此,包括I/O Access的效能、記憶體的大小、CPU的數量、各種分散式系統、水平擴展技巧的應用(如memcached等),在此就不再班門弄斧,希望能有高手、前輩們不吝給予指導,感謝!

下圖是我們前幾天實際調整後,CPU從原本超過50%負載的狀況降到20%以下,所以在AWS就可以繼續用m1.small的等級來提供、滿足服務,這是因為原本的瓶頸是在MySQL上,所以我們有針對該問題處理後就大幅提昇了效能!

優化前後的CPU負載

 

看到這兒,有些朋友或許會注意到AWS要自行管理妥當也不是件輕鬆的事,那乾脆用PaaS不就好了?!讓雲端服務廠商負責大部份效能及維運的工作,自己只要專心寫好應用程式來提供服務就行?!

的確是很不錯的建議,但仍要視各人的需求及考量而定,下述是我們從之前的演講資料中擷取出來的部份,在最後僅提供給各位參考,讓大家自己去想想囉~

 

使用雲端服務的五大考量:

成本:期初/營運、少量/巨量、移轉/備援…

 

支援性:系統操控彈性、中介程式、資料庫…

移植性:移轉至其它雲端的可能性、難易度

 

擴展性:可視需求進行水平、垂直擴展

 

延伸性:有配套服務可供應用(如Storage)

Facebooktwittergoogle_plusmail
志文

tts.ken@gmail.com