# ipdata 如何以每月 150 美元的價格為來自 10 個無限擴展的全球端點的 2500 萬個 API 調用提供服務 > 原文： [http://highscalability.com/blog/2018/4/2/how-ipdata-serves-25m-api-calls-from-10-infinitely-scalable.html](http://highscalability.com/blog/2018/4/2/how-ipdata-serves-25m-api-calls-from-10-infinitely-scalable.html)  *這是 IP 地理位置 API [ipdata](https://ipdata.co/) 的創建者 [Jonathan Kosgei](https://twitter.com/jonathan_trev) 的來賓帖子。* 我在去年的黑色星期五醒來，收到了來自用戶的大量電子郵件，報告來自 [ipdata](https://ipdata.co/) API 的 503 錯誤。 我們的用戶通常會在其網站上的每個頁面請求上調用我們的 API，以對用戶進行地理位置定位和本地化其內容。 因此，這一特殊故障在一年中最大的銷售日直接影響了我們用戶的網站。 那天我只失去了一個用戶，但差點失去了更多。 事件的順序及其無法解釋的性質-cpu，mem 和 i / o 遠沒有達到容量。 考慮到停機，我們擔心擴展規模（如果有的話），這是一個重新考慮現有基礎架構的重大呼吁。 ## 當時的技術堆棧  * Japronto Python 框架 * 雷迪斯 * AWS EC2 節點 * AWS 彈性負載平衡器 * 基于 Route53 延遲的路由 我已經在幾個新的，有希望的 Python 微框架上進行了測試。 在使用 [https://github.com/samuelcolvin/aiohttp-vs-sanic-vs-japronto 對基準 3 進行基準測試后，我在[aiohttp]，[sanic]和[japronto]之間進行選擇，選擇了](https://github.com/samuelcolvin/aiohttp-vs-sanic-vs-japronto) [Japronto](https://medium.freecodecamp.org/million-requests-per-second-with-python-95c137af319) 。 并發現它具有最高的吞吐量。 該 API 在 ELB 負載平衡器后面 3 個區域中的 3 個 EC2 節點上運行，并具有基于 Route53 延遲的路由，可將請求路由到距離用戶最近的區域，以確保低延遲。 ## 選擇一個新的技術堆棧  An Example Weather API using our current stack 大約在這個時候，我開始認真研究將 API 網關與 AWS Lambda 結合使用的原因： 1. 優惠的價格：API 網關每百萬美元約 3.50 美元，AWS Lambda 每百萬美元約 0.20 美元。 2. 無限規模和高吞吐量-API API 網關的帳戶限制為每秒 10、000 個請求或每天約 864M 調用。 通過打開支持請求可以解除的限制。 這也使在眾多 AWS 區域中擁有端點在經濟上可行，從而為全球所有用戶提供低延遲。 ## 設計多區域 API 網關 API 為了使之可行，已經解決了許多架構難題。 1. 每個區域中的每個 lambda 函數都需要能夠在同一區域中的數據庫中查找使用情況數據，以最大程度地減少延遲 2. 我需要找出一種方法來確定每個 IP 地址，引薦來源網址和 API 密鑰進行的 API 調用次數。 3. 一種同步所有區域中的使用情況數據的方法。 例如，如果 Route53 向我們的悉尼端點發送了 10000 個請求，然后決定向其首爾端點發送下一個 50000 個請求（具體取決于那個時間點的網絡延遲最小）。 每個 lambda 函數都需要知道用戶總共發出了 60 000 個請求才能正確處理速率限制。 4. 授權-API 網關提供使用計劃和 API 密鑰生成，并允許您將 API 密鑰鏈接到使用計劃。 此外，您無需為用戶超出配額的請求付費，而無需支付額外費用。 但是，我無法使用此功能，因為對我來說，提供不注冊，不使用信用卡的免費套餐非常重要。 通過大量的工作，我能夠以創造性的方式解決這些問題。 ## 在本地訪問使用情況數據（針對每個 lambda 函數） 顯而易見的解決方案是使用 Dynamodb，它在規模和速度上都具有成本效益！ 每月前 200M 個請求免費。 Dynamodb 還提供 1-2 ms 的始終較低的讀取延遲。  可以使用 [Dynamodb Accelarator](https://aws.amazon.com/dynamodb/dax/) （DAX）將其加速到微秒范圍。 > DAX 通過每秒數百萬個請求處理大量讀取工作負載的響應時間（以微秒為單位），將性能提升到一個新的水平。 ## 收集所有標識符的使用情況數據 下一個挑戰是如何實時計算每個 IP 地址，引薦來源網址或 API 密鑰發出的請求數。 最簡單，最直接的方法是在每次調用時更新動態表中的計數。 但是，這會在每次調用我們的 API 時引入數據庫寫操作，從而可能導致顯著的延遲。 我能夠找到一個簡單而優雅的解決方案： 1. 首先，在每個請求上打印包含所有請求標識符的日志（JSON 對象）。 這是 IP 地址，引薦來源網址和 API 密鑰（如果存在）。 真是 print（事件） 2. 將 [Cloudwatch 訂閱過濾器](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Subscriptions.html)添加到每個區域中每個 Lambda 函數的 Cloudwatch 日志流中，并將所有日志推送到 Kinesis 流中。 這將使我能夠處理中心位置中每個區域的日志事件。 由于可以回放事件，因此我選擇了 Kinesis 而不是 SQS（亞馬遜的簡單隊列服務）。 SQS 會在使用者讀取事件后立即刪除事件。 我希望能夠從節點故障和數據丟失中恢復。 3. 從 Kinesis 流中讀取并使用使用情況數據更新 [Local Dynamodb](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/DynamoDBLocal.html) 實例 4. 使用 [Dynamodb 跨區域復制庫](https://github.com/awslabs/dynamodb-cross-region-library)實時將對我的本地 dynamodb 實例的所有更改實時流式傳輸到所有區域中的所有表。 ## 驗證請求 我通過在注冊時將密鑰復制到每個區域來處理此問題，因此無論用戶點擊哪個端點，他們點擊的 lambda 函數都可以通過在毫秒內檢入本地 Dynamodb 表來驗證其密鑰。 它還可以存儲用戶的計劃配額，并且可以在一次讀取中驗證密鑰，如果密鑰存在，則可以獲取計劃配額以與使用情況進行比較并確定是否接受或拒絕請求。 ## 情況如何 今天，我們每月提供 2500 萬個 API 調用，每天大約提供 100 萬個調用。 它們中的大多數都在 30 毫秒之內，提供了業界最快的基于 SSL 的 IP 地理位置查找。 #### [Hyperping.io](https://hyperping.io/)  ### [我們的狀態頁面](https://updown.io/ndkd)  延遲幾乎是開發人員不愿意使用第三方 API 進行 GeoIP 查找的最大原因。 但是，我們的低延遲和冗余的全球基礎架構正逐漸將大型企業吸引到我們的服務中。 ## 費用  ## 經驗教訓 1. Cloudwatch 的成本可能出乎意料的高-而不是日志存儲-我們只能將 Cloudwatch 日志存儲 24 小時。 警報，指標和 cloudwatch 請求確實可以加起來。 2. 在 API 網關上，由于冷啟動次數減少，您獲得的請求越少，延遲就越低，因此我發現在我們最繁忙的地區（法蘭克福）的延遲低至 17 毫秒，而在悉尼等不那么繁忙的區域則只有 40 毫秒。 3. Dynamodb 的速度快，花費比您想象的要少（或者不，請參閱 [https://segment.com/blog/the-million-dollar-eng-problem/](https://segment.com/blog/the-million-dollar-eng-problem/) ）。 最初，我認為應該按我提供的 RCU 和 WCU 的數量收費。 但是，計費似乎只是標準用法，因此，如果您提供 1000 個 RCU 和 1000 個 WCU，但僅使用 5 個 RCU 和 WCU，則只需要為使用付費。 Dynamodb 定價的這一方面在剛開始時很難確定。 4. 增加 lambda RAM 可以使執行時間減半，并使的響應時間更加一致（同時使您的成本增加一倍！） 5. Kinesis 已被證明在高吞吐量下非常可靠。 中繼我們的所有日志事件以進行近實時處理。 6. 本地 Dynamodb 僅受系統資源的限制，這使其非常適合運行表掃描或查詢（例如，在生成報告時），否則這些掃描或查詢在 AWS 的 Dynamodb 上進行將非常昂貴。 請記住，Local Dynamodb 實際上只是 SQLite 周圍的 Dynamo 包裝:)。 對于我們的用例來說，它既有用又方便，但對您而言可能并非如此。 ## 筆記 * AWS 去年在 Re：invent 上宣布了 Dynamodb Global 表，該表將所有表（“跨區域”）中的所有寫入彼此同步。 我們目前不打算使用此功能，因為它僅在 5 個地區提供。 * 亞馬遜還推出了`REQUEST`類型的自定義授權者。 這可能使您可以通過 IP 地址以及任何標頭，查詢或路徑參數對速率進行限制。 [關于 HackerNews](https://news.ycombinator.com/item?id=16745376) 您的 DynamoDB 成本令人驚訝是因為默認情況下啟用了“自動縮放”以讀取/寫入卷。 只要您的峰值不大，就永遠不會看到配置錯誤... 我對此聲明感到困惑： ----- 我最初以為我要提供的 RCU 和 WCU 數量付費。 但是，計費似乎只是標準用法，因此，如果您提供 1000 個 RCU 和 1000 個 WCU，但僅使用 5 個 RCU 和 WCU，則只需要為使用付費。 Dynamodb 定價的這一方面在剛開始時很難確定。 ----- 定價頁面（https://aws.amazon.com/dynamodb/pricing/）指出，您需要為您提供的吞吐量付費 也許因為仍在免費套餐中而未向您收費？ 嘿 Cads， 我完全理解混亂，我也和您一樣。 但是我很確定我們不在免費領域，因為我們要為 Dynamodb 付費。 而且，我們只收取使用費用，并不超出表中的規定。 這似乎與亞馬遜的定價頁面上所說的相反，但這是我在 AWS 賬單上看到的。 感謝您的有趣文章。 關于本地 DynamoDB，我有一個問題：您在哪里運行此程序？ 作為 EC2 實例？ 嗨 Tobi， 謝謝！ 我實際上在 Azure 節點上運行它。 但是，它可以作為實例在 DO 或 EC2 上運行。 該圖顯然是不真誠的。 從來沒有太大的區別。 在這種情況下，可能是因為作者只是在測試管道而不是沒有管道。 此外，他將 go pro 限制為 1 cpu。 同樣，倉庫也不再存在。 我把廢話統稱為“基準”。 順便說一句，Japronto 主要是 C，請檢查代碼。 （我偏向于 Go，但是這不像 node，其他人無法應付自己） 我記得在中篇文章上有很多類似的評論，請參閱 https://medium.freecodecamp.org/million-requests-per-second-with-python-95c137af319 我還能夠找到另一個基準，使 japronto 緊隨 Rust https://github.com/tbrand/which_is_the_fastest 每月 2500 萬個請求是每秒 10 個請求... 每秒高峰請求呢？ 寫得很好的文章。 感謝您分享您的體驗。 我對以下部分有疑問： “首先，在每個請求上打印一個帶有所有請求標識符的日志（JSON 對象）。這是 IP 地址，引薦來源網址和 API 密鑰（如果存在的話）。確實是;```print（event）```“ 只是想知道為什么不將這些消息直接發送給運動機能？ 為什么要先登錄？ Esko，API 網關可以處理 10k req / s 的峰值 Kaivalya，這會為用戶帶來延遲，打印日志是最便宜的（就延遲而言）和最簡單的解決方案。 > > SQS 會在使用者讀取事件后立即將其刪除。 這是不正確的，一旦您從 SQS 讀取了一條消息，直到可見性超時，任何人都看不到它。 您需要確認對 SQS 的讀取，以便它可以刪除消息。 我們通常要做的是處理消息，然后僅在處理實例發生故障的情況下進行確認，這樣我們的消息仍然完好無損。 只需調整可見性超時以確保提供足夠的時間即可。 很棒的文章。 感謝您與社區分享。 嗨，您如何處理每秒 1,000 個 Lambda 呼叫限制？ AWS 的架構師建議我們不要在具有高使用率和高并發性的大多數項目中使用 Lambda-他們說，這僅對中小型項目更好，并且沒有您所說的無限規模-我們被告知的一個大問題 當以最大速度運行時，AWS 團隊將耗盡 VPC 中所有可用的 IP 地址。 超出 1,000 個限制的呼叫也會被拒絕，您的客戶也會出錯。 為了計算并發執行的次數，我們使用公式： 每秒事件（或請求）數*功能持續時間 如 https://docs.aws.amazon.com/lambda/latest/dg/scaling.html 所記錄。 自這篇文章上線以來，我們平均每天平均有 2M API 調用，大約每秒 12 次。我們的最大 lambda 使用上面公式中的值，調用時間為 20ms； 12 * 0.020 我們得到的并發級別為 0.24。 這意味著我們可以在目前的 1000 lambda 調用限制下，每秒處理 50，000 個請求，每天約 43.2 億個請求。 嗨， 單個訂戶的運動流事件有多個訂戶嗎？ 只是想知道為什么如果所有數據都存儲在一個中央（本地）dynamo 數據庫實例中，則跨區域 dynamo 數據庫進行復制。 因此，您為 9 req / s 支付 150 美元？ 對于許可證密鑰檢查，您是否考慮過使用 Bloom 或 Cuckoo 過濾器？ 您可以將過濾器保存在內存中，并避免數據庫調用。 首次使用 ipdata.co 的用戶，我們最近切換到了另一個 IP 地理位置提供商。 延遲在過去幾個月中增加了很多，并且在全球范圍內不一致（請參閱 https://status.ipdata.co/）。 此外，該服務缺少監視儀表板。 如果您處于類似情況，我建議嘗試 Ipregistry（https://ipregistry.co），其全局端點延遲實在令人難以置信（https://status.ipregistry.co/）！ 我聯系了他們的支持，建議在此博客上寫一篇文章，因為他們的體系結構可能很有趣。