대형 Discourse 멀티사이트 최적화: 데이터베이스 및 Sidekiq 병목 현상

지원 자체 호스팅
,
1

Discourse 멀티사이트 구성을 최적화하는 방법에 대해 전문가의 조언을 구하고 있습니다. 현재 주요 클라우드 제공사에서 웹 VM 1대와 데이터베이스 VM 1대를 별도로 운영하고 있습니다. 두 서버 모두 사양이 충분하지만, 대량의 백그라운드 작업이 시스템에 과부하를 주며 데이터베이스에 무리가 가고 있는 것으로 보입니다.

현재 app.yml 구성은 다음과 같습니다:

  • UNICORN_WORKERS: 4
  • UNICORN_SIDEKIQS: 4
  • DISCOURSE_SIDEKIQ_WORKERS: 10
  • DISCOURSE_DB_POOL: 8

관찰 결과, 병목 현상은 연결 수의 하드 리밋에 도달하는 것이 아니라, 동일한 시점에 데이터베이스 자원을 두고 경쟁하는 작업의 양 자체가 과도하기 때문인 것으로 보입니다. Sidekiq 큐가 지속적으로 쌓이고 있어, 기본적인 관리 작업조차 사이트가 느리게 느껴집니다.

안정성과 성능을 위해 시스템을 튜닝할 수 있는 일반적인 접근법을 찾고 있습니다. 구체적으로 다음 사항에 대한 모범 사례를 이해하고 싶습니다:

  • Sidekiq 동시성: 멀티사이트 환경에서 DISCOURSE_SIDEKIQ_WORKERS는 데이터베이스에 무리가 가지 않으면서 높은 작업량을 처리하기 위해 어떻게 설정해야 하나요?
  • 큐 분리: 서로 다른 큐(예: critical vs. low 우선순위)를 처리하기 위해 별도의 Sidekiq 프로세스를 실행하는 것이 권장되나요? 이렇게 하면 무거운 작업이 더 시급한 작업을 차단하는 것을 방지할 수 있습니다.

현재는 주요 아키텍처 변경이나 다른 웹 서버로의 전환이 필요한 해결책보다는, 프로세스를 최대한 단순하고 리스크가 낮게 유지하기를 원합니다. 안전하고 효과적인 진행 방향에 대한 조언을 듣고 싶습니다.

감사합니다!

2

Discourse는 시스템 리소스에 따라 이러한 설정을 자동으로 조정할 수 있습니다. 최근에 시스템 리소스를 증가시켰다면 ./discourse-setup 스크립트를 다시 실행하는 것이 안전합니다. 이 스크립트는 증가된 리소스에 맞춰 .yml 파일을 자동으로 조정합니다.

3

작업자 수를 줄여야 하는 것 같네요?

우선 순위가 높은 작업들을 우선적으로 처리하도록 이미 알고 있을 거라고 확신합니다.

4

@itsbhanusharma @pfaffman 도움 주셔서 감사합니다. 두 분 모두 시간을 내어 전문 지식을 나눠 주신 것을 진심으로 감사드립니다.

5

데이터베이스가 병목 현상의 원인이라면, 클라우드 데이터베이스의 인스턴스 유형을 더 큰 것으로 변경하는 것을 고려해 보셨나요?