모든 조정된 값을 기본값으로 되돌리고 2.6.0 beta4로 업데이트했습니다. 목요일과 금요일에 게임이 예정되어 있어 이번 주 후반에 충분한 테스트 커버리지를 확보할 수 있을 것입니다.
불행히도 해당 수정으로 문제가 해결되지 않았습니다. 600개의 메시지가 오가는 다소 활발한 게임을 진행했는데, 제 테스트에서도 그리고 회원분들로부터도 여러 번의 동결 현상이 관찰되었습니다. 이 현상은 게임 이벤트, 즉 활동량이 급증하는 시점과 일치합니다.
- CPU 사용량은 한도 내에서 잘 유지되었으며, 최고 60% 수준, 평균 부하 30% 수준이었습니다.
- 확실히 클라이언트 측 문제입니다. 채팅 토픽이 동결된 상태에서 인덱스 페이지로 이동하면 읽지 않은 게시물의 수를 확인할 수 있습니다. 다시 해당 토픽으로 돌아가면 게시물이 표시됩니다.
여전히 저를 당황스럽게 만드는 점이자 이 토픽에서 다루지 않은 내용은, 이 문제가 없었던 v2.3 이후 무엇이 변경되었느냐는 것입니다.
주요 업데이트인 2.4와 2.5는 우리의 (코로나19로 인해 길어진) 비시즌 기간에 이루어졌기 때문에 아무도 이상을 느끼지 못했지만, 프리시즌 첫 전시 경기에서부터 동결 현상이 바로 드러났습니다.
내일 시도해 볼 수 있는 파라미터 조정 방법이 있을까요? 내일은 뜨거운 더비 경기이자 원정 경기라 커뮤니티가 매우 뜨거울 것입니다.
우리의 경우, ‘Who’s Online’ 플러그인을 끄고 속도 제한 파일을 비활성화한 것(최근 베타 버전에서 일부 개선 사항이 있었다고 읽었습니다)이 문제를 해결하는 데 도움이 된 것 같습니다.
또한 300명 남짓한 사용자가 같은 주제에서 동시에 클릭하고 글을 작성하는 축구 경기를 가끔 진행했는데, 지난 경기에서는 이전보다 훨씬 더 잘 동작하는 것 같았습니다.
최근 수정 사항이 포함된 최신 버전을 사용하고 계신가요?
부탁드립니다, 테스트 통과 상태로 업데이트해 주세요. 베타 이후로 꽤 많이 다듬었습니다.
네, 최신 베타 버전입니다(최근 48시간 동안 업데이트된 내용 포함).
업데이트했습니다. 보고서는 곧 보내드리겠습니다.
아쉽게도 여전히 문제가 해결되지 않았습니다. 게임이 뜨거웠던 건 맞아요 — 메시지 수가 950개나 있었으니까요. GAnalytics를 주시하고 있었는데, 약 250명이 시청하고 119명이 게시물을 올렸습니다. 이전과 마찬가지로 몇 차례의 동결 현상이 관찰되었습니다. 메시지 버스가 429 오류를 반환했으며, "이 작업을 너무 많이 수행했습니다. X분 동안 기다려 주세요"라는 메시지가 표시되었습니다.
CPU 부하가 약 70%까지 치솟았지만 대기(wa)는 사실상 0에 가까웠습니다. 즉, 활동량은 높았지만 하드웨어가 처리할 수 있는 성능을 충분히 발휘하지 못하고 있습니다.
제가 궁금해하는 그 하나의 질문에 답변해 주시겠어요 — 2.3 이후에 무엇이 구현되어 이런 문제를 일으키고 있으며, 그것이 어떤 가치를 가져다줄 예정인가요?
구현 방식은 이전과 거의 동일하지만, 설정 가능한 전역 앱 레이트 리밋이 추가되었습니다. 원하시면 상한을 높일 수 있지만, 그렇게 하면 시스템이 완전히 무너질 수도 있습니다. 확신은 없습니다.
"동결(freezes)"이 정확히 무엇을 의미하는지 이해하지 못하겠습니다. 현재 부하가 너무 커지면 업데이트가 중단되지만, 이전과 다른 점은 브라우저 새로고침 없이도 페이지가 복구된다는 것입니다. 서버에 여유 용량이 생기면 자동으로 복구됩니다.
여기가 조금 불분명한데, 제 변경 사항 이후에도 사용자들에게 개선 효과가 전혀 보이지 않나요?
서버에 여유 RAM이 많이 있다면 유니콘(unicorn) 워커를 추가해 보세요.
db_shared_buffers 파라미터 값은 어떻게 설정되어 있나요? 처음에는 총 RAM의 권장치인 25%만 할당했을 때 '불안정’한 동작(특히 참여가 활발한 토픽에서 과도한 ‘채팅’ 발생)이 많이 발생했습니다. 하지만 이를 16GB(전체 32GB 중)로 늘린 후에는 그런 불안정성이 완전히 사라졌고, 최근 최신 변경 사항으로 인해 성능이 더 좋아졌습니다.
자, 이 현상은 프로덕션 환경(게임 채팅)에서 모니터링하기가 어렵습니다. 게임마다 환경이 다르기 때문이죠 – 치명적인 이벤트의 양, 상대, 감정적 긴장감 등이 모두 다르기 때문입니다.
우리의 관점에서 핵심 문제는 2.3 버전 이후 서비스 처리 용량이 감소했다는 점입니다. 이것이 핵심입니다. 모든 서버에는 한계가 있지만, 현재는 3월에 2.3 버전을 구동했을 때보다 서버에서 더 적은 성능을 내고 있습니다. 대략적인 백엔드 모니터링 결과에 따르면, 서버가 100% 부하나 용량에 도달하지 못하고 있습니다.
최종 사용자들이 목격하는 것은 UI에서 무슨 일이 일어나고 있는지 표시가 없이 채팅 흐름이 단순히 멈추는 것입니다. 이로 인해 혼란이 생깁니다.
테스트 통과율에 대한 변경 사항이 상황을 개선했을 것이라고 확신하지만, 성능 또는 최대 출력은 여전히 2.3 버전보다 상당히 낮습니다.
우리는 6개의 빠른 코어와 16GB RAM을 갖춘 VPS를 사용 중이며, 유니콘(Unicorn) 프로세스 수는 12로 설정되어 있고, RAM 버퍼 관련 설정은 기본값으로 유지하고 있습니다.
여기서 가장 좋은 다음 단계는 시스템의 과거 모니터링을 설정하여 병목 현상이 어디에 있는지 파악하는 것입니다. CPU 시간이 병목의 원인이 아님을 이미 확인했으니까요. 네트워크 연결이 포화 상태에 도달했을 수도 있습니다!
그리고 node-exporter와 같은 보다 전통적인 서버 지표도 함께 살펴보세요.
이러한 상황이 맞고 더 높은 부하를 견디도록 하려면 다음과 같은 조치를 취할 수 있습니다.
-
레이트 리밋을 줄일 수 있습니다. 이렇게 하면 사용자가 Discourse와 더 공격적으로 상호작용할 수 있습니다. 구체적으로
DISCOURSE_MAX_REQS_PER_IP_PER_MINUTE와DISCOURSE_MAX_REQS_PER_IP_PER_10_SECONDS값을 두 배로 늘릴 수 있습니다. -
유니콘(unicorn) 워커를 더 추가해 볼 수 있습니다.
부하가 과중된 상태에서는 일시적으로 이러한 현상이 예상되는 것이며, 부하가 감소하면 자동으로 복구되어야 합니다.
제 추측으로는 이것이 모두 레이트 리밋과 관련된 것 같습니다. 레이트 리밋은 새로 도입된 것이며 서버를 보호하기 위한 목적입니다. 현재 서버는 설계대로 보호되고 있는 것으로 보입니다.
우리는 다음 설정으로 게임을 시도해 보았습니다…
DISCOURSE_REJECT_MESSAGE_BUS_QUEUE_SECONDS: 0.3
DISCOURSE_MAX_REQS_PER_IP_MODE: none…그리고 3쿼터에서 감정이 고조되기 시작하자 상황이 더 악화되었습니다. 서버의 한계에 도달했고, 사용자는 계속 로그아웃 모드로 밀려났으며, 게임 채팅도 동결되었습니다.
지난 4년간 훌륭한 성공 사례였지만, 지금은 매우 어려운 상황에 처해 있습니다. VPS 용량을 다음 단계로 올리면 월 약 160유로 가격 범위로 올라가는데, 이는 취미 사이트로서 부담스러운 금액입니다. 사용자 수 자체가 매우 많은 것도 아닙니다. 게임 동안 116명의 사용자가 800개 이상의 메시지를 게시했습니다.
채팅 금지 이념도 적합하지 않습니다. 채팅이 없다면, 감성적인 반응 게시물이 더 “진지한” 주제들 사이로 흩어질 것입니다. 이러한 채팅은 라이브 상황의 감정적 에너지를 단일 주제로 유도하고, 더 분석적인 주제들을 깔끔하게 유지하는 데 중요한 도구입니다.
저는 축구 포럼을 운영 중이며, 비슷한 문제를 겪어본 적이 있습니다.
결론적으로 제가 발견한 것은 확장성(scalability) 문제였습니다.
제 경우, 문제는 다양한 수준에서 발생했습니다.
Digital Ocean
1 CPU, 1 GB = 채팅 상황처럼 30~40명
2 CPU, 2 GB = 채팅 상황처럼 70~80명
4 CPU, 8 GB = 2시간 동안 120명과 1000개의 게시물에 대해 문제없음. 한계에 도달하지 않음.
더 저렴한 Hetzner(미러 사이트)의 다른 단계별 업그레이드를 시도해 보고 있는데, 예상만큼 순조롭지 않았습니다.
지금까지의 제 경험은 다음과 같습니다.
3 CPU(CPX 21 AMD 칩)와 4GB = 20명 사용 시 어려움을 겪음
2 CPU(Intel)와 8GB = 20명 사용 시 문제없음.
곧 경기 상황(실시간 트래픽)에서 동시 접속자 80~100명으로 테스트할 예정입니다.
Digital Ocean에서 CPU 사용량을 확인했을 때, 스트레스 테스트 중에도 모든 단계에서 CPU 사용량이 비교적 낮게(<50%) 유지되었습니다.
Hetzner의 AMD 칩에 대한 CPU 사용량을 확인했을 때, 중간값(median) CPU 사용량이 약 60%였지만, 1분마다 CPU 사용량이 300%까지 치솟는 짧은 스파이크가 발생했습니다. Intel 칩에서는 이런 현상이 관찰되지 않았습니다.
이것이 무엇을 의미하는지는 알 수 없습니다. Hetzner의 CPU 모니터링이 더 정밀하여 짧은 스파이크를 포착하는 것 같습니다. 하지만 전반적인 CPU 사용량은 잘 균형 잡혀 보입니다. 겉으로 보기에는 Digital Ocean이 스파이크를 더 잘 처리하는 것처럼 보이지만, 이번 주말 이후 Hetzner에 대해 더 많은 정보를 얻을 수 있을 것입니다.
Hetzner 테스트에서 whose 온라인 플러그인이 어떤 차이도 만들지 않았다는 점도 덧붙여야 합니다.
하지만 discourse 빠른 메시지 플러그인은 오히려 해로운 것으로 seemed했습니다.
다음 게임은 내일 시작됩니다. 우리는 자체적으로 적용했던 해킹(우회 처리)들을 제거하고, 이 설정으로 테스트를 진행 중입니다.
또한, 아주 불확실한 시도(long shot)로 db_shared_buffers를 4GB(25%)에서 6GB(37.5%)로 늘렸습니다. 또한 app.yml의 db_work_mem 40MB 줄을 주석 해제했습니다(참고로 이 옵션은 문서화가 매우 불분명하지만, 관리자에게는 개선의 기회인 것처럼 제시되고 있습니다).
더 이상 이 문제의 해결책을 찾기를 기대하지는 않습니다. 다만, 더 나은 피해 관리, 즉 최종 사용자에게 가장 적은 부정적인 UX 영향을 미치는 파라미터 세트를 찾는 것만 기대하고 있습니다. 그사이 저는 호스팅 리소스를 더 늘릴 수 있는 가능성을 파악해야 합니다.
@sam 및 다른 개발자분들께 질문드립니다.
데이터베이스의 크기가 계속 커지는 것이, 사용자가 몇 시간 동안 단일 토픽에 집중적으로 몰리는 이 사용 사례에 어떤 영향을 미치나요?
과거 게임 채팅 활동을 살펴보니, 2017년 당시 서버 자원이 지금보다 훨씬 적었음에도 불구하고 통계 수치가 매우 큰 게임들이 있었습니다. 165명의 사용자가 1,600개의 게시물을 작성한 게임도 있었는데, 당시에는 성능에 대한 불만이 전혀 없었습니다. 그런데 지금은 훨씬 더 강력한 서버를 갖추고 있음에도 불구하고 그 절반 수준조차 처리하지 못하고 있습니다.
다른 변경 사항 대신 80MB로 늘려보는 것을 시도해 볼 수 있습니다.
이 부분은 우리가 항상 적극적으로 개선하고 있는 부분입니다.
Discourse가 처음 출시되었을 당시에는 거의 모든 사이트가 완전히 새로운 데이터베이스를 사용했기 때문에 데이터베이스가 메모리에 쉽게 올라갈 수 있었습니다. 그러나 몇 년이 지난 지금, 일부 사이트는 100GB가 넘는 데이터베이스를 가지고 있으며, RAM 용량은 그 10분의 1에도 미치지 못하는 경우가 있습니다.
몇 주 내에 예정된 업데이트 중 하나는 PostgreSQL 13 업그레이드로, 이를 통해 가장 큰 객체 크기를 절반으로 줄일 수 있습니다.
그 외, 성능 문제를 디버깅하기 위한 0단계는 Prometheus exporter plugin for Discourse를 사용하여 데이터를 수집하는 것입니다. 이를 통해 우리는 눈감고 운전하는 듯한 상황을 피할 수 있습니다.