https://www.wsgvet.com/ubuntu/129

 

라엘님의 자료를 도커로 구현했는데, PHP보다는 Nginx 자체 기능을 이용하는게 더 낫다고 하셔서 찾아보다가 의문점이 들어서 문의합니다.

 

 

링크( https://jojoldu.tistory.com/60 )를 보고 다시 Nginx proxy cache를 활용한 이미지 캐시 서버 구축에 궁금증이 있습니다.

 

 

img1.daumcdn.png

 

예를들어 위와 같이 이미지 캐시서버를 구축한다고 하면

 

proxy_pass http://원본서버IP

 

위와 같이 작업하게 될텐데요.

 

그렇다면 server_name의 경우 기존 운영하던 도메인일 것이고,

 

원래 서버의 도메인 설정은 버리고, 캐시서버 Nginx에서 해당 도메인을 가져가야될 것 같은데요.

 

이렇게 셋팅하는게 맞을까요?

 

 

정리하면

 

(1) 기존

 

요청 -> Nginx 단독서버

 

(2) 이미지캐시 서버 구축 후 proxy cache 서버 흐름도

 

요청 -> 이미지캐시서버(Nginx proxy cache, 원본서버의 도메인을 가짐) 에서 이미지만 캐시 -> 나머지 proxy_pass로 원본 서버 IP(원본 서버는 도메인 설정은 버리고 IP만으로 소통)로 통과

 

이렇게 이해하는게 맞는걸까요?

 

 

---

 

만약에 이게 맞다면, 굳이 원본서버에서 이미지 경로를 img.example.com 으로 변경할 필요가 없을 것 같은데...

 

아직도 헷갈리네요.

TAG •
  • profile

    두 가지 방법이 있습니다. 도메인을 바꾸지 않고 그대로 사용하신다면 이미지파일뿐 아니라 사이트 전체를 캐시서버를 경유하여 접속하게 됩니다. 이미지는 캐싱하고, 일반 HTML 페이지는 캐싱 없이 그냥 proxy 처리만 하고요. 이게 클플과 같은 방식입니다.

     

    반면에 img.example.com 같은 서브도메인을 만들어 캐시서버에 연결한다면, 이미지파일만 캐시서버를 통해 다운받고 실제 사이트 접속은 원본 서버를 그대로 사용하게 됩니다. proxy_pass에 원본서버 도메인이 들어가거나, IP를 넣고 Host 헤더를 별도로 지정해 주게 되지요.

     

    캐싱할 필요도 없고 캐싱해서도 안 되는 HTML 페이지를 보는 것까지 모두 캐시서버를 경유한다면 트래픽도 이중으로 소모되고 속도도 느려지기 때문에, 대부분 서브도메인을 분리하는 방법을 선택합니다. 실제로 캐시서버에 흔히 사용되는 AWS Lightsail이나 Vultr 같은 해외업체들과 궁합이 좋지 않은 국내호스팅이라면 굉장히 느려질 수 있습니다. (대표적으로 통큰아이 KT IDC는 AWS와 상극입니다;;;) 반면, 사이트 전체를 proxy 처리한다면 클플처럼 원본서버 IP를 숨겨서 약간의 디도스 방어 효과를 얻을 수 있습니다.

  • profile profile
    아하 글에 적어둔 방식이 1번이군요.

    1번의 경우 이미지는 캐시되었을때 빠른데, 실제로 HTML의 트래픽이 느려지니 사이트가 약간 느려질 수 있겠네요.

    2번의 경우는 아직도 조금 이해가 안되는게 있습니다.

    "반면에 img.example.com 같은 서브도메인을 만들어 캐시서버에 연결한다면, 이미지파일만 캐시서버를 통해 다운받고 실제 사이트 접속은 원본 서버를 그대로 사용하게 됩니다."

    이 말은 정확하게 이해했습니다. 라엘님의 자체 이미지 캐시서버 구축과 같네요.

    다만 "proxy_pass에 원본서버 도메인이 들어가거나, IP를 넣고 Host 헤더를 별도로 지정해 주게 되지요."

    이 말은 무슨 말인지 잘 모르겠습니다. 라엘님의 방식이라면 그냥 이미지의 URL만 바꿔주고, proxy_pass 방식은 사용하지 않는데요.

    만약에 원본 서버에서 프록시 패스로 이미지만 img.example.com으로 보내주면 실제 파일은 원본서버에 있고, 캐시서버에는 파일이 없어서 이건 아닌 것 같은데요.

    이 부분이 정말 궁금합니다.
  • profile profile

    proxy_pass와 도메인 관련된 부분은
    이미지 캐시서버에서 img.example.com으로 요청을 받아서
    원본서버에 접속할 때는 example.com으로 넘겨주어야 한다는 의미입니다.

    파일은 원본서버에 있지요. 캐시서버에는 그때그때 자동으로 복사되고요.
    이걸 구현하는 방법은 여러 가지가 있습니다.
    nginx 자체의 proxy_cache 기능을 활용하는 방법이 가장 간단하고,
    (최근에 가장 많이 요청된 이미지를 최대 n GB까지 알아서 관리해라... 라고 설정할 수 있습니다.)
    라엘님은 PHP를 사용해서 복사하는 방식을 배포하신 적도 있습니다.

    어떤 방식이든, 수동으로 복사하거나 동기화할 필요는 없습니다.

  • profile profile
    Nginx proxy_cache 기능은 저도 잘 쓰고 있습니다.

    제가 적은 1번 방식 말고, 2번 방식은

    프론트에는 원본서버가 있습니다. 그리고 원본서버의 이미지 URL은 전부 img.example.com 주소를 가지고 있습니다.

    프론트에 원본서버가 있기 때문에 HTML 속도는 기존 그대로이고, 이미지의 경우 img.example.com으로 바로 가게 되는데,

    원본서버의 Nginx 설정에서 sites-enabled에 img.example.com 설정파일을 하나 더 만들어서 해당 설정에

    proxy_pass로 이미지 캐시서버의 IP를 가리키게 되고,

    이미지 캐시서버의 Nginx 설정에는 proxy_cache 기능을 켜서 전부 캐시하고, 캐시가 없으면 proxy_pass로 원본 도메인으로 요청한다.

    이렇게 생각하면 될까요?
  • profile profile

    원본서버에 img.example.com을 연결하면 이미지 캐시서버를 사용하는 의미가 없지요. 모든 트래픽이 원본서버를 향하게 되잖아요. 게다가 말씀하신 대로 원본서버에서 이미지 캐시서버로 proxy_pass하고, 이미지 캐시서버에서 원본서버로 proxy_pass한다면 서로 주거니 받거니 무한반복하다가 끝나겠지요.

    example.com → 원본서버
    img.example.com → 이미지 캐시서버 → 원본서버로 proxy_pass + proxy_cache
    프론트 자체를 완전히 분리시키는 것이 핵심입니다.

    사용자가 이미지 캐시서버에 접속하면 proxy_pass로 원본서버에 이미지 파일을 요청하고, proxy_cache로 이미지 캐시서버에 저장함과 동시에 사용자에게 쏴주는 것입니다. 원본서버의 nginx에는 어떤 특별한 설정도 필요하지 않습니다.

  • profile profile
    아... 이제 정확하게 이해했습니다.

    구축해본적이 없으니 어떻게 구성해야되는지 감이 오질 않았는데, 이제야 무슨 말인지 알겠네요.

    감사합니다.
  • profile
    도메인을 따로 분리해서 사용하는게 항상 유리합니다.
    cookieless domain 이라는 것도 검색해보세요.
  • profile profile
    저도 그 방법이 제일 좋다고 생각합니다.
  • profile profile

    저도, 이번에 코드를 조금 업데이트 하려고 합니다.

    varnish 나 proxy_cache 가 하지 못하는 기능들을 추가해야겠어요.

    클플 Pro나 Business의 이런 기능들이죠.

    cf.png

  • profile profile
    와 이것까지 되면 진짜 대박이겠는데요?

    정말 기대됩니다.