Redis에 대해서 -3

조금은 더 자세하게 Pipeline을 살펴보기위해 작성된 글이다.

Redis 파이프라이닝의 메모리 부하: TCP 구조와 단일 스레드의 한계

Redis는 초당 수십만 건의 명령어를 처리할 수 있을 정도로 빠르지만, 그 이면에는 TCP와 커널, 그리고 Redis의 이벤트 루프 구조에 따른 메모리적 병목이 잠재되어 있다. 특히 파이프라이닝(pipelining)은 명령어 전송의 네트워크 효율을 높이는 강력한 기법이지만, 무분별한 사용은 Redis 서버에 상당한 메모리 부하(memory pressure)를 유발할 수 있다. 이 글에서는 파이프라이닝이 어떻게 메모리 부하를 유발하는지, 그리고 그 원인이 어디에 있는지를 TCP의 구조와 Redis의 내부 처리 메커니즘을 통해 분석해보자.

파이프라이닝의 동작 흐름과 버퍼의 역할(* 꽤나 어려움)

클라이언트가 여러 Redis 명령어를 파이프라이닝 방식으로 전송할 때, 그 흐름은 다음과 같은 단계로 이루어진다. 

(1) 먼저 클라이언트는 명령어들을 하나의 TCP 연결을 통해 송신 버퍼에 담는다. 이 데이터는 (2) 커널의 TCP 송신 버퍼를 거쳐 서버 측 Redis 프로세스에 도달하며, (3) 서버는 epoll_wait()을 통해 활성화된 소켓 이벤트를 감지한 후, recv() 혹은 read() 시스템 콜을 통해 이 데이터를 한꺼번에 읽는다.

이 시점에서 주목해야 할 점은 Redis가 받은 데이터를 그대로 한 번에 처리하지 않는다는 것이다. 

Redis는 RESP(REdis Serialization Protocol) 형식으로 구성된 명령어 스트림을 자체 파서로 분할하고, 이들 명령어를 메모리 내 자료구조에 따라 하나씩 실행한다. 그 결과는 서버의 응답 버퍼(client->reply)에 누적되고, 다시 커널의 송신 버퍼에 저장된 뒤 클라이언트로 전송된다.

여기서 중요한 점은, 모든 명령어가 단일 스레드에서 순차적으로 처리된다는 것이다. 즉, 비록 네트워크 단에서는 "한 번에 전송"되는 것처럼 보이지만, 실제로는 TCP 스트림 특성상 패킷이 조각화되어 도착할 수 있고, Redis는 이를 하나씩 파싱하고 실행하는 구조다. 이로 인해, 대량의 파이프라인이 유입되면 Redis의 입력 버퍼(querybuf)와 응답 버퍼(reply buffer)의 사용량이 급격히 증가할 수 있다.


TCP와 소켓 버퍼의 기술적 이해(* 꽤나 어려움)

이러한 현상을 이해하기 위해서는 TCP의 스트림 기반 동작 특성과 소켓 버퍼 메커니즘에 대한 이해가 필요하다. TCP는 데이터를 "바이트 스트림"으로 취급하며, 각 패킷의 경계를 명확하게 구분하지 않는다. 따라서 Redis는 자신이 받은 데이터 블록을 파싱하여 명령 단위로 분해해야 한다.

클라이언트가 아무리 100개의 명령을 한 번에 보냈더라도, 네트워크 경로 상에서 패킷은 조각화되어 순차적으로 도달하고, Redis는 이를 recv()를 통해 순차적으로 수신한다.

또한 서버 측에서는 epoll이 소켓의 데이터 도착을 감지하고, Redis가 이를 처리할 수 있도록 이벤트를 발생시킨다. 그러나 Redis는 싱글 스레드 구조를 유지하기 때문에, 이벤트가 감지되어도 한 번에 하나의 클라이언트 명령만 처리할 수 있다. 이는 멀티스레드 기반의 병렬 서버와는 달리, 응답 지연과 메모리 누적의 리스크를 동시에 내포한다.

왜 순차적으로 처리되는가? — 착시와 현실

많은 사람들이 Redis가 파이프라이닝을 통해 병렬로 명령을 처리한다고 오해하지만, 이는 TCP 스트림의 동작 방식과 커널 버퍼링 구조가 만들어낸 착시현상이다. 실제로 Redis는 다음 세 가지 이유로 명령을 순차적으로 처리한다.

(1) TCP는 패킷 경계가 없다.
(2) 클라이언트가 보낸 데이터는 조각화되어 도착할 수 있으며, 응용 계층(Redis)이 이를 파싱해야 한다.
(3)Redis는 단일 스레드 기반이다. 한 번에 하나의 명령만 실행되며, 다른 명령은 입력 큐에 대기한다.

OS 커널의 소켓 버퍼는 중간 저장소 역할만 한다. 모든 데이터는 epoll_wait() → read() → 파싱 → 실행 순으로 Redis 내부 이벤트 루프에서 처리된다. 이러한 이유로, 명령어가 많아질수록 Redis 서버 내 입력/출력 버퍼가 커지고, 그만큼 메모리 사용량도 증가한다.

운영 환경에서의 권장 전략

Redis의 높은 처리량은 많은 부분 파이프라이닝 덕분이지만, 그에 따라 발생할 수 있는 메모리 과부하를 방지하려면 몇 가지 운영 전략이 필요하다. 대표적으로 Redis는 client-query-buffer-limit 설정을 통해 클라이언트당 수신 버퍼의 최대 크기를 제한할 수 있다. 이 설정은 무분별한 대량 명령 전송을 방지하고, 서비스 안정성을 확보하는 중요한 수단이다.

일반적으로는 1,000~5,000개 수준의 명령어 배치를 단위로 파이프라이닝하는 것이 권장되며, 이는 AWS Redis 운영 가이드 및 다양한 퍼블릭 클라우드 환경에서도 권장되는 방식이다. 이보다 과도한 배치는 서버 메모리 사용량 증가뿐 아니라, 클라이언트 측에서도 응답을 순서대로 처리하는 데 큰 부담을 줄 수 있다.

마무리

Redis 파이프라이닝은 고성능 분산 캐시 시스템의 핵심 기술 중 하나지만, 네트워크 계층의 구조적 한계, Redis의 단일 스레드 아키텍처, TCP의 스트림 특성으로 인해 순차 처리 구조를 완전히 벗어나지는 못한다. 

따라서 성능 최적화와 메모리 안정성 사이의 균형이 매우 중요하며, 실제 운영 환경에서는 적절한 배치 크기와 서버 설정을 통해 Redis의 성능을 최대한 끌어내는 것이 필요하다.

파이프라이닝은 단순히 "빠른 기술"이 아니라, 네트워크, 커널, CPU, Redis 내부 구조의 복합적인 최적화 결과물이다. 이 기술을 안전하고 효율적으로 사용하는 것이 바로 Redis 운영자의 실력이다.