직접 만든 소프트웨어, 두 가지 개발 기록 구현 구조와 적용 범위, 확인한 기능과 남은 한계를 함께 기록합니다. MediaMTX 스트리밍 제어 서버Docker Compose 구성과 파일·라이브·멀티캐스트 송출 RTSP CCTV 관제·분석 프로그램관제 그룹, 영역·출입선, 이벤트 이력을 연결하는 구조 SQS2 SQS 작업이 두 번 실행될 때: 수신·처리·삭제 시각과 visibility timeout 점검 SQS에서 같은 작업이 다시 실행되면 visibility timeout부터 무작정 늘리지 마세요. 수신 시각, 업무 처리 완료 시각, 메시지 삭제 결과를 같은 작업 ID로 대조해야 긴 처리와 삭제 실패를 구분할 수 있습니다.적용 환경: Amazon SQS를 직접 소비하는 작업자; Lambda 이벤트 소스 매핑의 별도 설정은 제외. 자료 확인일: 2026-10-25. 문서 기반 안내이며 실제 운영 시험 결과가 아닙니다.1. 원인: 처리 성공과 큐에서 삭제는 별개수신한 메시지는 즉시 없어지지 않습니다. 잠시 다른 소비자에게 보이지 않다가, 삭제되지 않은 채 제한 시간이 끝나면 다시 받을 수 있습니다. 처리 성공 로그만 보고 큐의 완료까지 확정하면 이 구간을 놓칩니다.예를 들어 보고서 파일 생성은 끝났지만 삭.. 2026. 10. 26. SQS Standard와 FIFO 선택: 순서 보장 범위와 중복 처리 방지 구분 메시지 순서가 업무 결과를 바꾸지 않고 중복 처리를 견딜 수 있으면 Standard가 후보입니다. 주문·계정처럼 같은 대상 안의 순서가 중요하면 FIFO와 메시지 그룹을 검토하세요. FIFO를 선택해도 소비자의 재처리와 데이터베이스 부수 효과까지 자동으로 한 번만 실행된다고 가정하면 안 됩니다.혼동의 원인: 전달 순서와 업무 완료를 같은 것으로 본다큐에 들어간 순서, 소비자가 받은 순서, 데이터베이스에 반영한 순서는 별개입니다. 예를 들어 한 주문의 생성과 취소가 뒤바뀌면 문제가 생길 수 있지만 서로 다른 주문의 처리 순서는 중요하지 않을 수 있습니다. 큐 이름을 고르기 전에 이 경계를 정해야 합니다.조건후보별도 검증독립 작업Standard중복·순서 변화대상별 순서 필요FIFO그룹 경계외부 API 부수 .. 2026. 10. 21. 이전 1 다음
