[PostgreSQL] Skip Locked를 이용한 queue consume

#PostgreSQL

Lock은 Postgresql을 비롯한 RDB의 핵심요소라고 할 수 있다. 이를 통해 원자성과 동시성을 안전하게 관리할 수 있기 때문이다.

하지만 유즈케이스에 따라서는 이 lock이 병목이 되어서 문제가 발생할 수도 있다.
이를테면 "작업 큐" 같은 단순 쓰기/읽기가 무식하게 많은 데이터를 관리할 때 말이다.

테스트에 사용한 테이블 구성은 이런식이다.
단순한 key-value 형태의 큐다.

create table queue
(
    id serial primary key,
    data jsonb
);

insert into queue(data)
select to_jsonb('{ "value": "' || generate_series(1, 10000)::TEXT || '" }');

아래 쿼리는 큐에서 가장 오래된걸 순서대로 가져오는 간단한 쿼리다. 동시에 한놈만 하나씩 가져오도록 for update로 락을 걸었다. 아마 가져온 후에는 적절히 삭제 작업을 하게 될 것이다.

select * from queue
order by id
limit 1
for update;

그런데 저 쿼리가 완전히 동시에 몇개 몇십개가 실행된다면 어떻게 될까?
for update로 걸린 락 때문에 아마 한놈씩만 실행되게 기다릴 것이다.

그래서 테스트겸 병렬로 동시에 큐에서 하나씩 꺼내서 지우는 코드를 구성해보았다.
실제로 큐를 활용할 때는 이런식으로 처리할 일이 꽤 잦을 것이다.

이렇게 실행하면, 동작 자체는 잘 되긴 한다.

문제는 저 쿼리 하나하나가 다 락을 걸어버린다는 것이다.
select가 id=3짜리를 잡고 있으면 다른 쿼리들은 다 저 트랜잭션이 끝날 때까지 기다린다.
그래서 계속 병목이 발생해서 성능 자체도 느려지고, 계속 락을 잡고있으니 트랜잭션 타임아웃이 걸리기도 한다.
몇개 실패했는데도 61초가 걸렸다.

그래서 이런 유즈케이스의 경우에는 이미 락이 걸린 놈을 건너뛸 수 있도록 Skip Locked을 걸어주면 문제를 좀 해결할 수 있다.

select * from queue
order by id
limit 1
for update
skip locked;

이렇게 하면 하나씩 읽어오되, 락이 걸린 항목은 아예 무시하고 가져온다.

트랜잭션 타임아웃도 사라졌고, 실행시간도 조금더 빨라졌다.

이 경우에는 5만개짜리 스몰한 데이터를 다뤄서 큰 차이가 나지는 않았지만, 양이 많아질 수록 그 간극은 더 넓어질 것이다.

참조
https://www.pgcasts.com/episodes/the-skip-locked-feature-in-postgres-9-5
https://www.cybertec-postgresql.com/en/skip-locked-one-of-my-favorite-9-5-features/