摘要：雲時代，在面對雲廠商高額的成本時，放棄雲服務採用內部基礎設施進行替換是否是更合適的選擇？
原文連結：
https：//levelup。gitconnected。com/how-we-reduced-our-annual-server-costs-by-80-from-1m-to-200k-by-moving-away-from-aws-2b98cbd21b46
宣告：本文為 CSDN 翻譯，未經允許禁止轉載。
作者 | Trey Huffine譯者 | 彎月 責編 | 辛曉亮
出品 | CSDN（ID：CSDNnews）
在本文中，我們採訪了 Prerender。io 的首席工程師兼經理 Zsot Varga。他跟我們分享了一個真實的小故事：他們放棄了AWS，並構建了內部基礎設施來處理流量和快取資料，從而將伺服器每年的費用從100萬美元降低到了20萬美元。
“我們的目標是降低成本，同時保持渲染速度和服務質量不變。這類的遷移需要仔細計劃和認真執行，配置不正確或執行不給力就會導致客戶網頁和社交媒體宕機，影響他們的網路搜尋排名，也會導致我們的客戶流失。”
需要解決的技術問題
簡單來說，我們的產品Prerender會快取和預渲染JavaScript頁面，這樣搜尋引擎就可以抓取和索引一個純HTML檔案，你只需要在網站上安裝適當的中介軟體，就可以避免使用昂貴且冗長的JavaScript解決方案。
但是，所有這些資料和流程都需要在伺服器上處理，為此以前我們使用的是AWS。經過幾年的發展，如今我們每分鐘需要處理的頁面超過了7萬，儲存的頁面高達5。6 億，因此而產生的AWS費用也高達一百萬美元。
繼續使用AWS，我們就需要持續承擔如此高昂的費用。相反，我們花了三個月的時間，透過一些現成的思路和一個清晰的計劃，削減了80%的成本。
遷移計劃
之前，我們使用的是託管在亞馬遜的AWS之上的伺服器，用於儲存客戶快取和呈現的頁面。眾所周知，AWS是目前最大的雲提供商之一，提供虛擬伺服器和託管服務。
我們利用AWS來儲存快取頁面，然後供Google、Facebook以及其他搜尋引擎查詢或抓取。我們的產品Prerender的主要功能就是向Google以及其他搜尋引擎提供靜態的HTML頁面，向人類使用者提供動態的互動式 JavaScript。
我們所面臨的問題是，將大量（TB級）的預渲染網頁儲存到第三方伺服器上產生了鉅額的費用。透過這種方式儲存快取頁面，導致我們所需承擔的維護和託管費接近天文數字。
此外還有一個問題，很多初創公司都沒有考慮到，也沒有太多相關的話題引發討論，那就是流量成本。
將資料匯入 AWS 是免費的，但對於大多數軟體來說，靜態資料並沒有什麼用。但移動這些資料會產生鉅額成本，而這將成為我們前進道路上的瓶頸。
那麼，該怎麼解決呢？我們的計劃是，將快取的頁面和流量遷移到自己內部的伺服器上，並儘快減少對AWS的依賴。
我們預估了一下成本，發現可以將託管費用降低 40%，而且此次伺服器遷移不僅可以節省我們的成本，也可以為客戶省錢。
我們的目標是降低成本，同時保持渲染速度和服務質量不變。這類的遷移需要仔細計劃和認真執行，配置不正確或執行不給力就會導致客戶網頁和社交媒體宕機，影響他們的網路搜尋排名，也會導致我們的客戶流失。
為了避免可能出現的問題，我們的計劃包含三個階段。如果出現任何問題，我們可以輕鬆地退回到前一個階段。如果由於某種原因導致新伺服器無法工作，我們也可以輕鬆地回滾，而不會出現任何停機或影響到客戶的服務降級。
我們需要謹慎地執行系統測試，而且這是一個持續的過程，可能需要數週或數月的時間。
遷移過程
第一階段：測試（4～6周）
第一階段的主要工作是設定裸機伺服器，在小規模且易於管理的機器上測試遷移，然後再擴大規模。這個階段沒有太多修改軟體的需求，我們決定在Linux的KVM虛擬機器上執行伺服器。
5 月初，我們的第一批伺服器開始執行，1%的流量被定向到新伺服器。遷移兩週後，我們每天的費用節省了800美元。5月底，我們已將大部分流量工作負載從 AWS 遷移出去，渲染工作負載的成本降低了 45%。
伺服器每月的成本降到了13，000 美元，與AWS相比，開支已經削減了 22%。
測試階段對於確保今後流程的順利執行至關重要。我們付出了巨大努力，設法透過更多的監控和更好的錯誤處理來提高系統的穩健性。除了已有的伺服器監控儀表板外，我們還設定了一個新的渲染監控儀表板，以便發現錯誤或效能問題。
多虧了持續的監控和清晰的溝通，我們的測試成功了，最終能節省的成本已超出了預期。一切準備就緒，我們開始向第二階段邁進。
第二階段：技術遷移（4周）
6月～7月初，我們以第一階段的遷移作為概念驗證，在此基礎之上進行技術方面的遷移。第二階段的主要工作是將快取儲存移動到裸機伺服器。
6 月中旬，我們搭建了300臺伺服器，並開始順暢執行，快取頁面總數達到 2 億。我們的每臺伺服器上都使用了 Apache Cassandra 節點（與AWS S3相容）。
我們將線上遷移分為四個步驟，每個步驟相隔1～2周。在測試了頁面是否可以同時快取在 S3 和 minio 中之後，我們慢慢地將流量從 AWS S3 切換到minio。在向S3的寫入完全停止後，我們每天省下了200美元的成本（使用S3 API的費用）。也就是說，我們現在可以刪除快取在 Cassandra 叢集中的資料了。
6月24日，第二階段的工作暫告一段落，這時我們的成本驟降。在這之前的四個星期裡，我們將大部分快取工作負載從 AWS S3 轉移到了我們自己的 Cassandra 叢集。隨之而來的是，AWS每天的開銷降至1，100美元，預計每月3。5萬美元，而新伺服器的每月經常性成本約為1。4萬美元。
當時，S3仍留有一些資料，每天的開銷約為60美元，而且會在接下來的幾周內逐漸消失。儘管我們本可以將所有資料移出，將成本立即削減成零，但將資料移出 AWS 需要一次性支出5000美元，這筆錢花得有點冤。
移動資料是我們遇到的巨大瓶頸，我們的新CTO Zsolt Varga表示：
“ASW真正的坑在於流量成本，他們的儲存費用非常合理，甚至可以免費上傳。但是當你將資料拿出來的時候，就需要付出巨大的代價。”
“小型創業公司通常不會計算流量成本，儘管這筆費用有可能佔到總成本的90%。”
舉個例子，假設你在美國西部地區（比如俄勒岡），那麼必須支付的流量成本為0。080 美元/GB，而在亞太地區（比如首爾）則需要支付0。135 美元/GB。
而對於我們，每月的流量成本輕輕鬆鬆就能達到3萬～5萬美元。在第二階段結束時，我們的伺服器每月的總成本降低了 41。2%。
第三階段：實現和擴充套件（4～6周）
到這一階段，遷移工作進行得很順利，而且我們已經節省了大量資金。剩下的工作是將所有其他資料遷移到本地的伺服器上。
這個階段我們需要移動所有的亞馬遜RDS示例。這是整個過程中最容易出錯的部分，但是由於很大一部分資料已經遷移完了，因此任何故障或瓶頸都不會導致整個遷移崩潰。
以下是我們在遷移過程的最後階段所需完成的工作：
將儲存cached_urls表的PostgreSQL分片映象到Cassandra；
將 service。prerender。io 切換到 Cloudflare 負載均衡器，以允許動態流量分配；
建立新的歐盟私人快取伺服器；
反覆進行壓力測試，解決任何效能問題。
最終結果證明，此次遷移取得了巨大的成功。當所有快取頁面都被重定向後，我們每月的伺服器費用下降到最初預估的40%～80%。
我們獲取的經驗教訓
如果在此過程中遇到任何問題或實際的工作進展落後於計劃，伺服器遷移都將面臨很多風險。因此，我們在遷移的每個階段都設計了故障保險，以確保出現問題時我們可以回到上一步。這也是我們在全面遷移之前，實施了一系列小規模測試的原因。
為了規避風險，我們仔細規劃了遷移的每個階段，在擴充套件之前測試了每個實施階段，並在出現問題時及時修復。這樣，我們不僅大幅降低了伺服器的費用，而且將所有潛在風險降至最低。
遷移伺服器的動力
如你所見，客戶可以利用我們的產品推出以使用者體驗為中心的網站，他們的工作重心是為客戶提供最好的服務，而不是設法最佳化SEO。在過去的幾年裡，每當建立一個新頁面，我們都需要利用Wordpress，僅僅是為了獲得最好的 SEO，而只把管理介面等需要SPA的功能留給未索引的頁面。但如今，我們可以幫助客戶解決過去的這些難題。
技術棧的選擇
Javascript的使用範圍非常廣泛，由於我們解決了Javascript 渲染引起的“問題”，因此我們希望在這個領域積累儘可能多的專業知識。我們利用CloudFlare的分散式系統，實現了快速響應和全球擴充套件。在Digital Ocean雲平臺的支援下，我們可以保障正常的執行時間。此外，我們還使用了很多其他 SaaS 提供商來最大限度地提高我們的效率。
—