Redis를 왜 사용할까?

WebSocket을 이용한 채팅을 구현할 때 구글링을 하면 Redis를 이용한 WebSocket 채팅 구현이 보입니다.
저 또한 Redis를 이용하여 WebSocket 채팅을 구현했습니다.
그렇다면 Redis는 과연 이런쪽에서 장점만 있을까에 대해 정리해보겠습니다.

Redis의 장점과 한계

메모리 기반 저장소

Redis는 메모리 기반 저장소(In-Memory Data Store)로, 디스크 대신 RAM에 데이터를 저장합니다. 이로 인해 데이터 입출력 속도가 매우 빠르며, 실시간 처리가 중요한 애플리케이션(예: 채팅, 게임, 실시간 분석)에 적합합니다.

하지만 메모리를 기반으로 동작하기 때문에 물리적 메모리 용량에 크게 의존한다는 한계도 존재합니다. 메모리가 가득 차면 성능 저하가 발생할 수 있으며, 적절한 설정(maxmemory, eviction policy)이 없으면 데이터 유실 가능성도 있습니다. 따라서 사용 시에는 메모리 관리 정책을 함께 고려해야 안정적인 운영이 가능합니다.

단일 스레드 방식

Redis는 단일 스레드 방식으로, 모든 명령어를 순차적으로 처리합니다. 이 때문에 일부에서는 실시간 처리가 중요한 채팅 시스템에 적합하지 않다고 오해할 수 있습니다.

그러나 Redis는 I/O 멀티플렉싱 기반의 고속 이벤트 처리 구조를 통해 초당 수십만 건 이상의 요청을 처리할 수 있으며, 여러 채팅방의 메시지를 동시에 다뤄도 성능 저하 없이 안정적으로 운영됩니다. 실제로 대부분의 실시간 채팅 시스템에서 Redis는 널리 사용되고 있습니다.

또한 Redis 6.0부터는 네트워크 I/O 작업에 한해 멀티스레드 처리 기능이 도입되어, 클라이언트 수가 많거나 데이터 전송량이 큰 환경에서 처리 성능이 더욱 향상되었습니다. 반면, 명령어 실행 자체는 여전히 단일 스레드로 동작하기 때문에, Redis는 본질적으로 모든 명령에 대해 아토믹(Atomic) 보장이 가능합니다. 즉, 각 명령은 중간에 끼어들 수 없이 완전히 독립적으로 처리됩니다.

물론 단일 스레드 구조의 한계도 존재합니다. 예를 들어, 하나의 명령어가 오래 걸릴 경우 그 다음 명령어의 실행이 지연될 수 있으며, 멀티코어 시스템에서도 하나의 CPU 코어만 활용된다는 점에서 하드웨어 자원의 활용 효율이 낮을 수 있습니다.

또한 Redis의 Pub/Sub 기능은 메시지를 영속적으로 저장하지 않고 실시간으로만 전달되기 때문에, 수신자가 연결되어 있지 않으면 해당 메시지는 손실됩니다. 따라서 중요한 메시지는 보조 저장소(DB) 또는 큐 시스템과 병행 처리하는 방식을 고려하는 것이 바람직합니다.