AWS Lambda

이미지 후처리나 웹훅 처리처럼 실행 시간이 짧은 작업에 상시 서버를 두는 방식은 비효율적입니다. 대부분의 시간 동안 서버는 유휴 상태로 남아 있지만 비용은 계속 발생하고, 순간적으로 이벤트가 몰리는 상황에 대비해 서버 용량까지 미리 계획해야 하기 때문입니다.

마이크로서비스가 늘어나면서 서비스마다 VM을 따로 띄우는 방식은 점점 비효율적이 되었습니다. 특히 야간이나 비수기에는 많은 인스턴스가 거의 아무 일도 하지 않은 채 비용만 발생하는 경우가 많았습니다. 트래픽이 적더라도 서버 패치나 용량 관리, 스케일링 같은 운영 작업은 계속 필요했고, 몇 초면 끝나는 작은 작업 하나를 위해서도 인프라를 상시 운영해야 했습니다. Lambda는 이런 문제를 줄이기 위해 나온 방식입니다. 이벤트가 발생했을 때만 필요한 만큼 코드를 실행하고, 나머지 인프라 운영은 AWS가 맡도록 한 서버리스 모델입니다.

Lambda는 이벤트가 도착하면 실행 환경(경량 컨테이너)을 준비하고, 그 안에서 런타임을 초기화한 뒤 핸들러 함수를 실행합니다. 이 초기화 과정을 콜드 스타트라고 합니다. 핸들러가 응답을 반환한 뒤에도 실행 환경은 곧바로 사라지지 않고 잠시 대기 상태로 남아 있을 수 있습니다. 그래서 다음 요청이 얼마 지나지 않아 다시 들어오면, AWS는 같은 환경을 재사용해 초기화 과정을 생략하는데, 이를 웜 스타트라고 합니다. 반대로 한동안 요청이 없어 유휴 시간이 길어지면 AWS가 이 환경을 회수합니다. 동시에 여러 이벤트가 들어오면 각각 별도 환경을 만들어 병렬 처리하므로 별도 스케일링 설정 없이도 동시 실행 수가 자동으로 늘어납니다.

Lambda와 EC2는 둘 다 코드를 실행하지만 운영 방식이 다릅니다. Lambda는 요청이나 이벤트가 있을 때만 짧게 실행되고, EC2는 서버를 계속 유지하면서 프로세스를 직접 관리합니다. 요청 단위의 짧은 작업을 사용량 기반으로 처리하고 싶다면 Lambda가 잘 맞고, 오래 실행되는 작업이나 서버 수준의 세밀한 제어가 필요하다면 EC2가 더 적합합니다.

Lambda는 가벼운 API 백엔드, 파일 업로드 후처리, 스케줄 작업, 이벤트에 반응하는 자동화 로직처럼 요청 단위로 짧게 실행되는 작업에 잘 맞습니다. 반면 한 번 실행이 15분을 넘기거나, 실행 중인 프로세스가 상태를 계속 유지해야 하는 워크로드에는 적합하지 않습니다.