스냅샷과 근본 원인

작업 테이블에 락 경합이 있다는 이야기가 있어 실시간으로 들여다보고 원인을 하나 짚어 보고했다. 그것이 맞느냐는 지적을 받고 다시 보니 처음 짚은 것은 락이 퍼진 경로였지 락이 오래 잡힌 이유가 아니었다.

Open Table of contents

원인과 전파 경로의 혼동

처음 낸 결론은 특정 인덱스에서의 갭 락 연쇄였는데 그것은 락이 번져 나간 통로였다. 애초에 락이 길게 유지된 이유는 다른 곳에 있었다.

원인과 전파 경로를 섞어서 보면 통로를 막는 대책이 나오고 근본은 그대로 남는다. 둘을 갈라야 어느 쪽을 고쳐야 하는지가 정해진다.

다시 조사하며 관측한 첫째는 트랜잭션이 외부 호출 도중에도 열려 있다는 것이었다. 쿼리를 돌리지 않는 대기 상태인데도 수십 개의 락을 보유한 세션이 몇 분씩 남아 있었다.

코드를 보니 트랜잭션 안에서 행을 잠그고 외부 인터페이스를 호출한 뒤 결과를 갱신하고 있었다. 상대가 느려지면 그 지연만큼 락이 그대로 잡혀 있는 구조였다.

둘째는 카테고리 테이블의 특정 행 하나에 수십 개의 스레드가 동시에 갱신을 시도하는 상황이었다. 배치가 여러 갈래로 퍼지지만 결국 같은 상위 항목의 플래그를 건드린다.

여기까지가 그 순간의 스냅샷이고 둘 다 실제로 관측한 사실이다. 문제는 이 관측에서 곧바로 시스템의 근본 원인이라는 결론으로 건너뛴 것이었다.

같은 세션에서 누적 통계를 보니 그림이 완전히 달랐다. 문제의 작업 테이블은 누적 쓰기 락 대기가 수십 초 수준이고 카테고리 테이블은 상위 목록에도 없었다.

지배적인 병목은 내가 보지도 않은 다른 이력 테이블이었고 자릿수가 아예 달랐다. 실시간으로 본 두 경합은 누적으로 보면 거의 없는 수준이었으므로 조사 시점에 마침 그랬을 뿐일 수 있었다.

그렇다고 관측이 무의미한 것은 아닌데 트랜잭션 안에서 외부 호출을 하는 것은 그 자체로 문제다. 지금 지배적이지 않을 뿐 상대가 느려지면 그때 병목이 된다.

그래서 보고를 관측과 해석과 판단으로 나눠 적었다. 관측은 사례 확인이고 해석은 시점 스냅샷이며 판단은 안티패턴 자체는 검토 대상이되 이 관측만으로 구조 문제를 결론짓지 말라는 것이었다.