Discourse 및 Cloudflare

제품 지원 자체 호스팅
1

이 커뮤니티에서는 Cloudflare 사용에 대해 의견이 분분합니다. 어떤 사람들은 아무 문제 없이 잘 작동한다고 하는 반면, 다른 사람들은 사용하면 큰일이 날 것이라고 경고합니다. 어쨌든 이 정보 대부분은 2년 전에서 거의 10년 전까지의 매우 오래된 것입니다.

개인적으로는 2022년 현재 여기에서 Cloudflare를 Discourse와 함께 사용하고 있으며, 아무 문제가 없습니다.

모든 페이지와 HTML/CSS/JS를 완전히 최소화/캐싱하고 있으며, Brotli 압축을 사용하고 있습니다. 개인적인 선호에 따라 /admin 경로만 Cloudflare 성능 최적화에서 제외했습니다.

Rocket Loader를 끄지는 않았지만, 기본적으로 꺼져 있었습니다. 제가 한 유일한 다른 변경 사항은 사용자 IP를 복원하기 위해 app.yml 설정에 다음을 추가한 것입니다:

- "templates/cloudflare.template.yml"

또한 언급할 가치가 있는 점은, 제가 어떤 조정도 하기 전에 사이트가 이미 정상적으로 작동했다는 것입니다.

2

본인이 하고 있는 작업이 완전히 비공식적으로 지원되지 않는다는 점을 인식하고 있다면, 그렇게 하셔도 괜찮습니다.

CloudFlare는 최적화 설정을 계속 조정하고 있으며, 때로는 아무 문제가 없다가도 때로는 사이트를 완전히 마비시키기도 합니다. 대부분의 사용자들에게는 아무 조치도 취하지 않았는데 사이트가 깨지는 것은 매우 받아들이기 어려운 일입니다.

사이트 재빌드 과정을 한 번이라도 지켜보셨다면, Discourse 내부에서 이미 미니피케이션(minification)이 수행되고 있다는 것을 이미 알고 계실 것입니다. CloudFlare가 Discourse 자체보다 사이트를 더 잘 미니파이케이션하지는 않습니다. CloudFlare를 켜고 끄는 경우의 성능을 측정해 보셨나요?

또한, JavaScript 앱이 브라우저에 로드된 이후에는 CloudFlare가 실제로 사이트 속도를 늦추고 있다는 점을 잊지 마세요. 앱과 서버 사이의 모든 트래픽이 이제 CloudFlare 네트워크를 거쳐야 하므로, 네트워크 홉(hop) 수가 증가하고 그에 따라 지연 시간(latency)도 늘어납니다.

하지만 당신에게는 잘 작동하고 있다면 그건 좋은 일입니다. 다만, 지원을 요청하기 전에 CloudFlare를 꺼두시기 바랍니다. 그것이 가장 첫 번째(그리고 가장 가능성 높은) 원인이기 때문입니다.

3

클라우드플레어(Cloudflare)를 Discourse와 함께 사용할 때의 두려움 대부분(아니면 전부)이 몇 년 전의 문제에서 비롯된 것 같다는 느낌이 듭니다.

지난 10년간 클라우드플레어와 Discourse 모두 크게 발전했습니다.

저는 캐싱 문제 전반에 대해 상당한 경험을 가지고 있으며, 초기에는 클라우드플레어가 많은 스크립트를 깨뜨렸다는 사실은 맞지만, 이미 수년 전부터 안정적으로 작동해 왔습니다.

더 공격적인 캐싱 도구는 확실히 문제를 일으키며, 정상적으로 작동하도록 하려면 상당한 최적화가 필요합니다. 이러한 일반적인 인식은 여전히 유효합니다.

하지만, 클라우드플레어가 Discourse에서 지원되지 않는다는 주장이 여전히 정확한지 확인해 보셨나요? Discourse에는 클라우드플레어를 처리하기 위한 메커니즘이 내장되어 있습니다.

