ossia
6월 23, 2020, 9:53오후
1
6월 21일부터 freeCodeCamp.org Discourse에서 부하가 높아지는 현상이 관찰되었습니다. 평균 CPU 부하가 증가하여 결국 포럼 전체가 응답하지 않게 되었습니다.
최신 성능 수정 사항을 적용하기 위해 권장되는 Tests-Passed(베타) 버전으로 Discourse를 Stable 버전에서 업데이트했습니다. 하지만 큰 차이는 없어 보였습니다.
문제를 진단하기 위해 일부 오래된 플러그인을 제거해 보았지만, 이는 성능 저하의 원인이 아닌 것으로 보입니다.
설정 오류를 배제하기 위해 기본 테마로 테스트를 수행하고 /logs를 확인한 결과, 다음과 같은 예외가 발견되었습니다:
Job exception: could not obtain connection from the pool within 5.000 seconds (awaited 5.006 seconds); all pooled connections were in use
이는 인스턴스가 이미 많은 수의 장시간 실행되는 작업으로 인해 스트레스를 받고 있을 가능성이 있기 때문인 것으로 보입니다.
Discourse 컨테이너(업스트림)는 Digital Ocean에서 실행되고 있으며, 6개의 vCPU 모두 과부하 상태인 것으로 보입니다. 현재 실행 중인 버전은 2.5.0.beta7입니다.
오늘 아침, 우리 모더레이터들이 스팸 계정 수가 크게 증가했다는 사실을 알려주었습니다. 이를 통해 이것이 표적 공격일 수 있다고 추정하게 되었습니다.
문제를 완화하기 위해 포럼을 읽기 전용 모드로 전환했습니다. 그럼에도 불구하고 리소스 사용률은 여전히 60% 이상으로 높은 수준을 유지하고 있습니다.
우리가 파악한 바로는, 이 문제가 시작된 이후 프록시에서 초당 요청 수(requests-per-second)는 감소하고 현재 요청률(current request rate)은 증가하는 현상이 관찰되고 있습니다:
Google Analytics에 따르면 freecodecamp.org/forum으로의 트래픽량은 크게 변화하지 않았습니다.
같은 프록시에서 실행되는 다른 애플리케이션들은 영향을 받지 않는 것으로 보입니다. /news와 /learn 플랫폼은 정상적으로 작동하고 있습니다.
프록시에 추가적인 속도 제한(rate limiting)을 적용해 보았지만 큰 차이는 없었으므로, 일반 사용자가 사이트에 계속 접근할 수 있도록 이를 제거했습니다.
며칠 전부터 사용하지 않던 오래된 서브도메인(2.5년 동안 미사용)에서 트래픽이 급증하는 것을 확인했기 때문에, .org 포럼으로의 old forum.freecodecamp.com 리다이렉트를 제거했습니다.
현재 약 400명의 실시간 사용자와 함께 통계는 다음과 같습니다:
스팸머들은 Discourse 인스턴스에서 새 계정을 생성하는 스크립트를 실행하는 것 같습니다. 그런 후 며칠을 기다린 뒤, 해당 계정이 갑자기 활성화됩니다. 그들은 웹사이트 링크가 포함된 새 스레드를 게시하기 시작합니다. (아마도 백링크를 구축하기 위해서일까요?)
이러한 계정 중 일부는 3월로 거슬러 올라가게 됩니다.
다음은 그들의 스팸 게시글 중 하나의 모습입니다. 다양한 변형이 있으며, 많은 웹사이트로 링크를 걸고 있습니다:
여기서 조언을 환영합니다.
kneiser
6월 24, 2020, 9:14오전
2
공유해 주셔서 정말 감사합니다!
제가 가장 좋아하는 Discourse 인스턴스 중 하나인 freeCodeCamp가 지난 이틀 동안 거의 멈춰 버렸습니다.
스팸러가 주요 원인으로 인한 높은 부하라고 생각하지 않습니다.
일반적인 토론 사용(API 미사용)은 JavaScript에 크게 의존하기 때문에 최신 브라우저에서만 작동할 수 있습니다. Google Analytics도 다양한 사용자 정보를 수집하기 위해 JavaScript를 사용하며(애널리틱스 코드 실행에 최신 JavaScript 지원이 필요하지는 않음), Google Analytics가 사용자 활동을 감지할 수 없다면 Discourse도 콘텐츠와 기능을 제공할 수 없어야 합니다.
구식 헤드리스 브라우저 라이브러리(phantomjs)를 사용하여 Discourse 사이트에 접근했을 때 봇이 잡힌 모습입니다:
더 현대적인 라이브러리(puppeteer)를 사용한 모습은 다음과 같습니다:
Google Analytics가 감지하지 못하는 상황에서 누군가가 Discourse에서(API 미사용으로) 답글을 남길 수 있다면 이는 매우 이상합니다.
일반적으로 스팸러들은 불쾌한 일을 수행하기 위해 공개 프록시를 사용하며, Cloudflare이 실제로 앱에 도달하기 전에 *“악성 방문자”*를 차단할 만큼 충분히 지능적이라고 생각합니다.
Sidekiq 프로세스에서 높은 큐 작업을 확인하셨나요?
Falco
6월 24, 2020, 11:03오전
4
이것은 기술 커뮤니티의 절반 이상이 광고 차단 확장 프로그램을 사용하고 있으며, 이 프로그램들이 기본적으로 Google Analytics를 항상 차단한다는 사실을 무시하고 있습니다.
새로운 macOS 도 포함됩니다.
그것은 악의적인 루머에 불과했습니다. 아래 를 참고하세요.
pfaffman
6월 24, 2020, 11:58오전
6
Akismet이 활성화되어 있나요? 신뢰 수준 1에 대해 모더레이션을 켤 수 있나요?
네, 초기 조사 과정에서 작업들이 증가하고 감소하는 것을 확인했습니다. 이후 모든 사용자 키를 폐기했습니다.
하지만 안정성에 큰 변화는 없는 것 같습니다.
다만, 이 문제를 해결하기 위해 Discourse 팀과 긴밀하게 협력하고 있습니다.
balboah
6월 24, 2020, 12:52오후
8
JS 기반 분석 도구가 아무것도 표시하지 않는 상황에서 요청이 발생할 수 있는데, 왜 그걸 이상하게 여기는지 이해가 되지 않습니다.
이것은 플러그인 간 충돌이나 프록시 설정 오류일 가능성이 훨씬 높습니다. 저희 호스팅 환경에서는 스팸 공격자가 성공하는 사례를 전혀 확인하지 못했습니다.
코딩 사이트인 점을 고려하면, 포럼에서 개발자들이 이상한 행동을 시도하는 경우도 있을 수 있겠죠?
하지만 스팸은 저희가 호스팅하는 수천 개 사이트 전반에 걸쳐 일반화된 문제가 아닙니다.
네, 설정 문제(잘못된 플러그인 또는 프록시 구성)이거나 누군가가 포럼을 악용하고 있는 것으로 보입니다.
모든 패턴을 고려할 때 후자가 더 유력한 원인인 것 같습니다.
제가 파악한 바로는, 스팸 계정들이 오랜 기간에 걸쳐 생성되었으며, 자기소개란에 링크를 추가하려 하고(백링크를 얻기 위한 것일까요?) 온갖 이상한 행위들이 관찰되고 있습니다.
또한 스크래핑이 관여되었을 가능성도 있습니다. 우리는 사이트를 읽기 전용으로 설정해 두었고, 프록시에도 캐시 설정과 레이트 리미팅을 적용해 두었기 때문입니다. 그럼에도 불구하고 업스트림 컨테이너의 리소스 사용량이 여전히 높은 상태입니다.
다만, 우리 측 설정이 잘못되었을 가능성도 배제할 수는 없습니다. 우리는 서브패스를 사용하고 있으며, 리버스 프록시 위에 Cloudflare를 추가로 사용하고 있는데, 이는 전통적으로 Discourse가 권장하지 않는 가장 효율적인 구성이 아닙니다.
RGJ
6월 25, 2020, 10:44오전
13
42.5%의 스틸(steal)은 매우 높은 수치입니다. 해당 하이퍼바이저에서 문제를 일으키는 쪽이 당신이라고 해도요. 제 생각에는 ‘노이시 네이비어(noisy neighbour)’ 문제인 것 같습니다. 제 입장이라면 DO에 연락하여 드롭레트를 다른 하이퍼바이저로 이동해 달라고 요청하겠습니다.
그렇게 하고 계실 가능성이 높지만, 확실하게 확인하기 위해 OS 레벨에서 IP별로 요약된 열린 TCP/UDP 연결을 모니터링하는 것을 권장합니다. CPU 부하가 높다면 웹서버로 향하는 대량의 열린 연결이 표시되어야 합니다.
production.log에서 이상한 패턴이 있나요?
neounix
6월 25, 2020, 7:14오후
16
Hi Quincy @ossia
잠시 뒤로 물러서서 추측이나 "마지못해 붙잡는
kneiser
7월 3, 2020, 6:41오전
17
수고 많으셨어요, 팀!
& 그 도구를이렇게나 많이 진심으로 감사해요
sam
7월 3, 2020, 7:02오전
18
여기서 마무리를 하겠습니다.
Discourse가 현재 https://forum.freecodecamp.org/를 호스팅하고 있습니다. 사이트는 매우 빠르고, 스팸 스크립트가 더 이상 미세한 지연조차 일으키지 않습니다. Digital Ocean에서 어떤 문제가 있었는지는 여전히 정확히 알 수 없으며, 노이즈 네이바(noisy neighbor) 문제였을 수도 있고, 서버 사양이 부족했을 수도 있으며, 하드웨어적인 이상 현상이 있었을 수도 있습니다. 확실하지는 않습니다. 하지만 원 게시글의 문제는 100% 해결되었으며 커뮤니티는 매우 만족하고 있습니다.
