여기서 어떻게 해야 할지 조언을 듣고 싶지만, 이 문제를 더 잘 처리할 수 있는 방법에 대한 아이디어도 몇 가지 있습니다.
일어날 수 있는 상황
한 가지 가설은, YouTube가 우리의 서버를 음악 비디오를 대량으로 수집하는(farming) 행위로 의심하여 제한을 걸거나 차단하고 있을 수 있다는 것입니다.
우리는 영국에 있는 아주 평범한 작은 포럼이며 트래픽도 적지만, 음악 비디오로 이루어진 10K + 2K개의 게시물로 구성된 스레드가 두 개(실제로는 크기로 인해 둘로 나뉜 하나) 있습니다. 이는 음악 체인(musical chain)으로, 다음 게시자는 이전 게시물과 관련이 있는(종종 간접적으로) 노래를 올리는 방식입니다.
물론 YouTube 링크가 포함된 다른 스레드도 있지만, 이 스레드는 특히 (~100%) 음악으로 가득 차 있습니다.
주말에 재배이크(rebake)를 진행한 후, Oneboxer가 많은 음악 비디오의 헤더를 가져오려던 활동을 YouTube가 감지하고 알고리즘이 우리를 '나쁜 짓을 한 아이’로 분류한 것 같습니다.
그 후 게시물을 다시 베이킹(bake)을 시도했는데, 이는 아마도 YouTube가 이 IP 주소에서 우리가 하는 모든 것이 음악 비디오 다운로드 시도라는 의심을 확실히 한 것 같습니다.
Digital Ocean과 관련이 있을 수 있음
YouTube에서 429 에러를 검색하면서 YouTube API 관련 결과는 무시하고, 결국 유사한 문제들이 모인 그룹에 도달했는데, 모두 가상 서버(특히 Digital Ocean이 명시적으로 언급됨)를 사용했기 때문에 IP 주소가 그레이리스트/블랙리스트/차단되었다고 설명하고 있습니다.
YouTube가 IP 주소 시리즈를 '차단’할 수 있으며, 이로 인해 다른 합법적인 서버들이 종종 부수적 피해(collateral damage)로 함께 묶인다는 제안이 있습니다.
다음은 그러한 문제와 잠재적 해결책 중 하나입니다.
https://support.google.com/youtube/thread/21697789?hl=en
그리고 embed.ly API를 개발하는 medium.com의 개발자가 올린 또 다른 사례입니다.
https://support.google.com/youtube/thread/21939228?hl=en
첫 번째 게시물에서 제안된 해결책은 드롭렛(droplet)에서 ip6를 비활성화하는 것이었습니다.
이것이 그럴듯해 보인다고 아는 사람이 있습니까, 아니면 이것이 문제를 일으킬까요?
해결에 도움이 될 수 있는 다른 데이터를 수집할 수 있도록 현재는 이 작업을 보류하고 있습니다.
무엇이 일어나야 하는가?
먼저, 여기서는 제 경험이 가장자리에 있는 경우(edge-case)이며 변경이 필요하지 않다는 반응이 나올 가능성이 높다는 것을 이해합니다.
그것을 이해합니다. 하지만 만약 @marcozambi와 제가 상대적으로 짧은 기간 내에 동일한 문제를 발견했다면, 다른 사용자들도 이를 겪을 수 있음을 시사합니다. 아마도 YouTube가 임베딩(embedding)에 대한 감시에서 최근 더 엄격해졌을까요?
현재 제 포럼은 완전히 정체 상태(limbo)에 있다는 점을 기억해 주십시오. Onebox 처리에 실패한 링크가 수만 개 있지만, 어디에 있는지 알 수 없으며, 모두를 찾기 위해서는 전체 재배이크를 수행해야 할 것 같고, 이는 거의 확실하게 YouTube에서 더 부정적인 관심을 끌 것입니다.
최소한, Onebox는 레이트 리밋 에러에 도달했을 때 조용히 실패해서는 안 됩니다. 관리자의 주의를 끌어야 하며, 가능한 경우 레이트 리밋 문제를 일으킨 프로세스를 일시 중지해야 합니다.
포럼 소유자의 주의를 끌기 위한 옵션들
이것이 쉽지 않다고 생각합니다. 전혀.
Onebox가 여러 가지 뚜렷하게 다른 역할을 수행한다고 봅니다.
a) 게시물이 작성될 때 실시간으로 Onebox를 빌드합니다.
b) 오래된 게시물(종종 이미 알려진 링크 포함)의 재배이크 요청에 대해 백그라운드에서 헤드리스(headless)로 응답합니다.
c) 마이그레이션/재배이크 동안 대량의 백그라운드 작업 게시물을 처리하도록 요청받습니다.
시나리오 a)에서 레이트 리밋 에러가 발생하면 작성자는 Onebox가 확장되지 않은 것을 인식하고 포럼 관리자에게 불평할 수 있으며, 이것이 주목받을 수 있습니다. 작성 중에 단일 에러를 잡아 관리자에게 에러 또는 메시지를 푸시할 수도 있다고 추측합니다.
시나리오 b)에서 실패는 게시물의 백그라운드 처리 중에 발생할 수 있으므로, 재시도되거나 재시도 횟수에 도달했다면 실패 처리되고 포럼 관리자에게 통보되어야 할 수 있습니다.
시나리오 c)에서는 동시에 많은 실패가 발생하는 더 넓은 맥락이 알려져야 합니다. 현재 Onebox에서 10,000개의 429 에러가 반환되는 것을 관리자에게 10,000개의 개별 메시지를 보내는 것보다 더 큰 문제로 인식할 수 있는 게시물 재배이크 프로세스에 대한 포괄적인 제어 메커니즘이 없다고 생각합니다.
현실적으로, 그러한 실패는 YouTube(다른 제공자도 포함될 수 있음) 비디오 확장을 위한 Onebox 호출을 더 이상 레이트 리밋되지 않을 때까지 보류해야 함을 의미합니다.
대안적 접근법
발신 요청 레이트 리밋
예방이 치료보다 낫다는 격언이 적용될 수 있으므로, Discourse 레이트 리미터를 요청 앞에 배치하여 Discourse가 설정에 따라 요청을 보류하도록 할 수 있다고 추측합니다.
이는 재배이크와 마이그레이션에 큰 혼란을 야기할 것입니다.
Onebox Assistant
@merefield의 Onebox Assistant 플러그인에서 사용된 것과 같이 임베드를 캐시하고 프록시하는 조직과의 상업적 관계가 모두에게 필요할까요?
‘봇’ 화이트리스트
Discourse '봇’을 YouTube에서 화이트리스트에 추가하는 방법을 찾을 수 있을까요? 아마도 악용하기 너무 쉬울 것입니다.
YouTube API
Onebox가 Twitter에서 하는 것과 마찬가지로, 레이트 리밋이 더 크다면 YouTube API를 사용할 수 있을까요?