SW BBANG K

RDS 스냅샷 복원을 처음 시도하는 엔지니어들이 가장 많이 하는 실수가 있다. '복원하면 기존 DB가 덮어써지겠지'라고 가정하고 애플리케이션 설정을 그대로 두는 것이다. 실제로는 RDS 스냅샷 복원은 항상 새로운 DB 인스턴스를 생성 하며, 엔드포인트도 완전히 달라진다. 이 동작을 모르면 복원 후 애플리케이션이 여전히 구 인스턴스(또는 없는 인스턴스)에 연결을 시도하는 상황이 발생한다. TL;DR — RDS 스냅샷 복원 핵심 요약 항목 동작 기존 인스턴스 덮어쓰기 여부 ❌ 덮어쓰지 않음. 항상 신규 인스턴스 생성 엔드포인트 변경 여부 ✅ 새 인스턴스 식별자 기반의 새 엔드포인트 생성 기존 인스턴스 상태 복원 후에도 기존 인스턴스는 그대로 유지됨 파라미터 그룹 / 보안 그룹 기본값으로 초기화됨 — 수동 재적용 필요 애플리케이션 연결 문자열 새 엔드포인트로 업데이트 필요 Multi-AZ / 스토리지 설정 스냅샷에서 복원되지 않음 — 복원 시 재지정 필요 RDS 스냅샷 복원 동작 원리 RDS 스냅샷은 특정 시점의 스토리지 볼륨 전체를 캡처한 것이다. 복원 명령을 실행하면 AWS는 해당 스냅샷 데이터를 기반으로 완전히 독립된 새 DB 인스턴스를 프로비저닝한다. 기존 인스턴스의 데이터를 교체하거나 덮어쓰는 개념이 아니다. 새 인스턴스는 복원 시 지정한 --db-instance-identifier 값을 기반으로 고유한 DNS 엔드포인트를 갖는다. 기존 인스턴스와 신규 인스턴스는 복원 직후 동시에 존재하며, 각자 독립적인 엔드포인트를 가진다. ...

SQS 큐에서 메시지가 두 개의 컨슈머에 의해 동시에 처리되는 현상을 프로덕션에서 처음 마주치면, 대부분 애플리케이션 코드나 멱등성 로직을 먼저 의심한다. 하지만 실제 원인은 대부분 더 단순한 곳에 있다 — Visibility Timeout 이 처리 시간보다 짧게 설정되어 있는 것이다. 이 설정 하나가 SQS 중복 처리 문제의 가장 흔한 원인이다. TL;DR — SQS Visibility Timeout 핵심 요약 항목 내용 Visibility Timeout 역할 메시지를 수신한 후 다른 컨슈머에게 보이지 않도록 숨기는 시간 기본값 30초 설정 범위 0초 ~ 12시간 중복 처리 발생 조건 처리 시간 > Visibility Timeout 권장 설정 최대 처리 시간의 6배 이상 (AWS 권장) 런타임 연장 방법 ChangeMessageVisibility API 호출 삭제 타이밍 처리 완료 후 반드시 DeleteMessage 호출 SQS Visibility Timeout 동작 원리 SQS는 메시지 브로커가 아니라 분산 큐다. 컨슈머가 메시지를 ReceiveMessage 로 가져가도 메시지는 큐에서 즉시 삭제되지 않는다. 대신 Visibility Timeout 동안 다른 컨슈머에게 보이지 않는 상태(invisible)로 전환된다. 컨슈머가 처리를 완료하고 DeleteMessage 를 호출해야 비로소 큐에서 제거된다. Visibility Timeout이 만료되기 전에 DeleteMessage 가 호출되지 않으면, SQS는 해당 메시지를 다시 visible 상태로 되돌린다. 이 순간 다른 컨슈머(또는 동일 컨슈머의 다른 인스턴스)가 동일 메시지를 다시 수신할 수 있게 된다. 이것이 중복 처리의 정확한 메커니즘이다. sequenceDiagram participant Q a...