[Troubleshooting] 분석가님의 쿼리가 회사의 새벽을 멈춘 날 (feat. Redshift Lock)

00시 정각. 데이터 엔지니어에게는 가장 긴장되는 시간이다. 수백 개의 파이프라인이 동시에 돌아가며 데이터를 쏟아내는 이 시간에, 갑자기 지옥문이 열렸다.

1. 상황 발생: “배치는 돌고 있는데 데이터가 안 들어온다?”

여느 때와 다름없이 자정 배치가 시작됐다. 그런데 아침에 출근해서 확인해 보니, ODS(Operational Data Store) 테이블 갱신 작업이 Running 상태로 6시간째 멈춰 있었다.

이건 100% Lock 문제다. 그것도 아주 고약한 놈으로.

Redshift 시스템 뷰(STV_LOCKS)를 까보니 범인은 의외의 곳에 있었다.

어느 분석가님이 전날 오후에 특정 테이블에 SELECT를 날려놓고, 트랜잭션을 안 닫은 채로 퇴근하신 거다. (전문 용어로 Idle in transaction 상태)

우리 파이프라인은 성능을 위해 DELETE 대신 TRUNCATE를 치고 데이터를 때려 박는 방식을 쓴다.

내 배치 (Writer): TRUNCATE TABLE ... 실행 시도. 이놈은 테이블에 대해 AccessExclusiveLock이라는 가장 강력한 락을 요구한다. “나 작업할 거니까 아무도 건드리지 마!”라는 뜻이다.
분석가 세션 (Reader): 어제 날린 SELECT 때문에 AccessShareLock을 꽉 쥐고 안 놔주고 있다. “나 아직 읽는 중(일지도 몰라)!”
결과: TRUNCATE는 분석가가 출근해서 세션을 끌 때까지 무한정 기다린다.

설상가상으로 내가 Airflow Task에 timeout 설정을 안 해놨더니, Airflow는 “오~ 열일 중이네?” 하고 6시간 동안 같이 기다려준 거다. (이게 진짜 뇌절이지…)

일단 급한 대로 해당 세션을 PG_TERMINATE_BACKEND로 강제 종료(Kill) 시켰다. 죽이자마자 락이 풀리며 배치가 순식간에 끝났다. 하지만 이걸 매번 수동으로 할 순 없지 않은가?

1. Airflow 타임아웃 도입 (현실 자각)
모든 태스크에 execution_timeout을 걸었다. 이제 락 때문에 멈춰 있으면 6시간씩 기다리지 않고 바로 실패 처리된 후 나에게 알람을 보낸다.

2. 슬랙 “박제” 봇 개발
이게 이번 작업의 핵심이다. 람다로 5분마다 락 상태를 체크해서, 10분 이상 락을 잡고 있는 세션이 있으면 슬랙 채널에 해당 유저 계정을 태그(@멘션)해서 날려버리게 만들었다.

“@OOO님, ods_trade 테이블 락 잡고 계신 지 30분 넘었습니다. 확인 좀 부탁드려요! (배치 죽어욧!!)”

이렇게 실명을 박제해버리니, 분석가님들의 “트랜잭션 확인 습관”이 비약적으로 향상되었다. (역시 금융권은 책임 소재가 명확해야…)

3. WLM 정책 강화
분석가 그룹의 큐(Queue)에 “1시간 이상 실행되거나 유휴 상태인 세션은 강제 종료”하는 룰을 추가했다. 자원 할당도 좀 짜게(?) 조정해서 운영 배치의 안정성을 최우선으로 확보했다.

기술적으로는 WLM이나 타임아웃 설정이 답이겠지만, 사실 더 중요한 건 “데이터를 사용하는 사람들의 습관”을 어떻게 시스템적으로 가이드하느냐인 것 같다.

자원 할당도 좀 효율적으로 조정하고, 분석가 세션 타임아웃을 1시간으로 박아버리니 오히려 플랫폼 운영은 훨씬 쾌적해졌다. 가끔은 엔지니어링보다 이런 “운영의 묘”가 더 강력할 때가 있다는 걸 배운 사건이었다.