어쨌든, 저는 https://gtmetrix.com/에서 사용 전후 비교를 하지 않았습니다. 하지만 저에게는 이것이 다소 무의미한 문제입니다. 왜냐하면 속도 외에 클라우드플레어를 사용할 다른 이유가 있기 때문입니다. 따라서 속도가 극적으로(또는 눈에 띄게) 감소하지 않는 한, 저는 어쨌든 클라우드플레어를 사용할 것입니다.

마지막으로: CDN/캐싱/최적화 등의 도구를 사용할 때, 특히 경험이 부족하다면 문제가 발생할 수 있습니다. 이는 사이트의 구축 방식과 관계없이 모든 웹사이트에 적용되는 사실입니다. 하지만, 클라우드플레어가 모든 Discourse 사이트에 반드시 혼란을 가져온다는 생각은 시대에 뒤처진 정보이며, 더 이상 이런 오해를 퍼뜨리지 말아야 합니다.

4

Cloudflare 템플릿은 새로 추가된 기능이 아니며, 소스 코드를 자세히 살펴보면 그 유일한 목적은 Cloudflare의 IP 범위를 가져와 nginx를 수정함으로써, 오렌지 클라우드(Orange Cloud) 프록싱으로 인해 실제 클라이언트 주소가 가려진 상황에서 CF-Connecting-IP를 진정한 클라이언트 주소로 인식하도록 하는 것임을 확인할 수 있습니다. 이는 새로운 기능이 아니라 최소 7년 이상 존재해 온 것입니다. Cloudflare를 사용하여 서버의 위치를 숨기거나 업로드용 저렴한 CDN으로 사용할 수는 있지만, 이 두 가지 경우 모두 성능 관련 기능을 모두 비활성화하고 업로드 폴더에 대한 캐싱을 활성화하는 페이지 규칙을 사용하도록 권장합니다.

GTMetrix를 통한 테스트가 어떤 이점을 입증할 수 있겠습니까? Discourse가 어떻게 작동하는지에 대해 근본적인 오해가 있는 것 같습니다. Discourse는 웹사이트가 아니라 JavaScript 애플리케이션입니다. 사이트를 탐색할 때 브라우저에 정적인 HTML 페이지가 전달되는 것이 아닙니다. 브라우저에 로드되는 JavaScript 애플리케이션이 서버와 직접 통신하기 때문에, 클릭 사이에 특정 페이지 요소가 다시 로드되지 않는 것처럼 보입니다. 해당 애플리케이션의 반응성은 서버 리소스와 클라이언트 및 서버 간의 지연 시간에만 의해 결정됩니다. Cloudflare는 Discourse 인스턴스의 속도를 높일 수 없으며, 두 시스템 사이에 존재하는 Cloudflare는 오히려 지연 시간을 증가시킵니다.

위 내용은 느낌이 아니라 수년간의 경험에 기반한 것입니다. Discourse는 여전히 Cloudflare와 관련하여 주기적인 문제를 겪고 있습니다. 서버 IP를 숨기고 업로드 시 데이터 전송량을 약간 절약하는 것 외에는 Cloudflare가 Discourse 사이트의 속도를 높일 수 있는 것은 아무것도 없습니다.

5

Cloudflare 템플릿은 새로운 추가 기능이 아니며, 소스를 살펴보면 그 유일한 목적이 IP 범위를 가져와 nginx를 수정함으로써, 주황색 구름(클라우드플레어) 프록시 처리로 인해 실제 클라이언트 주소가 가려지는 문제를 방지하기 위해 CF-Connecting-IP를 진정한 클라이언트 주소로 인식하도록 하는 것입니다. 이는 새로운 것이 아니라 최소 7년 전부터 존재해 온 것입니다. Cloudflare를 사용하여 서버의 위치를 숨기거나 업로드에 대한 저렴한 CDN으로 활용할 수는 있지만, 두 경우 모두 성능 관련 기능을 모두 비활성화하고 업로드 폴더에 대한 캐싱을 활성화하는 페이지 규칙을 사용하는 것을 권장합니다.

