# AdStage 從 Heroku 遷移到 AWS > 原文： [http://highscalability.com/blog/2017/5/1/the-adstage-migration-from-heroku-to-aws.html](http://highscalability.com/blog/2017/5/1/the-adstage-migration-from-heroku-to-aws.html)  *這是 AdStage 網站可靠性工程負責人 [G Gordon Worley III](https://www.linkedin.com/in/gworley3/) 的來賓[重新發布](https://medium.com/adstage-engineering/migrating-from-heroku-to-aws-our-story-80084d31025e)。* 我在 2013 年秋季加入 [AdStage](https://medium.com/@adstage) 時，我們已經在 Heroku 上運行了。 這是顯而易見的選擇：超級容易上手，比全尺寸虛擬服務器便宜，并且足夠靈活以隨著我們的業務發展。 成長，我們做到了。 Heroku 讓我們僅專注于構建引人注目的產品，而不會分散管理基礎結構，因此，到 2015 年末，我們已同時運行數千個 dynos（容器）以跟上我們的客戶。 我們需要所有這些測功機，因為在后端，我們看起來很像[細分](https://medium.com/@segment)，并且像它們一樣，我們的許多成本[與用戶數量](https://segment.com/blog/the-million-dollar-eng-problem/)成線性比例。 以 25 美元/ dyno /月的價格計算，加上其他技術成本，到 2016 年中期，我們的年度基礎設施支出將突破 100 萬美元，而這占了 COGS 的很大比例，因此要花費數年才能實現盈利。 坦率地說，這種情況是不可持續的。 工程團隊開會討論了我們的選擇，一些快速計算表明我們為 Heroku 的便利每月要支付超過 10,000 美元，而類似資源將直接在 AWS 上花費。 如果我們從 Heroku 遷移，那足以證明工程師專職在基礎架構上工作，因此我的任務是成為我們的第一位運營負責人，并帶頭進行向 AWS 的遷移。 這也是一個很好的時機，因為 Heroku 已成為我們最大的限制。 我們的工程團隊采用了[看板](https://en.wikipedia.org/wiki/Kanban_%28development%29)方法，因此理想情況下，我們會不斷產生從構思到完成的故事。 不過，當時我們正在生成大量正在進行的工作，這些工作通常會阻塞我們的發布渠道。 進行質量檢查的工作很慢，并且經常被送回以進行錯誤修復。 “ [在我的計算機](https://jcooney.net/archive/2007/02/01/42999.aspx)上正常工作”的情況經常出現，但是當暴露在我們的暫存環境中時會失敗。 由于 AdStage 是寫在不同技術堆棧上的相互依賴的服務的復雜組合，因此每個開發人員都很難使其工作站與生產保持最新狀態，這也使得部署到分階段和生產過程很緩慢，需要大量的人工干預 。 但是，我們在此問題上別無選擇，因為我們不得不將每個服務都部署為自己的 Heroku 應用程序，從而限制了自動化的機會。 我們迫切需要找到一種替代方法，使我們能夠自動化部署并為開發人員提供更早的訪問可靠測試環境的機會。 因此，除了通過遷移 Heroku 削減成本外，我們還需要清除質量檢查約束。 否則，我可以自由地設計我們的 AWS 部署，只要它以最少的代碼更改即可運行我們所有的現有服務，但我添加了一些需求： * **簡單的系統管理** ：我以前使用過 Chef 等工具，并希望避免從頭開始頻繁重建系統的容易出錯的過程。 我想通過登錄機器并運行命令來更新機器。 * **無聊** ：我想使用已知有效的“無聊”技術，而不是嘗試一些新技術來解決其問題。 我想將風險集中在業務邏輯而不是基礎架構中。 * **零停機時間** ：在 Heroku 上進行部署往往會導致我們的用戶遇到“漏洞”，原因是某些用戶請求花費的運行時間比 Heroku 允許的連接耗用時間更長。 我希望能夠消除這些斑點。 * **回滾** ：如果部署出現問題，我希望能夠退出部署并使用最新的已知工作版本恢復服務。 * **有限的復雜度** ：我將是唯一一個專職構建和維護我們的基礎架構的人，因此我需要確定項目的范圍以適應需求。 知道 [Netflix](https://medium.com/@NetflixTechBlog) [設法通過](http://highscalability.com/blog/2015/11/9/a-360-degree-view-of-the-entire-netflix-stack.html)[在 AWS 上運行](http://techblog.netflix.com/2013/03/ami-creation-with-aminator.html)數十億美元的業務，沒有比亞馬遜的機器映像和自動縮放組更完美，我決定遵循他們的可靠方法，但絕對沒有 意味著“性感”的方法：構建機器映像，使用它在自動伸縮組中創建實例，將其放在彈性負載均衡器之后，并將負載均衡器連接到 DNS 記錄，以使我們的客戶以及彼此可以訪問它們。 因此，我著手構建我們的 AWS 部署策略。 ### 成為 AWS Sumo 在對系統進行工程設計時，我喜歡花很多時間在進行設計之前先仔細考慮并測試假設。 Rich Hickey 將此稱為[吊床驅動的開發](https://www.youtube.com/watch?v=f84n5oFoZBc)。 我們的辦公室沒有吊床，所以我使用了[相撲躺椅](https://www.sumolounge.com/)。  在 2016 年春季的幾個月中，我思考并思考并整理了 AWS 部署系統的基礎。 它的架構看起來像這樣：  它的核心是我們所謂的 AdStage 統一圖片。 此機器映像用于為所有環境（從開發和測試到過渡和生產）中的所有服務創建實例。 它上面是我們所有存儲庫的副本以及運行它們所需的依賴項。 根據一些實例標簽的值，實例可以以不同的方式出現以反映其用法。 例如，當一個實例以“審閱”模式出現時，所有服務及其從屬數據庫在該實例上一起運行并相互通信。 這樣，進行開發和質量檢查的工程師就可以訪問運行任意代碼版本的完整堆棧的隔離版本。 他們在這些評論框上所做的任何操作都不會影響登臺或制作，也不會與其他評論框進行交互，從而完全消除了我們以前的質量檢查/登臺限制。 另外，只要審核框通過質量檢查，就可以對其進行成像，并將該圖像部署到生產中。 之所以可行，是因為當實例以“登臺”或“生產”模式啟動時，它還會告知其應運行的服務。 這是由實例從其自動伸縮組繼承的標簽確定的，這使我們可以啟動運行相同代碼的實例隊列，以分散客戶的負載。 對于服務于 Web 請求的自動擴展組，它們連接到彈性負載均衡器，該負載均衡器在我們的服務器之間平均分配請求。 負載平衡器為我們提供了一個固定點，我們可以在該固定點上平穩地交換實例，從而實現零停機時間部署，并使回滾就像將舊版本的統一映像保留在備用數據庫中一樣容易交換。 但是，我們使用的 AWS 資源無法完全協調自身，因此我們編寫了一個使用 AWS API 來實現的 Ruby [Thor](https://github.com/erikhuda/thor) 應用程序。 它負責啟動審閱框，構建映像，然后將這些映像部署到暫存和生產環境中。 它會在將負載均衡器切換到新版本之前自動驗證部署是否正常運行，如果部署完成后檢測到問題，則會建議回滾。 它還使用一些巧妙的技巧來協調多個部署并鎖定關鍵資源，以防止多個工程師破壞彼此的部署，因此任何人都可以啟動部署，盡管如果這會引起沖突，他們將被停止。 這涵蓋了我們的所有需求：成像實例使系統管理變得容易，設置很無聊且被廣泛使用，部署過程固有的停機時間為零，支持回滾的部署是自動化的，并且在少于 1500 的情況下并不是很復雜 而且，由于它解決了 QA 約束，并且據我們估計將節省 10,000 美元的運營支出，因此剩下的只是計劃從 Heroku 到 AWS 的實時遷移。 ### 實時遷移 2016 年 7 月是舊金山的典型節日。 大部分時間，霧氣和寒冷的空氣使我一直在里面工作，而在我們辦公室對面的街道上，準備不足的游客在[龍門](https://www.lonelyplanet.com/usa/san-francisco/attractions/dragons-gate/a/poi-sig/383985/361858)上自拍時發抖。 同樣，因為一切都準備從 Heroku 遷移到 AWS，所以我們要做很多工作。 我們的客戶依靠我們來管理他們的廣告活動，自動化他們的廣告支出并報告他們的廣告效果。 當我們陷入困境時，它們又陷入了直接通過網絡界面手動創建和更新廣告的黑暗時代。 當我們切換到 AWS 時，他們負擔不起我們離線的費用，因此我們將不得不進行實時遷移。 或至少與合理生活一樣。 我們實施了 1 周的代碼凍結，并在星期六的早晨找到了 1 小時的窗口，那時我切換了數據庫和其他在運行時不易移動的服務，而 AdStage 進入維護模式。 在準備過程中，我們已經進行了登臺系統的遷移，并編寫了一部劇本，可以用來削減生產。 我使用代碼凍結功能花了一周時間來調整 AWS 部署以匹配 Heroku 部署。 周六上午一切似乎都很好。 我們失敗了，我切斷了數據庫，然后重新啟動了 AdStage。 我花了整整一天的時間看監視器，并靠近鍵盤，以防萬一發生任何問題，但是什么也沒做。 那天晚上我睡著了，以為一切都很好。 在一個 la 懶的星期天早晨之后，我開始在下午收到一些警報，提示我們的進口商正在備份。 當我們研究該問題時，問題很快就變得顯而易見：盡管名義上擁有更多的計算資源，但在某種程度上，我們在 AWS 上的 CPU 數量要少于 Heroku。 結果，我們無法跟上，并且每小時我們都越來越落后。 為了避免隊列溢出，我們不得不降低導入的頻率，最終我們不得不重新打開 Heroku 應用程序以與 AWS 一起運行以跟上工作量。 這與省錢相反。 我們發現，Heroku 一直在告訴我們一個幸福的謊言。 官方每個 dyno 僅獲得 2 個 [ECU](https://aws.amazon.com/ec2/faqs/#What_is_an_EC2_Compute_Unit_and_why_did_you_introduce_it) ，但實際情況是，由于我們 Heroku 上的鄰居沒有充分利用它們的全部份額，我們接近了 6 個。 這意味著我們的 AWS 實例數量太小了 3 倍，盡管 Heroku 實際上便宜得多！ 如果只有一種方法可以為更多實例支付更少的費用…… 那就是我們開始使用競價型實例的時候。 我們曾考慮過使用它們，因為它們的價格約為按需價格的 1/10，但是它們存在一定的風險，因為如果您的底價低于拍賣價，它們可以隨時終止。 幸運的是，這種情況很少發生，否則自動伸縮組會為您管理點實例的復雜性。 另外，如果備份臨時擴展組使用按需部署的按需實例，則很容易，如果我們暫時無法獲得足夠的競價型實例來滿足需求，則可以通過單個命令進行擴展。 我們最終能夠將約 80％的機隊轉換為現場實例，盡管使用的資源比原始預期多了 3 倍，但我們的成本卻降低到了預期目標之內。 ### 結論 除了我們對容量的意外低估外，從 Heroku 切換到 AWS 的過程也很順利。 不過請不要誤會我的意思：這是值得做的，因為我們已經達到了將我們的一些基礎設施運營納入內部的經濟規模才有意義。 如果我們不花至少一名工程師的薪水來購買可以通過轉用 AWS 節省的運營成本，并且如果基礎架構沒有成為核心能力，那么我們將堅持使用 Heroku 并讓那個人（我！）來工??作 在對我們的業務更重要的事情上。 只是由于經濟和流程的變化，從 Heroku 遷移到 AWS 成為了我們的故事的一部分。 Heroku 在 AWS 上運行，因此您不必進行過多的遷移就可以減少中間商。 ...或者您雇用知道如何正確運行數據中心的人員。 感謝您的帖子。 非常有趣，只是有幾個問題：圖像如何獲得其初始配置？ 您提到要避免使用 Chef / Puppet 之類的東西，但是大概您仍然需要一些可重復的過程來使用初始配置來構建 AMI。 那是雷神應用程序的功能嗎？ 您應該嘗試進行性能調整，例如 JVM 調整，線程池調整等，以降低基礎架構成本。 似乎沒有這么多麻煩就節省了很多。 您節省了全職人員成本，但是在 AWS 上通常需要 DevOps 成本，在 Heroku 中，Dev 團隊可以解決。 放大/縮小測功機與 EC2 相比，哪一個更容易？