안녕하세요. 다른 분들과 함께 기존 vBulletin3를 Discourse로 임시(ad-hoc) 이관하는 작업을 마쳤습니다. 이제 이관의 다른 측면을 고려해야 할 때인데, 그중 하나는 포럼을 서비스하고 있는 Cloudflare 계정이 있다는 점입니다.
포럼에 잠복 사용자(lurkers)가 매우 많고(활성 사용자 약 1,000명) 따라서 가능하면 Cloudflare를 유지하고 싶습니다.
여기서 찾은 관련 스레드는 2015년 것으로 일부 정보만 포함되어 있어, Cloudflare를 Discourse에 올바르게 설정하는 방법에 대한 “공식” 문서를 제가 놓친 것이 있는지 문의드립니다.
그리고 이관 후 다음 사항을 처리하기 위한 절차가 있는지 알고 싶습니다:
미리 감사드립니다 
어떻게 서빙하나요? DNS 모드를 사용하는 것이 가장 쉽습니다. 아주 적은 이점을 위해 추가적인 시간을 쓰시려면 관련 주제들이 몇 가지 있습니다. 대부분은 디스코스를 깨뜨리는 최적화 기능을 비활성화하는 것입니다. 만약 서버의 부하를 줄이고 싶으시다면, bunny.net과 같은 실제 CDN을 사용하는 것이 좋습니다.
통계와 검색은 그냥 작동할 것이라 생각합니다.
Cloudflare가 "진정한 CDN"이 아니라고 시사하는 것은 다소 근시안적일 수 있습니다. 왜냐하면 Cloudflare는 (그 이상으로) 진정한 CDN이기 때문입니다. 혹시 “전통적인” CDN을 의미하신 것일까요?
전통적인 CDN을 설정하는 데는 훨씬 더 많은 시간이 소요되며, 얻을 수 있는 이점은 대략 비슷할 것입니다.
말씀이 맞습니다!
Cloudflare이 더 저렴할 수 있습니다. 무료 버전이 많은 사용자에게 충분히 적합할 가능성이 높기 때문입니다. Cloudflare로 인해 사이트가 깨진 사례를 다루는 활성 토픽이 항상 있는 것 같으며, 가장 쉬운 해결 방법은 모든 최적화를 끄는 것인데, 이렇게 하면 지연 시간(latency)이 증가할 수밖에 없습니다.
Cloudflare를 설정하여 전통적인 CDN과 동일한 이점을 제공하도록 하는 방법을 설명하는 토픽을 작성하신다면 매우 유용할 것입니다. 아마도 로켓 로더(Rocket Loader)를 비활성화하는 것만으로 충분할 수도 있지만, 설정 방법을 정확히 아는 것이 마치 움직이는 표적처럼 느껴집니다(제품이 변경되고 개선되기 때문이죠).
어떤 CDN이 가장 좋은지 등에 대한 논쟁을 만들고 싶지 않아서 죄송합니다.
저도 아직 더 많은 정보를 얻지 못했지만, 제 이해로는 현재 포럼이 유료 플랜을 사용 중인 것 같습니다(즉, 무료 옵션은 아닐 거라고 추측합니다). 하지만 어쨌든 더 이상 논쟁할 가치가 없는 문제입니다.
간단한 질문입니다 → Cloudflare를 Discourse에 문제가 생기지 않도록 설정하려면 무엇을 해야 하나요?
그 후에는 이것이 정말로 필요한 것인지(즉, 이점 등) 이해하는 데 기꺼이 시간을 쓸 준비가 되어 있습니다
또한, 나머지 두 가지 사소한 질문에 대해 링크나 자료를 공유해 주시면 좋겠습니다 
다음 주에는 스테이징 환경에서 몇 가지 테스트를 해볼 계획이므로, 아직 결정된 것은 아무것도 없습니다!
discourse.org 또는 다른 곳에서 호스팅을 받고 있다면, Cloudflare를 사용하기 전에 해당 업체와 먼저 확인하는 것이 좋습니다. 일반적으로 해당 서버를 가리키는 DNS CNAME 레코드를 생성하기만 하면 됩니다. Discourse.org에는 이미 CDN이 구축되어 있으므로 걱정할 필요가 없습니다.
@pfaffman님, 감사합니다. 셀프호스팅으로 운영되고 있습니다. 말씀드렸듯이, 현재 vBulletin 포럼은 단순히 오프라인으로 전환되고, 동일한 도메인 이름에서 응답하는 Discourse로 대체될 예정입니다.
Cloudflare에 어떤 역할(있다면)을 부여하고 싶은지에 따라 다릅니다.
단순히 Cloudflare를 DNS로만 사용하려는 경우, 포럼의 ‘a’ 레코드에 대한 오렌지 클라우드(Orange Cloud)가 비활성화되어 있는지 확인하십시오.
Cloudflare 네트워크를 통해 Discourse 트래픽을 실제로 전송하고, 이로 인한 추가 지연 시간(latency)을 감수할 수 있는 경우, 최소한 포럼 도메인 전체에 대해 ‘성능 비활성화(Disable Performance)’ 페이지 규칙을 생성해야 합니다. Cloudflare의 성능 최적화 기능은 권장되지 않으며, 사이트가 깨지는 원인이 된 것으로 알려져 있습니다.
app.yml에 추가해야 하는 Cloudflare 템플릿이 있다는 점에 유의하십시오. 이 템플릿은 CF-Connecting-IP를 클라이언트 IP로 전달하여, 모든 사용자가 Cloudflare 네트워크의 노드에서 온 것으로 보이도록 방지합니다.
오브젝트 기반 스토리지를 사용하지 않고 오렌지 클라우드를 활성화한 채로 실행 중인 경우, 자산(assets) 경로에 대해 캐싱 규칙을 생성할 수 있습니다.
고맙습니다, @Stephen.
Cloudflare는 (아직도 그러하지만) 실제 웹서버에 요청이 과부하되지 않도록 하는 데 사용되었습니다.
가장 궁금했던 것은 Discourse의 실시간 업데이트 방식(웹소켓을 사용하는 것으로 추정합니다. 확인은 하지 않았습니다)이 Cloudflare의 캐싱과 같은 기능과 어떻게 문제를 일으킬 수 있는지에 관한 것이었습니다. 그래서 관련 문서나 팁이 있는지 궁금했습니다.
저는 아무것도 모르기 때문에 가끔씩 길을 잃곤 합니다. 하지만 질문자님은 PHP의 본질을 찾고 계신 것 같은데, 실제로는 JavaScript 앱의 본질을 얻고 계신 겁니다. 실제 데이터를 가져오는 것을 제외하면 모든 처리가 사용자의 디바이스에서 일어나는 것이죠.
이것이 제가 Varnish를 Discourse 앞에 배치하려는 시도가 그렇게 처참하게 실패한 이유입니다(그리고 제 제한된 기술력도요).
물론 CDN에서 에셋을 서빙할 수는 있지만, 그게 전부입니다.
네, Cloudflare는 애플리케이션 서버 부하를 줄이는 데 아무것도 할 수 없습니다. 단일 페이지 JavaScript 앱인 Discourse는 실제로 이점을 거의 받지 못합니다.
오히려 상황이 더 악화되는데, Discourse를 Cloudflare 뒤에 두면 브라우저의 앱과 서버 간 모든 요청에 네트워크 홉이 추가되어 응답 시간이 약간 증가하기 때문입니다.
업로드 파일을 서버에 보관하고 계신가요, 아니면 S3 또는 S3 유사 대안을 사용 중이신가요?
답변이 늦어 죄송합니다.
Discourse의 디자인에 대해 자세히 알지는 못하지만, 이미 redis가 존재하여 일반적인 요청에 대한 캐싱을 일부 관리하고 있다고 생각합니다. 이것이 "Cloudflare이 실제로 필요하지 않다"는 설명과 일치합니다.
즉, Discourse 설치 환경 앞에 Cloudflare을 두는 것은 거의 이점이 없거나, 오히려 응답 속도를 늦추는(네트워크 홉 증가) 결과를 초래한다는 것이 제 이해가 맞습니까?
vbulletin3 설치 환경에서 Cloudflare을 사용한 유일한 이유는 요청량이 서버를 압도했기 때문이었고(솔직히 vbulletin3의 코드 설계가 부족해서였을 것이라고 추정합니다), 해당 애플리케이션 자체를 위한 4vcore, 8GB RAM VM과 동일한 사양의 DB용 VM을 사용하고 있었기 때문이기도 합니다.
오늘날 어떤 현대적인 웹 앱도 그 정도의 성능이 필요하다고는 생각되지 않습니다.
아, 그리고 참고로, 평균적으로 활성 사용자가 약 1,000명이고 잠복 사용자가 약 5,000~6,000명인 Discourse 설치 환경에 필요한 하드웨어 사양을 평가하기 위해 참고할 수 있는 자료가 있을까요?
그것은 완전히 사실만은 아닙니다. 특히 첫 번째 로드 시, Cloudflare는 JavaScript 정적 자산 로딩을 빠르게 할 수 있습니다. 그리고 이는 Google이 검색 엔진 패널티를 피할 만큼 사이트가 충분히 성능이 좋은지 판단하는 기준 중 하나입니다. 검색 엔진에서 사용자를 유치하는 마케팅 성격의 포럼을 운영할 경우 이점이 더 크고, 활성적이고 반복적으로 방문하는 사용자 그룹이 있는 포럼인 경우 단점이 더 커집니다.
없습니다. 왜냐하면 그것은 정말로 해당 사용자가 매우 활동적인지, 아니면 하루에 한 번만 방문하는지에 따라 크게 달라지기 때문입니다. 50명 미만의 사람들이 큰 사진들을 주고받으며 하루 종일 Discourse를 채팅 박스처럼 사용하여 매우 성능 좋은 하드웨어를 무너뜨리는 것을 본 적도 있고, 반대로 일주일에 한 번씩 글을 남기러 오는 10,000명의 회원과 3,000만 명(!)이 넘는 잠복 사용자를 보유한 포럼이 평범한 VPS에서 구동되는 것을 본 적도 있습니다.
@RGJ, 통찰력과 정보 감사합니다. 그냥 모니터링하면서 상황을 지켜보겠습니다. 이전 소프트웨어에 비해 요구사항이 크게 증가하지 않기를 바랍니다 