Lambda cold start

The underlying technology of Lambda is a container. Therefore, if Lambda is used, even if it is set to the lowest specification, the container will quickly float and scale-out at the moment of load, and it is expected that it will be able to receive all the loads. Conceptually, that’s correct. But in practice, there are many cases where this is not the case. Otherwise, the container is not created quickly. i.e cold start !

( Lambda의 근간이 되는 기술은 Container이다. 때문에 Lambda를 쓰게 되면, 가장 낮은 사양으로 셋팅하더라도, 부하가 생기는 순간에, Container가 빨리 빨리 뜨면서 Scale-out이 되고, 그것이 부하들을 다 받아낼 수 있을거라는 기대를 하게 된다. 개념적으로는 맞는 말이다. 그러나 실제로는 그렇게 되지 않는 경우가 많이 존재한다. 그렇지 않은 경우는 빠르게 컨테이너가 생성되지 않는 경우. 즉 cold start ! )

 

To put it simply, cold start means to turn on a completely cooled computer that is turned off after all. To put it bluntly, it is easier to approach it with the concept that it takes more time to restart a computer that is completely turned off than to turn on a computer that is in sleep mode (power is on) for a while.

( 간단하게 표현하자면 Cold start라는 것은 결국, 꺼져있는 완전 식어버린 컴퓨터를 새로 킨다는 의미이다. 굳이 비유하자면, 잠시 절전 모드의(전원은 켜져있는)컴퓨터를 키는것 보다는, 완전히 꺼져버린 컴퓨터를 새로 키는데 시간이 더 많이 발생한다는 개념으로 접근하면 쉽다. )

 

첫 회사를 다닐 때 경험 했었는데, 관리나 비용적 측면에서 Lambda는 말도 안되는 computing 솔루션이라고 생각한다. 첫 회사에서 아워홈-메가존 컨설팅 미팅에서 담당 컨설턴트 분께서 5분 이하의 주기적인 서버 통신이 아니면 Lambda로 빼는 방법을 권장 해주셨다.

이게 마냥 저렴하고 좋은 솔루션으로만 알고 있다가 막상 소규모 프로젝트를 진행할때 API Gateway - Lambda 를 통한 방법으로 서버를 구성했다가 Cold Start로 인해 생각보다 주기적인 호출이 없는 프로젝트의 경우에 메모리를 올리거나 주기적으로 호출해주는 방식을 사용해야해서 생각보다 비용적으로 이점을 보지 못했던 적이 있었다.

 

최근에는 사내에서 잠깐 사용할 API나 주기적인 호출이 필요한 경우 CloudWatch - Lambda 혹은 Slack integration을 통해 현재 Release, QA 버전을 확인하는 서비스 등에 사용했었는데 이런 경우는 대체할게 없을 정도로 적절하게 사용했던거 같다.