“극한 부하로 인해, 이 화면은 현재 로그아웃된 사용자에게 보이는 것과 동일하게 임시로 표시됩니다”
저는 농구 경기 중 실시간 스레드를 제공하는 웹사이트를 운영하고 있으며, 경기 중(최고의 활동 시간대) 서버가 과부하를 받아 이 메시지가 표시되는 문제를 겪고 있습니다.
이 문제를 해결하는 가장 좋은 방법을 파악할 수 있는 방법이 있을까요? 저장소 속도인가요? 메모리인가요? CPU인가요? 서버를 업그레이드하는 것 외에 다른 조치를 취할 수 있을까요? 아니면 이 시간대에 서버를 업그레이드해야 한다면, 어떤 부분을 강화해야 할까요?
포럼을 사용하는 사람의 수를 줄이는 건 어떨까요? 아니면 게임 시간에만 몰려드는 대신, 사용 시간을 분산시키는 것도 좋습니다.
하지만 그 방법들은 도움이 되지 않습니다. 게임이 시작되는 시간을 알고 계시니, 게임 시간에만 서버를 강화하거나, 게임 시간 동안 로드 밸런서를 통해 여러 대의 서버를 동시에 운영하는 것이 더 나은 방법입니다.
더 많고 빠른 CPU 코어와 더 많은 RAM이 필요하므로, 피크 트래픽을 처리하기 위해 웹 프로세스(Unicorn Workers) 수를 늘릴 수 있습니다.
@sam이 현재 이 부분을 적극적으로 작업하고 있습니다. 성능 측면에서 볼 때, Discourse의 최신 버전들이 이 부분에서 오히려 퇴보한 것으로 보입니다.
그러나 근본적인 해결책은 수백 명이 동시에 실시간으로 상호작용해야 한다면 라이브 채팅 도구를 사용하는 것입니다 – 다만, Twitch나 YouTube 스트림처럼 스크롤이 너무 빨리 올라가서 아무도 내용을 제대로 볼 수 없는 채팅이 왜 “유용한” 것인지 여전히 의문입니다. 
이 스레드에서 해당 문제를 잘 설명하고 있습니다.
문제가 발생하기 전에 축구 토론 게시판에서 제가 겪었던 경험은 다음과 같습니다:
Digital Ocean
1 CPU 1 GB = 채팅과 유사한 상황에서 30~40명
2 CPU 2 GB = 채팅과 유사한 상황에서 70~80명
4 CPU 8 GB = 120명, 2시간 동안 1000개의 게시글에 대해 문제없음. 한계에 도달하지 않음.
Hetzner(미러 사이트) 사용 시
제 경험은 다음과 같습니다:
3 CPU(CPX 21 AMD 칩) 4GB = 20명에서 버거워함
2 CPU(Intel) 8GB = 20명에서 문제없음.
더 많은 사용자로 테스트해 볼 기회는 없었습니다.
핵심은 CPU와 RAM을 개선하는 것입니다. 그리고 또한 app.yml 파일을 수정해야 합니다.
여기에 더 많은 유니콘(프로세스)을 추가하고, db_shared_buffers 값도 변경해야 합니다.
스포츠 포럼에서는 경기 라이브 텍스트 업데이트에 가깝습니다. 사람들이 채팅을 하는 것이라기보다는(특히 전반 종료 시점에는 어느 정도 채팅도 이루어지지만), 오히려 같은 팬들로부터 라이브 텍스트 해설을 받는 것입니다.
많은 사람들이 라이브 텍스트를 읽기 위해 포럼에 접속합니다. 주요 인물들의 주요 경기 상황별 생각과 의견을 보는 것이죠. 유머러스한 반응부터 진지한 분석까지 다양합니다.
경기를 놓쳤다면, 사람들은 이벤트별 해설을 읽기 위해 접속합니다. 직장에 있는 사람들에게는 아주 좋습니다 
신문이나 TV 채널의 텍스트 해설보다 더 개인적이고 편향적이지만요.
맞습니다. 업그레이드된 서버에서 discourse-setup을 실행하면 해당 작업이 수행됩니다.
그 말씀에 공감합니다. @sam, @eviltrout, 그리고 저도 이 문제를 꼼꼼히 살펴보고 있습니다. Discourse가 점점 더 인기를 얻으면서 "수백 명의 사용자가 동시에 로그인하여 동일한 주제를 보고 있다"는 상황이 최근 꽤 자주 발생하고 있습니다.
이런 상황이 발생하면 새로운 행동 방식을 제안할 필요가 있을 것 같습니다. 주제 UI에 어떤 형태로든 “패스트 레인” 표식이 표시되기 시작해야 할 것입니다… 
여기서 기억해야 할 중요한 점은 “채팅” 구현 방식이 일반적으로 실제 콘텐츠를 구독자들에게 브로드캐스트한다는 것입니다.
Discourse에서는 상당히 복잡한 파이프라인이 있어, 단순한 구현 방식이 대량의 트래픽을 유발하는 복잡한 결과를 낳습니다.
(다양한 최적화, 속도 제한, 재시도 등의 기법을 사용하고 있지만, 핵심은 이렇습니다.)
이러한 모든 요청은 사용자가 게시글을 볼 권한이 있는지 등을 확인하기 위해 보안 파이프라인을 거쳐야 합니다.
만약 콘텐츠가 비교적 짧고, "패스트 레인"에서 보안을 더 가볍게 처리할 수 있는 방법을 찾아낼 수 있다면, 채팅 메시지를 브로드캐스트로 분배할 수 있을 것입니다. 이렇게 하면 성능이 크게 향상되어, 해당 설계로 단일 2GB Digital Ocean 드롭렛에서 10,000명의 사용자를 처리할 수 있을 것입니다.
보안은 매우 복잡합니다. 캐시 무효화 문제 때문에 캐싱도 복잡합니다.
따라서, 네, 우리는 이 문제에 대해 확실히 고민하고 있습니다. 하지만 현재 상황은 …
한 토픽에 로그인한 시청자가 많고 + 한 토픽에 새 콘텐츠가 많이 생성되면 = 비싼 서버 비용이 발생합니다.
정말 대단하네요!
솔직히 말하면, 위험할 만큼의 지식만 있는 상태입니다. 저는 직접 플레이(그리고 깨뜨리며) 배우는 타입이에요. 이 플랫폼을 만들느라 정말 많은 노력을 기울여 주신 점 진심으로 감사드립니다. 12개월 전에 처음 포럼을 만들었을 때, Vanilla, MyBB, SMF, Flarum 등 12개나 되는 다른 버전을 만들어 봤거든요 
그중에서도 Discourse가 압도적으로 좋았습니다.
가장 큰 장점 중 하나는 활발한 개발 활동입니다. 커뮤니티의 의견을 경청하고 지속적으로 개선해 나가는 모습을 볼 수 있어 정말 좋습니다.
이 부분에 대해 권장 설정이 있나요?
여러분, 제 사이트가 후퇴한 것 같습니다. 동일한 DO 패키지(8GB, 4CPU)를 사용하는데, 1000개의 게시글을 작성하는 60~70명의 사용자가 있을 때 사이트가 버거워하기 시작했습니다.
두 가지만 궁금합니다.
극한 부하(extreme load) 메시지를 제거할 수 있을까요? 도움이 되는 것보다 사용자들에게 더 많은 경각심을 주는 것 같습니다.
대규모 사용자 수를 처리하는 데 진전이 있었나요?
그동안 unicorn 설정을 수정하고 플러그인을 비활성화하는 등 자원을 확보하기 위한 방법을 모색해 보겠습니다.
설치 후 크기를 변경했다면 discourse-setup을 다시 실행했나요, 아니면 설정을 수동으로 변경했나요?
방금 수동으로 처리했는데, discourse setup을 실행해야 했나요?
필요한 편집을 수행했다면 재빌드(destroy/start가 가능한지 확실하지 않음)해야 합니다.
잘못 이해하고 있는 건 아닌지 확인하려고 합니다. yml 파일을 수정한 후 단순히 ./launcher rebuild app 명령을 실행했습니다.
대신 ./discourse-setup 명령을 시도해 볼 가치가 있을까요?
(앞서 언급했듯이, 저는 위험할 정도로 딱 필요한 지식만 갖추고 있습니다 
)
문제가 없을 것입니다. Discourse-setup이 메모리 설정을 자동으로 변경해 줍니다. 그렇게 하셨다면 문제없습니다.
확실히 하고자, 그리고 궁금해서 여쭤봅니다: 스왑이 구성되어 있나요?
현재 2GB 스왑 파일을 사용 중인데, 8GB 스왑 파일 사용을 권장하시나요? (RAM 용량과 맞출까요?)
디스크 공간이 충분하다면, 스왑을 더 늘려도 해롭지는 않습니다. free 명령어를 사용하면 메모리 사용량과 스왑 사용량을 확인할 수 있습니다.
