# 史詩般的 TripAdvisor 更新：為什么不在云上運行？ 盛大的實驗 > 原文： [http://highscalability.com/blog/2012/10/2/an-epic-tripadvisor-update-why-not-run-on-the-cloud-the-gran.html](http://highscalability.com/blog/2012/10/2/an-epic-tripadvisor-update-why-not-run-on-the-cloud-the-gran.html)  *這是 [Shawn Hsiao](http://www.linkedin.com/in/phsiao) ， [Luke Massa](http://www.princeton.edu/rocky/people/residential-college-advis/luke-massa/) 和 [Victor Luu](http://www.linkedin.com/pub/victor-luu/57/243/91a) 的來賓帖子。 肖恩負責運行[，TripAdvisor](http://www.tripadvisor.com/) 的技術運營團隊，盧克和維克托在去年夏天加入了他的團隊。 該帖子由 TripAdvisor 的工程負責人 [Andy Gelfond](http://www.linkedin.com/in/andrewgelfond) 介紹。* 距離我們上一篇關于 [TripAdvisor 建筑](http://highscalability.com/blog/2011/6/27/tripadvisor-architecture-40m-visitors-200m-dynamic-page-view.html)的帖子已經過去了一年多。 這是令人興奮的一年。 我們的業務和團隊不斷增長，我們現在是一家獨立的上市公司，隨著我們的發展，我們繼續保持/擴展我們的開發流程和文化-我們仍然經營著數十個獨立團隊，每個團隊繼續在整個 整個堆棧。 唯一改變的是數字： * 每月 5600 萬訪客 * 每天有 350M +頁的請求 * 120TB +的倉庫數據在大型 Hadoop 集群上運行，并且迅速增長 我們還有一個非常成功的大學實習計劃，該計劃于去年夏天招募了 60 多名實習生，所有這些人很快就入職，并且與我們的全職工程師一樣從事相同的工作。 這里反復出現的一個想法是，為什么不在云上運行？ 我們的兩個暑期實習生 Luke Massa 和 Victor Luu 通過在 Amazon Web Services 上部署我們網站的完整版本來認真研究這個問題。 用他們自己的話說，以及很多技術細節，這里是他們去年夏天所做的事情的故事。 ## 在 AWS 上運行 TripAdvisor 今年夏天，我們在 TripAdvisor 開展了一個實驗項目，以評估在亞馬遜的彈性云計算（EC2）環境中運行整個生產站點的情況。 當我們第一次嘗試在 EC2 環境中托管 www.tripadvisor.com 和所有國際域時，我們工程組織的許多成員的回應非常簡單：當我們已經擁有自己的硬件時，真的值得向 Amazon 付錢嗎？ 而且效果還可以嗎？ 幾個月后，隨著我們在云端的偉大實驗即將結束，**答案當然是肯定的，**是。 在這段時間內，我們學到了很多東西，不僅是關于 AWS 的驚人好處和嚴重的陷阱，而且還了解了如何在我們自己的傳統托管環境中改進架構。 盡管我們還沒有準備好翻轉 DNS 并通過 AWS 發送所有流量，但事實證明，它的靈活性是一種非常有用和實用的學習工具！ ## 項目目標 * 使用 EC2 構建整個站點，并演示我們可以獲取生產級流量 * 為此操作建立成本模型 * 確定有助于降低成本和提高可伸縮性的體系結構更改 * 使用此遷移到新平臺可以發現我們當前架構的可能改進。 ## 建筑 我們的目標是為現場站點建立一個功能完備的鏡像，以實現生產級流量。 我們將其稱為“ Project 700k”，因為我們試圖每分鐘處理 700k HTTP 請求，并且具有與我們的實時站點相同的用戶體驗。 用戶體驗將通過請求響應時間統計信息來衡量。 經過大量的擺弄和調整，我們最終提出了以下系統架構： **虛擬私有云**-我們所有的服務器都托管在單個 VPC 或虛擬私有云中。 這是亞馬遜在單個地理區域內提供虛擬網絡的方式（我們碰巧在美國東部弗吉尼亞州，但理論上我們可以在加利福尼亞州，愛爾蘭等地啟動一個全新的 VPC），所有實例都使用私有 IP 相互尋址 。 **子網**-在 VPC 內，我們有兩個子網，為簡單起見，每個子網當前位于同一可用區域中，但我們計劃稍后將它們擴展以實現冗余。 第一個子網具有其安全設置，允許來自 Internet（我們稱為公共子網）的傳入和傳出流量。 第二個私有子網，僅允許來自公共子網的流量。 Public Subnet 包含一個登臺服務器，它使我們可以通過 SSH 進入私有子網，以及一組稍后將要介紹的負載均衡器。 我們所有的服務器，內存緩存和數據庫都位于專用子網中。 **前端和后端服務器**-前端負責接受用戶請求，處理請求，然后向用戶顯示請求的數據，并提供正確的 HTML，CSS 和 javascript 。 前端使用 Java 處理大多數此類處理，并且可以查詢內存緩存或后端以獲取其他數據。 假設服務器正確地進行了負載平衡，那么所有前端的創建方式都是相同的，并且應該承載相似的流量。 后端實例被配置為托管特定服務，例如媒體或度假租賃。 由于這種分布，一些服務器配置為執行多個較小的作業，而其他服務器配置為執行一個較大的作業。 這些服務器還可以進行內存緩存或數據庫調用來執行其工作。 **負載均衡器**-為了充分利用彈性，我們使用 Amazon 的 ELB（彈性負載均衡器）來管理前端和后端服務器。 前端專門屬于一個池，因此僅在一個負載平衡器下列出。 但是，后端可以執行多種服務，因此在多個負載平衡器下列出。 例如，后端可能負責搜索，論壇和社區服務，然后成為這三個負載平衡器的一部分。 之所以可行，是因為每個服務都在唯一的端口上進行通信。 所有前端服務器和后端服務器都配置為發送和接收來自負載平衡器的請求，而不是直接與其他實例進行通信。 **登臺服務器**-另一個登臺實例，我們稱為 stage01x，用于處理進入 VPC 的請求。 它備份代碼庫，收集時序和錯誤日志，并允許 ssh 進入實例。 由于 stage01x 必須位于公共子網中，因此它會從 Amazon 那里獲得一個彈性 IP，該 IP 還在早期階段就將面向公眾的負載均衡器服務于托管在其背后的 AWS 站點。 stage01x 還會維護一個 Postgresql 數據庫，其中包含服務器的主機名和服務。 這在添加新實例并在其整個生命周期內進行管理方面起著至關重要的作用，我們將在后面討論。 ### VPC 站點架構圖  （[原尺寸](http://farm9.staticflickr.com/8450/8044909998_04e8375ef7_o.png)） **示例 HTTP 請求**-為了更全面地了解該體系結構，讓我們逐步瀏覽一下互聯網上的 HTTP 請求（用紅線標出）。 它通過彈性 IP 在作為運行 NGinx 的公共子網中的負載平衡器的登臺實例處進入 VPC。 然后，負載平衡器將流量路由到前端負載平衡器之一。 然后，ELB 重定向到它們后面的前端服務器，這些前端服務器開始處理請求。 在這里，我們有兩個負載均衡級別，可以將請求分為不同的池以進行 AB 測試。 然后，前端服務器決定它需要向后端服務發出請求，該服務也由 ELB 后面的許多后端服務器運行。 后端處理該請求（可能向其他后端發出請求）或數據庫服務器（其結果存儲在內存緩存服務器中），然后將信息發送回前端，該信息通過負載均衡器發回 給用戶。 **實例類型**-EC2 具有極好的可擴展性，因此，使用某些腳本，我們能夠快速更改網絡中后端服務器和前端服務器的數量。 因為所有后端和前端都在負載均衡器后面，所以沒有人需要直接解決它們或知道它們是什么。 但是，數據庫更難擴展，因為它們不在負載均衡器的后面。 可以預料，memcache 會根據實例數和每個實例上的 RAM 對鍵值綁定進行哈希處理，并假定兩者都是固定的。 內存緩存的版本允許添加/刪除成員資格，但是我們目前不在應用程序堆棧中使用它。 因此，memcache 的實時擴展將不是簡單或有效的。 我們為前端，后端和內存緩存實例選擇了 m2.xlarge（超大內存）實例，因為它們具有適當的內存量和較高的 CPU。 我們的數據庫使用 cc2.8xlarge（群集計算八個額外的大實例）實例，這些實例需要極高的 iops 才能處理整個站點的空緩存而導致的冷啟動。 ## 這個怎么運作 **TACL** -我們的前端和后端服務器通過 TACL（TripAdvisor 配置語言）進行配置，TripAdvisor 配置語言描述了如何設置實例。 本質上，我們創建了一個“ aws.ini”文件，該文件定義了在何處發送和接收某些請求。 例如，論壇數據（DEV_DB_FORUMS_HOST）存儲在 dbs001x 上，社區數據（DEV_DB_COMMUNITY_HOST）存儲在 dbs003x 上。 Memcache 實例通過其主機名直接引用。  如前所述，每個前端池和后端服務組由一個負載均衡器表示，我們分別以 lbf 或 lb 作為前綴。  每個需要 aws.ini 中信息的服務器都將其主機名添加到文件頭中。 例如，這就是 web110x 的 aws.ini 文件的標題。 設置 TACL，以便服務器在配置，啟動和提供服務時引用此 aws.ini 文件。 為了進行架構更改（例如添加新數據庫），我們將修改并分發此 aws.ini 文件，并啟動相關實例。 通過這種負載均衡器抽象，添加新的前端和后端實例非常容易，因為它們將被適當的 ELB 包含。 **Naming_service DB** -我們當前的活動站點使用托管在托管數據中心中的物理服務器。 因此，擴展或升級實例非常昂貴且耗時。 使用 Amazon EC2 的主要優勢在于，我們可以廉價，快速地做到這一點，以應對流量的逐分鐘變化。 為了對此進行管理，我們在 stage01x 上保留了一個存儲命名數據庫的數據庫。 由于 EC2 實例具有相對短暫的性質，因此該數據庫對于我們的運營需求至關重要。 我們偶爾會終止實例，并可能啟動替換實例。 開發與此數據庫一起使用的 API 可確保正確“重構”系統，例如，將舊實例從負載均衡器中刪除。 當然，通過啟動新實例進行擴展時，此數據庫是必需的。 它為每個給定的前端和后端實例存儲主機名，實例 ID 和服務。 stage01x 上的腳本用于為新啟動的實例查找和分配主機名。   **定制服務器映像**-我們為前端和后端服務器創建了兩個定制的 CentOS 5.7 映像。 在他們的/etc/rc.local 中，我們添加了一個腳本，該腳本負責完全配置和啟動實例。 啟動后，它將在 stage01x 上的命名數據庫中查詢其主機名和服務，將其添加到適當的負載均衡器中，然后對其進行配置和反彈。 “反彈”是指啟動或重新啟動需要在服務器上運行的應用程序的過程。 我們對這種模塊化的啟動感到特別興奮，因為它使測試后端服務更加容易。 從事度假租賃服務的團隊可以在 EC2 上啟動一個度假租賃實例，并專門在不影響整個測試環境的情況下工作，而不是在一個開發人員的工作站上啟動和啟動整個網站。 **時間和錯誤日志**-我們的前端服務器在接收和處理請求時生成日志。 使用 stage01x 和某些 ssh 隧道傳輸，我們可以遠程壓縮這些日志文件，并將它們發送回本地工作站進行分析。 ## 一路走來的問題 **停電**-2012 年 6 月 15 日，EC2 美東地區發生故障，我們失去了生產力。 2012 年 6 月 29 日，EC2 US-East 發生故障，我們丟失了一些實例。 Amazon 確實提供了可用區（相隔 20 或 30 英里）以實現冗余，因此這會稍微減輕影響。 但是，總的來說，亞馬遜可能會以其數據一致性而不是數據可用性而聞名。 [](http://technewspedia.com/wp-content/uploads/2012/06/6522_Chaiten-660x350.jpg) **磁盤空間不足**-如上所述，我們的服務器生成計時，錯誤和許多其他類型的日志。 在測試的早期階段，我們的日志（尤其是錯誤日志）將快速增長，并占用數 GB 的磁盤空間。 我們決定利用 m2.xlarge 的 420GB 臨時存儲空間。 之前，我們完全避免使用臨時存儲，因為它是臨時存儲（重新啟動后數據不會持續存在）。 但是，這對于存儲日志很好。 Cronjobs 每小時都會將日志發送到本地工作站，因此我們仍然能夠收集和備份重要數據。 [](http://kpao.typepad.com/.a/6a015392891771970b01543663249d970c-pi) **實例不可用**-我們嘗試在 us-east-1b 中使用新的 SSD hi1.4xlarge 實例，但這些實例通常在高峰時段不可用。 我們的 Amazon 聯系人告訴我們，由于需求旺盛，這些實例確實不可用。 我們在 us-east-1d 中遇到了類似的問題，其中我們未能啟動 m1.xlarge 實例。 這提醒我們，EC2 尚不具有無限的服務規模，因此需要在操作模型中建立實例類型及其數量的必需儲備。 作為附帶說明，每個 Amazon AWS 帳戶均以 20 個實例上限開始，隨著我們的實驗的進行，我們需要與我們的 Amazon 聯系人合作以將限制增加到 60 個實例，然后增加到 600 個。 我們的 ELB 遇到了類似的限制。 同樣，我們的聯系很快就使我們獲得了批準，從而使我們可以使用 20-30 個負載均衡器。 [](http://media.amazonwebservices.com/blog/console_ec2_hello_hi1_mndoci_1.png) **未充分利用的，配置錯誤的數據庫**-簡而言之，我們發現我們需要對 postgresql 數據庫（位于 cc2.8xlarge 實例中）進行其他修改，以使其在 EC2 環境中正常工作。 下面列出了其中一些。 這些變化幫助我們了解了自己的環境與亞馬遜環境相比的工作方式。 * enable_hashjoin = off（最初為 on） * enable_mergejoin =關（開） * shared_buffers = 4GB（8GB） * Effective_cache_size = 48GB（16GB） **丟失的數據**-EC2 通過 EBS 卷為數據存儲提供了很好的抽象級別。 為了擴展數據庫實例的存儲，我們只需為每個數據庫實例創建 1 TB EBS 卷，將其附加到實例上，然后使用``mkfs''和``mount''Unix 命令將其裝入。 使用 EBS 卷時，我們遇到了一些問題。 當我們將一個 EBS 卷重新裝載到另一個實例時，在將一個 EBS 卷轉移到另一個實例時，云以某種方式刪除了所有還原的成員數據，我們不得不花半天的時間在該實例上還原數據庫。 此外，在嘗試使用“ tunefs”和“ resize2fs”之類的命令從快照調整 EBS 卷大小時，我們遇到了問題。 使用這些調整大小的卷的實例在一天后遇到實例可達性錯誤，我們不得不運行“ e2fsck”幾個小時來清理它們。 當然，我們在安裝和調整大小過程中可能犯了一些嚴重的錯誤，因此不必過分擔心 EC2 的這種行為。 我們發現，一般來說，AMI 和 EBS 快照的可用性有助于我們快速啟動新的數據庫實例。 例如，如果我們想將 dbs001x 上的數據分成兩臺機器，則只需創建 dbs001x 的映像，從中啟動一個新實例，然后適當地重定向流量。 顯然，此功能僅限于只讀數據庫，創建 1 TB 設備的映像通常是一夜之間的工作。 我們仍在尋找提高數據庫冗余性和可伸縮性的其他方法。 我們當前的實時站點使用心跳和 DRDB 進行恢復，并且希望了解如何將其應用于 EC2。 **不相等的實例**-一方面，我們嘗試對前端和后端服務器的 CPU 性能進行基準測試，所有這些服務器的大小均為 m2.xlarge。 我們使用命令 bc 設置了一個簡單的數學運算 2 ^ 2 ^ 20 的時間，發現該時間分為兩組，具有統計意義。 我們在測試的實例上運行 cpuid，更快的組在雙 2.40 GHz 處理器上運行，而較慢的組在雙 2.66 GHz 處理器上運行。 盡管這不是我們網站功能的主要問題，但它使確定我們可以使用的計算能力變得更加困難。 另外，即使我們的前端計算機都具有相同的大小和相同的 AMI，大約 10％的前端計算機也無法正常彈跳。 同樣，這可能是我們配置而不是 Amazon 的無法預料的問題。 **負數時間**-通常情況下，低俗的時間值得慶祝。 但是，當我們分析一些最近的計時日志時，我們發現某些最小服務呼叫時間為負數。 這些計時統計信息是通過調用 Java.currentTimeMillis（）來計算的。 我們仍在對此進行調查，并且有興趣嘗試通過一個簡單的 Java 應用程序來復制問題。 **竊取周期**-運行 m2.xlarge 實例時，我們預期竊取周期為 1％或 2％。 但是，當前端處于負載狀態時，我們在一兩分鐘內會遇到高達 7-8％的抖動。 我們的 Amazon 聯系人告訴我們，這僅僅是由于每個實例的負載。 另外，我們在 m1.small 實例上進行了實驗，并通過數學計算接管了它的 CPU 使用率。 跑馬場表明，其中 98％用于數學計算，另有 2％被盜。 但是，在 Amazon 的監視服務 Cloudwatch 上，該實例似乎以 98％的 CPU 利用率運行，而不是 100％的全部利用率。 這可能會導致較大的竊用周期問題，因為無法確定某個實例是否由于竊用周期而被用完，或者是否“未充分利用”。 通常，我們希望看到更多有關 CPU 性能的保證。 **組播**-不支持。 我們使用 JGroups，這取決于它的工作。 有人告訴我們使用 vCider 或 vpncubed 來模擬多播。 vCider 要求我們升級到 CentOS 6，并且 vpncubed 的安裝時間很長。 在我們的優先級列表中，該級別較低，但是我們將來希望進一步探索這些選項。 **ELB 延遲**-盡管我們將所有后端置于特定負載均衡器之后的體系結構對于 50-60k reqs / min 以下的流量非常有效，但我們發現 ELB 大大降低了我們的后端響應時間，尤其是對于 二手服務。 為了測試這一點，我們讓一個前端直接將流量發送到后端，而不是通過 ELB。 我們在下午 4:50 左右更改了此設置，使負載測試流量保持不變，并發現服務時間顯著減少。  我們的亞馬遜聯系人告訴我們，ELB 可能需要預熱。 我們懷疑負載平衡器也是云平臺，默認情況下可能是小型實例。 預熱可能只是將這個給定平臺升級為可以處理更高流量負載的平臺的問題。 ## 負載測試 該網站的原始設置存在一些問題。 我們無法在前端使用 Amazon 的 ELB，因為我們的前端實例隱藏在私有 VPC 中。 我們發現有些公司通過將前端實例保留在公共 EC2 網絡中來解決此問題，但是這種架構會使我們的 VPC 設置無效。 我們使用了另一位工程師先前開發的負載測試系統，該系統獲取了真實現場流量的存檔日志，并以一定的請求數/分鐘發送。 最初，我們將此流量定向到 stage01x 實例。 但是，到我們達到 20k reqs / min 時，很明顯我們需要專用的實例來處理流量。 我們將這些實例命名為 lod01x 至 lod04x ，這些實例負責將 HTTP 通信發送到六個前端 ELB。 **VPC 帶寬問題**-在測試的早期階段，我們在 VPC 之外的實例將流量發送到 VPC。 但是，我們發現，無論我們如何擴展站點，負載測試的上限均為每分鐘 5 萬請求。 平均頁面大小為 18KB，看來 VPC 僅接受 100Mbps 的流量。 我們的 Amazon 聯系人向我們保證沒有此限制，但是為了確保所有負載測試都保留在 VPC 中。 **NGinx 問題**-在我們的早期階段，我們還為每個 lod 實例安裝了 NGinx 負載平衡器。 但是，后來發現這成為我們測試的瓶頸，因為小型實例無法處理這么多的“打開文件”。 我們將其抓取，然后將流量直接發送到負載均衡器，而沒有初始的 NGinx 負載均衡。 這是我們網站的配置，最高可達 70 萬請求/分鐘。 在提高請求率的過程中，我們無法保持相同的用戶體驗。 請求響應統計隨著請求率的提高而惡化，我們將在后面詳細討論。  **現場比較**-我們的現場有 80 個前端和 52 個后端，每個都有 24 個核心。 總共增加了 3168 個內核。 在我們的最高 AWS 配置下，每個 270 個前端和 70 個后端分別具有 2 個核心，我們只有 680 個核心。 這導致了后端垃圾回收的問題，我們將在后面討論。 我們的 Amazon 內存緩存的運行情況相當不錯。 我們通過 libmemcached-tools 附帶的 memslap 實用程序進行了基準測試，發現使用 12 個中等的物理服務器，我們最初的 12 個 Amazon memcache 實例的性能大約是我們 Memcache 集群容量的 80-90％。   ## 時間和錯誤編號 每個前端服務器都會自動記錄發送和接收的每個請求的計時數據。 壓縮后每小時發送一次到“伐木工人”服務器，在其中計算基本統計信息，并將請求時間細分為各個部分，例如 google，數據庫和 xml 調用。 在評估站點性能時，我們主要關注平均總時間和 cpu 時間。  （[原尺寸](http://farm9.staticflickr.com/8320/8044985089_c26e7e7a98_o.png)） [ （](http://farm9.staticflickr.com/8320/8044985089_c26e7e7a98_o.png) [全尺寸](http://farm9.staticflickr.com/8310/8044991710_8b0bdfcd23_o.png)） 這兩個圖表顯示了我們從 20k reqs / min 擴展到 60k reqs / min 時，Hotel Reviews Servlet 的時間統計信息（并非所有請求都與酒店評論有關）。 根據數據，向上擴展發生在星期五的 3-4pm 之間，直到 5pm 才穩定下來。 我們關閉了網站過夜，然后在周六中午左右將其恢復，請求數量大約增加了兩倍，請求時間大致保持相同，平均大約 200 毫秒。 在較低的負載下，這些延遲數與我們的實時站點相當，因為我們每分鐘最多擴展 15 萬個請求，因此延遲顯著增加。 我們的主要 servlet（例如，Hotel Reviews 或 Typeahead）的時間比我們的實時站點慢了近 10 倍，后者的運行時間是此請求級別的兩倍，并且在顯示出更高的延遲之前，已經經過了四倍于此請求級別的測試。 ELB 是問題的一部分，如前所述。 但是，我們懷疑根本原因是垃圾回收開銷超過了后端服務器的 CPU 數量。 僅使用兩個內核，我們的 m2.xlarge 實例就沒有足夠的計算能力來跟上高請求速率的 GC 需求，這不足以實現高應用程序吞吐量和低應用程序延遲。 為了解決這個問題，我們很可能需要將后端數量加倍，或者使用功能更強大的實例以及更多的內核。 在這兩種情況下，重點都將放在支持獲得更高請求率并執行更多工作的服務上。 ## 成本 ### EC2 EC2 的付款包括三個主要部分：實例使用情況，EBS 使用情況和網絡輸出使用情況。 在生產級別上假定網絡輸出率為 200 GB /小時，每小時的成本約為 14.30 美元。 可以預見，前端服務器和后端服務器的實例使用對總成本的貢獻最大。 ### 現場比較 我們每個托管數據中心的初始設置約為 220 萬美元，加上每年約 30 萬美元的升級和擴展費用。 如果我們假設初始安裝成本在三年內攤銷，則資本支出每年約為 100 萬美元。 運營支出（包括空間，功率和帶寬）每年約為 30 萬美元。 每個數據中心每年的總成本約為 130 萬美元。 每個數據中心有 200 多臺機器來支持我們的運營。 每臺機器的成本通常為 7,000 美元。 如果我們每年在完整的 EC2 站點上花費 130 萬美元，那么我們可以負擔得起以下架構，前提是我們使用了一年的預留實例。 * 550 前端和后端 * 64 個 Memcache * 10 個數據庫 的價格為$ 1,486,756.96 這意味著我們可以為當前配置添加更多 60％的容量（340 個前端和后端，32 個內存緩存，5 個數據庫）。 如果我們使用三年的預留實例合同，那么這種配置每年將花費 88 萬美元。 如果我們想在三年內花費 390 萬美元，我們可以負擔得起這樣的架構： * 880 前端和后端 * 64 個 Memcache * 20 數據庫 有趣的是，即使有這個數目，我們也只能獲得 1760 個服務器核心（每臺計算機上有 2 個），而我們的現場站點則可以運行 3500 個核心。 **不過，我們有信心，有了這樣的資源，我們將能夠正確解決我們目前在生產級流量**上遇到的垃圾收集和延遲問題。 ### 降低總成本 * 預留實例-我們計算出，僅在 1 年的合同上使用預留實例將使我們的年度總費用減少一半。 我們也不需要為高峰流量保留所有實例，而是利用按需或利用率較低的保留實例來降低總成本。 * 僅將實例調整為必要的容量。 現在，這可以通過啟動不同比例的后端來完成。 * 放置組-在我們知道將永遠存在的實例組之間獲得更好的性能。 ## 故障點 * 前面有某種“類似于 BigIP”的實例。 當這種情況發生時，我們該怎么辦？ * 我們的負載均衡器由 Amazon 管理，當它們出現故障時會發生什么？ 引用完整的 DNS 名稱而不是 IP 地址是有希望的，但這通常是未知的。 * 自動縮放有助于前端池和后端池，確保它們都保持在一定數量。 但是，將內存緩存恢復到命中率將非常耗時，并且我們需要依靠復制的熱備用數據庫。 ## 最佳實踐 * 可以通過 AWS 管理控制臺執行的所有操作都可以通過提供的命令行工具來完成。 準備好**來使**盡可能多的啟動過程自動化。 * 在自動化過程中，請確保**等待足夠長的時間，以使實例既運行又可訪問：** * “ ec2-describe-instances”告訴您實例是否正在運行 * 較新版本的“ ec2-describe-instance-status”會告訴您實例是否已通過實例以及系統可達性狀態檢查 * 早期，**開發了一些用于跟蹤所有實例**的系統。 這與 GUI 問題有關。 盡管您可以使用標簽和名稱來跟蹤所有內容，但通常需要一種更加自動化的方式將所有內容組合在一起。 例如，我們在登臺服務器上有一個 postgresql 數據庫來管理它。 * **停止的實例也可以是終止的實例**。 云計算的優勢在于，當某個實例出現問題時，通常更容易在其位置啟動新實例，而不是重新啟動。 顯然，請嘗試找出潛在的問題！ * 在此注意，請注意，``終止的實例''仍會在您的控制臺中閑逛，并且如果您運行 ec2-describe-instances 將會顯示出來。 如果您使用實例名稱來區分實例，這將是一個問題，因為兩個實例都會出現。 * **清理 EBS 卷**，如站點所建議。 存儲成本會迅速增加。 另外，請確保您清理快照，因為快照的收費與卷的 GB /月價格相同 * **不要忘記短暫存儲**，但不要忘記它的短暫存儲。 對于累積的文件（例如錯誤日志）很有用。 使用 crontabs 保存重要數據。 * **利用圖像和快照快速放大**。 * 詳細的監視非常酷，但是我們發現 CloudWatch / monitoring 的免費層**足夠**。 在 1 分鐘和 5 分鐘之間查看統計信息對于總體擴展決策而言并不那么重要。 但是，當然可以幫助對實例的代表性子集進行詳細監視。 * **ELB 也是監視實例狀態**的好方法，即使它們實際上并沒有使用（在更改架構后我們仍在使用它們）。 適當配置健康檢查/閾值。 * 通過**更加關注安全組設置**，可以解決許多令人沮喪的網絡問題。 時間向后移動是虛擬化的經典問題，特別是如果 VM 從一個物理主機移動到另一物理主機上，或者僅僅是由于 VM 時鐘漂移和重置而造成的。 最好也使用 nanotime API 進行時序實驗-并嘗試查看系統負載是否也很重要-因此生成 IO 和 CPU 負載以查看會發生什么。 如果您可以在測試 VM 的任一端請求其他實例，希望將它們分配在同一物理主機上，則可以查找相關行為 “暫時的（重新啟動后數據不會持續存在）” 臨時磁盤在重新啟動后仍然存在。 當您為實例快照時，它們只是不會被復制。 我在 EC2 上運行 Windows 操作系統，當我重新啟動任何安全補丁時，非啟動驅動器又回來了。 必填： xkcd on the“ Cloud” http://xkcd.com/908/ 很棒的帖子！ 很好地了解了將應用程序完全遷移到云中的成本和收益。 遷移到云+自動化部署的每個部分的另一方面是能夠迫使開發人員在交付給發布代碼流之前，在以 1：1 的生產環境中測試其更改的能力。 自動化整個部署的能力是我對于開發團隊的云所看到的最大好處之一。 感謝您提供的信息非常豐富。 您能否擴展一下創建 TACL 的原因？ TACL 提供的 AWS 缺少什么，或者 TACL 有什么更好的表現？ 我覺得這是一個非常有趣的概念。 我認為您提出了一些很棒的觀點，即 aws 沒有嬰兒規模，有些跌倒了。 我想用負數來解決您的問題，我不確定您是否跟蹤多個實例的時間，希望您設置 ntp 服務器并定期同步服務器。 我工作的一家公司遇到了一個同樣的問題，即日志時間到處都是，因為用戶將訪問一臺后端服務器，并且它將一個時間寫入 db，然后使用會回來，并再次記錄 db，但是因為第一個服務器關閉了時間同步，所以它寫的數量比第二個服務器大 成本模型中缺少的是建立和管理 DC 基礎結構所需的人員。 而且，它只談論核心，沒有網絡成本。 [摘自 PlanForCloud-RightScale]這篇文章啟發我們寫博客文章，比較在 AWS On-Demand 實例與預留實例上 TripAdvisor 的部署成本：http://blog.planforcloud.com/2012/10/tripadvisor-and -pinterest-costs-on-aws.html 非常翔實！ 該實驗需要多長時間才能完成？ 兩個暑期實習生 8 周？ 您好 我們是否可以獲取實時 xml tripadvisor 供稿？ 提前謝謝！ SJ