Lambda는 이벤트에 응답하여 코드를 실행하고 기본 컴퓨팅 리소스를 자동으로 관리하는 서버리스(Serverless) 컴퓨팅 서비스이다.
1. Lambda의 핵심 철학: Event-Driven
Lambda는 스스로 실행되지 않는다. 반드시 어떤 이벤트(Trigger)가 발생해야 동작한다.
- S3: 새로운 이미지가 업로드되었을 때 실행해라
- API Gateway: 누군가
/api/v1/usersAPI를 호출했을 때 실행해라 - DynamoDB: 데이터가 수정되었을 때 실행해라
- CloudWatch Events: 매일 새벽 3시에 배치 작업을 실행해라 (Cron Job)
2. 왜 Lambda를 사용하는가?
- 관리 부담 X: OS 패치, 서버 모니터링, 하드웨어 확장을 AWS가 다 한다.
- 완전한 탄력성: 요청이 없으면 0대, 요청이 1만개 들어오면 순식간에 1만 개의 함수가 뜬다.
- 비용 효율성: 서버를 켜놓는 시간당 비용이 아니라, 코드가 실행된 시간(ms)과 횟수에 대해서만 지불한다. (트래픽이 적은 서비스는 한 달에 0원에 가깝게 운영 가능하다)
3. 백엔드 실무 활용 시나리오
- 파일 처리 (Image Resizing): 사용자가 S3에 고해상도 사진을 올리면 Lambda가 이를 감지해 썸네일(Thumbnail)로 변환하여 다시 저장한다. 서버 리소스를 많이 먹는 무거운 작업을 메인 API 서버에서 분리할 대 아주 좋다.
- 서버리스 API 구축: API Gateway + Lambda + DynamoDB 조합으로 서버 한 대 없이 완벽한 웹 서비스를 만들 수 있다. 이는 유지보수 비용이 거의 들지 않는 것이 장점이다.
- 배치 및 스케줄러 (Batch Job): 매주 월요일 아침 뉴스레터를 발송하거나 매일 밤 로그 데이터를 정리하는 등의 정기적인 작업을 처리하기에 최적이다 (EC2를 24시간 켜둘 필요가 없다.)
- 실시간 데이터 처리: 사용자의 클릭 로그를 Kinesis나 DynamoDB Streams로 받아서 실시간으로 분석하고 통계를 내는 작업에 쓰인다.
4. 백엔드 개발자가 주의해야 할 점 (제한 사항)
4.1. Cold Start (최초 실행 지연)
- 한 동안 실행되지 않던 Lambda를 호출하면 실행 환경을 준비하는 데 약간의 지연 시간( 최대 약 2초)이 발생한다.
- 해결: Java보다는 실행이 빠른 Python을 사용하거나 프로비저닝된 동시성(Provisioned Concurrency) 설정을 사용한다.
4.2. 실생 시간 제한 (Timeout)
- 하나의 함수는 최대 15분까지만 돌아갈 수 있다. 1시간 이상 걸리는 복잡한 배치 작업은 Lambda보다는 ECS나 Batch 서비스를 사용해야 한다.
4.3. 상태 비저장 (Stateless)
- 함수가 끝나면 로컬에 저장된 파일이나 메모리 변수는 모두 사라진다. 데이터는 반드시 DB나 S3에 저장해야 한다.
4.4. VPC 연결 이슈
- Lambda가 VPC 내부의 RDS에 접근해야 할 경우 VPC 인터페이스를 생성하는 과정에서 추가적인 지연 시간이 발생할 수 있으므로 네트워크 설계에 주의해야 한다.
5. 언제 Lambda를 사용해야 할까?
- 트래픽이 불규칙하거나 적어서 서버 비용을 아끼고 싶을 때.
- 메인 서버에 부하를 주지 않고 특정 작업(이미지 처리, 알림 발송 등)을 비동기로 처리하고 싶을 때.
- 서버 관리가 귄찮고 코드만 짜서 바로 배포하고 싶을 때.
백엔드 개발자를 목표로 공부하는 대학생