이번 게시글에서는 람다의 트러블 슈팅내용을 정리합니다.
1. 에러로그
The Lambda concurrent execution limit is exceeded.
Increase the concurrent execution limit.
2. 이유
lambda는 동시에 실행될 수 있는 갯수의 한계가 있습니다.
Invoke숫자와 duration이 합산된 데이터로 요청이 많다고 걸리게 되는것이 아니라 수행시간도 길때 발생합니다.
예를들어 5초동안 수행되는 요청이 초당 10개씩 request가 들어오게 되면 concurrent execution은 50이 유지되는 형태입니다.
이는 계정(리전)별로 적용되며 서울리전 기준 1000개가 default입니다.
이를 초과하게 되면 람다 쓰로틀이 발생하게 됩니다.
3. 해결방법
(1). quota를 통한 limit 조절
quota에서 조절이 가능하므로 concurrent execution을 늘릴 수 있습니다.
하지만 한계가 있습니다.
limit을 2000개로 증성했고, 내 리전에서 일어나는 동시수행 갯수가 1200개 일때도 해당 에러가 발생할 수 있습니다.
init burst 숫자는 500이며, aws는 1분후에 500개로 부족하다고 판단되면 concurrent execution limit을 500씩 증대시키는 방식으로 lambda를 제공합니다.
따라서 lambda에 높은 tps가 들어가고, 하나의 transaction이 긴 환경에서는 람다 limit을 증설시키더라도 해당 에러가 발생할 수 있습니다.
높은 tps에 의한 에러라면 아래의 방법을 사용합니다.
(2). 재시도
람다의 invoke를 요청하는 방식이 synchronous 방식이라면 호출한쪽에서 retry를 하도록 대처하거나, event driven 방식으로 lambda에서 추가 동작을 하도록 지정할 수 있습니다.
(3). 예약된 인스턴스 사용
미리 람다 인스턴스를 넉넉히 준비시켜 해당 에러를 조치할 수 있으나, 비용이 비싼편이니 주의합니다.
'EFK' 카테고리의 다른 글
elastic search 트러블 슈팅(로그 적재) (0) | 2022.08.17 |
---|---|
fluent bit 트러블 슈팅 (0) | 2022.07.21 |
[EFK] kinesis firehose를 사용하여 fluent-bit 로그를 es로 보내기(datatransfer with lambda) (0) | 2022.06.16 |
[EFK] fluent bit을 사용해 로그를 elastic search 보내기 (0) | 2022.06.16 |
[EFK] EFK란(fluent bit 사용법) (0) | 2022.05.30 |
댓글