네, 유니콘을 늘리는 것이 여기서는 첫 번째 단계입니다.
@sam 님이 최근에 이 부분에 많은 시간을 보냈으니, 혹시 코멘트가 있을까요?
@sam 익명 트래픽(예: 특정 주제가 소셜 미디어에서 바이럴되는 경우)으로 인한 피크 트래픽을 추가로 최적화하는 방법에 대해 아이디어가 있으신가요? 위에서 언급한 두 경우 모두 Digital Ocean 기준으로 메모리와 CPU에 여전히 여유가 있으며, 부하가 4에 도달하지도 않았는데도 워커 수를 3배로 늘렸음에도 포럼이 “극한 부하” 모드로 진입합니다.
병목 현상이 무엇인지 파악할 수 있도록 일부 데이터를 수집해야 합니다.
DO의 데이터 모니터는 충분히 민감하지 않고, 다소 오해의 소지가 있다고 생각합니다. Hetzner와 Digital Ocean에서 극한 부하를 실험해 봤습니다. Hetzner의 경우, 극한 부하 메시지가 표시될 때 120%까지 치솟는 짧고 급격한 피크가 발생했습니다.
약 1초 정도 지속된 후 40~50% 수준으로 떨어졌습니다.
Digital Ocean에서도 동일한 상황을 재현해 봤는데, 기억에 따르면 CPU 사용률이 50%를 넘지 않는 것으로 보였습니다. (단, X축을 초 단위로 변경할 수 없었습니다)
제 추측으로는 DO의 CPU 수치가 5초 또는 15초 평균일 가능성이 높습니다. 따라서 짧고 급격한 피크를 볼 수 없는 것입니다.
더 깊이 살펴보기 위해서는 Prometheus exporter 리포트가 필요합니다.
RAM과 CPU 여유가 있다면, Unicorn 워커를 늘려 피크 시간대에 맞춰 스케일업할 수 있습니다. 다만 메모리가 스왑되면 성능이 크게 떨어지므로 이를 피해야 합니다.
이런 경우 해당 단일 주제 페이지는 백엔드에 접근하지 않고 짧은 기간 동안 캐시되고 정적으로 서빙될 수 있어야 할 것 같습니다. Discourse가 이를 수행할 수 있는지(즉, 부하가 걸렸을 때 캐시 제어 헤더를 설정하고 익명 사용자에게 콘텐츠를 서빙하는지) 그리고 DO(DigitalOcean) 설정에 체인 내에 능력이 있는 캐싱 프록시가 있는지 모르겠지만, 제가 완전히 틀린 것이 아니라면 그리고 이미 그렇게 되어 있지 않다면 고려해 볼 가치가 있는 개발 아이디어일 수 있습니다.
아마 @sam이 이미 이 부분을 생각했거나 구현했거나, 왜 나쁜 아이디어인지 알고 있을지도 모릅니다!
실제 부하 하에서 이미 토픽별로 동적으로 처리되고 있으며, 바로 이것이
…를 가리키는 것입니다. 다만 해당 모드는 **읽기 전용(READ ONLY)**이므로, 사람들이 실제로 대화를 나눌 수는 없습니다.
네, 맞아요. 제 제안은 익명 사용자를 짧은 타임아웃(60초 정도?)이 설정된 캐시된 페이지로 부팅시켜 부하를 줄이고, 나머지 사이트가 읽기/쓰기 모드로 계속 작동할 수 있기를 기대하는 것입니다.
그렇게 되면 정말 좋겠습니다. 현재 저희 20만 명 이상의 텔레그램 채널에서 특정 주제를 소개하면, 로그인한 사용자가 약 50명뿐(99%가 익명 트래픽)인 상태에서 디스코스 사이트 전체가 거의 1시간 동안 ‘읽기 전용’ 모드로 전환됩니다.
이미 이렇게 처리되고 있습니다. 토픽 목록 페이지와 토픽 페이지에서 익명 사용자를 대상으로 Redis에서 직접 상당히 공격적인 캐싱을 수행하고 있으며, 타임아웃은 60초입니다.
병목 현상을 파악하기 위해 Prometheus를 실행해 보겠습니다. 하지만 @Alec가 언급했듯이 DO의 모니터링이 지연되고 있는 것이 가능성이 높아 보입니다. 만약 그렇다면 더 큰 머신으로 전환하는 것이 해결책이 될 것 같습니다.
