大規模效率：AWS 成本優化的故事

已發表: 2022-07-22

我最近推出了一個加密貨幣分析平台，預計每日用戶數量很少。 然而，當一些受歡迎的 Y​​ouTube 用戶發現該網站有幫助並發表評論時，流量增長如此之快以至於服務器超載，平台 (Scalper.AI) 變得無法訪問。 我原來的 AWS EC2 環境需要額外的支持。 在考慮了多種解決方案後，我決定使用 AWS Elastic Beanstalk 來擴展我的應用程序。 事情看起來不錯並且運行順利，但我對計費儀表板中的成本感到吃驚。

這不是一個不常見的問題。 2021 年的一項調查發現，82% 的 IT 和雲決策者遇到了不必要的云成本，86% 的人認為他們無法全面了解所有云支出。 儘管亞馬遜在其文檔中提供了額外費用的詳細概述，但定價模型對於一個成長中的項目來說是複雜的。 為了讓事情更容易理解，我將分解一些相關的優化來降低您的云成本。

為什麼我選擇 AWS

Scalper.AI 的目標是收集有關加密貨幣對（在交易所交易時交換的資產）的信息，運行統計分析，並為加密交易者提供有關市場狀況的見解。 平台的技術架構由三部分組成：

  • 數據攝取腳本
  • 網絡服務器
  • 一個數據庫

攝取腳本從不同來源收集數據並將其加載到數據庫中。 我有使用 AWS 服務的經驗，因此我決定通過設置 EC2 實例來部署這些腳本。 EC2 提供了許多實例類型，讓您可以選擇實例的處理器、存儲、網絡和操作系統。

我選擇 Elastic Beanstalk 來實現其餘功能，因為它保證了流暢的應用程序管理。 負載均衡器在我的服務器實例之間正確分配負載，而自動縮放功能處理添加新實例以增加負載。 部署更新變得非常容易，只需幾分鐘。

Scalper.AI 運行穩定，我的用戶不再面臨停機。 當然，由於我增加了額外的服務，我預計支出會增加，但數字比我預期的要大得多。

我如何能夠降低云成本

回顧過去，我的項目使用 AWS 服務有很多複雜的地方。 我們將檢查我在使用常見 AWS EC2 功能時發現的預算優化：突發性能實例、出站數據傳輸、彈性 IP 地址以及終止和停止狀態。

突發性能實例

我的第一個挑戰是支持我不斷增長的項目的 CPU 功耗。 Scalper.AI 的數據攝取腳本為用戶提供實時信息分析； 這些腳本每隔幾秒鐘運行一次，並為平台提供來自加密貨幣交易所的最新更新。 此過程的每次迭代都會生成數百個異步作業，因此站點增加的流量需要更多的 CPU 能力來減少處理時間。

AWS 提供的具有四個 vCPU 的最便宜的實例 a1.xlarge 當時每月花費我大約 75 美元。 相反，我決定在兩個 t3.micro 實例之間分散負載，每個實例有兩個 vCPU 和 1GB RAM。 t3.micro 實例為我需要的工作提供了足夠的速度和內存，而成本僅為 a1.xlarge 的五分之一。 儘管如此，我的賬單仍然比我在月底的預期要大。

為了理解原因，我搜索了亞馬遜的文檔並找到了答案：當實例的 CPU 使用率低於定義的基線時，它會收集積分，但當實例突然超過基線使用率時，它會消耗之前獲得的積分。 如果沒有可用的積分，該實例將使用 Amazon 提供的“剩餘積分”。 這種賺取和花費積分的能力導致 Amazon EC2 平均 24 小時內實例的 CPU 使用率。 如果平均使用量高於基線，則實例按每個 vCPU 小時的統一費率額外計費。

我對數據攝取實例進行了多天的監控，發現我的 CPU 設置（旨在降低成本）卻適得其反。 大多數時候，我的平均 CPU 使用率高於基線。

