익명 조회수가 갑자기 급증

익명 조회수 수치는 어떤 의미를 갖는지 항상 이해하기 어렵습니다. Google Analytics 데이터와 의미 있는 방식으로 일치하는 것처럼 보이지도 않거든요.

최근 며칠 동안은 특히 이 문제가 부각되었습니다. 익명 조회수가 비정상적으로 크게, 그리고 지속적으로 증가했기 때문입니다.

3/3.1 버전으로 업그레이드한 이후부터 시작되었으므로 우연일 수도 있지만, 시점이 조금 늦게 겹치므로 관련이 있을 수도 있습니다.

동시에 로그인 통계도 상당히 하락한 것으로 보이는데, 이는 우려스럽습니다.

일반적으로 히트(hit)와 조회수, 로그인 통계도 해석하기가 어려운 편입니다. 분석 수치와 일치하지 않기 때문이죠. 하지만 대시보드만 보면 이상한 새로운 추세가 보입니다.

Google Analytics와 대시보드 통계 간의 차이점을 보여주는 간단한 예를 들자면, 하루에 Google Analytics에서 고유 방문자 500명이 보이지만 Discourse 대시보드에서는 로그인 2,000건, 익명 조회수 50,000건, 크롤러 5,000건이 표시됩니다.

이러한 통계 전반적으로 무슨 일이 일어나고 있는 건가요?

이 데이터를 어떻게 다루어야 하며, Discourse 포럼 운영 측면에서 무엇을 알려줄 수 있을까요?

익명 조회수는 원치 않는 농장(farmed) 트래픽의 지표이며 자원의 낭비인가요?

이러한 트래픽은 Google Analytics에서 적절한 옵션을 선택하면 필터링됩니다. Discourse 측에서는 그렇지 않을 수 있으며, 이는 어떤 기이하고 근거 없는 이유로 인한 저수준 DDoS 유형의 트래픽일 수 있습니다. 다시 말해 자원을 낭비할 뿐만 아니라 실제 로그인에도 영향을 미칠 수 있습니다.

아직까지 로그인 문제 관련 보고는 없습니다.

전체적으로 대시보드 수치를 어떻게 해석해야 할까요?

통찰력과 팁을 주시면 감사하겠습니다.

안녕하세요 @agemo!

최근 몇 달간 비슷한 현상을 저도 확인하고 있습니다. 이 문제에 대해 어떤 정보를 찾았나요?

아마도 봇, 특히 AI 스크레이핑 봇일 가능성이 높습니다.

저에게 큰 도움이 된 것은 관리자 페이지의 웹 크롤러 보고서였습니다. 누군가 그 존재를 알려주지 않았더라면 이전에는 전혀 인지하지 못했을 것입니다. 이 보고서를 활용하여 여러 크롤러를 차단했고, 그 결과 익명 페이지뷰가 감소했습니다. 크롤러도 익명 페이지뷰에 포함되는 것으로 생각됩니다. 정확히 어떤 방식으로 포함되는지는 알 수 없습니다.

보고서에는 크롤러 이름(사용자 지시문)도 표시되므로, 각 크롤러가 가치가 있는지 확인하기 위해 검색해 볼 수 있습니다.

아래 주제도 도움이 될 수 있습니다.

그럴 수도 있겠네요. 시스템이 봇과 사용자를 어떻게 구별하는지에 따라 달라질 것 같다는 추측만 가능해요.

최근 며칠 전에도 텍스트가 더 많이 게시될 때 크롤러가 급증하는 것을 보았고, 익명 뷰도 seemingly random하게 급증하는 것을 보았습니다.

이제 새로운 지표를 도입하여 익명 페이지뷰를 '사람일 가능성 높음’과 '봇일 가능성 높음’으로 분리했습니다. 이를 통해 후자를 크롤러처럼 생각할 수 있게 되었습니다(실제로 크롤러로 등록되어야 하지만, 그렇게 자신을 식별하지는 않고 있습니다).

이 리포트는 표준 리포트의 일부이며, /admin/reports/consolidated_page_views_browser_detection에서 확인할 수 있습니다.

봇에 의한 데이터 부풀림을 방지하기 위해 이 방식을 토픽 뷰 지표에도 적용하는 작업도 진행 중입니다.

이 새로운 그래프가 도움이 되네요. ‘아마도 봇’ 카테고리가 '기타 페이지뷰’로 표시되어 있는 것 같습니다:

