Message service 아키텍처

Message service 아키텍처

현재

현재

현재 구조에서 트래픽이 많아질 때 문제를 생각해보면 다음과 같다.

1. socket 연결의 리소스 점유와 많은 트래픽으로 pub/sub 속도가 느려진다.

2. pub/sub 속도는 충분하지만 db처리가 느리다.

 

서버를 늘린다면?

서버를 늘린다면

그럼 채널 기준으로 서버를 늘리면 될까?

채널 수와 그에 따른 socket 연결의 리소스는 해결되지만

특정 몇몇 채널에서 엄청난 볼륨의 메세지가 트래픽의 주요 원인이라면 해결되지 않는다.

 

결론

결론

그래서 채널을 기준으로 나누지 않고 사람을 기준으로 라운드 로빈으로 로드 밸런싱하는 접근을 생각해본다.

이 구조에선 어떤 유저가 어떤 pub/sub을 바라볼지 모른다. 그래서 특정 서버의 pub은 모든 서버의 pub으로 전파되어야 한다. 그 전파의 역할에 카프카를 고려해보자.

 

시나리오를 생각해보자.

같은 1ch을 보고
1번 pub/sub 서버에 할당된 A유저
2번 pub/sub 서버에 할당된 B유저

A유저가 pub을 했을 때 B유저에게 sub이 가는 과정

 

1. A유저가 1번 서버로 pub한다.

2. 1번 서버가 kafka에 message를 producer한다.

3. 모든(1번, 2번) 서버는 동일한 consumer로 동작하고 같은 message를 각각 자신의 서버에 pub한다.

4. 결과적으로 A유저는 1번 서버의 sub을 받고 B유저는 2번 서버의 sub을 받는다.

 

서비스 특성상 실시간 성능을 높이기 위해 message를 저장하는 트랜잭션 작업은 별도의 consumer에서 고려한다.

message consumer는 client에서 pub이 들어온 시간만 가지고 있다면 insert 작업 순서엔 제약이 없다.