讓我們先回顧下TripAdvisor的架構(gòu)。2011年6月，TripAdvisor發(fā)布其架構(gòu)。過去一年多我們的業(yè)務(wù)發(fā)展迅速，讓我來總結(jié)下我們的成績：

每月5600萬訪問者

每天3.5億頁面訪問量

Hadoop集群運行著120TB數(shù)據(jù)，并快速增長中

這個夏天，我們從大學招聘了60名兼職，其中包括Luke Massa和Victor Luu，他們像我們的全職工程師一樣工作，很快融入了我們。一直以來總有一個問題糾纏著我：為什么要使用云計算?Luke Massa和Victor Luu通過在AWS部署我們的服務(wù)，總結(jié)了在過去這個夏天他們在TripAdvisor發(fā)生的一切。

圖：AWS幫助企業(yè)節(jié)省大量成本

2012的夏天，TripAdvisor對我們的產(chǎn)品全部遷移到AWS進行了實驗性的評估。首先，我們開始試驗將www.tripadvisor.com和所有國際域名運行在AWS EC2環(huán)境，我們的工程師開始還懷有最簡單的問題：放棄我們已有的硬件，遷移到AWS上真的劃算嗎?(AWS)能運行的完好嗎?(注：停電、颶風以及其它不可知的原因，AWS今年已經(jīng)出現(xiàn)兩次大規(guī)模故障。或許，TripAdvisor考慮過在自己的服務(wù)器上運行OpenStack，這個開源平臺允許企業(yè)架設(shè)自己的私有云，它兼容AWS的大部分API。)

幾個月以前，我們開始試驗性與云計算親密接觸，當然結(jié)果并不是非好即壞。我們在過程中學到了大量經(jīng)驗，不僅僅是AWS提供的價值，還包括幫助我們改造了原有托管服務(wù)器集群的架構(gòu)。這一切都歸功于AWS的靈活性，我們將DNS切換，流量轉(zhuǎn)換到AWS，這非常實用，是非常好的學習工具!

目標

在EC2上建立網(wǎng)站的全部，評估實際生產(chǎn)環(huán)境的流量壓力

建立成本模型

確認架構(gòu)升級后我們可以減少支出，并增加擴展性

在轉(zhuǎn)換到AWS后，我們需要找到方法提升我們現(xiàn)有的架構(gòu)

EC2的支出

支出包括三個主要部分：實例、EBS和網(wǎng)絡(luò)。假定生產(chǎn)環(huán)境的網(wǎng)絡(luò)流量為200GB/小時，支出為14.30美元/小時。可以預(yù)見，實例的支出占據(jù)整個支出的大部分。

實際對比

部署每個數(shù)據(jù)中心需要大約220萬美元，加上每年30萬美元的升級和擴展費用。固定資產(chǎn)支出(Capex)大約100萬美元/年，假設(shè)數(shù)據(jù)中心的初始成本分攤到3年中。運營成本包括空間、電源以及帶寬，這些大概30萬美元/年。合計成本為130萬美元/年/數(shù)據(jù)中心。我們在每個數(shù)據(jù)中心有超過200臺設(shè)備，每臺典型設(shè)備的成本為7000美元。

如果我們將130萬美元全部花在EC2上，簽訂1年期合同，我們會得到下面的架構(gòu)：

550個前端和后端實例

64個緩存實例

10個數(shù)據(jù)庫實例

成本1486756.96美元。

這意味著我們將增加60%的容量(目前已有340個前端和后端實例，32個緩存實例，5個數(shù)據(jù)庫實例)。

如果我們簽訂3年合同，將享有驚人的優(yōu)惠，這個架構(gòu)的成本僅為88萬美元/年。如果我們想在三年內(nèi)花掉390萬美元，我們將得到如下的架構(gòu)：

880個前端和后端實例

64個緩存實例

20個數(shù)據(jù)庫實例