정체성을 제대로 밝히지 않는 장난기 많은 새로운 봇들이 있는데, 이들의 속도를 늦추거나 출처를 파악할 수 있는 방법이 있을까요?

웹 크롤러 사용자 에이전트 보고서를 확인할 수는 있지만, 거기에 표시되지 않으면 무엇을 더 조사해야 할지 모르겠습니다.

아니요. 해당 봇의 개발자가 보통 그렇듯, User Agent, 기기, 시스템 등 텍스트의 일부가 항상 동일하다면 완전히 차단할 수 있지만, 이를 위해서는 리버스 프록시가 필요합니다. robots.txt는 좋은 행동을 하는 봇을 위한 지침일 뿐입니다.

Discourse가 생성하는 로그는 대략적인 개요만 제공합니다. 이러한 상세한 데이터는 Nginx 로그에서 찾아야 하며, 즉 터미널에 오신 것을 환영합니다. :smirking_face:

WordPress는 봇 때문에 쉽게 무너질 수 있지만, Discourse의 경우 상황은 단순히 짜증나는 정도입니다. 콘텐츠 도용은 오늘날의 일반적 현상이며, 이미 오랫동안 그래 왔습니다.

리버스 프록시가 좋은 첫 단계인 것 같은데, 클라우드플레어가 그 용도로 괜찮을까요?

지역의 웹 개발자 친구가 보안을 위해 클라우드플레어 네임서버를 사용하는 것을 추천해 주었습니다.

공개된 콘텐츠가 '도용’되는 것에 대해 크게 걱정하지 않습니다. 텍스트가 공개적으로 게시되면, 다른 사람이 그것을 자신의 창작물로 팔지 않는 한 기록하는 것은 당연한 권리라고 생각합니다. 만약 자신의 창작물로 판매하려 한다면 그때 문제가 되겠죠.

Nginx나 Varnish를 추천합니다. 하지만 Cloudflare도 잘 작동할 수 있을 것 같지만, 제가 잘 알지 못해서 사용해 본 적이 없습니다.

어제 8월 17일에 봇 "기타 페이지 뷰"가 152건으로 비정상적으로 급증했습니다. 평소 하루 평균 15~20건에 불과한, 거의 활동이 없는 사이트에서 매우 이례적인 수치입니다.

전혀 이상하지 않습니다. 제 경우에는 가장 나쁜 사용자 에이전트를 차단하고 지오토픽 블로킹을 함께 사용했을 때 가장 좋은 결과를 얻었습니다. (제 포럼은 글로벌 포럼이 아니기 때문에 쉽게 할 수 있습니다.)

핀란드 외 다른 국가의 IP를 지리적으로 차단하는 걸 말씀하시는 건가요? 지역 중심의 사이트라면 좋은 아이디어인 것 같습니다.

응. 지금은 러시아, 싱가포르, 중국에서 꽤 많은 트래픽이 들어와. 예전에는 인도, 파키스탄, 이집트, 이란, 이라크였지. 그리고 그들은 핀란드어를 할 줄 모를 거라고 단언해. 러시아는 가능할 수도 있지만… 아니야.

가장 큰 세 곳은 미국, 프랑스, 네덜란드이고, 독일은 성장하고 있어. 하지만 이건 데이터 센터 때문이라서 그걸 차단할 수는 없어.

하지만 다시 말하지만, Discourse에서는 그것들이 그저 짜증나기만 해. WordPress(그리고 다른 LAMP 스택이라고 말하고 싶지만)에서는 부하가 너무 커져서 상황이 DDoS에 가까워지기 시작해.

그리고 대부분은 오래된 WordPress 문제를 이용해 Discourse를 공격하려는 바보 같은 스크립트 키디들이야.

하지만 요즘에는 SEO와 AI 봇이 진짜 문제점이 되고 있어.

하지만 로컬 포럼을 운영하는 경우라면 지리적 차단은 현명한 선택이지.

이것이 문제적인 속도로 진행되고 있을 수 있습니다.

discourse 서비스가 불평을 시작할 때쯤, DDoS 수준의 장애에 근접한 것으로 의심되는 AI 기반 봇 트래픽을 목격했습니다.

매우 강력한 구성은 아니지만, 일반적인 예상 수요에 대해 보통은 어느 정도의 여유(headroom)가 있습니다.

이번에는 거대한 익명 트래픽과 기타로 나타났습니다.

이것은 서버 CPU, 로드, 디스크 I/O 통계의 증가와 완벽하게 일치했습니다.

