awe.sm從創(chuàng)立之初就采用了AWS平臺，過去3年我們體驗了AWS的優(yōu)美和不足，并總結(jié)出一套最佳實踐。

不夸張的說，AWS徹底改變了科技創(chuàng)業(yè)公司的經(jīng)濟運行模式。沒有人意識到有多少公司正在使用AWS的EC2，直到它發(fā)生宕機“真相”才浮出水面。每個人使用AWS都可以從根本上實現(xiàn)非常簡單的運行軟件的方式，并節(jié)省大量硬件投資。

圖：AWS的優(yōu)勢和缺陷讓人既愛又恨EC2是一種運行軟件新的方式

首先，也是最重要的，EC2絕不僅僅是虛擬托管服務(wù)器。或者說，它就像雇傭了部分系統(tǒng)和網(wǎng)絡(luò)管理員：代替一名昂貴的管理員，實現(xiàn)自動管理，你只需要為每個虛擬機支付一點點費用而已，并將產(chǎn)生的問題匯總。供電、網(wǎng)絡(luò)拓撲、硬件成本、供應(yīng)商選擇以及網(wǎng)絡(luò)存儲系統(tǒng)——在2004年以前這些你都需要考慮。而通過AWS和其它競爭對手的努力，你不用再考慮這些，至少不用考慮這么多。

毫無疑問，彈性是使用EC2最大的優(yōu)勢和特色，我們只需要約5分鐘就能建立一個虛擬機，這將讓我們有更高的靈活性：

我們可以在新的硬件上進行大規(guī)模升級。當(dāng)我們進行大規(guī)模升級時，可以完全建立全新的硬件以及設(shè)置和依賴關(guān)系，并把它們裝入負載均衡器，然后重新設(shè)置負載均衡器即可。當(dāng)然最后要把之前運行的虛擬機關(guān)機。你需要2倍的硬件來進行升級切換，但只需要使用24小時，絕對的廉價和簡單。

對于一些非關(guān)鍵系統(tǒng)的備災(zāi)計劃(這些非關(guān)鍵系統(tǒng)最長允許宕機1個小時)，我們只要監(jiān)測到宕機的虛擬機，然后新啟動一個虛擬機然后做系統(tǒng)還原即可。

依照負載進行擴容絕對好過事先的判斷：當(dāng)監(jiān)控到負載很高時，你可以開啟額外的虛擬機，及時應(yīng)對高負載。

我們根本不擔(dān)心對虛擬機數(shù)量進行計算：我們總有用不完的虛擬機可供啟動，如果我們出錯了，可以很容易的關(guān)閉或者啟動虛擬機。這樣的硬件迭代就是AWS最棒的功能。

EC2為初創(chuàng)企業(yè)帶來強大的財務(wù)支持

AWS的最明顯的成本優(yōu)勢是硬件零安裝成本：你使用與亞馬遜相同的帳戶從互聯(lián)網(wǎng)上訂購，按一下按鈕，并啟動服務(wù)器，按小時支付。你只需支付正在運行的硬件，以及實際使用的存儲，這讓你的啟動成本達到最小。同時，這將鼓勵在硬件層面實驗：在現(xiàn)有的資源上增加10倍，運行負載測試，然后關(guān)閉這些增加的虛擬機，直到你真正需要它們。這不僅僅方便，而且是革命性的。

AWS能夠降低運營成本。截至到2012年，我們的公司已經(jīng)運營了2年多，我們甚至沒有專業(yè)的運維人員。不過我們依然有一名的全職的運維人員負責(zé)管理數(shù)以百計的虛擬機，這是相當(dāng)高的效率。我們根本不用考慮供電、網(wǎng)絡(luò)等等。

當(dāng)然，AWS并非完美，他的價格超過競爭對手不少。但借助定期的降價，10月份的18%，今年3月的10%。最后，如果長期使用，你可以預(yù)先支付費用，并獲得最多50%的折扣。

但是EC2有一些問題

EC2有嚴重的性能和可靠性問題，重要的是要做到心中有數(shù)，并提前做出應(yīng)對計劃。

首先，AWS那臭名昭著的“可用地區(qū)”模式，這些分布在不同地區(qū)的物理設(shè)備彼此分離，包括網(wǎng)絡(luò)、供電等。關(guān)于“可用地區(qū)”我們有幾條非常重要的經(jīng)驗：

虛擬設(shè)備不可能像硬件設(shè)備那樣長久：根據(jù)我們在過去3年的觀察，虛擬機的平均生命周期約為200天。這之后的“退休”將經(jīng)歷非常高的風(fēng)險，AWS的“退休機制”根本不可控：有些時候提前10天通知你虛擬機將被關(guān)閉;有時候虛擬機已經(jīng)關(guān)閉2小時后，才收到通知郵件。頻繁的硬件更迭并不是太大的問題，畢竟你可以很輕松的啟動新的虛擬機來替代，但重要的是你應(yīng)該意識到，要盡早進行自動部署，以減少更換虛擬機所需的時間。

