음, 세 가지 중 하나의 문제일 수 있다고 의심되는데, 내 생각에는 가장 가능성이 높은 것은 온더플라이(즉석) 리사이징입니다.
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 리졸버를 변경해 볼 수 있습니다.