여기의 사용자로서 저는 AI의 광적인 채택에 대해 우려를 표명했다가 많은 비난과 수많은 (임시) 밴을 받았습니다. 이것은 이제 일자리 손실처럼, 그리고 지금 이 상황처럼, 수많은 방식으로 되돌아와 물고 있습니다. 이것은 원포스터의 연속선상에 있으며, AI 기반 웹 봇 트래픽이 그 존재를 드러내고 있는 최신 사례일 뿐입니다, 오호.

그때 제 견해는 (또한) 고객/최종 사용자를 위한 완화를 위한 모든 전략을 생각할 때였으며, 단순히 머스크 스타일의 논리인 '이길 수 없으면 합류하라’는 방식의 무장 경쟁에 참여하는 것이 아니었습니다. 이 경우, 그렇게 말하기는 쉽지만 올바른 선택이 아니며, 규제에 대한 요구는 순진한 것입니다.

뒤로 물러설 것인가?

지금은 너무 늦었을지도 모릅니다.

AI 트래픽은 더 인간답게 들어올 수 있습니다: 기술적으로 그것이 어떻게 작동하는지는 알지 못합니다 (하지만 우리가 어떻게 여기까지 왔는지는 압니다). 아마도 인간 트래픽으로 더 쉽게 위장하고, 구글의 관점에서 보면 매력적으로 보이는 더 탐지하기 어려운 트래픽을 제시할 것입니다. 하지만 오, 이것은 더 큰 새로운 문제가 될 수 있습니다.

아무것도 무료(FREE)는 아닙니다. 얼마나 많은 사람들이(또다시) 이것에 의해 당황하여 인간 수준의 주의력을 발휘하지 못하고 뒤로 물러나는 옵션을 선택하지 않았는지 모르겠습니다.

지금 그 트래픽은 여전히 매우 구체적인 지역에서 들어오고 있으며, ASN 블록만으로도 정밀하게 열기를 제거하는 데 충분합니다.

그것은 얼마나 오래 지속될 것인가?

이건 꽤 일반적인 일이에요. 저는 여러 사이트를 운영하는데, CloudFlare는 보통 실제 트래픽의 10배에서 30배 정도를 표시합니다. 분석 도구가 트리거되지 않는다면, 그것들은 봇이거나 검색 엔진 크롤러일 거예요. 대부분의 봇은 분석에 사용되는 JavaScript를 실행하지 않으니까요.

CloudFlare는 무료예요 :wink:

이 항목들이 Google Analytics에 표시되었습니다. 기억이 맞다면, 그게 달랐던 부분이었습니다.

정말 걱정된다면 CloudFlare를 사용하고 문제를 일으키는 국가들을 방화벽으로 차단하세요. IP가 이미 DNS에 등록되어 있었다면 새 IP 주소를 받으세요. 이는 공격을 받고 있는 경우에 해당합니다.

실제로 서버는 이미 CF DNS에 등록되어 있었지만, 이전 설정 조언 때문에 작동하지 않는다고 생각하여 프록시를 사용하지 않았습니다. 주황색 구름에 대한 두려움은 정말 강하죠. :sweat_smile:

하지만 웨이브 중 하나에서 테스트해 본 결과, 잠시 지켜본 후 트래픽량을 비교적 쉽게 완화할 수 있었습니다. 또한 많은 양의 트래픽이 제거된 것으로 보입니다.

새로운 IP 주소를 얻는 유일한 방법은 새 서버로 이전하는 것인가요?

호스팅 서비스에 따라 다릅니다. DigitalOcean과 같은 일부 서비스는 대시보드에서 바로 새로운 정적 IP 주소를 할당할 수 있지만, 그렇지 않은 곳도 있습니다. 후자의 경우 직접 문의해야 할 수 있습니다. 저는 이 기능을 절대 끄지 않습니다. 오렌지 클라우드를 끄면 해당 IP가 손상된 것으로 간주합니다. 이 기능을 켜는 과정에서 트래픽이 유실된다면, SSL 설정이 올바르게 되어 있지 않거나 캐싱 설정에 문제가 있을 가능성이 큽니다. SSL 설정이 완벽하게 갖춰지지 않은 상태에서 Cloudflare로의 실시간 전환은 까다로울 수 있습니다. 테스트를 위해 캐싱되지 않은 IP 주소를 DNS에서 얻기 어렵기 때문입니다.