크롤러 DB 부하를 줄인 DML Broker 설계
80개가 넘는 크롤러의 DB 직접 연결을 공통 Broker와 제한된 queue로 바꿔 lock·connection 오류를 하루 3~4건에서 적용 후 4개월간 0건으로 줄인 작업
기간2026
소속래브라도랩스(LabradorLabs)
역할데이터 엔지니어 · 공통 DB 접근 구조 설계
MySQLPostgreSQLKubernetesHAProxyConnection PoolBounded Queue
1. 문제
80개가 넘는 크롤러가 같은 DB에 직접 연결해 읽기와 쓰기를 병렬로 처리했습니다. 부하가 몰리면 lock과 connection 오류가 하루 3~4건씩 발생했고, 크롤러마다 접속 방식과 재시도 로직도 달랐습니다.
2. 크롤러가 DB 계정을 직접 들지 않게 한 구조
크롤러가 DB 계정과 connection을 직접 들고 있지 않도록 중간 Broker API와 worker를 설계했습니다. 요청을 worker의 bounded queue에 넣고, 정해진 동시성 안에서 connection pool을 사용하게 했습니다.
3. 운영에서 정한 규칙
- queue가 차면 429와 Retry-After를 반환하고 client는 backoff 후 재시도
- write 요청은 idempotency key와 DB unique key/upsert로 중복 반영 방지
- Kubernetes 노드마다 Broker pod를 배치해 특정 노드로 요청이 쏠리지 않게 분산
- IDC와 In-house는 같은 host명을 쓰되 site-local worker로 연결
- request id, 처리 시간, active/pending 수를 로그로 남겨 병목 추적
4. 결과
DB lock·connection 오류 — 하루 3~4건에서 적용 후 4개월간 0건
접속 정보 — 크롤러마다 흩어져 있던 DB credential을 공통 계층으로 이동
부하 제어 — 동시에 처리할 요청 수와 대기열을 한 곳에서 관리
5. 제가 맡은 부분
문제 정리, Broker API와 worker 구조, queue·connection pool 정책, 실패·재시도 경계를 설계했습니다. 각 수집기 담당자는 자신의 크롤러를 Broker 호출 방식으로 바꾸고, 공통 DB 접근 구조와 운영 기준은 제가 맡았습니다.