현재 아키텍처는 로드 밸런서가 적용되어 있으며, 라운드로빈 방식으로 EC2 서버에 트래픽을 배정하고 있습니다. 이에 따른 문제와 질문은 다음과 같습니다.
문제:
채팅 요청이 많아져 서버를 증설할 경우, 1번 채팅방에 연결된 클라이언트들이 서로 다른 서버에 할당됩니다. 예를 들어, 클라이언트 A는 서버 A에 연결되고, 클라이언트 B는 서버 B에 연결됩니다. 하지만 두 클라이언트는 동일한 1번 채팅방에 속해 있음에도 불구하고 서로에게 메시지를 전송할 수 없습니다.
잠정적 해결책:
Nginx에서 특정 채팅방 토픽마다 고정된 서버로 라우팅을 설정하면, 이 문제를 일시적으로 해결할 수 있습니다. 그러나, 이 방법은 매번 서버 설정을 변경할 때마다 Nginx 설정 파일을 수정해야 하므로 비효율적입니다.
질문:
서버가 여러 대로 분산되었을 때, Nginx가 각기 다른 서버로 트래픽을 분배해도 모든 클라이언트가 동일한 채팅방에서 정상적으로 채팅을 주고받을 수 있는 방법은 무엇인가요?
pubsub
이새끼 차에코인가 - dc App
아 댓글말고 게시글 쓴사람 - dc App
아니다.. - dc App
차에코는 이것보다 가독성 떨어짐
가독성 구리다해서 바꿨다..
채팅 서버의 스케일 아웃을 고려안하고 하고 있었음.. 스케일 아웃 적용 생각보다 어렵네
뭐만하면 나네 시발ㅋ 그냥 레디스로 방을 기준으로묶어라 해보니깐 최적화 개좆이다 - dc App
레디스 쓰기 싫은데 다른방법 없음?
소켓에담구면 무거워질것같은뎅 추가적으로 메시지저장같은것도 백그라운드돌리고 최적화할것많드라 대강 레디스쓰자 메시지무거우면 쓰레기챗아니냐 - dc App
공부도 안하고 대충 싸갈기는거라서 최대한 레디스 안쓰려고 하려고 했는데, 네 말대로 걍 레디스 쓰는거 고려해봐야겠다.
대충 싸갈길꺼면 그냥 블로그보고 3일안에 끝내고 땡쳐라 - dc App
펍섭이 최선이지
걍 메시지큐써서 다른 서버로 다시 전송시키는 방법밖에 없음??
모든서버에서 숏폴링때리는 방법도 잇음
채팅방이라는 개념을 뭘로만들었는지부터 설명해야지
단순하게 채팅방이 가져야 할 필드목록들과 토픽 구독에 쓰일 UUID 로 이루어져있어용..
뭔소리야 ㅋㅋ 시스템설계를 어떻게했냐고. 막말로 채팅로그를 db로 관리한다던지 이런걸 설명해야 뭐가문제인지를 짚어주지