자, 제 핵심은 Cloudflare가 지원되지 않는다면 처음부터 이를 공식적으로 지원하기 위해 노력을 기울이지 않았을 것이라는 점입니다. 또한 사용법에 대한 공식 튜토리얼도 제공하지 않았을 것입니다. 물론 X, Y, Z와 같은 이유로 특정 경우 사용을 권장하지 않을 수는 있지만, 그것이 완전히 지원되지 않는다는 것과 같은 의미는 아닙니다. :skull_and_crossbones:

GTMetrix를 통한 테스트가 어떤 이점을 보여줄까요? 저는 Discourse가 작동하는 방식에 대해 근본적인 오해를 하고 있는 것 같습니다. Discourse는 웹사이트가 아니라 JavaScript 애플리케이션입니다. 사이트를 탐색할 때 브라우저에 정적인 HTML 페이지가 제공되지 않습니다. 브라우저에 로드되는 JavaScript 앱이 서버와 직접 통신하기 때문에 특정 페이지 요소가 클릭 사이에 다시 로드되지 않는 것처럼 보입니다. 해당 애플리케이션의 반응성은 오직 서버 리소스와 클라이언트 및 서버 간의 지연 시간에만 의해 결정됩니다. Cloudflare는 Discourse 인스턴스를 빠르게 할 수 없으며, 두 시스템 사이에 존재하는 Cloudflare는 오히려 지연 시간을 증가시킵니다.

네, Discourse가 웹사이트가 아니라 콘텐츠 전달을 위한 플랫폼이라는 점, 즉 다른 플랫폼/소프트웨어/CMS와 마찬가지로 작동한다는 점은 이해하고 있습니다. 물론 Cloudflare가 서버 레벨의 성능에 영향을 미칠 수는 없으며, 이는 특히 LAMP 환경에서 더욱 그렇습니다. 하지만 궁극적으로 모든 플랫폼은 클라이언트 사이드 코드(HTML/CSS/JS)를 전달해야 합니다. 물론 GTmetrix는 서버 측 속도를 스캔할 수는 없지만, 설정의 최종 출력에 대해 몇 가지 정보를 얻을 수 있습니다. 다시 말해, 사용자가 콘텐츠 로딩을 경험하는 방식에 대한 것입니다.

Cloudflare가 웹사이트를 실제로 그렇게 많이 빠르게 하지 않습니다. 서버 측 최적화와 더 나은 서버 리소스가 제공하는 효과에 비하면 훨씬 덜 극적입니다. 이 부분에는 전적으로 동의합니다. Cloudflare의 주요 초점은 DNS 최적화에 있습니다. 유료 계정의 경우 이미지와 관련하여 몇 가지 고급 CDN 기능이 있지만, 저는 유료 계정을 사용해 본 적이 없습니다. 사람들이 가장 많은 문제를 겪고 도움을 요청하는 것이 바로 그 고급 기능 때문일까요?

위 내용은 감정이 아니라 수년간의 경험에 기반한 것입니다. Discourse는 여전히 Cloudflare와 관련하여 주기적인 문제를 겪고 있습니다. 서버 IP를 가리고 업로드 시 데이터 전송을 조금 절약하는 것 외에는 Cloudflare가 Discourse 사이트를 빠르게 할 수 있는 것은 아무것도 없습니다.

아, 예상했던 대로 "감정"이라고 했다가 혼날 줄 알았습니다. 하지만 그것은 그냥 관용적 표현일 뿐입니다. 저도 경험에 기반해서 이야기하고 있습니다. :stuck_out_tongue_closed_eyes:

공식 Discourse 커뮤니티의 리더로서, 당연히 Discourse에 대한 경험이 더 많으실 것이며, Cloudflare로 인해 발생하는 다양한 기이한 문제들을 직접 목격해 오셨을 것이라는 사실에는 이의를 제기하지 않겠습니다.

