안녕하세요,
R2로 마이그레이션을 완료했고 모든 것이 완벽하게 진행되었습니다. 모든 이미지에 S3 CDN URL 링크가 정상적으로 설정되어 있습니다. 하지만 문제가 하나 있습니다. 아바타 로딩에 시간이 많이 걸립니다. 사용자의 아바타를 클릭하거나 게시물 안에서 확인하든, 평균적으로 3~4초 정도 걸립니다. 이것이 정상적인 현상인가요?
음, 세 가지 중 하나의 문제일 수 있다고 의심되는데, 내 생각에는 가장 가능성이 높은 것은 온더플라이(즉석) 리사이징입니다.
1. 온더플라이 아바타 리사이징
업로드 파일을 R2로 마이그레이션할 때 원본 이미지가 이동되었지만, Discourse는 아바타를 다양한 크기로 사용합니다(예: 게시물에는 45px, 사용자 카드에는 120px).
이러한 특정 최적화 크기가 완벽하게 마이그레이션되지 않았거나 아직 생성되지 않은 경우, Discourse는 사용자가 아바타를 클릭하는 순간 이를 동기적으로 생성해야 합니다:
- Discourse가 원본 아바타를 R2에서 로컬 서버로 다운로드합니다.
- ImageMagick을 사용하여 크기를 조정합니다.
- 새로운 크기의 이미지를 다시 R2에 업로드합니다.
- 브라우저가 새로운 URL로 리디렉션되며, 이 과정에 3~4초가 걸립니다.
확인 방법: 페이지를 강제 새로고침(Hard-refresh)하세요. 첫 번째로 아바타 로딩에 3~4초가 걸리지만 두 번째에는 즉시 로딩된다면, 바로 이 현상이 일어나고 있는 것입니다.
해결 방법: 사용자가 페이지를 탐색하면서 크기가 생성되므로 자연스럽게 해결됩니다. 하지만 즉시 해결하려면, 서버에 SSH로 접속하여 다음 명령어를 실행하여 백그라운드에서 모든 아바타를 미리 생성하도록 강제할 수 있습니다:
./launcher enter app
rake avatars:refresh
2. 3초 IPv6 타임아웃
여러 번 새로고침한 후에도 아바타가 매번 3~4초씩 걸린다면, 네트워크 타임아웃에 걸리고 있을 가능성이 높습니다.
Cloudflare R2 API 엔드포인트는 IPv4와 IPv6를 모두 사용하는 듀얼 스택(Dual-stack)입니다. 서버 드롭릿(Droplet)에 IPv6 주소가 할당되어 있지만 호스트의 IPv6 게이트웨이가 제대로 라우팅되지 않는 경우, Ruby의 R2 버킷에 대한 내부 연결은 먼저 IPv6를 시도하고 3초 동안 멈추게 됩니다(이것은 Linux의 기본 TCP 타임아웃입니다). 이후 실패하고 즉시 IPv4를 사용하여 성공합니다.
확인 방법: 서버에 SSH로 접속하여 다음을 실행하세요:
curl -I -6 https://cloudflare.com
몇 초간 멈추다가 실패한다면, 서버의 IPv6가 깨져 있어 모든 내부 S3 API 체크가 3초의 지연을 겪고 있는 것입니다.
해결 방법: 호스트 제어 패널에서 IPv6 라우팅을 수정하거나, 드롭릿에서 IPv6를 완전히 비활성화해야 할 수 있습니다.
3. Gravatar 지연
사이트 설정에서 Gravatar 업데이트를 확인하도록 되어 있다면, 아바타를 렌더링하기 전에 Gravatar의 외부 서버를 핑(Ping)할 수 있습니다. 서버의 아웃바운드 연결이 느린 경우(이것도 종종 DNS 또는 IPv6와 관련이 있습니다), 아바타 렌더링이 차단될 가능성이 높습니다.
확인 방법: 서버에서 다음을 실행하세요.
curl -I -6 https://gravatar.com
3초간 멈춘다면 IPv6가 깨져 있는 것입니다(위 항목 참조)
Gravatar 관련 해결 방법: Discourse 설정에서 automatically download gravatars 항목을 찾아 일시적으로 꺼보시고, 이것이 해결되는지 확인해 보세요. 이것이 문제라고 생각하지는 않지만, 만약 문제라면 이 설정을 꺼두거나, 위 2번과 같이 IPv6 라우팅을 수정하거나, DNS 리졸버를 변경해 볼 수 있습니다.
빠른 답변 감사합니다. 이전에 'rake avatars:refresh’를 이미 시도해본 것 같지만, 확실하지는 않습니다.
예전에 제가 아바타가 즉시 열리도록 했던 방법은 처음에 한 번 클릭하는 것이었습니다. 두 번째 클릭 시에는 즉시 열렸죠. 하지만 그것은 아마도 캐싱 때문일 것입니다. 또한, 두 번째 팁을 방금 테스트해봤는데 "HTTP/2 301"과 몇 줄의 다른 응답이 반환되었습니다. 세 번째 팁도 마찬가지입니다. 스냅샷을 복원해야 했기 때문에 며칠 후에 다시 avatars:refresh를 실행해 보겠습니다. 다시 한번 감사합니다!
Gravatar
server: nginx
date: Mon, 22 Jun 2026 19:29:00 GMT
content-type: text/html; charset=utf-8
content-length: 0
content-language: en
expires: Wed, 11 Jan 1984 05:00:00 GMT
cache-control: no-cache, must-revalidate, max-age=0
x-redirect-by: Gravatar
location: https://en.gravatar.com/
alt-svc: h3=":443"; ma=86400
strict-transport-security: max-age=31536000; includeSubdomains; preload
CF
HTTP/2 301
date: Mon, 22 Jun 2026 19:27:00 GMT
content-type: text/html
content-length: 167
location: https://www.cloudflare.com/
cache-control: max-age=3600
expires: Mon, 22 Jun 2026 20:26:59 GMT
set-cookie: __cf_bm=eBP2aJ7Eg30nHPuvMMNxxKrgNtcNwKs0WDgnYyONeus-1782156420-1.0.1.1-sXpW27iuhGDF615cOfwNFybH4IMxgvZy3uA_3X_o..402T_3KSgT7CSymipL5RjdpGe3raWEqsVxQFFLPKRoDjfoT7B.0rqyDt.osbkOF98; path=/; expires=Mon, 22-Jun-26 19:57:00 GMT; domain=.cloudflare.com; HttpOnly; Secure; SameSite=None
report-to: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report\/v4?s=QfYqSekEDPJHC2k%2BMjHN0cGjz172tmUWe2GSR8EgwNLh3TGjFYkQ0vwPxlzY1NcBcKFOMaAi4FlgjqjhETOOtHf%2BH9KdQSvqN3OME2Uh1i4nHIw%2Fy1qkvSpf4jxDchM7CaDW80tJkjBV4OqF"}],"group":"cf-nel","max_age":604800}
nel: {"success_fraction":0,"report_to":"cf-nel","max_age":604800}
strict-transport-security: max-age=15780000; includeSubDomains
server: cloudflare
cf-ray: a0fda5d8ecd6b26d-LAX
alt-svc: h3=":443"; ma=86400
네, 답변을 보면 클라우드플레어와 그라바타의 curl 명령 결과가 예상대로 나타나므로 문제 #1일 가능성이 거의 확실합니다. 편하신 시간에 rake avatars:refresh를 시도해 보시고, 작동하는지 알려주세요.
릴리, 안녕하세요. 여전히 동일한 문제가 발생하고 있습니다. rake avatars:refresh 명령어를 실행한 후에도 /latest 경로에서 같은 문제가 반복되고 있어요. 브라우저와 Cloudflare의 캐시를 비우는 방법도 시도해 보았지만 아직 해결되지 않았습니다. 좀 더 기다려야 하는 걸까요? 현재 4,500명의 사용자가 있는 포럼에서 테스트 중입니다.
브라우저나 Cloudflare 캐시를 더 이상 지우지 마세요. 사용자가 그렇게 많을 때 rake avatars:refresh를 실행하면 즉시 처리되지 않습니다. 대신 수천 개의 작업이 Sidekiq에 쌓여 백그라운드에서 처리되며, 서버 CPU에 따라 몇 시간까지 걸릴 수 있습니다. Sidekiq과 처리 시간이 사용자 수에 따라 달라질 수 있다는 점을 미리 언급하지 못한 점 죄송합니다.
your-forum.com/sidekiq/queues로 가서 큐를 확인하세요. 큐가 완전히 비어갈 때까지 기다려 주세요. Sidekiq 작업이 완료되면 모든 파일 크기가 R2 버킷에 영구적으로 저장되고, 아바타 로딩 속도가 정상으로 돌아올 것으로 생각합니다.
음, 다른 문제가 있는 것 같습니다. 제 큐에는 아무것도 없는데, 어떤 사용자의 아바타를 클릭하면 'tail -f log/production.log’에 다음 내용이 표시됩니다: Sent file /var/www/discourse/tmp/avatar_proxy/3689d91eb5e1013beef831c585b5e62edeeecbd6.jpeg (0.2ms)
오, 그래요. 이건 결정적인 증거(smoking gun)인 것 같고, 다른 문제를 가리키는 것 같습니다.
로그에서 avatar_proxy가 나타나는 것은 보통 discourse가 cloudflare R2 CDN에서 아바타를 직접 서빙하는 것을 거부하고 있다는 뜻입니다. 대신 discourse가 요청을 적극적으로 가로채 R2에서 이미지를 로컬 서버의 /tmp 폴더로 다운로드한 뒤, ruby를 사용해 브라우저에 이미지를 서빙합니다. 따라서 CDN을 완전히 우회하고 있다고 생각하며, 이것이 3초 지연을 설명하는 것 같습니다 - 서버가 모든 요청마다 수동으로 파일을 가져오고 로드한다고 추정합니다 
discourse는 몇 가지 매우 구체적인 시나리오에서 avatar_proxy를 사용하며, 보통 외부 URL을 마스킹하도록 서버를 강제하는 프라이버시 또는 보안 설정 때문입니다.
관리자 - 사이트 설정(admin - site settings)에서 다음 설정들을 확인해 주세요:
external system avatars url을 찾아보세요 - 그 입력란에 무엇이든(예: /letter_avatar_proxy/v4/...) 있다면, discourse가 기본 문자 아바타를 프록시하지 않도록 비워 두세요. 또한 uploaded avatars allowed groups도 확인하여 TL_0이라고 되어 있는지 확인하는 것이 좋습니다.
DISCOURSE_S3_CDN_URL도 다시 한번 확인하여 끝날에 슬래시나 오타가 없이 정확히 설정되어 있는지 확인해 보세요?
사용자 정의 아바타 리맵:
데이터베이스에 여전히 원본 R2 버킷 URL이 저장되어 있고 새로운 CDN URL이 아닌 것 같습니다. URL이 일치하지 않기 때문에 보안상의 이유로 포럼이 이를 프록시하는 것으로 보입니다.
rails 콘솔에서 discourse가 정확히 무엇과 충돌하고 있는지 확인해 보세요:
./launcher enter app
rails c
아바타 로딩이 느린 사용자를 선택하세요
u = User.find_by_username("the_selected_username")
u.user_avatar.custom_upload.url
출력이 원본 버킷 URL을 반환한다면 이전 리맵이 모든 것을 포착하지 못한 것입니다(서브도메인이나 스킴을 놓쳤을 수도 있습니다).
수정하려면 서버에 ssh로 접속하고 컨테이너로 돌아가세요(rails가 아님) (./launcher enter app) 그리고 리맵 도구를 실행하여(또다시 ㅋㅋ) 원본 URL을 CDN URL로 교체하세요:
discourse remap "https://<your-raw-cloudflare-url>.r2.cloudflarestorage.com" "https://cdn.your-domain.com"
그리고 혹시 모를 경우를 대비해 https:// 대신 //를 사용하여 두 번째로 실행해 보세요.
참고로, 궁금해서 여쭤보는 건데 어떤 호스팅 서비스를 사용하시나요? 저는 당신과 거의 동일한 일반적인 설정을 사용하는데 아직 이 문제를 경험해 본 적이 없습니다. 그래서 당신의 설정에 관심이 있고, 어떻게든 재현해 보고 싶습니다.
제가 받는 URL은 S3 CDN URL을 표시하며, 브라우저에서 이미지를 열 수 있습니다.
지금은 S3를 그대로 사용할 예정입니다. 현재로서는 실제로 필요하지 않으므로요.
저는 Advinservers를 오랫동안 사용해 왔습니다.
도와주셔서 감사합니다. 정말 감사드립니다.
추가 테스트를 마쳤으며, 이 문제가 R2와 관련이 없음을 확인했습니다. 올바르게 구성된 AWS S3를 사용해도 동일한 증상(게시물에서 아바타가 느리게 로드되고, 사용자명을 클릭할 때도 마찬가지)이 지속됩니다. “ufw status” 명령어로 확인한 결과 방화벽이 현재 비활성화되어 있으므로 방화벽 문제도 아닙니다. 이번 주말에는 스테이징 환경에서 더 많은 테스트를 진행할 계획입니다. 이 환경에서는 포럼을 더 긴 시간 동안 실행할 수 있고, 필요 시 아무 문제 없이 오프라인으로 전환할 수 있기 때문입니다.
사이트와 S3 CDN이 모두 구성되어 있나요?
네, 둘 다 사용하고 있습니다. S3 CDN URL을 위해 버킷이 CloudFront에 연결되어 있고, Discourse CDN URL도 마찬가지입니다.
R2 테스트에서는 Discourse CDN URL을 사용하지 않았습니다.
동작하지 않는 그쪽에서는 그렇지 않나요?
그리고 discourse CDN이 없는 R2 버전에서 문제가 발생하고 있다는 건가요?
제가 정확히 어떤 문제인지, 또는 아바타 이미지가 어떻게 작동하는지 완전히 이해한다고 말하지는 않겠지만, 더 많은 테스트를 하기 전에 CDN을 먼저 설정해 두는 것이 좋을 것 같습니다. 새 버킷으로 이동하면서 이미지가 재생성되어야 하는데 그렇지 못해서 문제가 생기는 것일 수도 있습니다.
여기서 아바타는 Discourse CDN으로 보이는 곳에서 로드됩니다: https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/lilly/48/555832_2.png
사용자 프로필이 처음 로드된 후 더 빠르게 로드되나요?
다시 말하지만, 제가 이해하고 코드를 확인했다고 약속하지는 않겠지만, 추측컨대 이 이미지들은 Discourse CDN을 통해 서빙되고, Discourse는 이후의 요청이 CDN에서 가져오도록 기대하는 것 같습니다. 이게 왜 discourse CDN이 없는 R2 버전에서 작동하지 않거나(또는 느리게 작동하는지)를 설명해 주는 것 같습니다.
아마도 제가 말씀하시는 내용을 정확히 파악하지 못하고 있는 것일 수 있지만, R2 오브젝트 스토리지를 사용하는 두 사이트가 이 문제를 경험하지 않고 있습니다. 
Discourse CDN이 없나요? 만약 없다면 제 말이 틀린 것입니다. 있다면, S3 버킷이 있는 상태에서 Discourse CDN이 없는 것이 이 문제를 일으키는 것일 수 있습니다.
하지만 아바타가 S3를 사용할 때와 사용하지 않을 때 다르게 동작하는 것은 이상해 보입니다.
실제로 4가지 다른 구성으로 테스트해 보았습니다:
-
Discourse CDN 없이 R2
-
Discourse CDN과 함께 R2
-
Discourse CDN과 함께 AWS S3
-
Discourse CDN 없이 AWS S3
모든 경우에서 S3 CDN URL인 files.mydomain.com을 사용했습니다.
Discourse CDN을 사용하는 경우에서는 cdn.mydomain.com을 사용했습니다.
문제는 모든 시나리오에서 아바카 로딩이 항상 매우 느리다는 점입니다.
토픽을 열면 아바카가 하나씩 로딩되는 것을 볼 수 있습니다. 하지만 이것은 한 번만 발생합니다. 예를 들어 admin/users로 이동하면 닉네임만 표시되고, 그 후 아바카가 하나씩 로딩되기 시작합니다.
닉네임을 클릭하면 사용자 카드가 열리고 3~4초 후에 아바카가 표시됩니다. 이것도 한 번만 발생하며, 다시 클릭하면 아바카가 즉시 표시됩니다. 이는 아마도 캐싱 때문일 것입니다.
PS: 각 테스트를 수행할 때마다 S3/R2를 사용하지 않았을 때의 스냅샷을 복원하고, 버킷을 삭제한 후 처음부터 다시 시작합니다.
객체 저장소 설정과는 전혀 무관할 것 같다고 추측해 봅니다. 네 가지 설정 모두에서 아바타가 느린 이유는 스토리지 제공사가 병목 현상을 일으키기 때문이 아니라, 사이트 드롭렛과 버킷 사이의 네트워크 지연 또는 서버 CPU가 이미지를 실시간으로 리사이즈하는 데 어려움을 겪고 있기 때문이라고 생각합니다. 서버/CDN 설정이나 여기에서 관여되는 거리 등에 대해서는 잘 모르지만, 엣지 캐시가 구축되면 어떤 스토리지를 사용하든 한 가지만 고수하고 캐시가 스스로 구축되도록 두면 문제가 되지 않을 것 같습니다. 다만 다른 아이디어가 없어서 지금은 단순히 추측만 하고 있습니다. 
나도 이제 뭘 생각해야 할지 모르겠다. R2는 서유럽(WEUR) 리전을 사용하고 있었고, S3는 eu-north-1을 사용했다. 내 VPS 사양은 다음과 같다:
AMD Turin 프로세서 (4 vCores) 8GB DDR5 ECC 메모리 256GB NVMe SSD 저장공간 5TB 대역폭 (10 Gbit) 위치: 로스앤젤레스, CA
다음에는 미국 리전으로 테스트해 봐야 할까? R2로는 그렇게 할 수 없다고 생각한다.
그렇게 예상합니다. 모든 아바타를 생성하는 데 시간이 오래 걸립니다. rake 태스크를 실행하면 처리가 이루어지지만, 특히 사용자가 많을 경우 상당한 시간이 소요됩니다. 처음 특정 사용자의 아바타에 접근할 때 아바타가 생성되며, 이미지 데이터를 다양한 크기로 처리하는 외부 프로그램을 실행하는 데 몇 초가 걸립니다. 그 후에는 문제가 없습니다. rake 태스크를 실행하고 다양한 크기의 모든 아바타가 생성될 때까지 기다리면 될 것 같습니다.
네, 아마 제가 여기서 하려는 말이 그거였는데 설명을 제대로 못 한 것 같습니다:
하지만 매번 로딩이 느리다고 말씀하셨던 것 같습니다. 
매번 S3 구성을 변경하거나 캐시를 비울 때마다 처음부터 다시 시작하는 것 같습니다. 사용자 아바타가 많다면 상당한 시간이 소요될 것입니다.