일단 캐시 개념을 잘 못 잡으신 것 같습니다. 틀릴수도 있지만, 제가 알고 있는 캐시 개념은,  만약에 캐시 서버가 죽더라도 동작을 해야 된다는 것입니다.  원본에 이미지가 존재하고,  그 이미지가 요청이 되면 캐시서버로 들어가서 캐시에 없으면 원본에 요청한후에 캐시에 넣고 요청한 곳에 보내주는 방식입니다.

즉 그러면 원본 소스코드를 수정안하고,  캐시서버쪽에서 세팅을 조정만 하면 되는 것으로 알고 있습니다.

https://medium.com/about-developer-blog/varnish-58c5d8269269

이론적으로는 이렇게 되는 것이 맞겠지만,  이 부분도 또 하나의 분야라서,  해보고 싶은 것은 많은데........

@우성짱 우선 docker로 그누보드 앞에 varnish를 넣고, 이미지 캐시로 동작시킨 다음에 서버를 별도로 분리하는 방법을 찾아 보는 식으로 진행해 보세요.

개인적으로 원본 코드를 수정하는 것은 비추입니다. (잘 죽지야 않겠지만, 한번 죽으면 모두 엑박이 나올것 같아서..)

https://apachezone.com/aai_plugin/8

참고 해 보세요..^^

개발 스터디모임 어느 하나 참가해보려고 찾아보는 도중에, 이 글을 발견했습니다!
위 댓글의 varnish 설명을 읽어보면 아시겠지만, 캐시 동작하는게 결국엔 똑같아요.

varnish 는 프록시의 일종으로써, 사용자 => varnish(proxy) => apache/nginx  방식으로 동작하는 것인데,
varnish 도 결국엔 파일을 저장해두는 것이고, varnish 죽으면 서비스가 죽는건 마찬가지에요.

제 블로그 글의 가이드가, 더 확장하기 좋고, 더 성능이 좋고, 더 안정적입니다. (복제와 확장이 쉽습니다.)
varnish 는 구축과 장애대처, 확장 관리가 어려워요.

요즘은 트랜드가, MVC, MVVM 등등, 역할 구성에 따라서 나누는 편이며,
주로, frontend(html/js), backend(PHP), storage(S3,Object storage)로 나누는 편입니다.

잘 판단이 안될때는 이미 앞서가는 기업들의 사용을 살펴보면 됩니다.
Naver 의 경우 이미지 캐시서버 도메인은 https://s.pstatic.net/static/www/u/2014/0328/mma_20432863.png 입니다.
Google 의 경우 https://ssl.gstatic.com/gb/images/i1_1967ca6a.png 입니다.

Naver와 Google 의 사례에서 봤을때 cdn.wsgvet.com 로 운영하는 것은 바람직하다고 생각합니다.