SW BBANG K

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...

Lambda 함수에 데이터베이스 엔드포인트를 하드코딩했다가 코드 리포지토리에 그대로 노출된 경험이 한 번쯤은 있을 것이다. Lambda 환경 변수는 이 문제를 해결하는 가장 직접적인 방법이지만, KMS 암호화 옵션을 잘못 이해하면 오히려 보안 감사에서 지적을 받는다. TL;DR — Lambda 환경 변수 핵심 요약 항목 내용 환경 변수 설정 방법 콘솔, CLI, IaC 모두 지원. 런타임에 OS 환경 변수로 주입됨 기본 암호화 저장 시 AWS 관리형 키(aws/lambda)로 자동 암호화 KMS 고객 관리형 키(CMK) 별도 KMS 키 지정 시 추가 제어 가능. 함수 실행 역할에 kms:Decrypt 필요 전송 중 암호화 콘솔 헬퍼 암호화 사용 시 배포 전 클라이언트 측 암호화 적용 민감 정보 대안 Secrets Manager 또는 SSM Parameter Store(SecureString) 권장 Lambda 환경 변수가 동작하는 방식 Lambda는 함수 배포 패키지와 환경 변수를 분리해서 관리한다. 환경 변수는 함수 설정의 일부로 저장되고, 실행 환경(Execution Environment)이 초기화될 때 프로세스의 OS 환경 변수로 주입된다. 코드에서는 process.env.DB_ENDPOINT (Node.js), os.environ['DB_ENDPOINT'] (Python) 처럼 일반 환경 변수와 동일하게 읽는다. 저장 계층에서 Lambda는 기본적으로 AWS 관리형 KMS 키( aws/lambda )를 사용해 환경 변수를 암호화한다. 이 키는 AWS가 소유하고 관리하므로 별도 비용이 발생하지 않지만, 키 정책 제어나 감사 로그 분리는 불가능하다. 고객 관리형 키(CMK)를 지정하면 키 정책으로 접근을 제어하고 CloudTrail에서 복호화 이벤트를 추적할 수 있다. ...

S3 버킷에 파일을 업로드하면 Lambda가 실행되고, Lambda가 처리 결과를 같은 버킷에 저장하면 또 Lambda가 실행된다. 이 Lambda S3 무한 루프 는 처음 설계할 때는 눈에 띄지 않다가, 프로덕션에서 갑자기 Lambda 동시 실행 한도를 소진하거나 S3 요청 비용이 폭발적으로 증가하면서 발견된다. TL;DR — Lambda S3 재귀 트리거 차단 방법 요약 방법 핵심 원리 적용 난이도 권장 여부 출력 접두사(Prefix) 분리 입력/출력 경로를 다르게 설정해 트리거 조건 자체를 제거 낮음 ✅ 1순위 출력 버킷 분리 처리 결과를 별도 버킷에 저장 낮음 ✅ 1순위 객체 메타데이터 확인 Lambda가 직접 처리 여부를 메타데이터로 판별 후 조기 종료 중간 ⚠️ 보조 수단 객체 태그 확인 처리 완료 태그가 있으면 즉시 반환 중간 ⚠️ 보조 수단 Lambda S3 재귀 트리거가 발생하는 구조 S3 이벤트 알림은 버킷 단위로 설정된다. 특정 접두사나 접미사 필터를 걸지 않으면, 버킷 내 모든 ObjectCreated 이벤트가 Lambda를 호출한다. Lambda가 처리 결과를 같은 버킷에 쓰는 순간 새로운 ObjectCreated 이벤트가 발생하고, 이 이벤트가 다시 Lambda를 호출한다. graph TD A["사용자: raw/input.csv 업로드"] --> B["S3: ObjectCreated 이벤트 발생"] B --> C["Lambda 호출 #1"] C --> D["처리 결과: processed/output.csv 저장"] D --> E["S3: ObjectCreated 이벤트 발생"] E --> F["Lambda 호출 ...