[lambda]서버리스 애플리케이션 성능 최적화
대표적인 서버리스 애플리케이션 중 하나로 AWS의 람다가 있다. 서버의 환경관리를 해 줄 필요없고, 자동으로 확장하므로 아주 편리한 서비스이다. 그러나 서비리스의 가장 큰 단점 중 하나인 cold starts 문제가 있다. 이것이 무엇인지 알아보고 해결하기 위해 어떤 방법이 있는지 알아보자.
cold starts와 latency
람다가 API를 통해 function을 실행시키도록 요청을 받을 때, 실행환경을 준비한다. 이 때 function에 필요한 코드를 다운 받는다. 설정에 따라 s3 버킷에서 가져올 수도 있고, ECR에서 컨테이너 이미지를 통해 가져올 수도 있다. 그 이후 메모리, 런타임, 환경설정한 것들에 따라 환경 설정에따라 실행환경을 만든다. 실행환경이 모두 만들어졌으면, 람다는 초기 코드를 실행한 후 최종적으로 설정한 handler code를 실행시킨다. 위 과정을 그림으로 나타내면 다음과 같다.
그림에서 보이는 앞 두 단계를 cold starts라 한다. 요청이 있고 난 후 실행되기에 두 단계만큼 latency가 생길 수 밖에 없다.
람다 함수가 실행이 되었다면, 만들어졌던 실행환경은 다시 cold상태, 즉 없어진다. 그러나 이 람다의 해당 function에 다시 같은 요청이 올 것을 대비해 잠시동안(정해지진 않았음) 실행환경을 보관하는데, 이 때 요청이 들어오면 앞 두 단계를 건너뛰고 바로 코드를 실행한다. 그러면 cold starts보다 latency가 줄어드는데 이를 warm start라 한다. 즉, 성능을 향상시키기 위해서는 어떻게 하면 warm start를 할 수 있을까를 고민해보아야한다.
The execution environment lifcycle: 실행환경의 lifecycle
람다는 여러 가용영역에 걸쳐 자동으로 확장되는 고가용성의 서비스이다. 그래서 트래픽의 변화에 대비하기 위해 로드밸런서를 사용하는데, 주기적으로 로드밸런서를 통해 람다에 요청을 보낸다면 warm starts를 할 수 있다.
만약 트래픽이 늘어나 람다가 수평확장을 하게된다면, 새로운 람다는 새로운 실행환경이 필요한 것이고 이때는 cold starts가 실행된다.
당연히 람다 function 코드를 수정하거나 환경설정을 수정했다면 다음 요청은 cold starts일 것이다.
어떻게 warm start를 할 수 있나?
- EventBridge
- 로드밸런서에 pinging mechanism을 활용하여 지속적으로 function에 요청을 보내어 warm start의 확률을 높임
- serverless 커뮤니티에 존재
- 공식적인 방법은 아님
- warming library
- 개발, 테스트 환경 또는 적은 트래픽에 적합한 방법
- Provisioned Concurrency
- 만약 쓸일 있으면, 문서를 참고하여 이해하자.
- Invocation pattern
출처