서버리스 아키텍처
서버리스 구성에서도 용량, 실패 처리, 재시도, 실행 시간은 설계자가 정해야 한다. Lambda가 요청을 처리하고 SQS가 작업을 완충하는지, SNS나 EventBridge가 여러 소비자로 라우팅하는지에 따라 장애 전파와 비용이 달라진다. 이 글은 각 서비스를 따로 외우기보다 이벤트가 들어와 완료될 때까지의 흐름으로 정리한다.
1. Lambda
핵심 개념
이벤트 소스 (트리거)
→ Lambda 함수 실행 (최대 15분)
→ 결과 반환 or 다음 서비스 호출
- 지원 런타임: Node.js, Python, Java, Go, Ruby, .NET, 커스텀 런타임
- 메모리: 128MB ~ 10,240MB (CPU는 메모리에 비례해 자동 할당)
- 최대 실행 시간: 15분 (긴 작업은 Step Functions으로)
- 배포 패키지: ZIP (50MB) or 컨테이너 이미지 (10GB)
Cold Start vs Warm Start
Cold Start: 컨테이너 초기화 → 런타임 초기화 → 핸들러 실행
Warm Start: 기존 컨테이너 재사용 → 핸들러 실행
Cold Start 최소화 방법
- Provisioned Concurrency: 미리 초기화된 실행 환경 유지 (비용 발생)
- 메모리 증가: 초기화 시간 단축
- Java 대신 Python/Node.js: 런타임 초기화 빠름
- Lambda SnapStart (Java 11+): 스냅샷 기반 빠른 초기화
SAP 핵심: 지연 시간에 민감한 서비스 + Lambda = Provisioned Concurrency
동시성 (Concurrency)
계정 기본 동시성: 1,000 (리전별, 증가 요청 가능)
Reserved Concurrency — 함수에 최대 동시성 예약 (다른 함수로부터 격리)
Provisioned Concurrency — 미리 초기화된 실행 환경 확보 (Cold Start 제거)
동시성 스로틀링
- 동시성 한도 초과 시 → 429 TooManyRequestsException
- SQS 트리거: 스로틀 시 메시지 큐에 보관, 재시도
- API Gateway 트리거: 즉시 503 반환
| 설정 | 목적 |
|---|---|
| Reserved Concurrency = 0 | 함수 비활성화 |
| Reserved Concurrency = N | 최대 N개로 제한 (중요 함수 격리) |
| Provisioned Concurrency | Cold Start 없는 즉시 응답 |
Lambda 레이어 (Layer)
- 공통 라이브러리, 의존성을 레이어로 분리
- 최대 5개 레이어 첨부, 압축 해제 후 총 250MB 제한
- 레이어는 여러 함수에서 공유 가능
함수 코드 (비즈니스 로직)
+ 레이어 1 (pandas, numpy)
+ 레이어 2 (공통 유틸리티)
= 실행 환경
Lambda 컨테이너 이미지
- Docker 이미지로 함수 패키징 (최대 10GB)
- Lambda Runtime Interface Client(RIC) 포함 필요
- 대용량 ML 모델, 복잡한 의존성에 적합
이벤트 소스 유형
동기 호출 (Synchronous)
- API Gateway, ALB, Cognito, Lex, CloudFront
- 응답을 즉시 반환, 오류 시 호출자가 재시도 책임
비동기 호출 (Asynchronous)
- S3, SNS, EventBridge, CloudWatch Events
- 이벤트 큐에 보관 → 최대 2회 재시도
- DLQ(Dead Letter Queue)로 실패 이벤트 캡처
폴링 기반 (Poll-Based)
- SQS, Kinesis, DynamoDB Streams, MSK
- Lambda가 소스를 직접 폴링
- 배치 처리, 오류 시 재처리 가능
VPC Lambda
Lambda를 VPC 내 리소스(RDS, ElastiCache)에 접근시키려면 VPC 설정 필요.
Lambda (VPC 설정)
→ 프라이빗 서브넷 ENI 생성
→ RDS, ElastiCache 접근 가능
주의: VPC Lambda는 인터넷 접근 불가 → NAT Gateway 또는 VPC Endpoint 필요
Lambda 권한 모델
- 실행 역할(Execution Role): Lambda가 AWS 서비스에 접근하는 권한
- 리소스 기반 정책(Resource Policy): 다른 서비스가 Lambda를 호출하는 권한
S3 → Lambda 호출: S3가 Lambda 리소스 기반 정책에 허용되어야 함
Lambda → DynamoDB 조회: 실행 역할에 dynamodb:GetItem 권한 필요
2. API Gateway
유형 비교
| 유형 | 특성 | 사용 시나리오 |
|---|---|---|
| REST API | 풍부한 기능 (캐싱, WAF, 사용량 계획) | 외부 공개 API, 세밀한 제어 필요 |
| HTTP API | 저비용, 저지연, OIDC/JWT 인증 | 내부 API, Lambda Proxy, 저비용 |
| WebSocket API | 양방향 실시간 통신 | 채팅, 알림, 실시간 대시보드 |
SAP 핵심: 비용 최적화 + Lambda = HTTP API / 캐싱·WAF·사용량 제한 = REST API
REST API 주요 기능
캐싱
- 응답을 TTL(기본 300초) 동안 캐시
- 동일 요청 반복 시 Lambda 호출 없이 캐시 반환
- 비용 절감 + 지연 감소
사용량 계획 (Usage Plan)
API 키 발급 → 사용량 계획 연결
→ 요청 제한: 초당 1,000건
→ 버스트: 2,000건
→ 월 할당량: 1,000,000건
스테이지 (Stage)
- dev, staging, prod 환경 분리
- 스테이지 변수로 Lambda 별칭 연결 → 환경별 다른 함수 버전 실행
통합 유형 | 유형 | 설명 | |------|------| | Lambda Proxy | 요청 전체를 Lambda에 전달, 응답 그대로 반환 | | Lambda (커스텀) | 요청/응답 변환 (Mapping Template) | | HTTP Proxy | 외부 HTTP 엔드포인트로 프록시 | | AWS Service | AWS 서비스 직접 호출 (Lambda 없이 SQS, DynamoDB 등) | | Mock | 백엔드 없이 하드코딩 응답 반환 |
엔드포인트 유형
엣지 최적화 (Edge-Optimized) — CloudFront 통해 전역 배포 (기본)
리전 (Regional) — 같은 리전 클라이언트, VPC Endpoint 연동
프라이빗 (Private) — VPC 내부에서만 접근 가능
3. SQS (Simple Queue Service)
핵심 개념
SQS는 **생산자와 소비자를 분리(디커플링)**하는 메시지 큐다. 소비자가 느리거나 다운돼도 메시지는 큐에 보존된다.
생산자 → SQS 큐 → 소비자 (폴링)
큐 유형
| 유형 | 특성 |
|---|---|
| 표준 큐 (Standard) | 최소 1회 전달, 순서 미보장, 초당 무제한 처리량 |
| FIFO 큐 | 정확히 1회 전달, 순서 보장, 초당 최대 300건 (배치 시 3,000건) |
SAP 핵심: 순서·중복 방지 중요 = FIFO / 최대 처리량 = 표준 큐
주요 파라미터
| 파라미터 | 설명 | 기본값 |
|---|---|---|
| 가시성 타임아웃 | 소비자가 처리 중인 동안 다른 소비자에게 숨김 | 30초 |
| 메시지 보존 기간 | 큐에 메시지 보존 최대 기간 | 4일 (최대 14일) |
| 배달 지연 | 메시지 전달 전 지연 시간 | 0초 (최대 15분) |
| 최대 메시지 크기 | 단일 메시지 최대 크기 | 256KB |
| 수신 대기 시간 | Long Polling 대기 시간 | 0초 (최대 20초) |
가시성 타임아웃 설정 핵심
- 처리 시간보다 충분히 길게 설정
- 타임아웃 내 처리 완료 → 메시지 삭제
- 타임아웃 초과 → 다른 소비자에게 재전달 (중복 처리 주의)
Long Polling vs Short Polling
Short Polling: 즉시 응답 (메시지 없으면 빈 응답) → API 호출 비용 낭비
Long Polling : 메시지 도착까지 최대 20초 대기 → 비용 절감, 권장
Dead Letter Queue (DLQ)
소비자가 N회 처리 실패
→ DLQ로 이동 (최대 수신 수 초과)
→ 분석·재처리·알림
- DLQ도 SQS 큐 (표준 → 표준 DLQ, FIFO → FIFO DLQ)
- Lambda + SQS: DLQ 설정으로 처리 실패 메시지 보존
SQS + Lambda 연동
SQS 큐 → Lambda (이벤트 소스 매핑)
- Lambda가 큐를 폴링
- 배치 크기: 1~10,000개
- 배치 처리 실패 시 전체 배치 재처리 (일부 성공 보고 가능)
4. SNS (Simple Notification Service)
핵심 개념
SNS는 **하나의 메시지를 여러 구독자에게 동시에 전달(팬아웃)**하는 Pub/Sub 서비스다.
게시자 (Publisher)
→ SNS 토픽
├── SQS 큐 (구독 1)
├── Lambda (구독 2)
├── HTTP/HTTPS 엔드포인트 (구독 3)
├── 이메일 (구독 4)
└── SMS (구독 5)
SNS vs SQS
| 항목 | SNS | SQS |
|---|---|---|
| 패턴 | Pub/Sub (팬아웃) | 큐 (폴링) |
| 전달 | 즉시 푸시 | 소비자가 폴링 |
| 보존 | 없음 (전달 실패 시 소멸) | 최대 14일 |
| 소비자 수 | 다수 동시 | 보통 하나씩 |
SNS + SQS 팬아웃 패턴
S3 이벤트 (1건)
→ SNS 토픽
├── SQS A (이미지 리사이즈 처리)
├── SQS B (메타데이터 추출 처리)
└── SQS C (CDN 캐시 무효화 처리)
S3는 이벤트 대상을 하나만 설정 가능 → SNS를 거쳐 여러 SQS로 팬아웃
메시지 필터링
SNS 토픽
→ SQS A (filter: type=order) → 주문 관련만 수신
→ SQS B (filter: type=payment) → 결제 관련만 수신
SNS FIFO
- 토픽 내 메시지 순서 보장
- 중복 제거 지원
- SQS FIFO 큐와 연동 가능 (SNS FIFO → SQS FIFO)
5. Kinesis
서비스 구성
Kinesis Data Streams — 실시간 스트림 수집·처리
Kinesis Data Firehose — 스트림 → S3·Redshift·OpenSearch 적재
Managed Service for Apache Flink — 상태 기반 스트림 실시간 처리
Kinesis Data Streams
핵심 구조
생산자 (Producer)
→ 샤드 (Shard) × N개
→ 소비자 (Consumer)
- 샤드 1개: 초당 1MB 입력, 2MB 출력, 1,000건 PUT
- 데이터 보존: 기본 24시간, 최대 365일
- 소비자: Lambda, KCL(Kinesis Client Library), Managed Service for Apache Flink
샤드 수 계산
필요 샤드 수 = max(입력 MB/s, 출력 MB/s ÷ 2)
소비 모드 | 모드 | 특성 | |------|------| | 공유 팬아웃 | 샤드당 2MB/s를 모든 소비자가 공유 | | 향상된 팬아웃 | 소비자당 샤드당 2MB/s 전용 (추가 비용) |
Kinesis Data Firehose
- 완전 관리형: 샤드·소비자 관리 불필요
- Near Real-Time: 60초 또는 1MB 단위로 배치 적재
- 변환: Lambda로 데이터 가공 후 적재
- 목적지: S3, Redshift, OpenSearch, Splunk, HTTP 엔드포인트
생산자 → Firehose → (Lambda 변환) → S3 / Redshift / OpenSearch
Kinesis vs SQS 비교
| 항목 | Kinesis Streams | SQS |
|---|---|---|
| 순서 | 샤드 내 순서 보장 | FIFO만 보장 |
| 소비자 수 | 다수 동시 소비 | 보통 단일 처리 |
| 보존 | 24시간~365일 | 최대 14일 |
| 재처리 | 보존 기간 내 가능 | 삭제 후 불가 |
| 처리량 | 샤드 기반 확장 | 거의 무제한 |
| 사용 사례 | 로그·클릭스트림·IoT | 작업 큐·디커플링 |
6. Step Functions
핵심 개념
Step Functions는 여러 Lambda와 AWS 서비스를 순서대로 조합하는 워크플로우 서비스다. 상태 머신(State Machine)으로 워크플로우를 정의한다.
Lambda가 15분 이상 걸리는 작업
복잡한 분기·병렬·재시도 로직
사람의 승인이 필요한 프로세스
→ Step Functions 사용
상태 유형
| 상태 | 설명 |
|---|---|
| Task | Lambda, ECS, DynamoDB 등 작업 실행 |
| Choice | 조건 분기 (if/else) |
| Parallel | 여러 브랜치 병렬 실행 |
| Map | 배열 항목에 반복 실행 |
| Wait | 지정 시간 또는 특정 시각까지 대기 |
| Pass | 입력을 출력으로 그대로 전달 |
| Succeed / Fail | 실행 종료 |
워크플로우 유형
| 유형 | 특성 | 사용 시나리오 |
|---|---|---|
| 표준 (Standard) | 최대 1년, 정확히 1회 실행, 상태 기록 | 장기 프로세스, 감사 필요 |
| 익스프레스 (Express) | 최대 5분, 고처리량, 저비용 | IoT 수집, 이벤트 처리 |
주요 패턴
패턴 1: 승인 대기 (Wait for Callback)
Step Functions → Lambda (이메일 발송 + 토큰 전달)
→ 사람이 승인 링크 클릭
→ SendTaskSuccess API 호출
→ 다음 단계 진행
패턴 2: 병렬 처리 후 집계
Parallel 상태
├── 브랜치 A: 이미지 리사이즈
├── 브랜치 B: 메타데이터 추출
└── 브랜치 C: 워터마크 삽입
→ 모든 브랜치 완료 후 결과 집계 → S3 저장
패턴 3: 재시도 및 오류 처리
Task 상태 실행
→ 실패 시: Retry (간격·횟수 설정)
→ 재시도 소진 시: Catch → 오류 처리 람다
7. 서버리스 아키텍처 패턴
패턴 1: API 기반 CRUD
클라이언트
→ API Gateway (REST API)
→ Lambda (비즈니스 로직)
→ DynamoDB (데이터 저장)
패턴 2: 이벤트 기반 비동기 처리
S3 파일 업로드
→ SNS 토픽 (팬아웃)
├── SQS A → Lambda (썸네일 생성)
├── SQS B → Lambda (바이러스 검사)
└── SQS C → Lambda (메타데이터 추출)
패턴 3: 실시간 스트림 처리
IoT 디바이스 / 웹 클릭스트림
→ Kinesis Data Streams
├── Lambda (실시간 이상 탐지)
└── Kinesis Firehose → S3 (배치 분석용)
패턴 4: 복잡한 주문 처리 워크플로우
API Gateway → Lambda (주문 접수)
→ Step Functions
├── Task: 재고 확인 (Lambda)
├── Choice: 재고 있음?
│ ├── Yes → Task: 결제 처리 (Lambda)
│ │ → Task: 배송 요청 (Lambda)
│ │ → Task: 알림 발송 (SNS)
│ └── No → Task: 대기 등록 (DynamoDB)
│ → Task: 재고 부족 알림 (SNS)
└── 완료
패턴 5: 서버리스 데이터 수집 파이프라인
클라이언트
→ API Gateway → Kinesis Firehose (Lambda 없이 직접 통합)
→ S3 (원본 데이터)
→ Glue (ETL)
→ Redshift / Athena (분석)
8. 서비스 간 비교 정리
메시징 서비스 선택 기준
| 요구사항 | 선택 |
|---|---|
| 다수 구독자에게 동시 전달 | SNS |
| 순서 보장 없는 작업 큐 | SQS 표준 |
| 순서 보장 + 중복 방지 | SQS FIFO |
| 실시간 스트림 + 재처리 | Kinesis Streams |
| 스트림 → S3/Redshift 적재 | Kinesis Firehose |
| 복잡한 워크플로우 | Step Functions |
Lambda 호출 방식별 오류 처리
| 호출 방식 | 오류 처리 |
|---|---|
| 동기 (API Gateway) | 호출자가 재시도 |
| 비동기 (S3, SNS) | Lambda 자동 재시도 2회 → DLQ |
| 폴링 (SQS) | 가시성 타임아웃 후 재전달 → DLQ |
| 폴링 (Kinesis) | 샤드 내 재처리 (보존 기간 내) |
9. 핵심 암기 포인트
| 키워드 | 선택 |
|---|---|
| Lambda Cold Start 제거 | Provisioned Concurrency |
| Lambda 실행 시간 15분 초과 | Step Functions + Lambda 조합 |
| Lambda + 공통 라이브러리 공유 | Lambda Layer |
| API Gateway 간단한 프록시 요구 | HTTP API (필요 기능과 총요금 비교) |
| API Gateway 캐싱·WAF·사용량 제한 | REST API |
| 실시간 양방향 통신 | WebSocket API |
| 메시지 순서 보장 + 중복 방지 | SQS FIFO |
| S3 이벤트 → 다수 처리 시스템 | SNS 팬아웃 → 각 SQS |
| 실시간 로그·IoT 스트림 수집 | Kinesis Data Streams |
| 스트림 → S3/Redshift 자동 적재 | Kinesis Firehose |
| 복잡한 분기·병렬·승인 워크플로우 | Step Functions |
| 사람 개입(승인) 포함 자동화 | Step Functions Wait for Callback |
| Lambda가 RDS 접근 필요 | VPC Lambda + NAT Gateway or VPC Endpoint |
| Lambda 동시성 제한으로 다른 함수 보호 | Reserved Concurrency |
핵심 내용을 다시 정리하면
- Lambda: Cold Start는 Provisioned Concurrency로 해결, 15분 초과 작업은 Step Functions로
- API Gateway: HTTP API(저비용)와 REST API(기능 풍부) 차이를 명확히
- SQS: 표준(처리량) vs FIFO(순서·중복) 구분, 가시성 타임아웃과 DLQ 이해
- SNS: 팬아웃 패턴, SQS와 조합해 다수 구독자에게 안정적 전달
- Kinesis: 실시간 스트림은 Streams, 적재는 Firehose, SQS와의 차이는 재처리 가능 여부
- Step Functions: Lambda 조합·분기·병렬·승인 등 복잡한 워크플로우의 답
이어 읽기: 12. 컨테이너 서비스 선택 기준