Lambda란?
람다는 개발자가 프로비저닝할 필요 없이, 함수만 작성하면 되는 컴퓨팅 서비스이다.
Lambda의 특징
1. 비용이 저렴하다.
람다는 호출 수, 함수 실행 시간으로 비용이 측정되며, 호출 수가 많지 않고 특정 시간대에만 호출이 많은 서비스에 사용하기 유리하다. 그 대신 리소스는 다른 서비스보단 제한되어 있다.
2. 유지보수가 쉽다.
개발자는 함수만 수정하면 된다.
3. 상태가 없다.
람다는 한 번 호출될때 하나의 인스턴스를 만들어서 요청을 처리하고, 요청이 없으면 사라진다. 그 다음 요청이 들어오면 새로 인스턴스를 생성한다. 따라서 상태를 저장하고 있을 수 없다.
Lambda의 Cool Start, Warm Start
람다는 하나의 요청이 들어올떄 인스턴스를 생성한다. 람다가 실행되려먼 생성된 인스턴스가 함수를 실행할 준비를 해야하는데, 이러한 준비 시간으로 인해 응답을 받기까지 오랜 시간이 걸린다. 비활성화인(cold)상태에서 실행하므로 cold start라고 한다.
한 번 실행되어서 활성화 상태인 람다는 일정 시간동안 활성화 상태로 요청을 기다린다.(warm한 상태이다.) 이 시간안에 요청이 들어오면 대기중인 람다가 빠르게 요청을 처리해준다. 이 걸 warm start라고 한다.
Cool Start를 막으려면?
- 람다를 주기적으로 호출해준다.
- warm up 해주는 플러그인을 사용한다.
- 람다의 성능을 업그레이드 한다.
Lambda를 사용해보면서 느낀점
확실히 편리하다. serverless 프레임 워크를 사용하면 코드를 수정하고 serverless deploy만 해주면 된다. GitHub Action을 설정해서 머지되면 자동 배포로 설정하면 더 편리하게 사용할 수 있다.
그리고 1년 넘게 람다로 서비스를 운영하면서 비용이 든 적이 거의 없었다. (프리 티어로 1년간 사용했는데 프리 티어가 끝난 뒤에는 2000원 정도 나왔다)
내가 운영하는 서비스는 크롤링 하고, 다른 api에서 값을 가져와서 가공하는게 전부여서 메모리에 상태를 저장하는 일이 필요없었는데, 사용자가 많아 지고 호출수가 늘면서 캐싱의 필요성을 느꼈다. 아무래도 Elastic Cache는 비용이 비싸므로 메모리에 파일 형식으로 캐싱을 하는 것이 비용을 아낄 수 있는데, 람다는 일정 시간 이상 요청이 오지 않으면 인스턴스가 사라지므로 인메모리 캐싱을 도입하기는 부적합하다는 생각이 들었다. 지금은 EC2로 변경하려고 작업중이다.
다양한 트리거를 붙일 수 있어서 좋았다. 특정한 시간마다 함수가 실행되게 하거나, 이벤트를 수신했을때라던가의 특정 상황에 활용하기 좋다. 나는 API Gateway를 붙여서 http 요청이 들어왔을때 실행되도록 하였다. 회사에는 이벤트 수신, 스케줄러로 많이 사용중이다. 이 외에도 다양한 트리거가 존재한다.