nginx로 이미지 서빙을 통해 유니콘 보존하기?

개발
1

메모리 사용량이 큰 유니콘 인스턴스를 절약하기 위해, 외부 nginx(이미 502 유지보수 페이지 제공 및 IPv6 주소의 정확한 귀속을 위해 사용 중)를 설정하여 이미지 요청도 처리하도록 하는 방안을 고려하고 있습니다. 이를 통해 S3(또는 호환되는 객체 저장 서비스)로 이미지를 이동했을 때 얻을 수 있는 상당한 이점을 누리면서도, 사이트를 내 서버에 자립적으로 유지하려는 의도입니다. (이 방식은 다른 사이트 에셋을 유니콘에서 분리하지는 않지만, 페이지 간 캐싱이 잘 이루어지기 때문에 유니콘에 대한 전체적인 비용 부담은 훨씬 작습니다.)

/var/discourse/shared의 소켓으로 외부 nginx를 지정한 것과 마찬가지로, /uploads 경로는 /var/discourse/shared/$container/uploads에서 제공될 것입니다.

메타에서 이 방법을 적용한 사례에 대한 언급을 찾지 못했지만, 제 검색 기술이 부족할 수도 있습니다. 이 방식이 작동하지 않거나, 실제로는 성능이 저하될 수 있는 이유가 있는지 놓친 부분이 있을까요?

2

이미지는 이미 컨테이너 내부의 nginx를 통해 서빙하고 있습니다.

3

아, 적어도 다음에 이 좋은 아이디어를 떠올린 사람이 검색을 통해 이 글을 찾을 수 있겠네요. 정말 감사합니다! :grin:

4

유니코르ンを 돕고 싶다면, 실제로 도움이 되는 방법 중 하나는 Discourse에 CDN을 활성화하는 것입니다. 스타일시트처럼 유니코르ン에서 서빙되는 소수의 에셋을 캐싱하기 때문입니다.

5

외부 nginx에 캐시를 활성화하면 CDN을 설정하지 않아도 유니콘(unicorns) 로딩에 동일한 이점이 있을 것 같습니다. 모든 JavaScript 자산에 캐시 제어 헤더가 있는 것을 보니, 한번 시도해 볼 수도 있겠네요…

… 음, 내부 nginx도 이미 오류가 아닌 요청에 대해 7일 유효기간으로 proxy_cache를 사용 중인 것을 확인했습니다:

    location ~ ^/(svg-sprite/|letter_avatar/|letter_avatar_proxy/|user_avatar|highlight-js|stylesheets|theme-javascripts|favicon/proxied|service-worker) {
      ...
      # 참고: x-accel-redirect는 proxy_cache와 함께 사용할 수 없습니다
      proxy_cache one;
      proxy_cache_key "$scheme,$host,$request_uri";
      proxy_cache_valid 200 301 302 7d;
      proxy_cache_valid any 1m;
      proxy_pass http://discourse;
      break;
    }

그렇다면 CDN은 유니콘(unicorns)에 어떤 도움이 되는 것일까요? 그 목록에 stylesheets가 있는 것을 확인했습니다.