서버리스(Serverless)가 뭘까
서버리스는 서버 인프라를 직접 관리하지 않고도 애플리케이션을 구축·실행할 수 있는 모델이다. 서버를 AWS가 대신 관리해준다는 뜻이다. 이 서버리스의 한 형태가 FaaS(Function as a Service)인데 EC2와 비교해보면 이렇다.
[EC2 방식]
서버 기동 ──────────────────계속 켜둠─────────────────→ 계속 과금
(트래픽 없어도 켜져있는 동안 요금 발생)
[Lambda 방식]
이벤트 발생 → 함수 실행 → 실행 끝나면 즉시 종료
(실행된 시간만큼만 과금, 평소엔 요금 없음)부트캠프에서 만들었던 Lambda
그 프로젝트에서 구성했던 흐름을 보면
CloudWatch ──(이상 지표 감지)──▶ SNS Topic ──(구독)──▶ Lambda 함수 ──(Webhook)──▶ Slack 채널
(EKS/EFK 클러스터 모니터링) (알림 발행) (메시지 가공) (알림 수신)당시엔 Lambda = SNS랑 Slack 사이를 이어주는 코드 정도로만 이해했는데 이 함수가 서버리스 컴퓨팅의 전형적인 사용 사례로서 서버가 SNS 메시지를 계속 지켜보고 있을 필요 없이 메시지가 도착하는 순간에만 함수가 켜졌다 꺼지는 구조임을 알게 되었다.
실제 경험에 비춰본 Lambda 특징
| 특징 | 개념 | 그때 겪었던 것 |
|---|---|---|
| 실행 시간/메모리 제한 | 최대 15분, 메모리 최대 10,240MB까지 설정 가능 | 알림 함수는 1초 안팎이라 기본값(가장 작은 설정)만으로 충분했음 |
| IAM Role | 코드에 액세스 키 없이 역할로 임시 자격 증명 자동 획득 | 실습 가이드대로 역할만 붙였는데, 이게 EC2/IMDS와 같은 구조였다는 걸 이번에 알게 됨 |
| 콜드 스타트 | 한동안 호출 안 되면 환경이 내려가 있다가, 재호출 시 재기동 지연 발생 | 알림이 몇 초 늦게 온 적이 있었는데, 이 때문이었을 가능성이 있음 |
| 무상태성(Stateless) | 호출 간 데이터 유지 불가, 상태는 외부 저장소(DynamoDB 등)에 저장해야 함 | "메시지 하나 받아 하나 전송"이라 문제없었지만, "누적해서 한 번에 발송" 같은 요구였다면 별도 저장소가 필요했을 것 |
| 벤더 종속성 | 트리거 연동 코드가 특정 클라우드 이벤트 형식에 종속 | SNS 이벤트 형식에 맞춘 코드라 다른 클라우드로 옮기려면 재작성 필요 |
트리거 종류
Lambda는 다양한 AWS 서비스를 트리거로 걸 수 있다.
S3 (파일 업로드/삭제) ─┐
DynamoDB (데이터 변경) ─┤
API Gateway (HTTP 요청) ─┼──▶ Lambda 함수 실행
SNS (알림 발행) ─┤
SQS (큐 메시지 도착) ─┤
EventBridge (규칙 매칭) ─┘내가 겪은 건 이 중 SNS 트리거였고 강의에 나온 다른 사례는 EventBridge 트리거였다.
CloudTrail ──(API 호출 기록)──▶ EventBridge ──(규칙 감지)──▶ Lambda ──▶ 자동 대응결국 트리거의 종류만 다를 뿐이지 무언가 감지되면 그 처리를 Lambda가 떠맡는다는 패턴은 동일했다.
활용 범위
- 운영 자동화 → CloudWatch Alarm 발생 시 Lambda로 알림/재시작 처리 (← 내가 겪은 사례)
- 웹 애플리케이션 → API Gateway와 연결해 서버 없이 백엔드 API 구성
- 배치 처리 → 정해진 시간에 대량 데이터를 일괄 처리
- 실시간 파일 처리 → S3에 파일 업로드 시 썸네일 생성 등 후처리
- 실시간 스트림 처리 → Kinesis 등으로 들어오는 스트리밍 데이터 처리
- IoT 백엔드 → IoT 디바이스에서 들어오는 이벤트 처리
- 모바일 백엔드 → 모바일 앱의 백엔드 로직 처리
- 자동화된 보안 대응 → CloudTrail 이벤트를 EventBridge로 받아 자동 대응
📍 출처: 패스트캠퍼스 강의 - 실전 DevOps의 모든 것