你需要是在一個以上的區(qū)域進行部署，并建立冗余。這一直是我們的經(jīng)驗，你可能失去整個區(qū)域，而不是一個虛擬機。如果你的系統(tǒng)有單點故障，你不能從故障虛擬機中獲取備份或設(shè)置信息，如果整個區(qū)域不可用，你甚至連這個虛擬機都看不到，更別提恢復(fù)數(shù)據(jù)了。

多區(qū)域故障也可能發(fā)生，因此，如果你能負擔(dān)得起，也要部署多個區(qū)域。美國東部是故障頻發(fā)​的地區(qū)(因為歷史最長，價格最便宜)，2012年6月、2012年3月，以及最引人注目故障是在2011年。AWS的不穩(wěn)定性似乎有相同的根本原因。

為了保持較高的正常運行時間 我們已經(jīng)不再相信EBS

這就是我們的經(jīng)驗和亞馬遜的市場建議最沖突的地方。AWS期望EBS是使用EC2的基礎(chǔ)：AWS希望你將所有的數(shù)據(jù)托管在EBS卷上，一旦實例故障，你能立刻將EBS卷遷移到新的硬件上，這一過程很輕松。AWS還希望你使用EBS快照來對數(shù)據(jù)庫備份并恢復(fù)。AWS同樣希望你在EBS卷上運行操作系統(tǒng)，即EBS備份實例。但根據(jù)我們的經(jīng)驗，EBS有幾大挑戰(zhàn)：

EBS卷的I/O性能太差。虛擬化的硬件的I/O性能顯然不如純粹的硬件，但我們的經(jīng)驗卻相反，EBS卷的性能遠不如本地存儲(AWS稱之為“短暫存儲”)。EBS卷本質(zhì)上是網(wǎng)絡(luò)存儲，所以性能不會非常好。AWS試圖游說用戶使用定制IOPS，這是一種更高性能的EBS卷，但它的價格會拒你千里之外。

EBS基于地區(qū)的可用性?；谖覀兊慕?jīng)驗，EBS有兩個特性：所有的卷可用，或都不可用。在前文提到的3起地區(qū)性的EC2事故中，2起是由EBS故障從一個地區(qū)擴展到其它地區(qū)引起的。如果你的故障恢復(fù)計劃建立在EBS卷基礎(chǔ)上，當(dāng)遇到EBS故障引起的宕機，你就要倒大霉了。悲催的是，這種情況我們已經(jīng)遇到好幾次了。

基于Ubuntu的EBS故障十分嚴重，因為EBS卷實際上通過網(wǎng)絡(luò)驅(qū)動偽裝成塊設(shè)備，這與Linux系統(tǒng)不兼容。我們曾經(jīng)遇到由此引發(fā)的嚴重事故，EBS卷故障導(dǎo)致整個虛擬機鎖定，無法遷移，甚至對任何磁盤需求都不予響應(yīng)。

因此，大約半年前開始，我們完全放棄了EBS。我們付出了相當(dāng)大的代價(主要是圍繞如何執(zhí)行備份和恢復(fù)系統(tǒng))。截至到目前看，這么做絕對值得。

請注意：其他AWS服務(wù)依賴于EBS

由于一些的AWS增值服務(wù)是建立在EBS中，當(dāng)EBS故障時，他們也隨即失效，包括彈性負載均衡ELB、關(guān)系數(shù)據(jù)庫RDS、EB(Elastic Beanstalk)以及其它。在我們的經(jīng)驗中，EBS總是位于故障的中心。所以，如果EBS發(fā)生故障，你需要迅速的將流量轉(zhuǎn)換到其它地區(qū)，但很遺憾，你根本無法完成切換，因為負載均衡就運行在EBS上。同時，你也不能啟動新的設(shè)備，因為AWS提供的控制臺服務(wù)也是運行在EBS上的。所以，我們愛EC2(以及真的真的愛S3)，但我們不用AWS提供的任何附加服務(wù)。這么做的好處是，我們可以相對簡單地切換到其他托管服務(wù)提供商，而不是密切的鎖定在AWS。

吸取的經(jīng)驗教訓(xùn)

如果我們明天再次啟動awe.sm，我會不加思索的繼續(xù)使用AWS。對于一個小團隊而言，你只有很少的預(yù)算，還需要迅速作出反應(yīng)，AWS就像一部高性能的全自動相機。Joyent、Rackspace等IaaS提供商正加緊追趕，我們期待著與他們的合作。當(dāng)我們從100多臺虛擬機增長到1000臺后，必須引入更多的供應(yīng)商，或者使用Carpathia的與AWS兼容的混合云方式。