一個有趣的現(xiàn)象是，即便是這個架構(gòu)我們只使用了1760個內(nèi)核(每個服務(wù)器2個CPU內(nèi)核)，然而我們現(xiàn)在使用(CSDN注：指傳統(tǒng)的服務(wù)器托管方式)總共3500個內(nèi)核。顯然，我們確信當下的架構(gòu)存在一些垃圾和潛在的威脅，運行效率十分低下。

成本節(jié)省總結(jié)

保留實例的前提下，我們計算后發(fā)現(xiàn)，簽訂1年合同情況下，年化成本將節(jié)省一半。同時，我們不需要為流量高峰或系統(tǒng)備份預(yù)留實例，從而節(jié)省我們的總成本。

每個實例均可定制，以符合實際的需求。而現(xiàn)在，我們只能使用每臺服務(wù)器的一部分性能。

運維人員-運維更加高效，因為我們知道實例會一直在那里運行。

幾點失敗

前端存在一些“BigIP喜好”(CSDN注：BigIP是F5公司推出的系列負載均衡設(shè)備)的類型實例。我們該怎么做，來減少對BigIP的依賴?

我們的負載均衡由Amazon管理，當Amazon出現(xiàn)故障時會發(fā)生什么?參考資料建議，全DNS名要好于IP地址，但這只適用于一般情況。

自動伸縮性幫助我們運行適當?shù)那岸撕秃蠖藢嵗Ｈ欢?，重建緩存實例需要很長時間，而且需要重復(fù)的數(shù)據(jù)庫熱備。

最佳實踐

任何事情都可以通過AWS管理控制臺搞定，它提供了命令行工具。你可以盡情的通過它自動完成許多啟動過程。

在自動化啟動過程中，在等待后確保實例運行并且達到要求：

“ec2-describe-instances”告訴你實例是否在運行

新版的“ec2-describe-instance-status”告訴你實例是否通過，以及系統(tǒng)狀態(tài)檢查

早期，開發(fā)了一些系統(tǒng)來監(jiān)控實例的運行狀態(tài)。但這關(guān)系到GUI問題。盡管你可以通過tag和名字監(jiān)控任何事情，你還是需要一個更加自動的方式來管理這一切。舉個例子，我們有一個PostgreSQL開發(fā)服務(wù)器來管理這一切。

停掉一個實例還不如終止它。這就是云計算的優(yōu)勢，當一個實例發(fā)生問題，常用的辦法是啟動一個全新的實例代替他，而不是進行重啟。當然，你也可以找到并解決實例發(fā)生的那些故障。

值得注意的是，通過“terminated instances”來終止某個實例后，當你運行“ec2-describe-instances”依然會顯示這個實例的名字。如果你用名字來區(qū)分實例的話，這的確是個問題，因為兩個實例都會顯示出來。

建議清理你的EBS卷。存儲的成本增加非?？?。同時建議及時清理快照，因為他們和卷有差不多的價格。

不要忘記短暫的存儲，不要忘記他們是短暫的。一些積累下來的文件十分有用，如錯誤日志。用定時任務(wù)來保存重要的數(shù)據(jù)。

充分利用副本和快照完成快速擴展。

細節(jié)監(jiān)控相當酷，不過我發(fā)現(xiàn)CloudWatch的自動排列功能已經(jīng)夠用。對于整個系統(tǒng)而言，檢查狀態(tài)時間間隔1分鐘與間隔5分鐘的區(qū)別并不重要。不過，對于監(jiān)控特定的實例組還是有幫助。

ELB(Amazon Elastic Load Balancing，彈性負載均衡)也是一個監(jiān)控實例狀態(tài)的好工具，即使我們實際上沒有用到。

許多令人崩潰的網(wǎng)絡(luò)問題可以通過小心照看安全設(shè)置組來解決。

總結(jié)

實際上，除了本文開始介紹的停電、實例磁盤空間不足這些問題外，TripAdvisor在遷移到AWS過程中還遇到了種種困擾，包括數(shù)據(jù)丟失、實例不可用、NGinx故障等等，詳細請閱讀原文“Problems Along The Way”部分。顯然，你不能指望云計算解決所有問題，而且就目前云計算的成熟度而言，企業(yè)還需要強大的技術(shù)積累，如需要在本地做好重要實例的備份。