분산 락과 단일 실행 보장

방법은 셋이고 일의 성격에 따라 고릅니다.

세 번째가 가장 단순하고 튼튼합니다. (작업이름, 실행일자) 를 유일 키로 넣고, 넣기에 성공한 한 대만 일을 합니다. 별도 인프라가 필요 없고 DB 가 살아 있는 한 정확합니다. 다만 실행 주기가 고정되어 있어야 키를 만들 수 있습니다.

분산 락은 주기가 불규칙하거나 작업이 길 때 씁니다. 이때 만료 시간이 가장 어려운 값입니다. 작업 시간보다 짧으면 일하는 중에 풀려 둘이 동시에 돌고, 너무 길면 붙잡고 죽었을 때 그만큼 멈춥니다. 일하는 동안 만료를 미루는 방식으로 둘 다 피합니다.

흔한 실수: 락만 걸고 끝내는 것. 락은 동시에 두 개가 도는 것을 막지만, 앞의 실행이 응답 직전에 죽고 재시도가 들어와 순서대로 두 번 도는 것은 막지 못합니다. 그래서 작업 자체가 두 번 돌아도 결과가 같아야 합니다.

락을 잡은 프로세스가 죽으면 아무도 풀어 줄 수 없기 때문입니다. 만료가 없으면 그 작업은 영원히 막힙니다.

그런데 만료를 두는 순간 새 위험이 생깁니다.

첫 줄이 더 위험합니다. 락이 있다고 믿고 짠 코드가 동시에 도는 것이라, 증상이 "가끔 중복 처리" 로 나타나고 재현이 어렵습니다.

해결은 일하는 동안 만료를 미루는 것입니다. 그러면 만료를 짧게 잡아도 되고, 죽으면 미루기가 멈춰 곧 풀립니다. 다만 미루기가 실패했을 때는 작업을 멈춰야 합니다. 미루기에 실패했다는 것은 이미 락을 잃었을 수 있다는 뜻입니다.

풀 때도 조심해야 합니다. 내가 잡은 락인지 확인하지 않고 지우면, 이미 만료돼 남이 잡은 락을 내가 푸는 일이 생깁니다. 락에 고유 값을 넣고 그 값이 같을 때만 지웁니다.

흔한 실수: 만료 시간을 작업 시간의 평균으로 잡는 것. 평균으로 잡으면 절반은 넘깁니다. 미루기를 쓰지 않을 거라면 최악의 시간을 기준으로 잡아야 합니다.

대표적인 시나리오 셋입니다.

1. 만료가 작업보다 짧았다. A 가 락을 잡고 일하는 중에 만료돼 B 가 같은 락을 잡습니다. A 는 자기가 락을 잃은 줄 모르고 계속 일합니다. 둘이 같은 자원을 동시에 건드립니다.

2. 정지 구간이 있었다. A 가 락을 잡은 직후 긴 GC 정지나 가상 머신 정지에 들어갑니다. 그 사이 만료되고 B 가 들어옵니다. A 는 깨어나서 아무 일 없었다는 듯 이어서 씁니다. 락을 확인한 시점과 실제로 쓰는 시점 사이가 벌어지는 것이 본질입니다.

3. 락 저장소가 장애를 겪었다. 복제 구성에서 리더가 바뀌면, 아직 복제되지 않은 락 정보가 사라져 두 프로세스가 같은 락을 잡을 수 있습니다.

펜싱 토큰이 2번을 진짜로 막는 유일한 방법입니다. 뒤늦게 깨어난 A 의 번호는 낮으므로 저장소가 거절합니다.

흔한 실수: 락을 걸었으니 안전하다고 보고 뒤쪽에 방어를 안 두는 것. 락은 확률을 크게 낮출 뿐이고, 마지막 방어는 데이터를 쓰는 자리에 있어야 합니다.

있습니다. 그리고 많은 경우 락보다 낫습니다.

두 번째가 실무에서 가장 자주 맞습니다. 상태 전이를 원자적으로 하고 바뀐 행 수가 1인 쪽만 진행하면, 별도 인프라 없이 단일 실행이 보장됩니다. 게다가 어디까지 했는지가 데이터에 남아 재시작도 쉽습니다.

락 방식과 결정적으로 다른 점은 진실의 위치입니다. 락은 별도 저장소에 있고 데이터는 다른 곳에 있어서 둘이 어긋날 수 있습니다. 조건부 갱신은 데이터 자신이 자기 상태를 들고 있어서 어긋날 자리가 없습니다.

흔한 실수: 단일 실행이 필요하다고 하면 반사적으로 분산 락을 떠올리는 것. 락은 만료와 갱신, 소유자 확인, 펜싱까지 제대로 해야 맞는데, 데이터 쪽 제약으로 끝낼 수 있으면 그게 더 적은 부품으로 같은 보장을 줍니다.