📡 Redis pubsub를 활용한 SSE 적용기

안녕! 클로바파트라! 는 사용자들이 음성으로 음정과 발음을 겨루는 게임을 즐길 수 있도록 설계된 게임입니다. 🎤 WebRTC를 통해 음성을 스트리밍하고, WebSocket을 사용하여 실시간 통신을 지원합니다. 그럼에도 불구하고, 게임 방 목록의 실시간 업데이트는 여전히 문제였죠. 방의 생성, 사용자 참여, 퇴장 등의 변경 사항을 즉시 반영하려면, 더 나은 방법이 필요했습니다.

이 문제를 해결하기 위해 Redis Pub/Sub와 Server-Sent Events를 도입하여 게임 방 목록의 실시간 업데이트를 구현한 경험을 공유하고자 합니다. 😊

---

기존 구조와 문제점

기존에는 HTTP REST API를 통해 게임 방 목록을 관리했습니다. 사용자가 페이지를 새로고침할 때마다 서버에서 방 목록을 전달하는 방식이었죠. 하지만 이 방법에는 몇 가지 문제가 있었습니다.

1️⃣ 실시간성 부족

• 방이 생성되거나 사용자가 방을 떠나면, 즉각적으로 다른 사용자에게 반영되지 않았습니다. 이로 인해 사용자 경험에 지연이 발생했습니다.

2️⃣ 서버 부하 증가

• 클라이언트가 주기적으로 서버에 데이터를 요청하는 방식으로 갱신되는 구조여서 서버에 불필요한 부하를 초래했습니다.

이 문제를 해결하기 위해 Redis Pub/Sub와 SSE를 도입하여 실시간성과 서버 효율성을 개선했습니다. 🚀

---

📡 Redis Pub/Sub와 SSE로 리팩토링

🔧 Redis Pub/Sub란?

Redis Pub/Sub는 Publish/Subscribe(발행/구독) 패턴을 기반으로 하는 메시징 시스템입니다. 발행자는 메시지를 특정 채널에 보내고, 구독자는 해당 채널의 메시지를 실시간으로 수신할 수 있습니다.

• Publisher(발행자): 메시지를 발행하는 역할을 합니다. 예를 들어, 게임 방 상태가 변경될 때마다 메시지를 발행합니다.
• Subscriber(구독자): 특정 채널을 구독하고, 그 채널에 메시지가 들어오면 실시간으로 이를 수신합니다.

Redis 공식 문서에서는 Pub/Sub를 다음과 같이 설명합니다:

"Redis Pub/Sub is a simple and fast messaging system. Messages are sent by publishers to channels, and subscribers receive those messages when subscribed to the corresponding channels."

— Redis Pub/Sub Documentation

Redis에서 Pub/Sub를 활용하면 여러 서버나 시스템 간 실시간으로 메시지를 전송할 수 있습니다. 이로써 게임 방 상태의 실시간 동기화를 구현할 수 있습니다.

🔧 SSE(Server-Sent Events)란?

SSE는 서버-클라이언트 간의 단방향 통신을 위한 기술로, 클라이언트가 서버에 연결을 유지하고 서버가 실시간으로 데이터를 푸시하는 방식입니다. WebSocket과 달리 양방향 통신이 필요 없는 상황에서 간편하고 효율적인 솔루션을 제공합니다.

SSE는 HTTP 프로토콜을 기반으로 작동하므로 브라우저 호환성이 뛰어나며 설정이 간단합니다. 이는 실시간 데이터를 서버에서 클라이언트로 푸시할 때 매우 유용합니다.

---

Redis Pub/Sub와 SSE를 활용한 작동 원리

1️⃣ Redis Pub/Sub로 상태 변경 감지

• 게임 방이 생성되거나 삭제되거나 사용자가 참여/퇴장하는 경우, Redis의 Pub/Sub를 사용하여 상태 변경 메시지를 발행합니다.
• 서버는 이 메시지를 구독하여 방 상태 변경을 감지합니다.

2️⃣ SSE로 클라이언트에 실시간 전송

• 서버는 Redis에서 메시지를 수신하고, 이를 SSE를 통해 클라이언트에 전달합니다.
• 클라이언트는 수신한 이벤트로 UI를 즉시 업데이트합니다.

이 구조는 실시간 데이터 처리의 핵심이 됩니다.

---

구체적인 Redis Pub/Sub 활용

1. pub/sub 클라이언트 분리

Redis의 Pub/Sub 기능을 활용하면 여러 시스템 간에 실시간으로 메시지를 전달할 수 있습니다. 이때, Publish(발행)와 Subscribe(구독) 역할을 분리하면 성능과 유지보수 측면에서 이점을 얻을 수 있습니다.

Redis Pub/Sub의 기본 구조

Redis에서 Pub/Sub 모델은 두 가지 주요 역할로 나뉩니다:

• Publisher (Pub): 메시지를 발행하는 클라이언트입니다. 특정 채널에 메시지를 보내면, 이 채널을 구독하고 있는 클라이언트들이 해당 메시지를 받을 수 있습니다.
• Subscriber (Sub): 특정 채널을 구독하고 있는 클라이언트입니다. 구독한 채널에 메시지가 도달하면 이를 실시간으로 수신합니다.

기본적으로 같은 Redis 클라이언트를 사용해 Pub/Sub를 처리할 수 있지만, 실제로 클라이언트를 분리하여 각각 독립적인 역할을 수행하도록 설계하면 더 효율적이고, 유지보수가 쉬운 시스템을 구축할 수 있습니다.