Cloudflare/Discourse의 모든 세부 사항에 대해 깊이 들어가는 것과는 별개로, 저는 여전히 제 주요 주장을 유지합니다. 그것은 단순히 이 포럼의 서사가 대부분의 사람들이 믿게 만드는 것처럼 Cloudflare가 그렇게 무서운 것이 아니라는 점입니다.

그럼에도 불구하고, 커뮤니티 관리에 대해 이해하고 있으며, 당연히 모든 사람이 개발자이거나 기술에 밝은 것은 아닙니다. 그 점에서, Discourse가 고장 난 것처럼 생각하지만 실제로는 Cloudflare나 비슷한 문제일 뿐인 사람들이 쏟아져 들어오는 상황이 짜증스러워질 수 있다는 점을 이해할 수 있습니다.

6

바로 그 점이 핵심입니다. "지원되지 않음(unsupported)"이라는 것은 "불가능"을 의미하는 것이 아니라, "그걸 해보시죠"라는 뜻에 가깝습니다. "버그가 있다"는 보고에 대한 흔한 답변 중 하나가 "Cloudflare를 끄면 사라지나요?"입니다.

정말 속도를 높이고 싶다면 실제 CDN을 사용하세요 - - Discourse에 CDN 활성화하기

7

아니면, 완전히 무료 옵션을 원하거나 그냥 Cloudflare를 쓰고 싶은 사람은 그렇게 하면 되죠. 문제없습니다.

거의 10년 전의 권고를 인용하고 계신데요. 세상은 변합니다. 2022년 현재, 공식 개발자 중 한 명이 이 문제에 대해 의견을 내줬으면 정말 좋겠습니다. 그는 상황이 훨씬 더 안정화되었다고 말할 것 같고, 또한 JS를 건드리지 말라는 권고는 Cloudflare뿐 아니라 모든 CDN에 해당하는 권고일 가능성이 높다고 생각합니다.

8

팀원을 태그하지 말아 주세요. 의견을 나누고 싶다면 본인이 직접 참여할 것입니다.

9

???

저는 Discourse의 개발자를 태그했습니다. 2022년 현재 Discourse가 Cloudflare에 대해 어떤 입장을 취하고 있는지 논쟁을 하루 종일 할 수는 있지만, 당사자로부터 직접 확인하기 전까지는 확정적인 답변보다는 추측에 불과합니다.

그가 태그되지 않는 한, 사람들이 그의 의견을 듣고 싶어 한다는 사실을 어떻게 알 수 있겠습니까?

10

지난주에 사람들이 광고를 봐서는 안 되는 상황에서 광고를 보는 문제가 발생했는데, 이는 Cloudflare의 문제임이 명확했습니다. Cloudflare를 끄는 것은 항상 첫 번째 조치 중 하나입니다. 여기서 지원을 받는 많은 사람들이 완전한 초보자이기 때문에, 가능한 한 문제를 없애는 것이 목표입니다. 여러분에게 잘 작동한다면 좋습니다. 만약 매주 20개 이상의 게시물에 응답하고 싶다면

하지만 그것은 사실이 아닙니다. 실제 CDN을 사용하는 Discourse 사용자는 CDN으로 서빙되어야 할 항목에만 이를 사용합니다.

@JammyDodger님, Cloudflare FAQ가 필요할 때인 것 같습니다(제가 처음 제안한 것은 아닙니다). Jeff와 Sam의 의견을 들어보실 수 있습니다.

11

사실 이런 문제가 있습니다. 캐싱/병합/최적화(minification)는 사용하는 소프트웨어나 CDN 조합과 관계없이 JS를 깨뜨리는 것으로 악명이 높습니다. 저는 다른 10여 개 이상의 도구/서비스에서도 이 흔한 문제를 목격해 왔습니다. 초보자를 상대할 때, 브라우저 캐시 하나만으로도 그들에게 교육시키는 것이 늘 골치 아픈 일입니다. 저는 과거 대규모 소프트웨어 커뮤니티를 관리해 본 경험이 있으며, 같은 문제가 반복적으로 발생한다는 것을 잘 알고 있습니다.

