為了要讓無伺服器( Serverless )架構可以處理高流量，可以使用 Lambda 的 Concurrency 機制，提升處理整個系統處理 request 的速度，但是這麼做也有一些風險，接下這兩天就來探討如何使用 Lambda 的 Concurrency ，以及優缺點。

理解 Lambda 併發的基本概念

在深入討論如何處理高流量之前，讓我們先了解 AWS Lambda 中的「併發( Concurrency )」究竟是什麼。

併發( Concurrency ): 指同時有多個 Lambda 處理多個 request。每當有新的 request 到達， Lambda 會為其配置獨立的執行環境。

在沒有調整任何併發( Concurrency )機制下， AWS 會根據流量自動為 Lambda 進行 auto-scaling ，這也是無伺服器架構「自動擴展」的核心優勢。以 Lambda 和 SQS 為例，如下圖所示，可以清楚看到 AWS 自己長出 Lambda 消化 SQS 的 message 。

Lambda 高流量下的常見挑戰

• 然而，這個擴展能力並非無限， AWS 賬戶在每個區域的 Lambda 共享一定數量( Unreserved account concurrency ，大部分帳號約 1,000 個左右)併發執行數量，所以當所有的 Lambda 數量達到上限，就無法再新增執行環境。
• 而且瞬間流量大增時， 新增一個 Lambda 也需要時間，會有冷啟動( Cold Start )延遲的問題，這會導致在 queue 中的 message 要堆積一段時間才能緩解，成為整個系統的 bottleneck 。
• 使用 auto-scaling 加快處理 request 雖然可以解決高流量的一些問題，但是一次使用太多 Lambda 執行 message ，如果 Lambda 有呼叫第三方的 API ，大量呼叫 API 也會造成其他系統的負擔。

為了解決上述的困境，需要適當的調整併發( Concurrency )策略，讓整個處理 request 的流程可以更順暢，明天會介紹如何調整 Lambda 的併發( Concurrency )。

medium: 使用 AWS Lambda 的 Concurrency 機制處理高流量應用