이 설정을 적용했을 때 UX가 더 좋았습니다. 네, 몇 가지 “막힘” 현상이 있었고, Chrome 인스펙터에서 429 오류가 여러 건 기록되었습니다. CPU 부하는 낮았습니다. 하지만 다시 말하지만, 당시에는 비교적 한가한 홈 게임이었기 때문입니다(많은 활성 멤버가 현장에 있었고 채팅을 하지 않았습니다).
구체적으로 어떤 설정을 조정해야 하는지는 명확히 말하기 어렵지만, 제 다소 주관적인 경험에 따르면 다음과 같습니다:
코드의 기능은 여전히 서버 부하에 대해 지나치게 방어적입니다. 서버 스트레스 수준을 약간 더 높게 허용할 수 있을지도 모릅니다.
클라이언트가 백오프(백오프 전략)할 때, UX 관점에서 지연 시간이 너무 깁니다. 게임은 계속 진행되며 1분 동안 많은 일이 일어날 수 있습니다. 채팅이 동기화를 잃고, 사람들이 게임의 서로 다른 이벤트에 대해 언급하게 됩니다. (이것은 실시간 vs 케이블 TV vs IPTV vs 20초 Chromecast 버퍼 등 사이의 다양한 시간 지연 문제로 이어지는 문제를 악화시킵니다.)
사용자는 채팅이 멈췄다는 것만 보고, 사이트가 여전히 온라인이고 활성 상태라는 어떤 표시도 받지 못합니다. 이로 인해 사용자는 페이지를 새로고침하거나 다른 작업을 수행할 가능성이 높아지며, 이는 높은 부하를 더 악화시킵니다.
다시 한번 말씀드리자면, 수천 개의 사이트 중에서도 여러분의 사이트보다 훨씬 더 많은 트래픽을 처리하는 사이트들이 있는데도 이 문제를 보고하는 고객이 없습니다. 따라서 이 시점에서 더 이상의 논의는 사실상 무의미합니다. 왜냐하면 여러분 측에서 발생할 수 있는 특이한 구성 환경이나 하드웨어 성능 관련 이상 현상에 대해 저희는 전혀 파악할 수 없기 때문입니다.
VPS 제공업체에게 문제를 넘기는 것에 대해 추측하지 말아 주세요. UpCloud은 시장에서 가장 우수한 업체 중 하나이며, 자사 측에서 특별한 이상이 없는지 확인을 마쳤습니다. 해당 업체는 저희 사이트에 광고를 게재하고 있으며, 사이트가 버벅거리는 모습을 보여주는 것은 좋은 홍보가 되지 않습니다
하지만 과거 데이터가 없고, 솔직히 말해서 8월에 첫 전시 경기가 열리기 전까지는 모든 것이 정상적으로 작동했기 때문에 그렇게까지 주의를 기울이지 않았습니다. 물론 COVID 덕분에 인간의 행동 패턴이 변했고, 그 외에도 어떤 일이 벌어졌는지 알 수 없습니다. 다만, 저희 사이트나 서버의 메트릭에서는 그런 모습을 확인할 수 없습니다.
하지만 이것은 훌륭한 테스트 자료입니다. 서버 과부하가 발생했을 때 어떤 일이 일어나는지에 대한 스크린샷을 @riking에게 몇 장 전달해 주었습니다. 여러분은 이런 상황을 자주 보시지는 않을 것 같네요.
저도 처음 사이트를 설정했을 때 정확히 이런 경험을 했다는 점을 말씀드리고 싶었습니다. (따라서 이는 특정 사이트에만 국한된 문제가 아닙니다.)
당시에 이 문제에 대해 제가 만든 스레드입니다:
이것이 제가 아래에 설명된 대로 더 높은 CPU/메모리 옵션으로 업그레이드하게 된 직접적인 이유였습니다.
불행히도, 제가 설명했던 대로 Digital Ocean에서 Hetzner로 제대로 전환할 기회가 없었습니다(새로운 직장에 입사했기 때문입니다). 하지만 이번 달에 기회가 되는 대로 진행할 것입니다.
유저가 스레드에서 강제로 나가는 경험, 또는 스레드에 머무는 경험(로그아웃 메시지와 함께). 이는 부하에 따라 상관관계가 있는 것처럼 보였습니다. (골이 들어간 직후에는 더 많은 사용자가 사이트 인덱스로 이동했습니다)
저는 도움을 드릴 만큼 기술적인 지식이 충분하지 않지만, 채팅과 유사한 행동의 피크가 있는 스포츠 사이트에서도 비슷한 문제가 발생한다는 점을 알아두는 데 도움이 될 것 같아 공유합니다. 하지만 제 사이트(더 작고, 운영 기간이 짧은)는 서버를 추가로 업그레이드하면서 해결되었습니다.
코로나19로 인해 하키 시즌이 망가졌고, 지금은 관중 없이 몇몇 경기를 무작위로 치르고 있습니다. UpCloud.com에 호스팅 크레딧이 남아 있어, 현재 보유한 자원을 활용하여 사용자 경험을 개선하기 위해 노력하고 있습니다. 현재 웹 전용으로 6x vCore 16GB, 데이터용으로 4x vCore 8GB를 사용하고 있으며, 유니콘(unicorns)은 18개입니다.
다시 한 번 레이트 리미터를 비활성화했습니다…
DISCOURSE_MAX_REQS_PER_IP_MODE : none
…이것이 도움이 되긴 하지만, POLL에서 여전히 429 에러가 발생하여 최종 사용자에게 긴 지연/동결 현상을 유발하고 있습니다. DISCOURSE_REJECT_MESSAGE_BUS_QUEUE_SECONDS 값을 증가시키며 계속 조정할 예정입니다.
게임 수가 많지 않아서(코로나19 때문) 이 부분을 측정하고 조정해 볼 기회가 매우 적었습니다.
우리가 발견한 바에 따르면, 개선된 하드웨어 리소스(6+4 vCores 및 16+8GB RAM)를 사용하더라도, 비교적 활동적인 사용자 그룹만으로도 429 클라이언트 프리즈가 발생할 수 있었습니다. 이는 약 50%의 정기적인 게임 시청자들이 채팅에 참여한 U20 월드컵 경기에서 확인되었습니다.
이것은 429 오류의 80%를 제거하여 대부분의 사용자에게 비교적 원활한 경험을 제공하는 것 같습니다.
다음 단계는 다른 종류의 하드웨어 리소스를 구매하는 것이었을 것입니다. 단일 스레드 속도를 위해 전용 서버를 사용하는 것이거나, 수많은 vCores를 제공하는 플랜을 가진 VPS 제공업체로 전환하는 것이죠. 하지만 우리에게는 @sam이 이전에 언급했듯이 Discourse 호스팅 팀과 협력하는 것이 다음 단계입니다.
이 조정 사항들이 @iceman, @alec 또는 다른 분들에게 도움이 되기를 바랍니다. CPU 사용량과 큐잉에 주의를 기울이시기 바랍니다. 또한 이 작업을 통해 배운 것은, 컨테이너 2개가 하나보다 훨씬 낫다는 것입니다. 조정 사항을 거의 제로 다운타임으로 적용할 수 있고, 하드웨어 리소스를 더 세밀하게 활용할 수 있기 때문입니다.
실제 사건에 의해 주도되는 빠른 속도의 토론에서 성능/UX를 개선할 수 있는 새로운 조정 사항이나 발견 사항에 대해 여전히 관심이 있습니다.