제가 궁금한 것은, 이것이 정말 Cloudflare만의 고유한 문제인지, 아니면 모든 최적화 도구가 JS를 깨뜨릴 수 있는 일반적인 문제인데 Cloudflare의 인기 때문에 이 일반적인 문제가 Cloudflare 문제로 잘못 인식되고 있는 것인지 하는 것입니다. 이런 구분이 명확한가요?

어쨌든, 공식 개발자들이 이 문제에 대해 의견을 밝혀 주었으면 좋겠습니다. 그리고 최신 FAQ가 있다면 매우 도움이 될 것입니다. 많은 반발을 받고 있지만, 저는 문제를 일으키려 하는 것이 아닙니다. 커뮤니티에서 이 주제에 대해 이렇게 많은 모순된 의견들이 오가는 것이 그저 답답할 뿐입니다. 저는 2022년 현재 이 문제의 진정한 실체를 파악해 보려는 것뿐입니다.

하지만 만약 그것이 불가능하다면, 우리가 그것을 해낼 수 없다면, 그것은 괜찮습니다. 모두 주말의 남은 시간을 잘 보내세요. 이제 가엾은 :horse:를 혼자 두겠습니다.

12

아니요, 그것은 사실이 아닙니다. Cloudflare와 Discourse 조합으로 인한 문제를 매우 빈번하게 목격하고 있습니다.

"지원된다"는 것은 존재하지 않습니다. 하지만 무엇을 하고 있는지 모른다면 문제를 일으킬 수 있고, 실제로도 그렇게 됩니다. 그리고 정말 무엇을 하고 있는지 안다고 해도 예상치 못한 문제가 발생할 수 있습니다.

Cloudflare의 성능상의 이점이 있다면 그것은 작을 것입니다. Discourse가 제공하는 대부분의 자산은 잘 압축되어 있고 불변(immutable)이므로(즉, 브라우저에서 매우 긴 시간 동안 캐시됩니다) 대부분의 다른 콘텐츠는 개인화된 애플리케이션 데이터이기 때문에 캐시할 수 없습니다.

그럼에도 불구하고, Cloudflare는 DDoS 방지에 매우 유용할 수 있습니다.

13

사용자들 사이에서 의견이 엇갈리고 있으므로 :person_shrugging: 환영할 만한 일입니다.

14

Cloudflare와 Discourse 설정(및 비설정)에 관한 FAQ가 있습니다. 셀프 호스팅 인스턴스에도 적용됩니다.

15

그 점은 의심하지 않지만, 제가 파악하려던 구분이 빠진 것 같습니다. 실제로 문제가 되는 것이 구체적으로 Cloudflare 자체인가요, 아니면 이 유형의 최적화 도구가 일반적으로 JS를 쉽게 깨뜨릴 수 있다는 사실인가요? 그리고 대부분의 사람들이 Cloudflare를 사용하는 것은 단순히 그것이 인기 있기 때문이며, 이로 인해 잘못된 혼동이 발생하는 것은 아닌가요?

모든 이메일이나 호스팅 서비스에 고유한 문제를 Gmail이나 GoDaddy 탓으로 돌리는 것과 같습니다.

Cloudflare보다 더 인기 있는 다른 CDN이 있었다면, 그 서비스에 대해서도 마찬가지로 이상한 지원 요청을 많이 보았을 것입니다.

동의하지 않더라도, 제 의도를 이해하시나요?

16

특정 설정을 피해야 하므로, 메타 사용자들은 다음과 같은 말을 했습니다.

CloudFlare가 해 줄 수 있는 일은 IP를 숨기고 업로드에 대해 CDN 역할을 하는 것뿐입니다. 이점은 미미합니다.