Pub/Sub 클라이언트 분리의 이점

Redis 공식 문서에서는 Pub/Sub 시스템을 통해 여러 클라이언트가 메시지를 실시간으로 받을 수 있다고 언급합니다. 또한, Pub/Sub 패턴을 사용할 때, 각 클라이언트를 독립적으로 관리하면 더 효율적으로 시스템을 확장할 수 있습니다.

"Using separate clients for publishing and subscribing can help improve performance in scenarios where a client might need to do other work in parallel, such as managing a user interface while receiving messages."

— Redis Pub/Sub 공식 문서

따라서 Pub/Sub 클라이언트를 분리하면 성능 개선과 함께 유지보수성이 향상되며, 각 클라이언트가 자신의 역할에 맞게 최적화된 작업을 할 수 있습니다. 예를 들어, Publisher는 메시지를 발행하는 데 집중하고, Subscriber는 수신된 메시지를 처리하는 데 집중하게 됩니다.

@Injectable()
export class RedisService implements OnModuleDestroy {
  private pubClient: Redis; // publish 클라이언트
  private subClient: Redis; // subscribe 클라이언트

  constructor(@Inject('REDIS_CLIENT') private readonly redisClient: Redis) {
    this.pubClient = new Redis(redisClient.options);
    this.subClient = new Redis(redisClient.options);
  }

  onModuleDestroy() {
    this.pubClient.quit();
    this.subClient.quit();
  }
  ...
}

2. 메시지 발행

게임 방 상태가 변경될 때마다 roomUpdate 채널을 통해 메시지를 발행합니다. 예를 들어, 방이 생성될 때 다음과 같이 Redis에 메시지를 발행할 수 있습니다.

await this.redisService.publishToChannel(
  "roomUpdate",
  JSON.stringify(roomData)
);

이 메시지는 roomUpdate 채널을 구독하는 모든 클라이언트에게 실시간으로 전달됩니다.

3. 메시지 구독

서버는 roomUpdate 채널을 구독하고, 게임 방의 상태 변화를 실시간으로 감지하여 클라이언트에게 전송합니다. RoomController에서는 RedisService를 통해 채널을 구독하고, roomUpdateSubject로 데이터를 전달하여 SSE를 통해 클라이언트에게 실시간으로 업데이트를 전송합니다.

export class RoomController {
  private readonly roomUpdateSubject = new Subject<MessageEvent>();

  constructor(private readonly redisService: RedisService) {
    this.redisService.subscribeToChannel("roomUpdate", async (message) => {
      const roomKeys = await this.redisService.keys("room:*");
      const rooms = await Promise.all(
        roomKeys.map(async (key) => {
          const roomData = await this.redisService.get<string>(key);
          return JSON.parse(roomData) as RoomDataDto;
        })
      );
      this.roomUpdateSubject.next({ data: rooms });
    });
  }

  @Sse("stream")
  getRoomUpdates(): Observable<MessageEvent> {
    return this.roomUpdateSubject.asObservable();
  }
}

4. 클라이언트에서 SSE 이벤트 수신

클라이언트는 EventSource API를 사용하여 SSE를 통해 실시간 데이터를 수신합니다. 클라이언트는 서버와 연결 후, 실시간으로 전송되는 데이터를 받아 UI를 업데이트합니다.

const eventSource = new EventSource("/api/rooms/stream");

eventSource.onmessage = (event) => {
  const update = JSON.parse(event.data);
  updateRoomList(update); // UI 업데이트
};

---

WebSocket 대신 SSE를 선택한 이유

1. 단순성

WebSocket은 양방향 통신에 유용하지만, 실시간으로 데이터 전송만 필요할 때는 SSE가 더 간단하고 효율적입니다.

2. 브라우저 호환성

SSE는 HTTP 기반이므로 대부분의 브라우저에서 기본적으로 지원되며, 설정이 간단합니다. 반면, WebSocket은 방화벽이나 네트워크 설정에 따라 차단될 수 있습니다.

3. 연결 효율성

WebSocket은 모든 클라이언트와의 연결을 유지해야 하므로, 다수의 클라이언트에게 동일한 데이터를 전달할 때 SSE가 더 효율적입니다.

---

적용 결과

1️⃣ 실시간 방 목록 업데이트

• 방 생성, 삭제, 사용자의 이동 등이 즉시 반영되어 사용자 경험이 크게 향상되었습니다.

2️⃣ 서버 효율성 향상

• 기존의 HTTP REST 방식에서는 클라이언트가 주기적으로 서버에 요청을 보내야 했지만, SSE와 Redis Pub/Sub를 통해 서버는 필요한 경우에만 데이터를 전송하고, 클라이언트는 실시간으로 업데이트를 받을 수 있게 되었습니다.

---

마무리하며

Redis Pub/Sub와 SSE를 활용한 게임 방 목록의 실시간 업데이트 시스템은 안녕! 클로바파트라! 게임의 사용자 경험을 크게 향상시켰습니다. 앞으로도 다양한 실시간 기술을 활용하여 더 나은 서비스를 제공할 수 있도록 노력하겠습니다. 😊

참고 자료

• Redis Pub/Sub 공식 문서: Redis Pub/Sub
• SSE 공식 문서: MDN Web Docs - SSE