에그코드 기술 이야기 · 데이터베이스 Lock 시리즈 ③
안녕하세요, 에그코드입니다.
저희는 자체 서비스를 직접 운영하며 웹·SaaS·MVP를 만드는 개발사입니다.
1편 낙관적 락, 2편 비관적 락은 모두 DB 한 대 안에서 도는 이야기였습니다.
그런데 서비스가 커지면 서버를 여러 대로 늘립니다. 이때부터 지금까지의 락만으로는 부족해집니다.
이번 3편은 그 해답인 분산 락(Distributed Lock)입니다.
왜 서버가 여러 대면 부족할까
애플리케이션이 거는 락은 자기 서버 안에서만 유효합니다. 서버 A가 자기 메모리에 락을 걸어도, 서버 B는 그걸 모릅니다.
그래서 서버 A와 B가 같은 재고를 동시에 건드리면 또 꼬입니다. DB의 비관적 락으로 막을 수는 있지만, 모든 요청이 DB로 몰려 병목이 되기 쉽습니다.
결국 필요한 건 모든 서버가 함께 보는 심판 하나입니다.
분산 락이란 무엇인가
분산 락은 모든 서버가 공유하는 한 곳에 "이 작업은 내가 한다"는 표식을 남기는 방식입니다. 그 저장소로는 보통 빠른 인메모리 DB인 Redis를 씁니다.
한 서버가 표식을 선점하면, 나머지 서버는 풀릴 때까지 기다립니다. 서버가 몇 대든 동시에 한 작업만 돌게 만드는 거죠.
어떻게 잠글까 — SET NX PX
Redis에서는 명령 하나로 잠급니다.
SET 키 값 NX PX 30000
NX는 "그 키가 없을 때만" 만들라는 뜻이라, 먼저 온 하나만 성공합니다. PX는 밀리초 단위 자동 만료입니다. 락을 쥔 서버가 갑자기 죽어도, 시간이 지나면 저절로 풀립니다.
예전처럼 잠금과 만료를 따로 걸면, 그 사이 죽었을 때 영원히 안 풀리는 락이 생깁니다. 그래서 한 명령으로 붙이는 게 핵심입니다.
풀 때도 조심 — 내 락만 지우기
잠그는 것만큼 푸는 것도 조심해야 합니다.
내 작업이 늦어져 락이 먼저 만료되면, 그 사이 다른 서버가 새 락을 잡습니다. 이때 내가 뒤늦게 풀면 남의 락을 지우는 사고가 납니다.
그래서 락마다 고유한 값(토큰)을 넣고, "그 값이 내 것일 때만 삭제"하도록 처리합니다.
정리하며
분산 락은 여러 서버가 공유 저장소로 "한 번에 하나"를 보장하는 방법입니다.
다만 만능은 아닙니다. 만료 시간이 작업보다 짧으면 두 서버가 겹칠 수 있고, Redis 한 대가 죽으면 락도 흔들립니다. 그래서 실제 구현은 재시도·만료·통지를 세심하게 다뤄야 합니다 — 다음 두 편의 주제입니다.
저희 에그코드는 자체 서비스를 운영하며, 분산 환경에서도 정합성이 깨지지 않도록 상황에 맞는 락 전략을 골라 적용합니다.
다음 편 예고 — 4편 «Lettuce 스핀락». 락을 못 잡았을 때, 어떻게 기다려야 할까요?
함께 읽어보세요 — Lettuce 스핀락으로 대기를 구현하는 법 · Redisson pub/sub으로 폴링을 없애는 원리 · 에그코드 웹 개발 서비스
에그코드는 자체 서비스를 운영하며 웹·SaaS·MVP를 만듭니다. 여러 서버가 도는 환경에서도 정합성이 깨지지 않게 락 전략을 함께 설계합니다.
분산 환경의 동시성·정합성이 걱정된다면 문의하기