여기서 기억해야 할 중요한 점은 “채팅” 구현 방식이 일반적으로 실제 콘텐츠를 구독자들에게 브로드캐스트한다는 것입니다.
Discourse에서는 상당히 복잡한 파이프라인이 있어, 단순한 구현 방식이 대량의 트래픽을 유발하는 복잡한 결과를 낳습니다.
- 사용자가 답변을 게시합니다.
- 해당 토픽을 보고 있는 모든 사용자가 브로드캐스트를 통해 새 콘텐츠가 있음을 알게 됩니다.
- 모든 사용자가 서버에 게시글 내용을 요청합니다 (시청자 100명 = 요청 100건)
- 이미지를 가져오거나 최적화합니다.
- 해당 토픽을 보고 있는 모든 사용자가 브로드캐스트를 통해 새 콘텐츠가 있음을 알게 됩니다.
- 모든 사용자가 서버에 게시글 내용을 요청합니다 (시청자 100명 = 요청 100건)
(다양한 최적화, 속도 제한, 재시도 등의 기법을 사용하고 있지만, 핵심은 이렇습니다.)
이러한 모든 요청은 사용자가 게시글을 볼 권한이 있는지 등을 확인하기 위해 보안 파이프라인을 거쳐야 합니다.
만약 콘텐츠가 비교적 짧고, "패스트 레인"에서 보안을 더 가볍게 처리할 수 있는 방법을 찾아낼 수 있다면, 채팅 메시지를 브로드캐스트로 분배할 수 있을 것입니다. 이렇게 하면 성능이 크게 향상되어, 해당 설계로 단일 2GB Digital Ocean 드롭렛에서 10,000명의 사용자를 처리할 수 있을 것입니다.
보안은 매우 복잡합니다. 캐시 무효화 문제 때문에 캐싱도 복잡합니다.
따라서, 네, 우리는 이 문제에 대해 확실히 고민하고 있습니다. 하지만 현재 상황은 …
한 토픽에 로그인한 시청자가 많고 + 한 토픽에 새 콘텐츠가 많이 생성되면 = 비싼 서버 비용이 발생합니다.