無伺服器架構的廣泛應用推動了雲端運算的發展，而在實現高可用性、自動擴展和靈活分發的過程中，負載平衡器成為關鍵元件。 AWS Elastic Load Balancer（ELB）為無伺服器架構提供了一種可靠的解決方案，它能夠在分散式環境中智慧地管理流量分發，從而確保應用程式的效能和穩定性。透過與AWS Lambda、API Gateway 等無伺服器服務無縫集成，ELB 為開發者提供了高效且可擴展的負載管理方式。
什麼是彈性負載平衡器(ELB)？
ELB 是AWS 提供的一組負載平衡（LB）服務。它們包括Classic Load Balancer、Gateway Load Balancer、Network Load Balancer和Application Load Balancer。
每個LB 都涵蓋不同的用例
- Classic Load Balancer是基於EC2 的架構的不錯選擇
- 網關負載平衡器可協助VPC 中的第三方虛擬機
- 網路負載平衡器專注於高效能低階網絡，例如基於UPD 的遊戲或物聯網連接
- 應用程式負載平衡器是使用HTTP 協定的軟體的高階解決方案
在無伺服器架構的情況下，所有服務都使用HTTP API，這表示ALB是最佳選擇。因此，本文將重點放在ALB。
什麼是應用程式負載平衡器(ALB)？
ALB 專注於HTTP，因此它可以使用協定的某些部分來做出有關快取的決策，從而為您節省一些Lambda 執行時間。這意味著您的Lambda 函數必須正確設定其快取標頭。
價格
雖然ALB 可以與Lambda 集成，但ALB 不是無伺服器服務；它沒有即用即付模式，這意味著您需要為未使用的時間付費。但是，如果您的服務具有持續穩定的流量需求，那麼從長遠來看，它可能比API Gateway 更便宜。
限制
此外，API Gateway 限制連線數為10k，而ALB 沒有限制。它是一個API Gateway，具有更多次要功能；功能簡單，但性能卓越。如果您要做大，ALB 可能是您的唯一解決方案。
權限
ALB 更像是傳統的「綁在公共HTTP 端點前面」的東西。因此，雖然它與Lambda 集成，但它不提供基於IAM 的權限。您必須在無伺服器函數中處理這個問題。
變換
這種傳統的負載平衡方法也意味著ALB 無法進行請求和回應轉換；它只是將您的資料傳輸到管道。同樣，這使得ALB 的靈活性不如API 網關，並將更多工作轉移到Lambda。
多區域
您一次將ALB 部署到一個區域。同樣，這不是無伺服器服務，因此您需要做更多工作。要使流量在多個區域之間保持平衡，您需要Route53 的基於DNS 的平衡。
可靠性或成本配置
使用具有Lambda 目標的ALB 通常可以提供良好的可靠性，因為Lambda 會自動擴展。如果您需要的不僅僅是開箱即用的可靠性，則必須將ALB 部署到多個區域並將其置於Route53 之後。
在成本方面，Lambda 可能會成為您的主要罪魁禍首。如果您將每個請求路由到具有大記憶體配置的Lambda 函數，那麼成本很快就會變得昂貴。因此，請遵循無伺服器最佳實踐，使Lambda 函數保持小巧和目的驅動。為您的ALB 偵聽器設定條件，以便盡可能使用記憶體佔用較小的函數。
健康檢查最佳實踐
儘管EC2 目標很容易不堪重負，但Lambda 目標由於其固有的自動擴展功能而具有更多的緩衝；無伺服器系統中仍然存在可能出錯的情況。
AWS 預設會停用Lambda 目標的ALB 運作狀況檢查，因此您必須在此處選擇加入。
雖然有些問題可能是由推送到Lambda 的錯誤代碼引起的，但大多數問題都來自函數使用的上游服務。因此，請設定Lambda 以管道方式傳輸健康檢查，然後使用上游服務的結果進行回應。
如果出現問題，唯一快速的解決方案是告訴Route53 將以下請求路由到不同的部署。
AWS 中的日誌分析
AWS 讓您可以使用Amazon Athena 分析ALB 日誌。 Athena 是一種無伺服器查詢服務。您需要啟動查詢日誌並將其儲存到S3，然後使用Athenas SQL 查詢進行探索。
AWS Elastic Load Balancer 在無伺服器架構中扮演了至關重要的角色，透過其自動化的流量管理、靈活的擴展能力以及與其他AWS 服務的深度集成，幫助開發者輕鬆應對各種業務需求。無論是處理高並發請求或優化資源利用率，ELB 都能為無伺服器架構提供可靠的支撐，讓開發者專注於核心邏輯的實作與創新。
