[AWS DEA] 문제로 공부하기 11 - 유지 기간 연장 + DLQ 연결

AWS DEA-C01 Amazon SQS 메시지 유지 기간 Dead Letter Queue 데이터 손실 방지

SQS 다운타임 메시지 손실 방지 — 유지 기간 연장 + DLQ 연결이 정답인 이유

AWS DEA-C01 시험에 자주 나오는 SQS 메시지 손실 방지 문제입니다. 애플리케이션 다운타임으로 메시지가 만료·삭제되는 상황에서 메시지 유지 기간 연장(최대 14일)과 DLQ(Dead Letter Queue) 연결이 정답인 이유를, 가시성 시간 제한·지연 대기열·처리 시간 단축과 비교하여 도식으로 정리합니다.

📋 문제

한 애플리케이션에서는 Amazon SQS 대기열의 메시지를 처리한다. 애플리케이션에는 가끔 다운타임이 발생한다. 다운타임으로 인해 대기열 내의 메시지가 만료되고 1일 후에 삭제된다. 메시지를 삭제하면 애플리케이션의 데이터가 손실된다.

다음 중 애플리케이션의 데이터 손실을 최소화하는 솔루션은 무엇인가? (2개 선택)

✅ 핵심 상황 분석

• ⏰
  현재 유지 기간: 1일 (기본값)
  SQS 기본 메시지 유지 기간은 4일, 문제 상황에서는 1일로 설정되어 있어 다운타임 시 만료 위험 큼
• 💀
  다운타임 → 메시지 미처리 → 만료 → 삭제 → 데이터 손실
  처리되지 않은 채 유지 기간이 지난 메시지는 SQS에서 영구 삭제됨
• 🎯
  목표: 메시지가 삭제되기 전에 처리하거나, 삭제 후에도 재처리 가능하도록 보존
  유지 기간 연장(삭제 전 버퍼 확보) 또는 DLQ(삭제 대신 이동)로 해결

📐 SQS 메시지 생명주기 — 정상 vs 다운타임 상황

🔄 정상 처리 흐름

Producer → SQS 대기열 전송

→

Consumer 폴링 (가시성 타임아웃)

→

처리 완료 → 삭제

⚠️ 다운타임 발생 시 — 해결책 없는 경우

SQS 대기열에 메시지 대기

→

Consumer 다운 (처리 불가)

→

유지 기간(1일) 초과

→

메시지 영구 삭제 💀

✅ 해결책 A — 유지 기간 연장 (최대 14일)

Consumer 다운

→

메시지 대기 (최대 14일 유지)

→

복구 후 정상 처리 ✅

✅ 해결책 C — DLQ 연결

만료·처리 실패 메시지

→

DLQ로 이동 (삭제 대신)

→

나중에 검토·재처리 ✅

⏱️ 메시지 유지 기간 설정 범위

현재 설정 (1일) ❌

1일 💀

기본값 (4일)

4일

최대값 (14일) ✅

14일 (권장) ✅

DLQ 추가 보관

DLQ 유지 기간도 별도 설정 가능 🛟

🔍 SQS 5가지 기능 — 데이터 손실 방지 효과 비교

📅

메시지 유지 기간 연장 ⭐

범위 1분 ~ 14일

다운타임 ✅ 직접 해결

만료 방지 ✅ 버퍼 확보

복구 후 ✅ 자동 처리

✅ 다운타임 중 메시지 보존

📬

DLQ 연결 ⭐

동작 만료/실패 → DLQ 이동

데이터 보존 ✅ 삭제 대신 저장

재처리 ✅ 검토 후 가능

모니터링 ✅ 실패 추적 가능

✅ 만료 메시지 유실 방지

👁️

가시성 시간 제한

목적 처리 중 재전달 방지

다운타임 ❌ 해결 불가

만료 방지 ❌ 효과 없음

유지 기간 ❌ 영향 없음

❌ 만료·삭제 문제 미해결

⏳

지연 대기열

목적 전달 시점 지연

다운타임 ❌ 해결 불가

만료 방지 ❌ 효과 없음

최대 지연 15분

❌ 전달 타이밍만 변경, 손실 무관

⚠️ 핵심 함정: 가시성 시간 제한은 메시지를 처리 중인 동안 다른 Consumer가 가져가지 못하도록 숨기는 기능입니다. 다운타임으로 인한 메시지 만료·삭제 문제와 전혀 무관합니다.

📝 선택지 해설

✅ 복수 정답 (2개 선택)

A

✅ 메시지 유지 기간을 늘린다

현재 1일 → 최대 14일까지 연장 가능 — 다운타임 중 메시지 만료 방지

💡 정답. 메시지 유지 기간(Message Retention Period)을 늘리면 메시지가 SQS 대기열에 더 오래 남아 있을 수 있습니다. 현재 1일로 설정된 유지 기간을 최대 14일까지 늘리면 애플리케이션이 다운된 동안에도 메시지가 삭제되지 않고 대기열에 유지됩니다. 애플리케이션이 복구되면 만료 없이 쌓인 메시지를 모두 정상 처리할 수 있습니다. 설정 범위: 최소 1분 ~ 최대 14일 (기본값 4일).

