TIL

10. Pipelining

• 명령마다 응답을 기다리며 왕복(RTT)하는 대신, 여러 명령을 한 번에 보내고 응답을 몰아 받아 RTT 비용을 줄이는 클라이언트 기법
• 핵심: 전송만 묶을 뿐 원자성·격리는 없음 — 07. Transaction·08. Lua Scripting과 결정적으로 다른 지점

문제: RTT 비용

• 일반 흐름은 명령 전송 → 응답 대기 → 다음 명령 → 명령 N개면 왕복도 N번
• 네트워크 지연이 서버 처리 시간보다 크면 RTT가 전체 시간을 지배
• 예: RTT 1ms, 명령 100개 → 왕복에만 약 100ms

동작

# 일반: 명령마다 왕복
SET k1 v1     # → OK   (왕복 1)
SET k2 v2     # → OK   (왕복 2)

# 파이프라이닝: 응답을 안 기다리고 연속 전송 후 응답을 한꺼번에 수신
SET k1 v1
SET k2 v2
SET k3 v3     # 세 명령 연속 전송 → 응답 3개를 한 번에 받음 (왕복 1회)

• 클라이언트가 응답을 기다리지 않고 N개를 연속 전송 → 서버는 순서대로 처리하며 응답을 큐잉 → 클라이언트가 응답을 몰아서 읽음
• N개 명령 = 1 RTT(+ 처리 시간). 소켓 read/write 같은 syscall 횟수도 줄어듦
• 응답 순서는 보낸 순서대로 보존

원자성 없음 (가장 중요)

• 파이프라이닝은 네트워크 전송만 배치할 뿐 — 다른 클라이언트의 명령이 파이프라인 명령들 사이에 끼어들 수 있음
• 격리·원자성이 필요하면 MULTI/EXEC(트랜잭션)나 Lua를 써야 함
• 트랜잭션도 보통 내부적으로 파이프라인으로 전송되지만, 거기에 원자성·격리가 더해진 것

명령 묶기 3종 비교

기준	파이프라이닝	트랜잭션(MULTI/EXEC)	Lua
목적	RTT 절감(전송 배치)	원자적 일괄 실행	원자적 read-modify-write
원자성·격리	없음(끼어듦 가능)	있음	있음
결과 기반 분기	불가	불가(EXEC 전엔 값 없음)	가능(서버 로직)
RTT	1회	1회(보통 파이프라인됨)	1회(EVALSHA)
적합	서로 독립적인 대량 명령	묶어서 원자 실행	조건부 원자 연산

한계와 주의

• 이전 명령의 결과에 의존하는 로직은 파이프라인 불가 — 응답을 아직 안 받았으므로. read-modify-write는 Lua로
• 거대한 파이프라인은 메모리 스파이크 — 서버·클라이언트 모두 응답을 버퍼링하므로, 수만 개를 한 번에 보내지 말고 청크로 나눠(예: 1k~10k 단위) 전송
• 서버 처리 시간 자체는 줄지 않음 — 줄어드는 건 왕복뿐
• Redis Cluster: 한 연결의 파이프라인은 같은 노드(슬롯)의 키에만 유효 → 클라이언트가 슬롯별로 분할해 보내야 함

사용

• Spring Data Redis: RedisTemplate.executePipelined { ... }
• Lettuce: 비동기 API로 네이티브 지원, 가까운 시점에 발행된 명령을 자동 파이프라이닝하기도 함
• Jedis: Pipeline 객체

참고

• Redis 공식 — Pipelining