讓我們先回顧下TripAdvisor的架構。2011年6月，TripAdvisor發布其架構。過去一年多我們的業務發展迅速，讓我來總結下我們的成績：

每月5600萬訪問者

每天3.5億頁面訪問量

Hadoop集群運行著120TB數據，并快速增長中

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

圖：AWS幫助企業節省大量成本

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

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

目標

在EC2上建立網站的全部，評估實際生產環境的流量壓力

建立成本模型

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

在轉換到AWS后，我們需要找到方法提升我們現有的架構

EC2的支出

支出包括三個主要部分：實例、EBS和網絡。假定生產環境的網絡流量為200GB/小時，支出為14.30美元/小時。可以預見，實例的支出占據整個支出的大部分。

實際對比

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

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

550個前端和后端實例

64個緩存實例

10個數據庫實例

成本1486756.96美元。

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

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

880個前端和后端實例

64個緩存實例

20個數據庫實例

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

成本節省總結

保留實例的前提下，我們計算后發現，簽訂1年合同情況下，年化成本將節省一半。同時，我們不需要為流量高峰或系統備份預留實例，從而節省我們的總成本。

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

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

幾點失敗

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

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

自動伸縮性幫助我們運行適當的前端和后端實例。然而，重建緩存實例需要很長時間，而且需要重復的數據庫熱備。

最佳實踐

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

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

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

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

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

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

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

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

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

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

細節監控相當酷，不過我發現CloudWatch的自動排列功能已經夠用。對于整個系統而言，檢查狀態時間間隔1分鐘與間隔5分鐘的區別并不重要。不過，對于監控特定的實例組還是有幫助。

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

許多令人崩潰的網絡問題可以通過小心照看安全設置組來解決。

總結

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