redis pub / sub 아키텍처

💡 여기서 나오는 아키텍처는 간단하게 표현한 것이며 팀장님이 설계한 아키텍처입니다. 그리고 나름 괜찮은것 같아서 기록해보려고 합니다.

무엇을 하는가?

---

채팅 기능과 상태 변경 등의 기능을 실시간으로 처리하기 위해서 소켓서버를 사용하게 되었습니다.

사용 이유

---

1. 레디스는 데이터 저장기능도 있지만 메세지 브로커 기능또한 있어서 활용 가능하다.
2. 빠른 개발이 가능하다. ⇒ kafka같은거로도 가능하나 초반에는 채팅부분만 활용할거라 생각한것 같고 kafka를 사용해본적이 없다.
3. 클러스터 기능도 제공한다.

구조

이 구조로 주로 두가지 publish가 사용됩니다.

1. 백엔드에서 redis publish

• 백엔드에서 redis에 publish 하면 다른 연결된 모든 소켓서버에 전달하고 그것이 클라이언트단으로 갑니다.(상태 변경)

1. 클라이언트에서 redis publish

• 클라이언트에서 redis에 publish하면 다른 연결된 모든 소켓서버에 전달하고 그것이 다른 클라이언트단까지 갑니다.(채팅)

또한 한 소켓 서버에만 많은 클라이언트가 붙지 않게 haproxy에서 로드밸런서 처리를 합니다.

문제점

---

1. 소켓 통신 자체가 클라이언트와 서버 양쪽의 통신으로 연결을 계속 유지하고 있어 리소스가 많이 소모됩니다.
2. 카프카와 같은 이벤트 브로커는 publish한 데이터를 가지고 있지만 redis와 같은 메세지 브로커는 데이터를 가지고 있지 않습니다. 즉 유실될 가능성도 있습니다. ⇒ 하지만 중요한 데이터가 유실된 적은 없음

결론

---

redis에 publish, subscribe 기능이 있는것을 알았지만 직접 사용해본 경험은 처음이였습니다. 또한 더 좋은 아키텍처가 있을수도 있지만 위에 설명한 아키텍처도 괜찮다고 생각이 들어 좋은 경험이였다고 생각합니다.