그리고

Cloudflare의 성능 향상 효과는 있더라도 미미할 것입니다.

그렇다면 "속도 설정이 활성화되지 않은 상태에서, Cloudflare는 Bunny CDN이나 Stackpath(또는 일반적인 CDN이라고 할 수 있지만)와 비교했을 때 어떤 이점이 있는가"라는 질문에 대해 명확하고 단순한 답변이 있을까요?

저는 현재 CDN(Stackpath) 비용을 크게 줄여줄 Bunny와, 제 경우엔 무료가 될 Cloudflare(도메인 소유자가 제 포럼을 그의 엔터프라이즈 계정에 추가할 수 있습니다) 사이에서 아직 고민 중입니다.

또한, 저는 기술에 밝지 않아서 이해하지 못하는 부분도 있습니다.

17

JS를 깨뜨리는 것만의 문제가 아닙니다. 프록시 처리로 인해 포트 80에 접근할 수 없게 되고, LetsEncrypt가 깨지며, 일부 서비스는 필요 이상으로 캐싱을 하는 문제도 있습니다.

Cloudflare는 이 “이런 유형의 최적화 도구” 중 가장 크고, 널리 사용되며, 인기가 있고 무료이기 때문에 대부분의 논의가 이 서비스에 집중되고 있습니다. 하지만 네, 맞습니다. 이런 도구들의 일반적인 문제입니다.

그래서, 네, 동의합니다.

이런 주제들은 본질적으로 다소 위험할 수 있습니다. 사람들이(특히 “문제” 대상 집단인 사람들이) 잘 읽지 않기 때문입니다. 마약이나 알코올 남용의 위험성에 대한 주제에서 "남자 여러분, 이건 마약과 알코올만의 문제가 아닙니다. 저는 아무 문제 없이 마약을 사용하며, 잊지 마세요: 어떤 물질을 과다하게 사용해도 위험합니다"라고 주장하는 것과 비슷합니다. (네, 압니다. 모든 비유에는 한계가 있지만, 제가 생각할 수 있는 가장 좋은 비유입니다).

그리고 우리가 아무리 위험하다고 큰 소리로 말해도, 사람들은 여전히 사용할 것입니다.
그래서 FAQ를 만든 겁니다 :wink:

18

새로운 FAQ 가이드는 좋은 아이디어인 것 같습니다. 커뮤니티 링크는 안정적이지 않았습니다.

이 포럼에서는 일부 사람들이 Cache Level: Bypass, Disable Performance라는 일반적인 규칙을 설정하고 있지만, 이미지나 CSS는 Cloudflare가 캐시하도록 허용하고 있습니다. 이것이 허용되는지 아닌지에 대한 공식적인 답변은 아직 보지 못했습니다…

Cloudflare를 사용하지 말라고 한 뒤 문제 있는 사용자를 개별적으로 대응하기보다는, 무엇을 해야 하고 무엇을 하지 말아야 하는지에 대해 명확한 가이드라인을 제시하는 것이 좋을 것입니다. 그러면 향후 그 게시물을 간단히 링크만 하면 관련 질문에 답할 수 있을 것입니다.

단 한 사람의 의견일 뿐입니다.

19

@RGJ — 감사합니다! 많은 분들이 제 구분의 의도나 그것이 어떤 차이를 만드는지 이해하지 못할 수 있지만, 저에게는 큰 명확성을 줍니다. 저는 명확함이 없으면 매우 좌절감을 느낍니다. 그 초기의 단단한 기반이 없으면, 특정 주제를 더 깊이 탐구하고 더 나은 이해를 얻기 위해 어떤 방향으로 나아가야 할지 알 수 없기 때문입니다.

20

구체적인 의견이 있으시다면 듣고 싶습니다.

캐싱에 대해서는 "찬성"이나 "반대"보다는 "그저 그렇다"고 표현하고 싶습니다: