몇일 전부터 (Discourse 2.5 beta 5로 업데이트한 직후라고 생각되며, beta 6에서도 계속되고 있지만 우연일 수도 있습니다) YouTube 동영상 임베딩이 간헐적으로 작동합니다.
몇 시간 동안 작동하지 않다가 갑자기 다시 정상적으로 임베딩이 시작됩니다.
어제부터는 완전히 작동이 중단되었습니다.
포럼 로그에서 특정 의심스러운 오류를 발견하지 못했습니다.
타임아웃 문제일까요? 이 문제를 구체적으로 조사할 방법이 있을까요?
미리 감사드립니다!
브라우저가 원박스(onebox)가 실패하는 실제 이유를 알려줄 수 없습니다. 서버에서 유사한 요청을 직접 시도해 보아야 합니다.
제안하신 내용을 이해하지만:
헤더 등을 예상대로 전달하면서 간단한 GET 호출을 /onebox?url=… 에 반복하면 단순히 HTML 404 오류만 반환됩니다.
서버에서 youtube_onebox.rb의 Ruby 코드에서 복사한 onebox가 수행하는 요청을 반복하면, 즉 임베드되지 않은 비디오 중 하나에 대해 curl 'curl 'https://www.youtube.com/oembed?format=json&url=https://www.youtube.com/watch?v=Xl-PTTeRsik'를 실행하면, 완벽하게 정상 동작하는 것 같습니다.
실제로 호출 결과는 다음과 같습니다:
{"author_name":"AstronautiCAST","version":"1.0","height":270,"author_url":"https:\/\/www.youtube.com\/user\/AstronautiCAST","provider_name":"YouTube","provider_url":"https:\/\/www.youtube.com\/","thumbnail_height":360,"width":480,"html":"\u003ciframe width=\"480\" height=\"270\" src=\"https:\/\/www.youtube.com\/embed\/Xl-PTTeRsik?feature=oembed\" frameborder=\"0\" allow=\"accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture\" allowfullscreen\u003e\u003c\/iframe\u003e","type":"video","thumbnail_width":480,"title":"Loading cargo into HTV-9 Konutori","thumbnail_url":"https:\/\/i.ytimg.com\/vi\/Xl-PTTeRsik\/hqdefault.jpg"}root@fait-2020:/var/discourse#
여기에는 임베딩에 필요한 모든 것이 포함되어 있습니다.
이해가 되지 않습니다 
@Falco 번거롭게 해서 정말 죄송합니다. 하지만 YouTube 원박싱(oneboxing) 기능이 없으니 우리 포럼의 사용자 경험이 정말 많이 저하되고 있어요.
어제 저는 원박싱이 404를 반환하는 조건과 단계가 무엇인지 이해하기 위해 소스 코드를 읽어보는 것부터 시작해서, 현재 프로덕션 포럼을 새로운 Digital Ocean 드롭렛(droplet)으로 클론하는 시도까지 여러 가지를 해보았습니다.
코드를 읽는 것만으로는 큰 도움이 되지 않았는데, 주로 플랫폼에 대한 실질적인 지식이 부족했기 때문입니다.
이와 관련해 아직 해결되지 않은 질문이 하나 있습니다. 원박싱 프로세스가 어딘가에 로깅되고 있을까요? 원박싱이 실패하여 404를 반환하게 만드는 에러를 이해하는 데 매우 유용할 것 같습니다.
클론 드롭렛은 프로덕션 서버의 IP가 YouTube에 의해 차단되었는지, 그리고 우리가 사용하는 도메인 이름과 관련이 있는지 확인하려는 시도였습니다.
잘못된 점은, IP 주소와 도메인 이름이 달랐음에도 YouTube 원박싱은 작동하지 않았습니다.
정말 누군가가 원박싱이 어떤 작업을 수행하는지 추적할 수 있는 방법을 최소한 하나라도 제안해 주셨으면 좋겠습니다.
아니요, 최근 리베이크를 추가한 적이 없습니다. 다른 사용자들도 불만을 제기했으니 유튜브 측의 변경 사항인 것 같습니다.
"Onebox Assistant", crawl for those previews reliably! 사용하여 프록시 크롤을 시도해 보세요.
답변해 주셔서 모두 감사합니다.
하지만 Onebox 엔진이 보내는 요청(적어도 제 생각에는 그렇게 되어야 할 것 같은데. @Falco 님이 맞나요?)을 그대로 재현하면, 429 오류가 아니라 올바른 응답이 담긴 JSON 응답을 받는 이유가 여전히 궁금합니다.
제 스크린샷에 보이는 요청(curl 'https://www.youtube.com/oembed?format=json&url=https://www.youtube.com/watch?v=Xl-PTTeRsik' )을 수행하기 전에, 429 오류를 유발하는 다른 요청을 Onebox가 보내고 있는 건가요?
말할 필요도 없이, 이 요청들은 Discourse가 실행 중인 서버(즉, 동일한 외부 IP)에서 전송되었습니다.
curl 명령어 하나만으로는 레이트 리밋에 걸릴 가능성이 낮습니다.
연속으로 여러 번 실행해 보세요. 반복 실행되는 bash 스크립트로 돌려 보세요. (다만 너무 많이 실행하면 계정이 정지될 수 있으니 주의하세요)
글쎄요, 유튜브 링크 하나만 있는 게시물을 다시 처리해 보려 해도 onebox에서 404 오류가 나네요…
트러블슈팅을 하느라 주말을 보내고 나서 발견한 흥미로운 점입니다.
@Falco님 또는 @codinghorror님, 이 문제를 살펴봐 주시면 좋을 것 같습니다.
현재 youtube_onebox.rb 소스 코드를 읽어보니, 비디오 ID가 추출되는 3가지 URL 형식을 지원하고 있습니다.
http://youtu.be/<videoid>https://www.youtube.com/embed/<videoid>https://www.youtube.com/watch?v=<videoid>1번과 3번 형식의 링크를 가진 비디오를 원박스(onebox)로 변환하려는 모든 시도가 404 오류를 반환하며 실패합니다(이는 우리의 IP가 차단되었기 때문이라고 생각합니다).
2번 형식의 링크를 임베드하려고 하면 정상적으로 작동합니다!
이것이 이 게시물에서 설명된 사실과 어떻게 관련이 있을지 궁금합니다.
원박스의 내부 작동 방식(즉, 유튜브에 어떤 정확한 호출이 이루어지는지)에 대한 이해(및 로깅)가 있다면 매우 유용할 것입니다…
이 스레드에 마침표를 찍기 위해 다시 돌아왔습니다.
어제 YouTube가 우리의 계정 정지를 해제했고, 다시 정상적으로 운영되고 있습니다.
제 생각에 어떤 경우에도 이해할 가치가 있는 몇 가지 점이 있습니다:
/embed/ URL은 정지 상태였음에도 불구하고 어떻게든 계속 작동했습니다.)당황한 제 질문에 답해 주신 모든 분께 감사드립니다! 
이거예요!! (이전에 언급했던 아주 좋은 아이디어입니다)
여기서 과제의 일부는 대상이 og 태그가 없는 페이지를 반환하는 경우, Onebox가 이것이 리다이렉트 때문이었는지 알 수 없다는 점일 것입니다. 그러나 이를 로깅할 수 있습니다(“ONEBOX: og 태그를 찾을 수 없음”?) 그리고 빈 onebox로 이어지는 모든 오류는 반드시 로깅되어야 합니다.
요약: 여기서는 같은 문제로 보이는 현상을 겪고 있다고 덧붙이고 싶습니다. 최근 변경 사항으로 인해 레이트 리밋(rate limit) 문제가 발생했다면, 마이그레이션 중이나 게시글 재처리(re-baking) 시, 혹은 단순히 포럼이 매우 바쁜 상황에서 다른 사용자들도 이 문제를 겪기 시작할 것이라고 생각합니다. 원박스(onebox)가 겉보기에는 조용히 실패한다는 사실 때문에, 사용자가 유튜브 원박스가 사라졌다고 불평하기 전까지는 이러한 문제가 눈에 띄지 않습니다.
현재 2.6.0.beta 1 버전을 사용하고 있습니다.
사용자들이 보안이 되지 않는 콘텐츠(non-secure content)에 대한 메시지를 받고 있었습니다. 조사 결과, Chrome이 HTTP 사이트에서 링크된 이미지 때문에 오류를 보고하는 것으로 보였습니다. 그래서 Discourse 설정을 변경하여 모든 이미지/미디어를 다운로드하고 HTTPS로 서빙하도록 했습니다.
이 설정을 변경한 후, 과거 게시글에 대한 재처리(re-bake)를 수행해야 했습니다. 해당 재처리 이후, 이전에 원박스로 표시되던 유튜브 영상 중 큰 부분이 다시 링크된 URL로 돌아가 버렸습니다.
유튜브 영상 답변만으로 구성된 10,000개의 게시글이 있는 스레드가 하나 있는데, 모든 게시글이 원박스가 아닌 URL로만 표시되고 있습니다.
재처리 동안 큐에 있던 모든 작업이 유기적으로 처리되었으므로, 삭제된 작업이 쌓인 큐에 작업이 막혀 있는 상황이 아닙니다.
@marcozambi 님이 설명한 것과 동일한 오류 메시지는 확인되지 않았지만, 우리도 레이트 리밋에 걸린 것으로 믿습니다.
이 레이트 리밋 가설을 뒷받침하기 위해, 게시글을 재처리하기 위해 작성한 소규모 코드는 스레드 내 첫 80개 이상의 유튜브 영상은 정상적으로 작동(원박싱)했으나, 나머지 영상은 변환에 실패했습니다.
그 시점 이후로, 게시글을 편집하여 작은 수정을 하고 다시 저장해도 URL이 원박스 ‘확장’ 형태로 변하지 않았습니다. 동시에, 예상대로 모든 큐가 비어 있거나 소량의 작업만 즉시 처리되고 있었습니다.
30분 동안 해당 코드를 재실행하여 링크의 원박싱을 강제하려 했으나 실패했습니다. 80이라는 숫자가 마법의 숫자는 아니고, 단순히 우리가 가진 쿼터에서 사용 가능한 양이었을 뿐이라고 생각합니다.
@marcozambi 님은 다른 링크가 실패할 때 /embed/ 형식의 유튜브 링크가 작동한다고 언급했으므로, 유튜브 링크를 /embed/ 형식으로 변환하기 위해 정규식(regex) 기반 검색 및 치환을 사용하는 방식으로 코드를 수정했습니다.
코드가 작동했습니다.
다시 게시글만 재처리하기 위해 코드를 재실행했을 때, 원박스 표현으로 변환되지 않았습니다.
제 계획은, 큰 스레드 내 모든 유튜브 링크를 /embed/ 유튜브 형식으로 변환하는 작업을 실험해 보는 것입니다. 만약 실패하거나 더 높은 레이트 리밋에 걸린다면, @merefield 님의 Onebox Assistant를 살펴볼 것입니다.
나중에 업데이트를 게시하겠습니다.
OK, 분명 뭔가 이상한 일이 일어나고 있으며, 이는 레이트 리밋(rate-limit)과 관련이 있는 것으로 보입니다.
대규모 재베이크(rebake)를 수행하여 일시적으로 제한 조치를 받은 것인지, 아니면 다른 사용자들도 겪을 수 있는 한계에 도달한 것인지 확신이 서지 않습니다.
YouTube 비디오의 원박스(Oneboxing)에는 한도가 있는 것 같고, 이 한도에 도달하면 원박싱이 조용히 실패합니다.
분명히 변경되어야 할 문제라고 생각하며, 그 이유는 충분히 명백할 것입니다. 특히 마이그레이션이나 재베이크를 수행하는 사용자는 수많은 확장되지 않거나 한 번 확장된 원박스가 이제 그냥 일반 URL로 남아 있다는 사실을 전혀 모를 수 있기 때문입니다.
위에서 @marcozambi가 언급했듯이, 다른 형식이 실패할 때(아마도 레이트 리밋 문제 때문일 것입니다) 비디오 ID 앞에 /embed/가 포함된 YouTube URL 형식이 작동합니다.
이 현상을 잘 보여 주는 비디오입니다.
이 스크린캐스트를 녹화했을 당시에는 큐를 막는 작업이 없었고, 포럼은 그 외에는 잘 작동하고 있었습니다.
이 비디오 이전부터 YouTube 링크는 원박스(OneBox)에 의해 확장되지 않는 문제가 이미 시작되어 있었습니다.
https://youtu.be/<video-id> 형식의 YouTube 링크를 원박싱이 확장하지 못하는 작성 창을 볼 수 있습니다.
그런 다음 형식을 https://youtube.com/embed/<video-id> 형식으로 변경하면 원박싱이 이를 확장합니다.
그 후 원래 형식으로 다시 시도해 보지만 실패합니다.
이 비디오를 녹화하는 동안 브라우저 콘솔과 네트워크 탭을 추적했습니다. 문제가 제 브라우저와 우리 서버 사이가 아니라 우리 서버와 YouTube 사이에서 발생하고 있다는 점을 인식하고 있지만, 유용할 수 있으므로 아래에 포함했습니다.
(이미지가 확대되지 않은 상태로 촬영된 점 양해 부탁드립니다. 확대했을 때 잘 보일 것으로 생각합니다)
그리고 여기는 원박싱이 작동했을 때의 네트워크 추적입니다.
여기서 /embed/ 형식의 링크가 만능 해결책이라고는 생각하지 않습니다.
https://youtu.be/<video-id> 경로가 한도에 도달했을 때, https://youtube.com/embed/<video-id> 경로는 별도의 한도를 가진 다른 경로인 것 같습니다.
두 경로 모두 제한이 있다는 사실의 근거는, 99%가 유튜브 영상 답변인 10,000개 이상의 거대한 게시물 스레드에서 유튜브 임베드 형식을 변경하기 위해 제가 작성한 유틸리티에서 찾을 수 있습니다.
이 시점에서 Onebox는 이미 https://youtu.be/<video-id> 형식의 링크를 확장하지 못하고 있었습니다.
제 유틸리티는 스레드의 첫 3,000개 게시물에 대해 유튜브 영상 URL을 https://youtube.com/embed/<video-id> 형식으로 변경했습니다.
처음 1,108개에서는 잘 작동했지만, 이후 약 1,900개 게시물에 대해서는 형식은 변경되었으나 Onebox에 의해 확장되지 않았습니다.
이 기간 동안 많은 작업(job)이 생성되었고(제 코드는 post.revise를 사용했습니다), 모든 작업이 오류나 재시도 없이 처리되었습니다.
경험적으로, 특정 시점에 작업 처리가 극적으로 가속화되는 것을 관찰했습니다. 이는 Onebox 코드가 YouTube로부터某种 형태의 오류를 빠르게 받아냈기 때문일 수 있다고 추측합니다. 다만, 시간을 측정하지 않았으므로 다른 원인일 수도 있습니다.
더 자세한 근거를 제공해 드리고 싶지만, Onebox gem을 계측(instrument)하지 않으면 무엇을 할 수 있을지 불확실합니다.
저는 해커이지 Ruby 전문가가 아니지만, 고수준의 지침을 주신다면 기꺼이 따르겠습니다.
서버의 명령줄에서 동일한 사용자 에이전트를 사용하여 짧은 반복적인 curl 스크립트를 실행하면 속도 제한 문제를 분리해낼 수 있을 것입니다.
우회책이 작동하는 이유는 아마도 별도의 카운트이기 때문일 것이라는 데 동의합니다.
여기 몇 가지 추가 결과를 공유합니다. 참고로, 아래 게시글에는 실제 지식의 부재로 인해 많은 가정이 포함되어 있습니다.
이 게시글 이후로, 현재 어떤 일이 일어나고 있는지 그리고 무엇이 이루어져야 하는지에 대한 제 의견을 후속 게시글로 올리겠습니다.
답변해 주셔서 감사합니다, Robert.
/watch 라우트를 사용하여 비디오를 원박스(Oneboxing)하는 시도가 (그때도 그랬고, 지금도 그렇습니다!) 실패했기 때문에 실패를 강요하기 위해 루프가 필요하지 않았습니다.
따라서 제가 세운 가정 중 하나는, Onebox가 사용하는 user-agent가 이 코드에 근거하여 Discourse Forum Onebox v2.6.0.beta1라는 것입니다…
임의의 비디오를 하나 선택하여 curl을 사용해 헤더를 읽으려 했습니다.
실제 운영 중인 사이트의 Docker 컨테이너 내부에서 이를 수행했으며, 다음과 같은 응답이 생성되었습니다.
명령어
curl --user-agent "Discourse Forum Onebox v2.6.0.beta1" -sD - -o /dev/null "https://m.youtube.com/watch?v=s0ONj4TG0UA"
응답:
curl --user-agent "Discourse Forum Onebox v2.6.0.beta1" -sD - -o /dev/null "https://m.youtube.com/watch?v=s0ONj4TG0UA"
HTTP/2 303
content-length: 0
p3p: CP="This is not a P3P policy! See http://support.google.com/accounts/answer/151657?hl=en-GB for more info."
cache-control: no-cache
x-frame-options: SAMEORIGIN
content-type: text/html; charset=utf-8
location: https://www.youtube.com/watch?v=s0ONj4TG0UA&app=desktop
accept-ch-lifetime: 2592000
x-content-type-options: nosniff
accept-ch: DPR
expires: Tue, 27 Apr 1971 19:44:06 GMT
strict-transport-security: max-age=31536000
date: Fri, 07 Aug 2020 11:35:21 GMT
server: YouTube Frontend Proxy
x-xss-protection: 0
set-cookie: VISITOR_INFO1_LIVE=rcVTSJn81Ck; path=/; domain=.youtube.com; secure; expires=Wed, 03-Feb-2021 11:35:20 GMT; httponly; samesite=None
set-cookie: YSC=cFXIPerzT3Y; path=/; domain=.youtube.com; secure; httponly; samesite=None
set-cookie: GPS=1; path=/; domain=.youtube.com; expires=Fri, 07-Aug-2020 12:05:20 GMT
alt-svc: h3-29=":443"; ma=2592000,h3-27=":443"; ma=2592000,h3-T050=":443"; ma=2592000,h3-Q050=":443"; ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; ma=2592000,quic=":443"; ma=2592000; v="46,43"
즉, location 헤더의 URL인 https://www.youtube.com/watch?v=s0ONj4TG0UA&app=desktop으로 303 응답을 통해 리다이렉트되었습니다.
이는 단순히 URL에 &app=desktop을 추가하는 효과를 냈습니다.
명령어
curl --user-agent "Discourse Forum Onebox v2.6.0.beta1" -sD - -o /dev/null "https://www.youtube.com/watch?v=s0ONj4TG0UA&app=desktop"
응답
HTTP/2 429
x-content-type-options: nosniff
expires: Tue, 27 Apr 1971 19:44:06 GMT
x-frame-options: SAMEORIGIN
cache-control: no-cache
p3p: CP="This is not a P3P policy! See http://support.google.com/accounts/answer/151657?hl=en-GB for more info."
accept-ch-lifetime: 2592000
content-type: text/html; charset=utf-8
accept-ch: DPR
strict-transport-security: max-age=31536000
content-length: 48982
date: Fri, 07 Aug 2020 11:46:00 GMT
server: YouTube Frontend Proxy
x-xss-protection: 0
set-cookie: VISITOR_INFO1_LIVE=VQwNuouhq-s; path=/; domain=.youtube.com; secure; expires=Wed, 03-Feb-2021 11:46:00 GMT; httponly; samesite=None
set-cookie: YSC=8IRfPRFRY6c; path=/; domain=.youtube.com; secure; httponly; samesite=None
set-cookie: GPS=1; path=/; domain=.youtube.com; expires=Fri, 07-Aug-2020 12:16:00 GMT
set-cookie: VISITOR_INFO1_LIVE=VQwNuouhq-s; path=/; domain=.youtube.com; secure; expires=Wed, 03-Feb-2021 11:46:00 GMT; httponly; samesite=None
set-cookie: YSC=8IRfPRFRY6c; path=/; domain=.youtube.com; secure; httponly; samesite=None
set-cookie: GPS=1; path=/; domain=.youtube.com; expires=Fri, 07-Aug-2020 12:16:00 GMT
alt-svc: h3-29=":443"; ma=2592000,h3-27=":443"; ma=2592000,h3-T050=":443"; ma=2592000,h3-Q050=":443"; ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; ma=2592000,quic=":443"; ma=2592000; v="46,43"
즉, retry-after 헤더 없이 429 “요청이 너무 많습니다(too many requests)” 응답 코드를 받고 있습니다. 협상 없이 중단하라는 뜻입니다.
어쨌든, 이것이 Onebox가 보고 있는 내용이라면, 응답을 무시하고 있거나, 로깅되고 있다면 어디를 봐야 할지 모르겠습니다.
단일 429 응답에 대해 이것이 적법한 조치일 수 있지만, 매우 짧은 시간 내에 많은 429 응답을 확인하는 것은 무시할 수 없습니다.
완결성을 위해, 즉시 같은 비디오를 가져오려 했지만 이번에는 /embed/ 라우트를 사용했습니다.
명령어
curl --user-agent "Discourse Forum Onebox v2.6.0.beta1" -sD - -o /dev/null "https://www.youtube.com/embed/s0ONj4TG0UA"
응답
HTTP/2 200
accept-ch-lifetime: 2592000
content-type: text/html; charset=utf-8
expires: Tue, 27 Apr 1971 19:44:06 GMT
x-content-type-options: nosniff
cache-control: no-cache
p3p: CP="This is not a P3P policy! See http://support.google.com/accounts/answer/151657?hl=en-GB for more info."
strict-transport-security: max-age=31536000
accept-ch: DPR
date: Fri, 07 Aug 2020 11:55:29 GMT
server: YouTube Frontend Proxy
x-xss-protection: 0
set-cookie: VISITOR_INFO1_LIVE=PNE6x6djF00; path=/; domain=.youtube.com; secure; expires=Wed, 03-Feb-2021 11:55:29 GMT; httponly; samesite=None
set-cookie: VISITOR_INFO1_LIVE=PNE6x6djF00; path=/; domain=.youtube.com; secure; expires=Wed, 03-Feb-2021 11:55:29 GMT; httponly; samesite=None
set-cookie: GPS=1; path=/; domain=.youtube.com; expires=Fri, 07-Aug-2020 12:25:29 GMT
set-cookie: YSC=pDW-hdbauK8; path=/; domain=.youtube.com; secure; httponly; samesite=None
alt-svc: h3-29=":443"; ma=2592000,h3-27=":443"; ma=2592000,h3-T050=":443"; ma=2592000,h3-Q050=":443"; ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; ma=2592000,quic=":443"; ma=2592000; v="46,43"
accept-ranges: none
vary: Accept-Encoding
200 - 성공.
이것이 중요할지 확실하지 않지만… 임베디드 플러그인인 lazy-yt가 기본적으로 활성화되어 있는 것 같습니다. 개발 설치 환경에서 이를 발견했습니다.
YouTube Oneboxer의 to_html 메서드를 몽키 패치(monkey patch)하는 것으로 보입니다.
중요한지는 모르겠지만, 원래 Onebox의 to_html 메서드는 /embed/ URL 형식을 반환합니다…
반면 lazy-yt 플러그인은 /watch?v= URL 형식을 사용합니다.
관심을 끌어야 할 문제가 있음을 보여주기 위해 제가 더 할 수 있는 다른 것이 있습니까? 다음 게시글에서는 근본 원인이 무엇이라고 생각하는지 설명하겠습니다.