안정적인 메시지 큐 운영을 위한 Heartbeat 시스템 디자인
2026, Jan 08
S3 파일 업로드 이벤트를 SQS로 전달하고 ECS에서 처리하는 시스템에서, 일회성 Task 실행 방식의 한계를 Netflix의 Heartbeat 패턴으로 개선한 경험을 공유합니다.
기존 아키텍처의 문제점
Push 모델 흐름
S3 파일 업로드 → Lambda → SQS + ECS Task 실행 → 일회성 처리 후 종료
문제점
| 문제 | 설명 |
|---|---|
| 일회성 실행 | Task가 메시지 처리 후 즉시 종료, 실패 시 재시도 없음 |
| DLQ 미작동 | 메시지를 한 번만 수신하므로 Receive Count가 증가하지 않음 |
| 리소스 낭비 | 메시지마다 Task 생성/종료 오버헤드, 시작 지연 발생 |
Heartbeat 패턴으로 개선
Pull 모델 흐름
S3 파일 업로드 → Lambda → SQS → 상시 실행 ECS가 Polling하여 처리
Heartbeat 패턴이란?
Consumer가 지속적으로 실행되며 주기적으로 큐를 polling하는 방식입니다. 심장 박동처럼 일정한 간격으로 메시지를 확인하고 처리합니다.
개선 효과
재시도 및 DLQ 정상 작동
- 처리 실패 시 메시지를 삭제하지 않음
- Visibility Timeout 후 메시지가 다시 visible → 재수신 → Receive Count 증가
- 설정 횟수 초과 시 DLQ로 자동 이동
리소스 효율성
- Task 생성/종료 오버헤드 제거
- 메모리, DB 연결 등 리소스 재사용
안정성
this.shutdownProvider.subscribeToShutdown(() => {
this.isRunning = false;
});
- Graceful Shutdown으로 메시지 유실 방지
- 개별 메시지 실패가 전체 시스템에 영향 없음
운영 설정
SQS
| 설정 | 권장값 | 비고 |
|---|---|---|
| Visibility Timeout | 300초 | 처리 시간보다 충분히 길게 |
| maxReceiveCount | 3 | DLQ 이동 기준 |
| Wait Time | 20초 | Long polling으로 비용 절감 |
Application
| 설정 | 권장값 |
|---|---|
| Polling Interval | 1초 |
| Concurrency | 순차 처리 (필요시 병렬 확장) |
결론
Heartbeat 패턴 도입으로 자동 재시도, DLQ 정상 작동, 리소스 효율성, 에러 격리를 달성하여 프로덕션 환경에서 안정적인 메시지 처리 시스템을 구축했습니다.