圖表在屏幕頂部選擇了三個下拉選項。左邊的前兩個是“2022 年 2 月 10 日 - 2022 年 2 月 19 日”和“每日”，然後是一個帶圓圈的小“i”。第三個位於屏幕右側，顯示“Line”，帶有折線圖符號。在下拉選項下方，圖表包含兩個帶有過濾器的折線圖。在頂部，過濾器行顯示“分組依據：使用類型”（選定的過濾器，具有藍色背景），然後顯示未選擇的過濾器：“服務、關聯賬戶、區域、實例類型、資源、成本類別、標籤、更多”，其中“資源”灰顯，最後三個旁邊有下拉箭頭。最上面的折線圖在 y 軸上有“成本 ($)”，範圍從 0.0 到 2.5。底線圖在 y 軸上有“使用情況（vCPU-小時）”，範圍從 0 到 40。兩個線圖共享標記在 x 軸上的日期，範圍從 2 月 10 日到 2 月 19 日，以及一個鍵標記他們的紫色線條：“USE2-CPUCredits：t3。”最上面的折線圖大約有八個點呈線性連接，並且隨著時間的推移呈上升趨勢：一個點在（2 月 10 日，0.3 美元）左右，第二個在（2 月 11 日，0.6 美元）左右，第三個在（2 月 12 日，0.5 美元）左右，一個第四左右（2 月 14 日，2.1 美元），第五次左右（2 月 15 日，2.4 美元），第六次左右（2 月 16 日，2.3 美元），第七次左右（2 月 18 日，2.3 美元），第八次左右（2 月- 19 美元，2.6 美元）。底線圖也有大約八個點呈線性連接並且隨著時間的推移呈上升趨勢：一個點大約（2 月 10 日，5 個 vCPU 小時），第二個點（2 月 11 日，15 個 vCPU 小時），第三個點（2 月-12, 10 vCPU-Hours), 四分之一左右 (Feb-14, 40 vCPU-Hours), 五分之一左右 (Feb-15, 50 vCPU-Hours), 六分之一左右 (Feb-16, 45 vCPU-Hours) ，七分之一左右（2 月 18 日，45 個 vCPU 小時），八分之一左右（2 月 19 日，55 個 vCPU 小時）。
上圖顯示了 CPU 使用率高於基線期間的成本激增（上圖）和增加的 CPU 積分使用率（下圖）。 美元成本與花費的剩餘積分成正比，因為實例按 vCPU 小時計費。

我最初分析了幾個加密貨幣對的 CPU 使用情況； 負載很小，所以我認為我有足夠的成長空間。 （我只使用了一個微實例進行數據攝取，因為更少的加密貨幣對不需要那麼多的 CPU 能力。）然而，一旦我決定讓我的見解更全面並支持數據的攝取，我就意識到我最初分析的局限性對於數百個加密貨幣對——除非以正確的規模執行，否則云服務分析毫無意義。

出站數據傳輸

我的網站擴展的另一個結果是由於一個小錯誤而增加了從我的應用程序傳輸的數據。 隨著流量穩步增長並且沒有更多的停機時間，我需要添加功能以盡快吸引並吸引用戶的注意力。 我的最新更新是當加密貨幣對的市場條件與用戶的預定義參數匹配時觸發的音頻警報。 不幸的是，我在代碼中犯了一個錯誤，音頻文件每隔幾秒就會加載到用戶的瀏覽器中數百次。

影響是巨大的。 我的錯誤從我的網絡服務器生成了音頻下載，導致額外的出站數據傳輸。 我的代碼中的一個小錯誤導致賬單幾乎是以前的五倍。 （這不是唯一的後果：該錯誤可能導致用戶計算機中的內存洩漏，因此許多用戶不再回來。）

