SQS는 마이크로서비스, 분산 시스템 및 서버리스 애플리케이션을 분해하고 확장할 수 있게 해주는 완전 관리형 메시지 대기열(Message Queue) 서비스이다.

1. 왜 메시지 큐(SQS)를 사용할까?

1.1. 디커블링 (Decoupling, 결합도 낮추기)

• 상황: 주문 서버가 결제 서버에 직접 요청을 보낼 때, 결제 서버가 점검 중이면 주문 자체가 실패한다.
• 해결: 주문 서버는 SQS에 “결재”라는 메시지만 던지고 자신의 일을 수행한다. 결제 서버는 나중에 살아났을 때 큐에서 메시지를 꺼내 처리하면 된다.

1.2. 부하 분산 (Load Smoothing)

• 상황: 갑자기 트래픽이 몰려 초당 1만 건의 요청이 들어왔을 때, 서버가 이를 감당하지 못하고 죽어버릴 수 있다.
• 해결: 모든 요청을 일단 SQS에 쌓아둔다. 서버는 자신이 처리할 수 있는 속도만큼만 큐에서 가져와 차근차근 처리한다.

2. SQS의 두 가지 유형

2.1. 표준 대기려 (Standard Queues)

• 처리량: 거의 무제한의 처리량을 제공한다.
• 순서: 메시지 전달 순서가 보장되지 않을 수 있다.
• 전달 횟수: 최소 한 번 전달을 보장한다. (하지만 드물게 중복 메시지가 발생할 수 있다)

2.2. FIFO 대기열 (First-In-First-Out)

• 처리량: 초당 최대 3000건 정도로 제한된다.
• 순서: 보낸 순서대로 정확히 처리된다
• 전달 횟수: 정확히 한 번 전달한다.
• 용도: 금용 거래, 티켓 예매 등 순서가 엄격히 중요한 경우에 사용한다.

3. 백엔드 개발자가 알아야 할 핵심 파라미터

• Visibility Timeout (가시성 제한 시간): 소비자가 큐에서 메시지를 가져간 순간부터 다른 소비자가 그 메시지를 볼 수 없는 시간이다. 이 시간 내에 처리를 완료하고 메시지를 명시적으로 삭제해야 한다. 처리하지 못하면 메시지는 큐에 다시 나타난다.
• Dead Letter Queue (DLQ, 데드 레터 큐): 여러 번 시도해도 실패한 ‘문제 있는 메시지’들은 따로 모아두는 저장소이다. 나중에 개발자가 왜 실패했는지 로그를 보고 분석할 수 있다.
• Long Polling: 큐에 메시지가 없을 때 무조건 응답을 받는 대신, 메시지가 들어올 때까지 일정 시간(최대 20초) 기다리는 방식이다. API 호출 횟수를 줄여 비용을 획기적으로 아껴준다.

4. 실무 활용 시나리오

• 비동기 작업 처리(이메일 발송, 푸시 알림): 사용자가 회원가입을 하면 API 서버는 즉시 응답을 주고 SQS에 이메일 발송 요청을 넣는다. 별도의 Worker 서버가 큐를 모니터링하다가 이메일을 발송한다. 사용자 대기 시간을 줄여준다.
• 외부 API 연동: 연동하는 외부 API 업체가 응답이 느리거나 자주 장애가 난다면 요청을 SQS에 넣고 재시도 로직을 적용하여 데이터 유실을 방지한다.
• 데이터 분석 파이프라인: 로그 데이터를 수집하여 분석 서버로 보낼 때, 트래픽 변화에 유연하게 대응하기 위해 중간에 SQS를 완충지로 두기도 한다.