# Swiftype 如何以及為何從 EC2 遷移到真實硬件 > 原文： [http://highscalability.com/blog/2015/3/16/how-and-why-swiftype-moved-from-ec2-to-real-hardware.html](http://highscalability.com/blog/2015/3/16/how-and-why-swiftype-moved-from-ec2-to-real-hardware.html)  *這是 [Oleksiy Kovyrin](https://twitter.com/kovyrin) 的來賓帖子， [Swiftype](https://swiftype.com/) 。 Swiftype 目前為超過 100,000 個網站提供搜索功能，每月提供超過 10 億個查詢。* 當 Matt 和 Quin 在 2012 年創立 Swiftype 時，他們選擇使用 Amazon Web Services 建立公司的基礎架構。 云似乎是最合適的選擇，因為它很容易在不管理硬件的情況下添加新服務器，并且沒有前期成本。 不幸的是，盡管某些服務（如 Route53 和 S3）最終對我們來說確實非常有用且非常穩定，但使用 EC2 的決定卻在我們成立的第一年困擾了團隊一些主要問題。 Swiftype 的客戶需要卓越的性能和始終可用的可用性，而我們能否提供這些功能在很大程度上取決于我們基礎架構的穩定性和可靠性。 在 Amazon 中，我們**遇到了網絡問題，VM 實例掛起，不可預測的性能下降（可能是由于嘈雜的鄰居共享我們的硬件**，但沒有辦法知道）以及許多其他問題。 無論我們遇到什么問題，亞馬遜始終有相同的解決方案：通過購買冗余或高端服務向亞馬遜支付更多錢。 我們花在解決 EC2 問題上的**時間越多，我們為客戶開發新功能**的時間就越少。 我們知道可以使我們的基礎架構在云中工作，但是要做的工作，時間和資源遠比遷移要大得多。 經過一年的云斗爭，**我們決定將 EC2 保留為真正的硬件**。 幸運的是，這不再意味著要購買您自己的服務器并將它們放在機架中。 托管主機提供商有助于物理硬件，虛擬實例和快速配置之間的良好平衡。 鑒于我們以前在托管服務提供商方面的經驗，我們決定選擇 SoftLayer。 他們出色的服務和基礎架構質量，供應速度以及客戶支持使其成為我們的最佳選擇。 經過一個多月的辛苦工作，準備進行數據中心間遷移，我們能夠以零停機時間執行遷移，并且對客戶沒有負面影響。 **從第一天開始，向真實硬件的遷移就極大地改善了服務的穩定性，為所有關鍵基礎架構組件帶來了巨大的（?2 倍）性能提升，并將每月托管費用降低了約 50％**。 本文將解釋我們如何計劃和實施遷移過程，詳細介紹在過渡后我們看到的性能改進，并為年輕的公司提供有關何時執行此操作的見解。 ## 準備交換機 遷移之前，我們在 Amazon EC2 上有大約 40 個實例。 我們每周至少 2-3 次（有時每天）會遇到嚴重的生產問題（實例中斷，網絡問題等）。 一旦決定遷移到真正的硬件，我們就知道我們的工作已經完成，因為我們需要在不中斷服務的情況下切換數據中心。 準備過程涉及兩個主要步驟，每個步驟在下面的單獨部分中都有專門的解釋： 1. **連接 EC2 和 SoftLayer** 。 首先，我們在 SoftLayer 的數據中心中構建了新基礎架構的骨架（最小的服務器子集，能夠以開發級的負載運行所有關鍵的生產服務）。 一旦建立了新的數據中心，我們就會在新舊數據中心之間建立一個 VPN 隧道系統，以確保兩個數據中心中組件之間的透明網絡連接。 2. **對我們的應用程序**的架構更改。 接下來，我們需要對應用程序進行更改，以使它們既可以在云中也可以在我們的新基礎架構上運行。 一旦應用程序可以同時存在于兩個數據中心中，我們便建立了一條數據復制管道，以確保云基礎架構和 SoftLayer 部署（數據庫，搜索索引等）始終保持同步。 ### 步驟 1：將 EC2 和 Softlayer 連接 為遷移做準備的第一件事之一就是弄清楚如何將 EC2 和 SoftLayer 網絡連接在一起。 不幸的是，使用 EC2 的虛擬私有云（VPC）功能將一套 EC2 服務器連接到另一個專用網絡的“正確”方法對我們來說不是一種選擇，因為如果沒有以下方法，我們無法將現有實例集轉換為 VPC 停機時間。 經過一番考慮和周密的計劃，我們意識到，真正需要能夠跨越數據中心邊界相互連接的唯一服務器是我們的 MongoDB 節點。 我們可以做的其他所有事情都可以使數據中心本地化（Redis 群集，搜索服務器，應用程序群集等）。  由于我們需要互連的實例數量相對較少，因此我們實施了一個非常簡單的解決方案，事實證明，該解決方案對于我們的需求是穩定且有效的： * 每個數據中心中都部署了專用的 OpenVPN 服務器，該服務器將所有客戶端流量 NAT NAT 到其專用網絡地址。 * 每個需要能夠連接到另一個數據中心的節點都將在此處建立 VPN 通道并設置本地路由，以將指向另一個 DC 的所有連接正確轉發到該隧道。 以下功能使我們的配置非常方便： * 由于我們沒有控制任何一方的網絡基礎架構，因此我們無法真正迫使任一端的所有服務器通過連接到另一個 DC 的中央路由器來集中其流量。 在我們的解決方案中，每個 VPN 服務器（在某種自動化的幫助下）決定通過隧道路由哪些流量，以確保所有客戶端的完整 DC 間連接。 * 即使 VPN 隧道崩潰了（令人驚訝的是，這僅在項目的幾周內發生了幾次），這僅意味著一臺服務器失去了與另一 DC 的傳出連接（一個節點從 MongoDB 集群中退出，有些 工作服務器將失去與中央 Resque 框的連接，等等）。 那些一次性的連接丟失不會影響我們的基礎架構，因為所有重要的基礎架構組件的兩端都具有冗余服務器。 ### 步驟 2：對我們的應用程序進行架構更改 在準備遷移的幾周內，我們必須對基礎架構進行許多小的更改，但是對它的每個組成部分都有深刻的了解有助于我們做出適當的決策，從而減少了過渡期間發生災難的可能性 。 我認為，幾乎所有復雜性的基礎架構都可以通過足夠的時間和工程資源進行遷移，以仔細考慮在應用程序和后端服務之間建立的每個網絡連接。  以下是我們為確保平穩透明遷移所必須采取的主要步驟： * 所有無狀態服務（緩存，應用程序集群，Web 層）均獨立部署在每一側。 * 對于每個有狀態后端服務（數據庫，搜索集群，異步隊列等），我們都必須考慮是否要（或可以負擔得起）將數據復制到另一端，或者是否必須引起數據中心間的延遲 對于所有連接。 一直以來，依靠 VPN 一直是最后的選擇，最終我們能夠將數據中心之間的流量減少到一些小的復制流（主要是 MongoDB）以及與無法復制的服務的主/主副本的連接 。 * 如果可以復制服務，則可以這樣做，然后使應用程序服務器始終使用或偏愛該服務的本地副本，而不是轉到另一端。 * 對于我們無法使用其內部復制功能進行復制的服務（例如我們的搜索后端），我們對應用程序進行了更改，以實現數據中心之間的復制，在此數據中心的每一側的異步工作人員都將從各自的隊列中提取數據， 總是將所有異步作業都寫入兩個數據中心的隊列中。 ### 步驟 3：翻轉開關 當雙方都準備好為 100％的流量提供服務時，我們通過將 DNS TTL 降低到幾秒鐘來確保快速的流量變化，為最終的切換做好了準備。 最后，我們將流量切換到新的數據中心。 將請求切換到新基礎架構，對客戶的影響為零。 一旦流向 EC2 的流量耗盡，我們便禁用了舊數據中心，并將所有剩余的連接從舊基礎結構轉發到了新基礎結構。 DNS 更新需要時間，因此在截止時間之后至少一周的時間內，我們的舊服務器上會看到一些剩余流量。 ### 明顯的改進：從 EC2 遷移到實際硬件后的結果 **穩定性提高了**。 每周我們要避免 2-3 次嚴重的故障（大多數故障對于客戶而言是不可見的，因為我們盡了最大的努力使系統能夠應對故障，但是許多故障會喚醒某人或迫使某人放棄家庭時間） 每月 1-2 次中斷，我們可以通過花費工程資源來提高系統對故障的適應性，并減少故障對我們客戶可見的可用性產生影響的機會，從而更徹底地處理故障。 **性能提高了**。 多虧了 SoftLayer 提供的現代硬件，我們看到了所有后端服務（尤其是 IO 綁定的服務，例如數據庫和搜索集群，但也有 CPU 綁定的應用程序服務器）的性能持續提高，更重要的是， 性能更可預測：沒有與我們的軟件活動無關的突然下降或上升。 這使我們可以開始進行實際容量規劃，而不必在所有性能問題上拋出更慢的實例。 **成本降低**。 最后，但同樣重要的是，對于一家年輕的初創公司而言，我們的基礎架構每月成本下降了至少 50％，這使我們能夠過度配置某些服務，從而進一步提高性能和穩定性，從而使客戶受益匪淺。 **供應靈活性提高了，但是供應時間卻增加了**。 現在，我們可以精確地指定服務器以滿足其工作量（大量磁盤并不意味著我們需要功能強大的 CPU）。 但是，我們無法再通過 API 調用在幾分鐘內啟動新服務器。 SoftLayer 通常可以在 1-2 個小時內將新服務器添加到我們的機隊中。 對于某些公司來說，這是一個很大的折衷，但是對于 Swiftype 來說，這是一個很好的選擇。 ## 結論 [ 自從改用真正的硬件以來，我們有了長足的發展-我們的數據和查詢量增長了 20 倍-但我們的 API 性能比以往任何時候都要好。 確切了解服務器的性能將使我們以前所未有的方式規劃增長。 根據我們的經驗，當您需要快速啟動新硬件時，云可能是個好主意，但只有在您做出巨大努力（Netflix 級）以在其中生存時，它才能很好地工作。 如果您的目標是從一開始就建立企業，而您又沒有多余的工程資源可用于支付“云稅”，那么使用真實的硬件可能是一個更好的主意。 *如果您對軟件和基礎架構交叉領域的工程技術充滿熱情，Swiftype 將聘請高級技術運營工程師。* [關于黑客新聞](https://news.ycombinator.com/item?id=9212467) [上 reddit](http://www.reddit.com/r/programming/comments/2z9xwp/how_and_why_swiftype_moved_from_ec2_to_real/) 很棒的文章。 我只需要添加 Google 工程師的一些明智的話即可（我忘了看到它的地方，但一定是演示文稿）：不要期望在距離上同步復制數據。 編碼應用程序以解決此問題是更好的方法。 您可能會失去性能，但最終不會出現數據不一致的情況 嗨，有趣的文章，您使用的實例類型和操作系統是什么？ 您使用的是原始 AMI 還是其他東西？ 每當我看到公司何時離開亞馬遜并經歷成本下降時，我都會大笑和哭泣：)我來自波蘭，但是許多國家/地區都有自己的云服務提供商，因此每個人都應該檢查他們，然后再尋求更大的參與者。 我為數百個客戶和平均值進行了許多計算。 波蘭云與亞馬遜的成本比較表明，亞馬遜的價格比我選擇的提供商高 7 到 20 倍。 我知道這些提供商無法擴展到 1000Gbps 或 PB 數據，但是如果人們遇到網絡問題和性能下降，他們仍然使用如此糟糕的提供商真是可笑。 我為幾天的活動做了很多設置，并且它總是像魅力一樣發揮作用。 兩種設置工作了幾個月（一切都按計劃進行），我沒有遇到任何問題。 你們有什么特殊的原因要選擇 DigitalLacean 而不是 SoftLayer。 根據 DigitalOcean 網站的性能基準，它們便宜 90％，但性能更好。 只是好奇。 有趣的帖子，Oleksiy。 我自己廣泛使用 EC2 和 Softlayer，得出了不同的結論。 Softlayer 的后端網絡并不如我所愿穩定。 我曾嘗試在其中運行分布式文件系統（例如 glusterfs），但不得不放棄-網絡太不可靠了。 盡管值得，但 Ceph 能夠更好地應對夜晚的顛簸，但它們仍然存在。 上次我檢查（最近幾個月內）無法從 SL 獲得 10G 網絡。 它來自 EC2。 此外，如果您自己想要一臺服務器，這是相當普遍的常識，您可以在 EC2 上配置哪些實例大小。 很高興到目前為止您的客戶服務經驗非常好。 物理服務器的問題之一是發生故障，并且在租用服務器時，您會被這些位卡住。 打開故障單，嘗試更換驅動器/任何部件，希望支持技術人員能夠充分了解并進行處理，而不是嘗試進行故障排除并告訴您系統是否正常。 我建議您記住短語“請升級”，并毫不猶豫地使用它。 在云環境中，您將啟動一個新實例并恢復工作，讓其他人處理硬件問題。 也就是說，與 EC2 相比，通過電話從 SL 中找到某人要容易得多。 :) 您沒有提到的一件事是，如果您想在 SL 獲得合理的價格，則需要從銷售代表處獲取報價。 根據我的經驗，這通常會大大降低系統的價格。 我認為最重要的是，如果您要為云構建應用程序，則需要設計一個解決方案，該解決方案在 Amazon 重新啟動您所使用的系統時不會崩潰。 但是，這不是唯一的情況-實例崩潰比服務器崩潰要痛苦得多。 很高興為您解決！ 眾所周知，Netflix 擁有 EC2 上所有最好的服務器。 他們引導 30,000 臺計算機并運行性能測試，然后僅保留前 5％的數據并關閉所有其他實例。 但是，請注意，您的開發團隊可能經驗不足，無法充分利用 EC2。 Netflix 和 Reddit 在 EC2 上運行沒有問題。 當您談到降低成本時，你們與 SoftLayer 達成任何特別交易，合同等嗎？ 還是僅通過支付公共價格表就可以從 AWS 跳到 SoftLayer？ 由于 Softlayer 確實是 IBM 的事實，他們可能確實獲得了更好的交易。 我認為對于 Netflix 和 reddit，他們肯定可以通過聯系人訪問特殊服務器。 我不確定為什么甚至可以與數字海洋進行比較，我們不要忘記 softlayer 托管了 whatsapp。 對于如此大的環境，停機率令我感到驚訝。 該基礎結構是作為現代臨時和自動伸縮堆棧實現的，還是傳統堆棧設計？ 我已經管理了 AWS 中成千上萬個節點的平臺，故障率低得多。 沒有任何基礎設施是完美的。 我想知道該平臺在傳統環境中的長期故障率，尤其是 MTTR。 此外，在較慢的物理環境中進行創新的機會成本是多少？ 我們在 EC2 上運行了 14K 實例。 如果僅在 40 個實例上看到 VM 掛起等問題，則不確定部署是否正確。 這種遷移對于小型環境是可行的。 除了 AWS 或自己推出自己的服務以外，沒有太多其他用于大規模操作的選項 我希望您也殺了您的主要帳戶。 :)