與上一張類似的圖表，但第一個下拉菜單顯示“2022 年 1 月 6 日 - 2022 年 1 月 15 日”，頂部折線圖的“成本 ($)”範圍為 0 到 30，底部折線圖具有“使用情況 (GB)”在 y 軸上，範圍從 0 到 300。兩個折線圖共享在 x 軸上標記的日期，範圍從 Jan-06 到 Jan-15，以及標記紫色線的鍵：“USE2-數據傳輸輸出字節。”最上面的折線圖大約有八個點呈線性連接，並且隨著時間的推移呈上升趨勢：一個點在 (Jan-06, $2) 左右，第二個點在 (Jan-08, $4) 左右，第三個點在 (Jan-09, $7) 左右，a第四次（1 月 10 日，6 美元），第五次（1 月 12 日，15 美元），第六次（1 月 13 日，25 美元），第七次（1 月 14 日，24 美元），第八次（1 月- 15 美元，29 美元）。底線圖也有大約八個點呈線性連接並隨著時間的推移呈上升趨勢：一個點在 (Jan-06, 10 GB) 左右，第二個點在 (Jan-08, 50 GB) 左右，第三個點在 (Jan-09, 80 GB），第四個左右（Jan-10, 70 GB），第五個左右（Jan-12, 160 GB），第六個左右（Jan-13, 270 GB），第七個左右（Jan-14, 260 GB）和八分之一左右（1 月 15 日，320 GB）。
上圖顯示了成本激增（上圖）和增加的出站數據傳輸（下圖）。 由於出站數據傳輸按 GB 計費，因此美元成本與出站數據使用量成正比。

數據傳輸成本可佔 AWS 價格飆升的 30% 以上。 EC2 入站傳輸是免費的，但出站傳輸費用按每 GB 計費（我構建 Scalper.AI 時每 GB 0.09 美元）。 正如我在艱難中學到的那樣，對影響出站數據的代碼保持謹慎是很重要的。 盡可能減少下載或文件加載（或仔細監控這些區域）將保護您免受更高的費用。 由於將數據從 EC2 傳輸到 Internet 的費用取決於工作負載和特定於 AWS 區域的費率，因此這些便士加起來很快。 許多新 AWS 客戶不知道的最後一個警告：不同位置之間的數據傳輸變得更加昂貴。 但是，使用私有 IP 地址可以避免在同一區域的不同可用區之間產生額外的數據傳輸成本。

彈性 IP 地址

即使使用彈性 IP 地址 (EIP) 等公共地址，也可以降低您的 EC2 成本。 EIP 是用於動態雲計算的靜態 IPv4 地址。 “彈性”部分意味著您可以將 EIP 分配給任何 EC2 實例並使用它，直到您選擇停止。 這些地址可讓您通過將地址重新映射到您賬戶中的不同實例來無縫地將不健康的實例與健康的實例交換。 您還可以使用 EIP 為域指定 DNS 記錄，使其指向 EC2 實例。

AWS 每個區域的每個賬戶僅提供五個 EIP，這使其資源有限且成本高昂且使用效率低下。 如果您在一個月內重新映射 EIP 超過 100 次，AWS 會為每個額外的 EIP 收取較低的小時費率和額外費用； 保持在這些限制之下將降低成本。

終止和停止狀態

AWS 提供了兩個選項來管理正在運行的 EC2 實例的狀態：終止或停止。 終止將關閉實例，為其配置的虛擬機將不再可用。 任何附加的 Elastic Block Store (EBS) 卷都將被分離和刪除，並且本地存儲在實例中的所有數據都將丟失。 您將不再為該實例付費。

停止實例是類似的，只是有一點不同。 附加的 EBS 卷不會被刪除，因此它們的數據會被保留，您可以隨時重新啟動實例。 在這兩種情況下，Amazon 不再對使用實例收費，但如果您選擇停止而不是終止，只要 EBS 卷存在，它們就會產生成本。 AWS 建議僅在您希望盡快重新激活實例時才停止該實例。

但是有一個功能可以在月底擴大您的 AWS 賬單，即使您終止了一個實例而不是停止它：EBS 快照。 這些是存儲在 Amazon 簡單存儲服務 (S3) 中的 EBS 卷的增量備份。 每個快照都包含您使用以前的數據創建新 EBS 卷所需的信息。 如果您終止一個實例，其關聯的 EBS 卷將被自動刪除，但其快照將保留。 由於 S3 是按存儲的數據量收費的，因此如果您短期內不使用這些快照，我建議您刪除它們。 AWS 能夠使用 CloudWatch 服務監控每個卷的存儲活動：

  1. 登錄 AWS 控制台後，從左上角的服務菜單中，找到並打開 CloudWatch 服務。
  2. 在頁面左側的Metrics可折疊菜單下，單擊All Metrics 。
  3. 該頁面顯示具有可用指標的服務列表，包括 EBS、EC2、S3 等。 單擊EBS ，然後單擊Per-volume Metrics 。 （注意：只有在您的賬戶上配置了 EBS 卷時， EBS選項才可見。）
  4. 單擊查詢選項卡。 在編輯器視圖中，複製並粘貼命令SELECT AVG(VolumeReadBytes) FROM "AWS/EBS" GROUP BY VolumeId ，然後單擊運行。 （注意：CloudWatch 使用具有獨特語法的 SQL 方言。）

頁面頂部出現一個帶有深藍色標題菜單的網頁，從左到右包括 aws 徽標、“服務”下拉菜單、搜索欄、代碼圖標、鈴鐺圖標、問號圖標、下拉文本閱讀“N. Virginia”，下拉文本閱讀“Toptal 測試帳戶”。在下面，我們看到網頁的主要部分是白色的。頁面左側有一個滾動菜單，標題為“CloudWatch”和一個“X”。在下方，從上到下，菜單顯示：“收藏夾和最近”、“儀表板”、“警報”（粗體，帶有三個下拉菜單：“警報中”、“所有警報”和“計費”）， “日誌”（粗體，帶有兩個下拉菜單：“日誌組”和“日誌洞察”），“指標”（粗體，帶有三個下拉菜單：“所有指標”，以亮橙色突出顯示，“ Explorer”和“Streams”）、“X 射線跟踪”（粗體）、“事件”（粗體）和“應用程序監控”（粗體）。菜單中的所有粗體文本在文本左側都有一個下拉菜單三角形。網頁的中部在頁面的上半部分顯示一個圖表，在頁面的下半部分顯示一個編輯器。該圖有兩行標題。第一行左側顯示“CloudWatch > Metrics”（藍色顯示“CloudWatch”文本），右側顯示藍色顯示“切換到您的原始界面”。第二行顯示“Untitled graph”，左側有一個編輯圖標，右側顯示選項：“1h, 3h, 12h, 1d, 3d, 1w, Custom”（“3h”為藍色，“Custom”帶有日曆圖標）、“行”（帶有下拉圖標）、“操作”（帶有下拉圖標）和帶有下拉圖標的刷新按鈕。圖表本身在其中心顯示文本：“您的 CloudWatch 圖表為空。選擇一些指標以顯示在此處。”編輯器還有兩行標題。第一行在左側顯示“瀏覽”、“查詢”（以橙色突出顯示）、“圖表指標”、“選項”和“來源”，以及“添加數學”（帶有下拉圖標）和“添加查詢”（帶有下拉圖標）在右側。第二行左側為“Metrics Insights - query editor”和“Info”（藍色），右側為“Builder”和“Editor”（選擇了“Editor”）。編輯器下方左側是橙色的“運行”按鈕，右側是文本“使用 Ctrl + Enter 運行查詢，Ctrl + Space 自動完成”。網頁右側有一個白色菜單，從上到下分別為“查詢”和“幫助”。
上述 CloudWatch 監控設置的概述（顯示為空數據且未選擇任何指標）。 如果您的賬戶上有現有的 EBS、EC2 或 S3 實例，這些實例將顯示為指標選項並填充您的 CloudWatch 圖表。

CloudWatch 提供了多種用於分析存儲活動的可視化格式，例如餅圖、折線圖、條形圖、堆積面積圖和數字。 使用 CloudWatch 識別非活動 EBS 捲和快照是優化云成本的一個簡單步驟。

口袋裡有多餘的錢

儘管 CloudWatch 等 AWS 工具為云成本監控提供了不錯的解決方案，但各種外部平台與 AWS 集成以進行更全面的分析。 例如，VMWare 的 CloudHealth 等雲管理平台顯示了可用於趨勢分析、異常檢測以及成本和性能監控的最高支出領域的詳細細分。 我還建議您設置 CloudWatch 計費警報，以在費用過高之前檢測到任何費用激增。

Amazon 提供了許多出色的雲服務，可以幫助您將服務器、數據庫和硬件的維護工作委託給 AWS 團隊。 儘管雲平台成本很容易因錯誤或用戶錯誤而增加，但 AWS 監控工具為開發人員提供了保護自己免受額外費用的知識。

考慮到這些成本優化，您已準備好啟動您的項目，並在此過程中節省數百美元。

帶有“PARTNER”字樣的 AWS 徽標和下方的“Advanced Tier Services”文本。
作為亞馬遜合作夥伴網絡 (APN) 中的高級諮詢合作夥伴，Toptal 為公司提供在世界任何地方按需訪問 AWS 認證專家的機會。