Redis에 대해서 -4

Redis Pipeline의 원리와 메모리 사용에 대한 고찰

Redis에서 Pipeline은 성능을 향상시키는 대표적인 기법 중 하나다. 여러 개의 명령을 클라이언트가 Redis 서버에 한 번에 전송하고, 그에 대한 응답을 한꺼번에 수신하는 방식으로 작동한다. 이는 단순한 트릭이 아니라, RTT(Round Trip Time)를 획기적으로 줄이고, 시스템 콜 수를 감소시켜 Redis의 초당 처리 능력을 극대화하는 핵심적인 기술이다.

하지만 Pipeline은 항상 긍정적인 효과만을 가져오는 것은 아니다. 특히, 명령어 수가 많아질수록 Redis 서버의 메모리 사용량이 비약적으로 증가할 수 있으며, 이는 실제 운영 환경에서 성능 저하의 원인이 되기도 한다.

Pipeline이 필요한 이유: 성능 최적화의 본질

일반적인 Redis 명령 전송은 아래와 같은 과정을 반복한다.

1. 클라이언트가 명령을 Redis에 전송
2. Redis가 해당 명령을 처리
3. 응답을 클라이언트에 전송

이때, 각 명령마다 하나의 네트워크 왕복(RTT)이 발생한다. 이 방식은 소규모 트래픽에서는 큰 문제가 없지만, 수십~수백만 건의 명령을 처리해야 하는 환경에서는 네트워크 지연이 누적되며 병목이 된다.

Pipeline은 이러한 구조를 극복하기 위한 해결책이다. 클라이언트는 여러 명령을 하나의 요청에 담아 Redis로 전송하고, Redis는 순차적으로 명령을 실행한 후, 응답을 한 번에 클라이언트에 반환한다. 이를 통해 RTT를 줄이는 동시에, read() 및 write() 시스템 콜 호출 횟수까지 줄어드는 이점이 있다. 단순화하면, 100개의 명령을 1회의 read/write로 처리할 수 있다는 것이다.

그러나, 왜 메모리 문제가 발생할까?

Pipeline은 명령을 서버로 묶어서 전송하는 것이지, Redis 서버에서 병렬로 처리하거나 즉시 실행하는 구조는 아니다. Redis는 단일 스레드로 동작하므로, Pipeline으로 전달된 명령들을 큐에 순차적으로 적재한 뒤 하나씩 처리한다. 이 과정에서 다음과 같은 메모리 사용이 발생한다:

(1) 입력 버퍼(Query Buffer): 클라이언트가 보낸 명령들이 여기에 저장된다.
(2) 응답 버퍼(Reply Buffer): 명령 실행 결과가 클라이언트에 전송되기 전까지 여기에 보관된다.
(3) 임시 자료구조: 각 명령어의 파싱, 실행을 위해 Redis 내부에 할당되는 메모리 구조들.

즉, Pipeline 명령이 많아질수록 Redis 서버의 메모리 상에 임시로 유지해야 할 데이터 양이 증가하며, 이는 버퍼 메모리 압박(memory pressure)으로 이어진다. 특히 수천 개의 명령을 한 번에 처리할 경우, 단일 클라이언트의 입력/출력 버퍼만으로도 수 MB~수십 MB의 메모리를 점유할 수 있으며, 동시에 여러 클라이언트가 Pipeline을 사용하면 Redis 전체의 메모리 사용량은 빠르게 증가하게 된다.

파이프라이닝의 잘못된 오해: 명령은 즉시 실행되지 않는다

많은 개발자가 Pipeline을 트랜잭션처럼 모든 명령이 한번에 실행되는 것으로 착각하지만, 이는 잘못된 이해다. Redis는 파이프라이닝된 명령을 받는 즉시 실행하는 것이 아니라, 입력된 순서대로 큐에 쌓아둔 후 차례대로 하나씩 처리한다. 그리고 결과 역시 즉시 전송하지 않고, 응답 버퍼에 저장해두었다가 마지막에 한 번에 클라이언트에 반환한다. 이로 인해 다음과 같은 현상이 발생한다:

(1) 처리 중인 명령이 많아질수록 Redis 내부에 유지되는 데이터가 많아진다.
(2) 모든 명령 결과가 반환되기 전까지 클라이언트는 응답을 수신하지 않는다.
(3) Redis 서버는 응답 결과를 메모리에 보존해야 하므로, 그만큼 리스크가 커진다.

결국, Pipeline은 성능과 메모리 사용량 사이의 트레이드오프를 수반하는 구조다.

운영 전략: 크기 제한과 주기적 처리(개인 플젝에서 마주쳤던 문제들)

Redis는 이러한 상황을 방지하기 위해 client-query-buffer-limit와 같은 설정을 제공한다. 이는 각 클라이언트가 서버로 전송할 수 있는 쿼리 버퍼의 최대 크기를 제한하여, 지나치게 큰 Pipeline 요청이 서버를 압도하지 않도록 한다.

또한 실무에서는 다음과 같은 전략을 함께 사용하는 것이 좋다:

(1) Pipeline 배치 크기 제한: 일반적으로 1,000~5,000개 명령 단위로 제한
(2) 스케줄링 기반 처리: 예를 들어, 5분 주기 Cron 작업이 존재할 경우, 이 시간 동안 누적된 Like/Unlike 요청의 수를 예측해 안전한 처리량을 산정하고 이를 기준으로 배치 크기를 조정
(3) 기한 + 개수 조건 처리: 일정 시간이 지났거나, 배치 개수가 일정 수를 넘으면 Pipeline을 실행

만약 개수 기준을 만족하지 못해도, 시간이 지나면 Cron이 강제로 실행하는 방식은 안정성과 효율성을 동시에 확보할 수 있는 방안이다. 반면 Redis 명령 중 KEYS *와 같은 O(N) 시간 복잡도를 가진 명령어를 파이프라인에 포함시키는 것은 Redis의 단일 스레드 구조상 매우 위험한 전략이다. 이는 전체 시스템 응답성을 저하시킬 수 있으므로 반드시 지양해야 한다.

결론: 성능은 선택이 아닌 설계다

Redis Pipeline은 강력한 성능 향상 수단이지만, 그 효과는 단순히 명령을 모아 보낸다고 얻어지는 것이 아니다. 메모리 구조, 버퍼 관리, 시스템 콜 비용, 단일 스레드 구조에 대한 깊은 이해를 바탕으로 사용할 때, 비로소 Redis의 진정한 성능을 이끌어낼 수 있다. Pipeline을 사용할 때는 성능 향상과 메모리 부하 사이의 균형을 반드시 고려해야 하며, 이를 위한 설정과 운영 전략을 함께 설계하는 것이 중요하다.