Design Async Invocation using API Gateway and SQS


Using API Gateway as DynamoDB Proxy 一文提及可以透過 API Gateway 直接整合 DynamoDB ,而不一定要透過 Lambda,其實 Lambda 只是大家最常整合的服務而已。同樣的概念,其實 API Gateway 可以直接整合除了 Lambda 之外的很多服務,像是 DynamoDB、SQS、Step Functions、Kinesis、 … 等。

延伸這個應用,我很常被問的一個問題:

發送給 API Gateway 的請求,會不會掉?怎樣避免 Request 遺失?

這個問題很多人都問過我,本文提供一個架構設計的想法。


常見設計

底下最常見的設計,也就是 API Gateway 提供 REST API,然後透過 Lambda 讀、寫 DynamoDB。

讀、寫經過的路徑如下:

  • GET: R-Req1 -> R-Req2 -> R-Req3 -> R-Res1 -> R-Res2 -> R-Res3
  • POST: W-Req1 -> W-Req2 -> W-Req3 -> W-Res1 -> W-Res2 -> W-Res3

不管讀還是寫都要經過四個點,每個點都有三段,來回 (Request / Response) 共六段路由要走。這樣的設計沒什麼不好,但效能就會因為以下而打折扣:

  1. 經過的服務的通訊方式是強耦合 (Tightly Coupled),也就是 Request / Response 整個流程都是直接接續著,一棒一棒傳下去
  2. 經過的服務節點太多
    1. Client
    2. API Gateway
    3. Lambda
    4. DynamoDB
  3. 使用者體驗不好

架構解偶

解偶 (Loosely Coupled,又稱鬆耦合) 是架構設計常見的手法,目的是降低兩個服務之間的強依賴關係,達到可以獨立開發、部署、維運 彈性。在 AWS 經典的 Whitepaper - Architecting for the Cloud 也特別提到類似的概念,其核心概念就是利用 Message Queue 解構服務的強依賴,如下圖:

非同步設計

有時候同事會問我:

如果 Client 瞬間丟太多 Request 給 API Gateway,請求會不會掉?那後面的 Lambda 長得不夠快,會不會就炸掉?

這個問題分成幾個層次:

  1. API Gateway 本身的 Rate Limit 是否夠用?
  2. Lambda Cold Starts 造成回覆延遲的現象,最後反映的是體驗不好。

第一個問題通常不會是問題,除非生意真的做到像掏寶、天貓那種等級,詳細參閱: API Gateway - Rate Limit and Throttling。如果不幸真的超過上限而掉了 Request ,就要換 Solution 了。

第二個問題就是很多人會擔心的,特別是因為一些因素,Lambda 必須放在 VPC 裡面的時候,問題就更明顯了。

通常我會追問:

運算的結果需要馬上知道?

大部分的需求是不需要的,所以問題就限縮到:

解決 Request 不會丟失、能穩定消化完就好

只要不是需要立即有結果,也就是結果是 最終一致 即可,那麼就可以利用空間換時間的方式達到:非同步、解偶。以此概念,整理如下的設計:

修改的有兩個部分:

第一部分:透過 API Gateway 的 Integration Request,選擇 AWS Services,然後直接整合 SQS ,先讓 Request 的訊息留在 SQS,然後返回,後續由 SQS 的 Consumer - Lambda 處理。API Gateway 設定如下圖:

圖中 SQS 的 Action 請參閱: SQS API Reference

第二部份:其實就是把 Read 的 Lambda 拿掉,也是利用 Integration Request 直接整合 DynamoDB,詳細介紹參閱 Using API Gateway as DynamoDB Proxy

Lambda 的非同步官方文件有解法,請參閱:Set up Asynchronous Invocation of the Backend Lambda Function


結論

API Gateway 的 Integration 其實很強大,只要會好好利用 AWS Services (像是 Step Functions、SQS、SNS、Batch ),可以設計很多有趣的應用。而這個範例提到的設計樣式,讓 API Gateway 可以提供非同步設計,而且是高度與 AWS 既有服務整合,是非常實用的。


延伸閱讀

系列文章

站內延伸

參考資料

類似工具


Comments