제 경험상 현재 어떤 방식으로도 이 문제를 직접적으로 해결할 수 없거나 선형적인 해결책이 존재하지 않습니다. 실제로 이 문제를 해결하기 위해 각 요소를 다른 머신으로 분리하는 것만으로는 즉각적인 해결책이 되지 못합니다.
저희도 큰 이벤트(예: @ljpp 님이 말씀하신 게임 등)가 발생하면 심각한 트래픽 급증과 함께 "사이트가 매우 혼잡하여 로그인하지 않은 사용자처럼 표시됩니다"라는 메시지를 경험하고 있습니다. 이는 해당 토픽에 있는 사용자들뿐만 아니라 사이트 전체의 성능을 저하시킵니다.
그래서 저는 분리된 구성과 “대형 머신” 구성 두 가지를 시도해 보았으나, 두 경우 모두 이러한 유형의 문제가 발생했습니다. 제 인스턴스는 Prometheus로 모니터링되고 로그는 Grafana 등을 통해 확인 가능하므로 하드웨어/컨테이너 성능에 대해 매우 세밀하게 파악할 수 있으며, 어떤 조치를 취하든 결국 문제가 발생한다는 것을 확인할 수 있습니다.
뒤에 대형 머신을 배치하면 문제를 약간 지연시킬 수는 있지만, 결국 오류와 세션 끊김 현상이 발생하며, 디스크, CPU, RAM을 막론하고 머신의 사용률은 거의 0%에 가까울 것입니다. 이는 "기본 설치"와 “2컨테이너” 설치 모두에서 발생하는 현상입니다.
서로 다른 머신을 사용하는 경우에도 문제는 동일합니다. 머신 유형이 동일하거나, 하나가 “CPU 최적화”, 다른 하나가 "디스크 최적화"인 등 어떤 조합이든 마찬가지입니다. 여기에 두 머신 간 연결의 추가적인 장애 요인까지 더해야 합니다. 이 연결은 반드시 지연이 발생하며, 지연의 양은 연결 설정 방식과 두 머신 간의 물리적 거리에 따라 달라질 수 있지만, 결국 동일한 동작을 보일 것입니다.
참고로, Babel 플러그인 같은 경우에도 이러한 유형의 동작이 발생하지만, Babel 플러그인은 "채팅"이 실제로는 숨겨진 토픽임에도 불구하고 훨씬 더 많은 “동시” 쓰기를 처리할 수 있는 것으로 보입니다. 그 차이는 토픽이 어떻게 표시되고 “새로 고침”/"검색"되는지에 있습니다. 이러한 동작상의 차이는 제가 이 문제를 FrontEnd 측면의 문제(제 전문 분야는 BackEnd이므로 FrontEnd는 전문 영역이 아닙니다)로 인해 앱이 "크래시"하는 것과 관련된 애플리케이션 레벨의 상관관계로 결론 내리게 했습니다. 1분 안에 수십 개의 메시지가 쌓이는 상황에서 게시물을 작성하고 토픽이 "자동 업데이트"되기를 기다리는 사용자들의 작업이 그 원인이 되는 것입니다.
여기에 인간적인 요인도 추가해야 합니다. 사람들이 사이트가 "느리다"고 느끼거나 토픽이 "적당히 빨리 업데이트되지 않는다"고 생각하면 F5 키를 무차별적으로 눌러 더 많은 부하를 가합니다. 그런 부분까지 "교육"시키기는 정말 어렵습니다. 