最近時間過得特別快，因為同時在忙著幾件不同的案子，所以很少上來分享一些心得，還請大家見諒！
「MobileCare手機保姆」的服務由於媒體的報導，已經有越來越多人知道並持續在使用中，也因此資料量成長得十分快速，在5月就已經破百萬筆，而且每天都有數萬筆的記錄在持續產生中．．．
這是很令我們振奮的事，但相對而來的便是營運上的壓力及日常維運等議題，而首先碰到的就是：效能問題！
我相信有很多網路創業的朋友們或企業主們都會誤認為只要採用AWS雲端後就不必擔心資料備援、運作效能等，實際上用得夠久的朋友應該都會發現：
AWS是IaaS的服務，而不是PaaS的服務(如GAE、Azure或其它新興的PaaS平台)。而這也代表在AWS上，所有該做的事還是要自己做，不論是備援、擴展或是效能調校等各種基本需求！
以下是我們最近遇到的問題及實際的處理，歡迎享用～
備援．備援．備援
前陣子AWS(Amazon雲端服務)因為EBS、RDS的問題而使得很多公司或網站服務受到很大的影響，花了三天才整個處理完畢，事實上，我們的網站雖然EBS出現問題，但網站營運卻一切正常，這是因為我們有做好事前的規劃，所以能夠不受到此次事件的影響（多年前也曾遇過，自那時以後就特別重視架構規劃），下面是幾個我們經常推薦的架構：
★AWS基本架構
除了EC2之外，並使用S3及EBS來搭配使用，主要是在資料的備援處理（週期備份、即時備份、災難復原）
★AWS進階架構(一)
與基本架構不同的地方在於增加了異地備援及DB Replication的機制，這是企業最喜歡、也至少要用的架構
★AWS進階架構(二)
這個架構已經略有水平擴展的基礎模式，主要是增加了http loading banlance、MySQL loading balance的處理，並兼顧異地備援的需求，當然成本上就會大大增加，因此若是遇到效能上的問題時，建議先找出實際的運作瓶頸後，再針對該問題加以處理，這樣才能看得到增加成本後真的得到了明顯的效益。
其實備援的問題是老生常談，我相信在所有講雲端技術的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上，所以我們有針對該問題處理後就大幅提昇了效能！
看到這兒，有些朋友或許會注意到AWS要自行管理妥當也不是件輕鬆的事，那乾脆用PaaS不就好了？！讓雲端服務廠商負責大部份效能及維運的工作，自己只要專心寫好應用程式來提供服務就行？！
的確是很不錯的建議，但仍要視各人的需求及考量而定，下述是我們從之前的演講資料中擷取出來的部份，在最後僅提供給各位參考，讓大家自己去想想囉～
使用雲端服務的五大考量
成本：期初／營運、少量／巨量、移轉／備援…
支援性：系統操控彈性、中介程式、資料庫…
移植性：移轉至其它雲端的可能性、難易度
擴展性：可視需求進行水平、垂直擴展
