day-log

새벽 2시에 알림이 울렸다. 배포 파이프라인이 Error acquiring the state lock을 뱉고 멈춰 있었다. 락 ID를 들고 DynamoDB 콘솔에 들어가 강제로 항목을 지우고, 파이프라인을 재실행. 익숙한 절차였다. 근데 그날따라 이 절차가 어이없게 느껴졌다.우리 팀은 Terraform 1.11 무렵부터 S3 backend + DynamoDB 락을 써 왔다. 몇 년 잘 돌던 조합이다. 그런데 올봄에 팀 내부 논의 끝에 DynamoDB 락 테이블을 정리하기로 했다. 이유는 두 가지였다. 하나는 Terraform과 OpenTofu 양쪽 다 S3 네이티브 락을 밀고 있고 DynamoDB 방식이 사실상 deprecated가 됐다는 것. 다른 하나는 우리 조직에 IaC state가 40개 넘게 흩..

KEDA SQS scaler에서 새벽에 만난 함정지난주 토요일 새벽 3시쯤이었다. 핸드폰 진동 한 번에 눈이 떠졌다. SQS DLQ 누적 알림. 큐 메시지가 12,000개 쌓여 있었고, 컨슈머 파드는 정확히 한 개. 분명 KEDA로 ScaledObject 걸어놨고, 두 달 동안 잘 돌던 워크로드인데 왜 안 늘어났을까. 멘탈이 좀 흔들렸다.그래서 뭐가 문제였나상황부터 정리하자. 우리 팀이 운영하는 컨슈머는 이미지 후처리(리사이즈 + 메타데이터 추출)를 하는 파이썬 워커다. SQS에서 메시지 꺼내서 S3 거쳐 DynamoDB 업데이트하는 평범한 패턴. KEDA 2.16으로 SQS scaler 붙여놨고 설정은 이랬다.apiVersion: keda.sh/v1alpha1kind: ScaledObjectmetada..