레디스를 안 쓰고 웹소켓(WebSocket)만 사용하는 경우에는 여전히 실시간 통신 기능은 구현할 수 있습니다. 하지만 레디스와 같은 메시지 브로커나 데이터 저장소를 사용하지 않을 때 발생할 수 있는 몇 가지 제한 사항이 있습니다:
1. 확장성
- 분산 시스템에서의 한계: 웹소켓만 사용할 경우, 모든 클라이언트 연결을 하나의 서버가 처리해야 합니다. 이는 서버의 부하가 증가하고, 서버가 다운되면 모든 연결이 끊어지는 문제를 야기할 수 있습니다. 반면, 레디스와 같이 사용하면 여러 서버 간에 메시지를 공유하고 로드 밸런싱을 통해 확장성 있는 아키텍처를 구축할 수 있습니다.
2. 메시지 관리
- 메시지의 지속성과 복구: 레디스와 같은 데이터 저장소를 사용하지 않을 경우, 서버가 다운되면 메모리에 저장된 모든 메시지나 상태 정보가 사라집니다. 이는 시스템 복구 시 메시지 손실로 이어질 수 있습니다. 반면, 레디스를 사용하면 메시지를 일시적으로 저장하고 필요한 경우 복구할 수 있습니다.
3. 메시지 브로드캐스팅
- 효율적인 메시지 브로드캐스팅: 여러 클라이언트에 메시지를 브로드캐스팅하는 경우, 레디스의 Pub/Sub 기능을 활용하면 효율적으로 메시지를 전달할 수 있습니다. 웹소켓만 사용할 경우, 서버는 연결된 모든 클라이언트에 대해 개별적으로 메시지를 전송해야 하며, 이는 서버의 부하를 증가시킬 수 있습니다.
4. 상태 공유
- 상태 공유의 어려움: 여러 서버 인스턴스가 있을 경우, 레디스와 같은 외부 저장소를 통해 서버 간 상태를 공유할 수 있습니다. 웹소켓만 사용할 경우, 각 서버는 자체적으로 상태를 관리해야 하며, 이는 서버 간 상태 동기화를 어렵게 만듭니다.
결론적으로, 웹소켓만을 사용하여 실시간 통신 기능을 구현할 수는 있지만, 레디스와 같은 메시지 브로커나 데이터 저장소를 함께 사용함으로써 시스템의 확장성, 안정성, 메시지 관리 능력을 향상시킬 수 있습니다. 따라서, 실시간 통신이 필요한 대규모 시스템이나 복잡한 아키텍처를 구축할 계획이라면, 웹소켓과 함께 레디스를 고려하는 것이 좋습니다.
Redis의 Pub/Sub
Redis를 사용한 메시지 발행(publishing)과 구독(subscribing)은 직접적으로 최종 구독자들에게 메시지를 보내는 것이 아닙니다. Redis의 발행/구독(pub/sub) 시스템은 메시지를 중계하는 역할을 합니다. 즉, Redis는 메시지를 직접 구독자에게 전달하지 않고, 해당 메시지를 구독하고 있는 클라이언트(일반적으로 서버 또는 백엔드 시스템)에게 메시지를 전달합니다.
이러한 방식은 주로 다음과 같은 이유로 사용됩니다:
-
분산 시스템에서의 메시지 동기화: 대규모 분산 시스템에서는 여러 서버 인스턴스가 동시에 운영되는 경우가 많습니다. Redis를 사용하면 모든 서버 인스턴스가 Redis로부터 메시지를 받고, 각 서버 인스턴스에 연결된 클라이언트(웹소켓을 통한 브라우저 등)에게 메시지를 전달할 수 있습니다. 이를 통해 시스템 전체에서 메시지의 일관성을 유지할 수 있습니다.
-
확장성 및 유연성: Redis를 메시징 중계자로 사용하면 시스템의 확장성이 향상됩니다. 새로운 서버 인스턴스를 추가하거나 제거하는 것이 더 쉬워지며, 모든 메시지는 Redis를 통해 동기화되므로 각 서버는 독립적으로 스케일링될 수 있습니다.
-
부하 분산: Redis를 사용하면 메시지 전달 부하를 여러 서버 인스턴스에 분산시킬 수 있습니다. 이는 특히 많은 수의 클라이언트와 실시간으로 상호 작용하는 시스템에서 유용합니다.
결과적으로, Redis는 최종 구독자에게 직접적으로 메시지를 발행하지 않고, 대신 메시지를 구독하는 서버나 서비스에 메시지를 전달합니다. 그 후, 이러한 서버나 서비스는 자신과 직접 연결된 클라이언트에게 웹소켓을 통해 메시지를 전달합니다. 이런 방식으로, Redis와 웹소켓 기술은 함께 사용되어 대규모 분산 시스템에서의 메시지 전달을 효율적으로 관리할 수 있습니다.
