아까워서 붙여넣고간다 볼진모르겠다만 혹시나 아직 있다면 한번 읽고나 가렴

일단 이런 질문을 백엔드 준비하지 않은 친구한테 했다는거 부터가 그회사는 안가는게 낫지않을까 싶으요.

-----

수평확장 자체는 맞는 접근인데, redis pub-sub을 쓰는건 아키텍처 자체를 다시 잡아야 되. 경험상 간단한 어플리케이션 만드는 정도라면 redis pubsub으로도 커버 되지만 동시에 1000개 넘는 디바이스에서 패킷이 꽤 쏟아지기 시작하기만 해도 redis는 못버팀(경험담, 실제 케이스 바이 케이스이긴 함). redis 자체가 싱글쓰레드라서 이런 구조에선 한계가 있을수밖에 없음.
일단 앞에 로드밸런서를 박는데, 통신이 쌩 TCP일 경우 haproxy 같은걸 쓸 수 있고, HTTP일경우 nginx 쓸수 있음. 게다가 https를 쓸 경우엔 앞단의 로드밸런서에서 https offloading을 해서 내부에서 https 복호화 연산 부담을 확 줄일 수 있고.

synchronized 방식이 아닌 완전 pub-sub 구조로 간다면 난 redis보다는 kafka를 추천하는 편인데, kafka를 성능 빠방하게 만들어놓고 사용자 패킷 요청 들어오면 패킷의 메시지 별로 토픽을 구분해서 요청을 던지고(pub) 이걸 받아서 실제로 액션을 수행하는(sub) 형태가 적당하지 않을까 싶음.

이렇게 되면 유저와의 소켓을 최종적으로 물고있는 socket front 서버와, 실제 비즈니스로직이 구현되는 back 서버가 별도로 분리되는 구조가 되서 자연스럽게 각각의 아키텍처 레이어별로 사용자의 요청과 비즈니스 무게에 따라서 리소스를 여유롭게 분배할 수 있지.

kafka에 프론트에 백에 뭐 서버가 졸라많이 떠서 기본 운용비용은 비싸겠지만, 전체 시스템 가용성의 범위는 확 늘어나니 나중에 서비스가 커져도 이런 구조라면 커버 가능하지 않을까?