인프런 커뮤니티 질문&답변
작성한 질문수
Streaming 중인 서비스에서 모든 파드에 broadcast하는 방법
작성
·
47
0
대규모 트래픽 환경에서 broadcasting을 잘 처리하는 방법이 궁금합니다.
만약 파드가 60개가 띄워져 있고 60명의 유저가 각 파드에 한 명씩 room에 배치되었다고 할 때, a 유저의 메시지를 60명의 유저에게 보여져야 한다고 가정해 보겠습니다.
이때, 한 파드에 유저 모두가 room에 들어와 있는 게 아니라 각 파드 별로 room에 유저가 한 명씩 배치되어 있다고 하면, 모든 유저에게 broadcast를 해야 할텐데 어떻게 해야 효율적으로 처리할 수 있을까요?
만약 단일 메시지만 전달해야 한다면, redis pub/sub 구조로 충분히 처리할 수 있을 것 같은데 streaming으로 작은 chunk 단위로 메시지를 보내야 하는 경우는 redis network bandwitdh를 가뿐히 뛰어넘을 것 같습니다.
room의 기준이 되는 id를 hash화하여 특정 파드에 클라이언트의 socket 연결을 고정하는 방법도 사용하나요?
예를 들어, room의 기준이 되는 id를 hash화 한 후에 한 채팅방 세션에 속한 유저들이 한 파드에 Socket 연결을 몰아서 이어버린다면, broadcasting을 하지 않아도 될 것 같은데 이런 접근법은 많이 쓰이는지 궁금합니다.
감사합니다!
답변 3
1
안녕하세요 질문 턴태님 질문 주셔서 감사합니다. 이 강의는 기본적으로 단일 인스턴스 상황을 가정하여 예시로 어떤 형태인지 알려드리고자 촬영이 되었는데 이렇게 더 큰 그림을 보시면서 다중 인스턴스 상황을 가정하셨다니!! 너무나도 기쁘네요 ㅎㅎ 이렇게 강의 내용을 넘어서서 고민하시는 분들이 더 많아지면 좋겠습니다.
일단 메시지 자체가 화면상에 보이는 부분은 문제가 되지 않습니다. UI에서 이런 부분은 모두 표기가 가능하기 떄문이에요
하지만 서버간 이 메시지를 동기화 해야 한다면 문제가 조금 복잡해 질 수가 있습니다.
말씀해 주신대로 단일 메시지의 경우에는 단순히 Pub/Sub 모델이 가장 많이 사용이 됩니다. 메시지 자체의 크기가 크지 않기 떄문에 효과적이고 모든 서버에 요청이 가기 떄문에 구현을 하는데에 있어서 큰 문제가 없고 말씀해주신대로 roomId와 기본적인 prefix가 혼용이 되어서 이벤트가 브로드캐스팅 될 것입니다.
또한 한쪽에 소켓 통신을 모는 행위는 사용하지 않는 편인거 같습니다. 부하에 대해서도 핸들링 할 수 있는 부분이 적고 애초에 한쪽에 커넥션을 몬다는 행위가 LB를 적용하는 의미가 없어지기 떄문이죠
한가지 더 질문을 주셨는데 스트리밍 관련해서는 Redis Pub/Sub 모델을 사용하지 않습니다. 대표적으로 WebRTC같은 기술이 사용이 되거나 Peer to Peer와 같은 형태가 사용이 됩니다.
일반적으로 Soop이나 네이버 치지직과 같은 서비스는 이 P2P랑 웹 소켓 통신을 혼용해서 사용한다고 봐주시면 됩니다.
0
오 답변 감사합니다.
그러면 스트리밍 말고, 클라이언트 <---웹소켓---> 백엔드 서버 <---SSE--- LLM 서버 처럼 LLM 서버가 백엔드 서버로 sse를 통해 데이터를 잘게 쪼개서 계속 보내주고, 백엔드 서버에서 클라이언트로 계속 메시지를 보내고 있는 상황일 때는 괜찮을까요? (ex. chat gpt나 claude 채팅방에 여러 명의 유저가 들어와 있는 상황)
이 경우에 redis pub/sub에 데이터 송수신이 많아질 것으로 예상되어 고민이 되더라고요!
0
안녕하세요, 인프런 AI 인턴입니다. 턴태님의 질문에 대해 답변드리겠습니다.
대규모 트래픽 환경에서 효과적으로 데이터를 broadcasting하는 방법에는 여러 기술적 접근이 존재합니다. 특히 유저들이 여러 파드에 분산된 상황에서 모든 유저에게 메시지를 전달하는 것은 매우 복잡한 작업이 될 수 있습니다. 아마도 여기에 대해 고려할 수 있는 몇 가지 방법을 제안드리겠습니다.
Redis Pub/Sub 사용: 기본적으로 Redis의 Pub/Sub 모델은 다수의 수신자에게 메시지를 전달하는 데 효과적이지만, 매우 높은 트래픽 환경에서는 네트워크 대역폭의 병목이 발생할 수 있습니다. 이런 경우 Kafka와 같은 분산 스트리밍 플랫폼을 사용하는 것이 더 효율적일 수 있습니다. Kafka는 더 높은 처리량과 안정성을 제공하여 스트리밍 데이터의 처리를 지원합니다.
Hash 기반 클라이언트 소켓 연결: 말씀하신 것처럼, 클라이언트의 소켓 연결을 특정 파드에 고정하는 방식은 종종 사용됩니다. 이를 통해 데이터 일관성을 유지하고 특정 파드 내부에서의 통신을 최적화할 수 있습니다. Consistent Hashing을 사용해 유저들을 특정 파드로 라우팅하면, 동일한 Room의 유저들이 항상 같은 파드에 연결되어 효율적으로 메시지를 처리할 수 있습니다.
Broadcast 최적화: 모든 파드에 메시지를 동시에 전송하는 대신 각 파드가 중요한 메시지에 대해서만 독립적으로 트리거될 수 있도록 설계하는 방법도 있습니다. 이를 위해 특정 메시지만 특정 유저에게 전달하는 데이터 패턴을 분석하여 트래픽과 자원을 효율적으로 사용하는 방법을 적용할 수 있습니다.
해당 방법들은 고급 트래픽 관리 및 데이터 전송을 효율화하는 데 도움을 줄 수 있습니다. 각 방법은 특정 상황과 요구사항에 맞게 조정되어야 하며, 실제 구현 시 다양한 성능 테스트를 통해 최적의 솔루션을 찾는 것이 중요합니다.
관련해서 자세한 내용은 다음 URL을 통해 확장된 논의를 참조하시는 것이 좋습니다:
- 소켓 서버의 수평적 확장 및 무중단 배포에 대해 질문드립니다!
- 채팅 클라이언트는 누구와 연결되는지
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.
제가 이제 말씀해주신 아키텍처에 대해서 지식이 전무하여 구체적인 답변을 드리지는 못하겠습니다.
하지만 chatGPT나 claude가 웹소켓 프로토콜을 사용하는지 알아야 할 꺼같고
개인적인 생각으로는 HTTP 같은데.. 혹시 알고 계시다면 말씀해 주세요
당연하게도 Redis Pub/Sub을 통해서 부족해 질 수도 있습니다.
그래서 보통 TPS가 많은 상황에서는 kafka와 같이 애초에 메시지 데이터를 분산 저장하는 MSQ를 사용하는 경우도 있습니다.
괜찮은지에 대한 부분은 TPS가 얼마나 나오는지가 좀 더 중요할꺼 같네요.