[AWS] Lambda: Cold Start 문제

#AWS

cold start 이슈는 lambda를 사용할때 겪을 수 있는 대표적인 문제 중 하나다.

이게 뭐냐 하면, 람다를 오랫동안 쓰지 않다가 간만에 실행하면 느리게 실행이 되는걸 말한다.

이렇게 초기화 시간이 더해지는 것이다.

한번 호출하고 나면 그때부터는 다시 빨라진다.

수백밀리초가 발생하던게 2밀리초로 줄었다.

밀리초 단위라서 별거 아닌것처럼 보일 수도 있지만, Lambda의 구성 상태에 따라서 cold start 시간이 1초를 넘는 일도 비일비재하다.
경우에 따라서는 서비스에 중대한 품질 저하를 일으킬 수도 있는 문제다.

이런게 왜 발생하나?

cold start는 Lambda 시스템의 근본적인 한계 때문에 발생한다.
아마존이 자선사업가도 아니고... 쓰지도 않는 함수를 계속 메모리에 올려놓을 수는 없는 노릇 아닌가.

Lambda는 내부적으로 숨겨진 S3 버킷에서 소스코드를 다운로드해서 컨테이너를 띄우고, 코드를 실행시키는 프로세스를 가진다.

여기서 코드를 다운받고 컨테이너를 생성하는 시간이 cold start 딜레이가 되는 것이다.

cold 모드로 전환되기까지 걸리는 시간은 일정하지 않고, cold start가 완료되는 시점도 정해져있지는 않다.
cold start 시간은 함수 구현, 언어 런타임, 코드 크기, 메모리 크기 등에 영향을 받는다.

메모리를 크게 잡아두면 cold start를 줄일 수 있다고는 한다. 하지만 이것도 완전한 해결책은 아니다.

고전적인 방법은, 그냥 람다를 주기적으로 호출해서 강제로 warm-up을 해주는 것이다.

보통 이벤트브릿지로 몇십분에 한번씩 호출하는 형태로 사용한다.

이정도 호출한다고 비용이 딱히 튀는 것도 아니고, 꽤 많이들 사용하는 방법이다.

권장하는 방법은 아니지만, 저렴하다는 점에서 많이들 쓴다.

AWS에서 공식적으로 권장하는 방법은 동시성을 예약해서 프로비저닝하는 것으로 항상 활성화 상태를 유지하는 것이다.

일단 알아둬야할건, 비용이 추가발생한다는 것이다.

https://aws.amazon.com/ko/lambda/pricing/
실제로 사용되는 것과 별개로 그냥 떠있는 만큼도 요금을 꽤 부과한다..

설정하기에 앞서서, 동시성 개수를 확인한다.
도쿄 같은 부르주아 리전은 동시성 할당값을 1000개씩 주는데, 서울은 그렇지가 않아서 요청을 해서 늘려달라 해야한다.

이렇게 50밖에 없으면 못쓴다.

AWS 팀에서 처리를 해줘서 충분히 늘어났다면, lambda 구성-동시성 탭으로 이동한다.

여기서 프로비저닝에 사용할 동시성 개수를 몇개 빼줘야 한다.

예약되지 않은 것도 어느정도 남겨놔야하는데, 리전마다 다르더라. 서울은 50개는 남겨야 하고, 도쿄는 100개는 남겨야 한다.

그리고 예약해둔걸 여기서 가져다가 구성하면 된다.
싸지는 않다.

이러면 이제, 동시 실행 개수가 저 100개를 넘지만 않으면 cold start 문제는 없을 것이다.