본문 바로가기

Backend/INFRA

Image resizing with Lambda@edge -2

이미지 리사이징 서버 구조를 구성하고, 서버 로직까지 작성해서 서비스를 구축했더니 갑자기 특정 파라미터를 호출한

사진 파일에서 503에러 났다.

 

 

aws lambda 503 error 를 검색하자 이와같은 설명이 있었다.

 

이후 cloudwatch에 쌓여있는 람다함수의 로그를 유심히 보기 시작했는데, 에러가 난 요청의 총 실행시간이 3초를 초과한것이 아닌가?!

 

람다함수의 제한 시간은 디폴트 값이 3초로 지정되어있다. 이를 초과했기 때문에 503에러를 응답한 것이다.

 

하.지.만!

 

이미지 리사이징을 처리하는데 3초이상 걸린다는것이 몹시 이상하다고 생각했는데, 람다 서버의 메모리가 128mb로 맞춰져 있어

터무니 없는 시간이 걸린 것이었다. 아래의 차트를 참고하자.

 

128MB는 worst 옵션이다.

 

여기서 중요한 점은, 람다의 메모리는 비용과 선형적인 관계를 유지하지 않는다는 점이다.

람다 서버의 비용은 실행시간에 의해 결정되는데, 메모리가 낮을수록 실행시간이 길어져 비용이 더 많이 나올 수 있다.

위의 차트에서 보듯, 최적의 비용대비 효율을 갖는 메모리는 512MB이다.

하지만 1024MB에서 적은 비용이 늘어나는데 비해 실행시간은 유의미하게(약 1초) 줄어들기 때문에 1024MB 메모리를 적용하기로 했다.

 

1024MB 메모리에 제한 시간은 5초로 늘렸다. 제한시간이 초과할 일은 없겠지만..

이후 사진은 정상적으로 응답되었고, 총 응답시간은 1/6로 줄어들었다.

 

 

참고 : https://towardsdatascience.com/optimize-aws-lambda-memory-more-memory-doesnt-mean-more-costs-51ba566fecc7

 

 

 

'Backend > INFRA' 카테고리의 다른 글

젠킨스 도커플러그인이 인식되지 않을때  (0) 2022.06.02
Image resizing with Lambda@edge -1  (0) 2021.11.30
Image resizing with Lambda@edge  (0) 2021.11.08