B

❌ 가시성 시간 제한을 늘린다

처리 중 재전달 방지 목적 — 만료·삭제 문제와 무관

💡 가시성 시간 제한(Visibility Timeout)은 Consumer가 메시지를 가져간 후 처리 완료 전에 다른 Consumer가 동일 메시지를 가져가지 못하도록 일시적으로 숨기는 시간입니다. 이것을 늘려도 애플리케이션이 완전히 다운된 상태에서 메시지를 가져가지 않는 문제를 해결할 수 없습니다. 유지 기간이 지나면 메시지는 여전히 만료·삭제됩니다.

C

✅ 배달 못 한 편지 대기열(DLQ)을 SQS 대기열에 연결한다

만료·처리 실패 메시지를 삭제 대신 DLQ로 이동 → 나중에 검토·재처리 가능

💡 정답. DLQ(Dead Letter Queue)를 원본 SQS 대기열에 연결하면 최대 수신 횟수(maxReceiveCount)를 초과하거나 만료된 메시지가 영구 삭제되는 대신 DLQ로 자동 이동됩니다. DLQ에 보관된 메시지는 나중에 원인 분석, 검토, 재처리가 가능합니다. 다운타임으로 처리되지 못한 메시지가 사라지지 않고 DLQ에 안전하게 저장되므로 데이터 손실을 방지할 수 있습니다. DLQ도 유지 기간을 별도로 설정할 수 있습니다.

D

❌ 지연 대기열로 메시지 전달을 지연한다

소비자에게 보이는 시점만 늦춤 — 만료 카운트는 전달 시점부터가 아닌 수신 시점부터 진행

💡 지연 대기열(Delay Queue)은 메시지가 Consumer에게 보이는 시점을 최대 15분까지 지연시킵니다. 전달 시점을 늦춰도 메시지 유지 기간(만료 타이머)에는 영향을 주지 않습니다. 메시지는 SQS에 수신된 시점부터 유지 기간 카운트가 시작되므로, 전달을 지연해도 다운타임 중 만료되는 문제를 해결할 수 없습니다.

E

❌ 메시지 처리 시간을 줄인다

처리 효율 향상 — 다운타임 중 처리 자체가 불가능한 상황에는 효과 없음

💡 처리 시간을 줄이면 정상 운영 시 처리 효율이 높아지는 장점이 있습니다. 그러나 애플리케이션이 완전히 다운된 상태에서는 처리 속도와 무관하게 메시지를 소비할 수 없습니다. 다운타임 중에는 아무리 빠른 처리 로직을 구현해도 메시지가 만료·삭제되는 것을 직접적으로 방지할 수 없습니다.

정답 및 핵심 정리 (클릭)

정답: A + C — 유지 기간 연장 + DLQ 연결

두 정답은 서로 다른 레이어에서 데이터 손실을 방지합니다. A(유지 기간 연장)는 메시지가 만료되기 전 버퍼 시간을 확보하고, C(DLQ)는 혹시 만료되더라도 영구 삭제 대신 별도 대기열에 보존합니다. 두 방법을 함께 사용하면 이중 안전망을 구성할 수 있습니다.

# SQS 주요 기능 목적 비교 기능 목적 다운타임 해결? ────────────────────────────────────────────────────────────── 메시지 유지 기간 연장 만료 전 대기 시간 확보 ✅ 직접 해결 DLQ 연결 만료/실패 메시지 보존 ✅ 직접 해결 가시성 시간 제한 처리 중 중복 소비 방지 ❌ 무관 지연 대기열 Consumer 노출 시점 지연 ❌ 무관 처리 시간 단축 정상 처리 효율화 ❌ 무관 # 유지 기간 설정 최소: 1분 (60초) 기본: 4일 최대: 14일 ← 권장 # DLQ 활용 패턴 소스 대기열 → (maxReceiveCount 초과 or 만료) → Dead Letter Queue → 검토·재처리

📊 선택지 비교 요약

선택지	기능	목적	다운타임 해결	데이터 보존	결론
A ⭐	유지 기간 연장	만료 시간 연장	✅ 직접 해결	최대 14일	정답
B	가시성 시간 제한	중복 소비 방지	❌ 무관	효과 없음	탈락
C ⭐	DLQ 연결	실패 메시지 보존	✅ 간접 해결	삭제 대신 이동	정답
D	지연 대기열	전달 시점 지연	❌ 무관	효과 없음	탈락
E	처리 시간 단축	처리 효율 향상	❌ 무관	효과 없음	탈락

#AWS_DEA-C01 #AmazonSQS #SQS메시지유지기간 #SQS_DLQ #DeadLetterQueue #배달못한편지대기열 #SQS가시성시간제한 #지연대기열 #메시지만료 #데이터손실방지 #AWS자격증 #AWS데이터엔지니어