환경: AWS EC2에서 자체 호스팅된 Discourse, Ubuntu 24.04 AMI 사용. 호스트는 2개 vCPU와 16GB RAM을 갖춘 r7g.large입니다. Discourse 버전은 3.6.0.beta1-dev (db974047e4)이며 정기적으로 업데이트되고 있습니다. WordPress 버전은 6.8.2, wp-discourse 플러그인 버전은 2.5.9입니다. WordPress와 Discourse 모두 Cloudflare 뒤에서 프록시(‘오렌지 클라우드’)로 설정되어 있습니다.
현재 wp-discourse 설정: 모든 주제에 대해 Discourse 댓글을 표시하고 있으며, “Ajax로 댓글 로드” 옵션이 체크되어 있습니다. (독자와 WordPress 사이트 소유자 모두 WP 게시물 아래에 새 댓글이 즉시 표시되기를 원하므로, 소유자의 요구 사항에 따라 “Ajax로 댓글 로드” 옵션을 활성화한 채로 유지하는 것이 좋습니다.)
관찰되는 현상: 일반적으로 wp-discourse는 훌륭하게 작동하고 있습니다. 독자가 WP 게시물을 방문하면 브라우저가 /wp-json/wp-discourse/v1/discourse-comments?post_id=XXXXX를 요청하며(여기서 XXXXX는 예상 게시물 ID입니다), 댓글이 문제 없이 로드됩니다. 새 댓글은 Discourse에 게시된 후 몇 초 이내에 WordPress 쪽에도 표시됩니다.
그러나 방문자의 브라우저는 사이트의 모든 WordPress 주소를 방문할 때 동일한 discourse-comments URI에 대한 호출을 내보내고 있습니다. 사이트의 홈페이지만 아니라, 댓글 아카이브, 소개 페이지, 문의 페이지, 저자 프로필 페이지, 정적 페이지, 검색 페이지 등 모든 페이지에서요. 이러한 요청은 모두 /wp-json/wp-discourse/v1/discourse-comments?post_id=undefined를 대상으로 하며, 24시간 동안 약 20,000건의 요청을 받고 있습니다(대략적으로 제공된 페이지 총 수와 일치합니다).
이것은 큰 문제가 아니지만, 그렇게 많은 추가 요청을 처리하는 것이 WP 오리지널 서버에 눈에 띄는 부하를 주고 있습니다. 지금은 관리 가능하지만, 이 사이트는 걸프 연안 기상 예보 사이트로, 기상 이벤트(특히 허리케인) 기간 동안 일일 조회수 가 정상적인 약 2만 건에서 150만~200만 건까지 급증할 수 있습니다. 하루에 수백만 건의 post_id=undefined 요청을 처리하는 것은 어려울 것입니다.
meta에서 이 문제와 관련이 있는 것처럼 보이는 유일한 것은 2019년 이 스레드이며, 제시된 답변은 “Ajax로 댓글 로드 기능을 끄라”는 것입니다. 위에서 언급했듯이, 제가 운영 중인 요구 사항에 따라 그렇게 하고 싶지 않습니다.
다음은 대표적인 undefined 요청입니다. 이것은 사이트의 홈페이지에 접근할 때 생성된 것입니다:
우회 방법: 이러한 요청이 실제로 무언가를 수행하는 것 같지 않으므로, Cloudflare WAF 규칙을 구현하여 CF 레벨에서 빈 응답 본문으로 응답하도록 설정했습니다. 이로 인해 문제 행동의 영향이 완전히 제거되었습니다—더 이상 오리지널 서버에서 undefined 요청을 보지 않으며, 응답 생성에 CPU를 낭비하지도 않습니다.
질문: 모든 WP 페이지에 대해 discourse-comments?post_id=undefined Ajax 요청을 보내는 것이 wp-discourse 플러그인의 의도된 동작인가요? 실제로 WP 게시물(또는 wp-discourse 옵션에서 페이지가 활성화된 경우 페이지도 포함)을 로드할 때만 이러한 요청을 보내는 것이 조금 더 안전하거나(적어도 조금 더 결정적일 수 있습니다) 좋아 보입니다.
말했듯이, 수만 건의 잘못된 요청을 처리하는 추가 부하를 제거하는 것처럼 보이는 우회 방법이 있으므로 안정적이고 좋은 상태입니다. 하지만 제가 보고 있는 동작이 의도된 것인지 알아보고 싶습니다.
