Line 세미나. Redis Pub/Sub을 사용해 대규모 사용자에게 고속으로 설정 정보를 배포한 사례
데이터베이스/Nosql

Line 세미나. Redis Pub/Sub을 사용해 대규모 사용자에게 고속으로 설정 정보를 배포한 사례

반응형

개요

- Line Live chat은 Akka로 동작하며 client와 server사이에는 웹소켓으로 동작

- 120대의 채팅 서버와 사이의 커뮤니케이션은 redis pub/sub을 사용

- 채팅의 임시데이터는 레디스에 저장하고 영속 데이터는 정규화해서 배치를 통해 mysql에 저장

- 유저와 시스템을 통해 일부 코멘트를 제어하기도 함

 

 

기존 아키텍처 소개

- 방송자가 시청자를 차단하는 경우 차단된 시청자의 코멘트를 해당 방송에서 보여지지 않도록 하는 기능이 있다.

- 방송자가 api에 특정 사용자 차단을 요청하면 block 정보를 디비에 저장하고 chat internal api서버에 차단 정보를 전송한다.

- 전송 받은 internal 서버는 정보를 mysql에 저장한다.

- 웹소켓은 로컬캐시를 뒤지고 없으면 mysql을 뒤져서 차단정보가 있는지 확인하고 해당 사용자의 차단정보가 있는 경우 다른 클라이언트들에게 해당 정보가 보이지 않도록 처리한다.

- 하지만 위와 같은 방식의 경우 사용자의 수많은 chat 하나하나마다 mysql을 뒤질수도 있고 또한 local memory에 많은 양에 데이터를 저장하게 되는 문제가 있기 때문에 우선은 전체 시스템의 일부분의 메모리 만큼만 로컬메모리로 사용하도록 한다.

- redis를 캐시로 사용한다고 해도 결국 너무 많은 캐시로 인해서 스파이크 현상이 발생할 수 있기 때문에 이도 문제가 될 수 있는 부분이다.

- 하지만 그렇게 크게 문제가 되지 않아서 우선 사용하게 되었다.

 

 

새로운 아키텍처를 도입하게된 문제 상황

- 하지만 chat 데코레이션 기능으로 여러 사용자들이 자신마다 설정을 할 수 있는게 많아지게 되었고 실시간성이 부족하게 되어 설정한게 반영되는 부분이 늦어지는 문제가 발생하게 되었다.

- 이 때문에 internal api -> chat mysql -> websocket으로 동작하는 방식을 대신할 새로운 동기화 방식으로 redis pub/sub을 도입하게 되었다.

 

 

새로운 아키텍처

- 사용자가 자신의 chat 데코레이션 기능을 on하면 데이터를 mysql에 저장하고 internal api에 보내는 부분은 기존 시스템과 동일하다.

- 이때 기존의 internal -> mysql로 보내던 부분을 publish 후 websocket에서 subscribe한 뒤 local cache로 쌓아서 사용하도록 변경되었다.

- 이로 인해 거의 모든 시스템이 동시간대에 모든 설정을 한번에 받을 수 있다.

- 추가적으로 브로드 캐스팅 메시지를 redis pub/sub을 이용해서 전송하기 쉬워진다.

 

 

레디스 subscribe의 fault tolerance (for even safer operation)

- 인프라 장애로 인해 redis pub/sub기능이 정상적으로 동작하지 않은적이 있다.

- 장애 예상을 할 수 있다면 자동복구가 가능하고 안심이 가능하다.

- subscribe에 이상이 생기면 자동으로 복구하는 시스템을 만들었다.

- subscriber 서버들의 health를 체크하는 시스템을 구축

- 특정 시스템이 망가지게 되었을 때 특정 웹소켓에 연동되어 있는 사용자들은 subscribe 정보를 받지 못한다.

- 망가진 subscriber는 일정시간동안 subscriber를 하지못하기 때문에 redis서버로 publish (ping)을 주기적으로 보내고 ping정보를 수신하지 못했을 경우에는 내 서버가 정상적으로 subscribe 하지못하는구나라고 판단하고 reconnect를 하도록 설계하였다.

- 결국 각서버마다 핑을 redis에게 publish하고 subscribe 응답을 받지 못했을 때 서버를 reconnect하도록 하는게 전부이다. (드라마틱한 부분은 아닌거 같다.)

 

 

나의 생각

- 내가 생각했던 발표내용은 대규모 redis pub/sub을 하면서 redis의 튜닝이라던가 cluster, standalone 어떤 구성이 더 좋다던가 등의 설명이 있기를 바랬으나 실제 내용은 기존의 시스템에서 mysql을 주기적으로 긁어가는 것을 없애기 위해 publish/subscribe로 변경했다는 내용뿐이여서 너무 아쉬웠다. 

 

출처 : https://www.youtube.com/watch?v=CENLaIz2Yb8

반응형