참고: 이것이 Discourse의 버그인지는 확실하지 않습니다. 필요한 증거를 수집하기 위해 노력해 왔지만, 현재까지 우리의 인프라/설정에서 원인을 가리키는 단서를 찾지 못했습니다. Tappara.co에서는 설정을 최대한 기본(vanilla) 상태로 유지하고 있습니다.
관찰된 현상:
채팅처럼 빠르게 진행되는 토론 주제가 자동으로 업데이트되지 않습니다. 30~180초의 지연 후 업데이트가 재개되는 것이 일반적이며, 동결된 동안 작성된 게시글들이 표시됩니다.
지금까지 파악한 내용
지난 시즌에는 이러한 현상을 확인하지 못했으며, 마지막 경기는 3월에 치러졌습니다.
stable 브랜치를 사용 중이며, 마지막 주요 업데이트는 8월에 수행했습니다.
이 문제는 중간 수준의 트래픽/활동이 발생한 첫 번째 전시 경기에서 즉시 보고되었습니다.
이 문제는 iOS 및 Android Chrome에서 영향을 미치지만, Chromebook에서는 훨씬 드뭅니다.
이 글을 작성하는 동안, 제 Android 폰에서는 동결 현상을 보고 있는 반면, Chromebook에서는 토론이 예상대로 정상적으로 흐르고 있습니다. 같은 네트워크에 있는 두 개의 다른 기기입니다.
사용자/클라이언트마다 경험이 다릅니다. 다른 사용자들이 서로 다른 시간에 동결을 보고합니다. 전반적으로 약 30분 동안 약 300개의 메시지를 기록했는데, 사용자들은 수십 건의 동결을 보고했습니다. 대부분 동결은 경기 내의 이벤트(골, 페널티)와 상관관계가 있는 것으로 보입니다.
제외하기 위해 시도해 본 사항
CloudFlare – CF 캐싱 없이 경기를 한 번 진행했는데, 문제가 지속되었습니다.
CPU 과부하 – CPU 사용량은 한도 내에 있으며, 보통 20~30% 수준으로 유지됩니다.
디스크 용량 부족 – 디스크 I/O도 한도 내에 있는 것으로 보입니다. UpCloud의 MaxIOPS SSD를 사용하고 있습니다.
기타 정보
경기 중 Chrome 인스펙터를 실행하고 있었는데 429 에러가 몇 건 기록되었지만, 제 경우 동결과 상관관계가 없었습니다.
최종 사용자는 429(속도 제한) 또는 극심한 부하에 대한 알림을 받지 못하고 있습니다. 업데이트가 단순히 동결되었다가 다시 재개될 뿐입니다. 최근 레이트 리미터가 변경되었나요? UI에서 알림이 트리거되어야 한다고 생각하는데, 그렇지 않은 것 같습니다.
정말 까다로운 문제입니다. 플레이 바이 플레이 경기 채팅에 큰 영향을 미치고 있습니다. 우리는 수년 동안 이 서비스를 운영해 왔지만, 이전에는 이런 현상을 본 적이 없습니다.
현재 11마리의 유니콘을 사용하고 있으며, 6코어 VPS 환경에서 실행되고 있습니다. 앞서 언급했듯이, 이전 시즌에는 이런 문제가 발생하지 않았으며, 가장 최근에는 3월에 발생했습니다. 지금은 중간 정도의 트래픽에서도 발생하고 있습니다. 또한 데스크톱보다 모바일 기기, 특히 Android Chrome에서 훨씬 더 자주 발생하는 경향이 있습니다.
또한, 이전에도 CPU를 소진한 적이 있습니다(트레이드 마감 시점).
게임을 모니터링하고 서버 설정을 조정하는 동안 한 경기를 놓쳤습니다. web.ratelimited 매개변수를 두 배로 늘렸지만, 문제는 해결되지 않았습니다.
인스펙터에서 429 오류가 여러 건 포착되었습니다:
1. Request URL:
https://tappara.co/message-bus/3ed86765a67f4c31ba4053a0352ecaf5/poll
2. Request Method:
POST
3. Status Code:
429
내일 경기가 있으니 유니콘 수를 늘려서 테스트해 볼 수 있습니다. 얼마나 높게 설정할 수 있나요? 최신 메이저 업데이트로 인해 이 부분이 변경되었나요?
수정:
통계를 살펴본 결과, 현재까지의 활동량(페이지뷰, 사용자 수)은 봄철에 비해 적었습니다. 게임 채팅의 시간당 게시글 수는 동일합니다(3시간당 약 900~1000개).
따라서 원인은 알 수 없지만, 현재는 3월에 비해 동일한 규모의 사용자를 서비스하지 못하고 있는 상황입니다.
이 문제를 디버깅하면서 저는 사실상 실시간으로 이루어지는 토론의 UX(사용자 경험)에 대해 전반적으로 생각하게 되었습니다. 많은 커뮤니티가 실제 생활의 사건들을 다루는데, 이는 자연스럽게 토론을 채팅과 유사한 빠른 대화 형태로 유도합니다. 주식 시장, 주요 제품 출시 행사, 게임(e스포츠나 실제 스포츠) 등 무엇이든 해당될 수 있습니다.
하지만 이러한 채팅형 토론 문화에서는 게시글의 품질이 크게 달라집니다. 또한 게시글들은 자연스레 거의 동시에 작성되는 경향이 있습니다. 예를 들어 큰 하키 경기가 진행 중이고 누군가가 골을 넣었다고 상상해 보겠습니다.
게시글의 상당 부분은 단순히 감정적인 반응, 환호 또는 탄식일 뿐입니다.
“골!!! 와, 대박!”
일부는 정보 제공 목적입니다:
“크로스비가 득점, 펜스 1-0 리드”
소수의 일부는 분석을 담기 위해 노력을 기울입니다:
“크로스비가 캡스의 부주의한 포워딩 체크 이후 브레이크어웨이 골을 넣었지만, 오프사이드 플레이로 보이는 부분이 많았습니다. 캡스 코치는 이 판정에 챌린지를 해야 합니다.”
Discourse는 빠른 플랫폼(사실상 실시간)이므로, 모든 것이 순조롭게 진행되더라도 거의 동일한 시점에 수십 개의 게시글이 생성됩니다. 독자에게, 특히 경기를 직접 보지 않고 채팅 토픽을 통해 경기를 따라가는 사람들에게는 이것이 UX적 과제를 초래합니다. 환호와 탄식 속에서 정보성 게시글을 찾아내기 어렵기 때문입니다. 저희 포럼의 게임 채팅에서는 채팅으로 경기를 보는 사람들이 당연한 정보를 게시하지 않거나, 정보가 메시지 홍수 속에 묻히기 때문에 _“현재 점수는 얼마인가요?”_라는 질문을 자주 받습니다.
이것이 실제 생활에서는 어떻게 작동할지 확실하지 않지만, 관리자가 토론의 **속도(pace)**를 설정할 수 있는지 테스트해 보는 것이 흥미로울 것입니다. 예를 들어, 초당 1개의 게시글만 게시하도록 설정한다고 해 보겠습니다. 모든 게시글은 대기열에 쌓이지만, 정의된 속도로 사이트에 게시됩니다. 만약 한 골에 20개의 반응 게시글이 생성된다면,它们是 동시에 토픽에 나타나는 것이 아니라 20초의 시간 창 동안 순차적으로 나타날 것입니다. 이렇게 하면 따라가기 쉽고 관련 정보를 더 잘 파악할 수 있을까요?
물론 이는 다른 문제들을 야기할 수 있습니다. 새 메시지의 속도가 게시 속도를 지속적으로 초과하게 되면, 점점 길어지는 대기열이 생기고 채팅이 실제 현실보다 뒤처지기 시작할 수 있습니다.
제가 전달하려는 의도를 제대로 이해하셨는지 모르겠고, 심지어 저도 이 아이디어가 좋은 것인지 확신이 서지 않습니다. 핵심은 실시간 채팅의 UX가 흥미로운 토론 주제이며, 추가 개발의 잠재력이 있을 수 있다는 점입니다. Discourse의 주요 초점이 채팅 플랫폼을 만드는 것이 아니라는 점은 잘 이해하고 있습니다. 그러한 용도로는 다른 소프트웨어가 존재하니까요. 하지만 이러한 상황은 자연스럽게 발생합니다.
이 변경 사항은 1,000명이 하나의 주제를 보고 있고 게시물이 작성되고 있는 경우 서버가 다운되지 않도록 보장합니다.
클라이언트가 이러한 상황에서 훨씬 더 깔끔하게 동작합니다.
@ljpp 님의 질문을 예상하여, 아직 백포트 여부를 결정하지 못했습니다. 이는 API 변경 사항이 포함되며 상당히 큰 변경 사항이기 때문입니다. 만약 백포트를 진행한다면 … 아마도 몇 주 정도 걸릴 것입니다. 프로덕션 환경에서 부하가 걸린 상태에서 이 변경 사항을 관찰해야 하며, 호스팅에 여유 공간이 많아 이러한 상황이 거의 발생하지 않기 때문에 이를 확인하는 데 시간이 좀 걸릴 것입니다.
이것이 백포트 후보가 아닐 수 있는 이유에 대해서는 이해합니다. 우리는 현재 _ratelimiter_를 비활성화했으며, 내일이 다음 게임일 예정이라 베타 버전을 설치하지 않으려는 인스턴스에 대해 이것이 실행 가능한 우회책인지에 대한 대략적인 판단을 내릴 수 있을 것입니다.
앞으로 몇 달간 베타 브랜치를 사용하는 방안을 확실히 고려하고 있습니다. 다만, @rizka가 지적했듯이 FI(핀란드어) 번역이 뒤처져 있다는 등 다른 우려 사항도 있습니다(그는 이번 주 후반에 작업을 진행할 수 있을지도 모릅니다).
.