@기진곰님의 슈퍼캐시 모듈을 서버로 확장해서 사용할 수 있다면 어떨까? 가능한 서비스 같고 또 실제 그렇게 구성해서 서비스 중인 곳도 있지 않을까 개인적으로 생각해 봤습니다.

 

현재 캐시설정시간이 있어 짧은 시간 만료 후 다시 방문자에게는 캐시된 화면이 아닌 실제 db까지 조회해야 하는 작업이 요구 됩니다.

 

다양한 문서가 분포된 커뮤니티 사이트에서는 어찌 보면 약간 효율이 떨어질 수도 있다고 생각해 봤는데요.

이를 극복하기 위해 아예 서버 한대를 캐시전용 서버를 두는 것 입니다. (모든 페이지를 html로 캐시해서 저장)

 

비로그인 방문장에게는 캐시된 화면만 보여주는 것입니다. 캐시만료시간이 아예 없습니다.

(얼핏 보면 이미지 CDN이 확대된 페이지 전체를 CDN 하는 것으로 아예 자체적으로 서버를 가지고 있는 것이죠.)

 

클라우드 플레어의 경우 캐시된 이미지를 다시 갱신요구를 해야 변경된 새로운 이미지로 바꿔주는 강력한 캐시를 제공합니다.

이렇게 아예 html을 캐싱해서 저장해 두고 비로그인 방문자들이나 봇에게는 이 빠른 html출력 화면만 보여주는 거죠.

 

db 갱신이 있을경우는 어떻게 하냐구요? 이러한 이벤트가 있는 페이지들만 트리거를 이용해서 캐시서버에게 새로 읽어가게 해주면 되지 않을까 상상해 봤구요..

 

이렇게 움직인다면 2만개의 문서가 축적된 커뮤니티라면 각 2만개 모든 문서가 활발하게 db변화가 일어나지 않을 거기에 대부분의 문서는 캐시된 빠른 화면만 비로그인 대상자들에게 뿌려주면 굉장히 빠른 응답을 보여줄 것이라 생각이 되어집니다.

 

모든 문서가 계속 갱신이 된다면 물론 캐싱작업 때문에 더 바빠지는 상황이 생길 수 ? 있다는 생각도 해봤지만 실제로 그런일은 없을 듯 하다는게 현실적인 생각이었습니다.

 

db없이 html로만 구성된 페이지들은 굉장히 빠릅니다. db구조를 가진 사이트를 html 페이지로 만들어주는 효과 ??

 

이런 서버가 구축이 가능하다면 본서버 + 캐싱서버 이렇게 해서 되지 않을까 생각해봤어요. 실제 이렇게 하는게 있나요 ?

 

 

웹지기

profile
10년을 다루다 보니 이제 간단한 것도 만들고 커뮤니티 운영에 관한 다양한 노하우가 있습니다. 어려운 점이나 가지신 생각을 함께 소통해 보아요.
https://rxtip.kr/ 라이믹스 꿀팁
  • profile

    캐시서버와 본서버가 같은 IDC내에 있다면 모를까 그렇지 않다면 오히려 성능저하가 있지 않을까 싶습니다. 그리고 지금도 캐시 설정시 외부서버를 지정하면 캐시서버와 본서버 분리가 가능합니다.

  • profile profile
    네. 서버를 물리적으로 분리를 하되 네트워크는 같은 곳으로...... 혹은 아예 같은 서버에서 작업만 분리 하면 어떨까요...
  • profile profile
    캐시 설정시 127.0.0.1 대신 외부 redis/memcache 서버 아이피를 입력하면 됩니다. 해당 서버에 캐시서버 설정과 방화벽 포트설정만 하면 됩니다. 아니면 아예 redis/memcache 호스팅을 받거나요.

    다만 캐시 자체가 그렇게 큰 성능을 요구하는 작업은 아니라 성능 향상이 있을지는 모르겠네요.
  • profile profile
    일단 저희 사이트의 경우는 쿼리 없이 캐시된 화면을 뿌려주면 응답에서는 10배정도 시간이 단축이 되서요.
  • profile profile
    캐시 사용 vs 비사용은 큰 차이가 나겠죠. 다만 캐시서버 내부 vs 외부 간 성능차이는 있을지 잘 모르겠습니다. 일단 서버가 두대면 비용이 더 들 수밖에 없는데, 내부에 두나 외부에 두나 비슷비슷하다면 굳이 돈낭비하며 서버를 하나 더 둘 이유는 없겠죠.
  • profile profile
    내부 캐시로 제가 원하는 만료시간 없이 db변경시만 캐시초기화 이게 가능하다면 굳이 외부서버로 갈 필요는 없겠지요. 제가 원하는 핵심은 캐시만료가 없고 특정한 요청에만 초기화되는 것이 있다면 좋겠다는 상상이었습니다.
  • profile profile
    그런 것이라면 문서 페이지 편집시 등에만 초기화하게 할 수는 있겠죠. 외부에 두냐 내부에 두냐는 큰 문제가 되진 않습니다.
  • profile profile
    네. 내외부는 제가 서버의 동작을 잘 몰라 꼭 서버와 같은 자원이 필요할 것 같아 그렇게 글을 쓴 것이구요. 말씀 하신대로 정해진 act에만 초기화 되는 것을 원하는 것 이었습니다.
  • profile

    슈퍼캐시 모듈에서 Cache-Control 헤더를 사용하도록 하고, 앞단에 Varnish를 설치하면 대략 말씀하신 것과 비슷한 구성이 됩니다.

     

    아니면 그냥 캐시 시간을 몇 시간 정도로 길게 잡아 놓고, 글이나 댓글 작성시 갱신하는 것만 제대로 해줘도 됩니다.

     

    커뮤니티 사이트는 워낙 여기저기에서 실시간으로 바뀌는 부분이 많기 때문에 이용에 불편을 주지 않으면서 캐시를 사용하는 데 한계가 있습니다. 그러나 블로그라면 static site generator를 사용해서 모든 페이지를 html로 만들어 놓고, 블로그 주인이 글을 새로 쓰거나 수정할 때만 갱신해 주는 기법도 많이 사용합니다. 실시간 갱신이 필요한 댓글 부분은 Disqus 같은 외부 서비스로 연결해 버리고요.

  • profile profile
    사실 제가 캐시 시간을 길게 주고 싶다고 저번에 말씀 드렸던 이유가 오늘 글 쓴 이유와 맥락이 거의 같아요. 사실 지나간 오래된 글들은 검색해서 들어오는 새로운 방문자들에게 제공이 될텐데 이 글들은 실제적으로 캐싱된 화면만 보여줘도 충분하거든요.

    문서내에 위젯들을 최대한 빼버리고 캐시 시간을 아예 길게 잡을까도 고민해 봤습니다. 그런데 이 시간이 또 경과되면 모든 문서의 캐싱이 또 초기화 된다는 생각에 이런 생각까지 하게 되었네요.

    캐싱시간을 말도 안되게 길게 세팅해도 될까요??? 현재 슈퍼캐시 모듈의 캐시시간 설정을요....
  • profile profile
    회원들의 활동이 얼마나 많은지에 따라 다르겠지만, 캐싱 기간이 몇 시간을 넘어가면 아마 캐시가 만료되기 전에 글쓰기나 댓글쓰기로 인한 갱신이 먼저 일어날 거예요. 새 글이 등록되었을 때만 갱신시킨다는 웹지기님의 의도에 맞기는 하겠네요 ㅎㅎ
  • profile profile

    회원들의 소통은 아주 최근 글에 한정되어 있어요. 그래서 대부분 문서는 캐시시간을 실제로 주지 않아도 되는 상황이랍니다.
    그래서 개인적인 생각인데요. 캐시시간을 굉장~~~~~~~~~~히 길게 두고
    수정과 댓글 작성의 작업이 있을 경우 해당문서 또는 목록을 갱신시키면 어떨까 생각합니다.

     

    대신 목록 상단에 있는 위젯은 비회원에게는 제대로된 데이터 제공이 어려울 수도 있다는 문제점은 안고 가면 될 것 같다는 생각까지 해봤어요.

  • profile profile
    현재 슈퍼캐시 모듈은 캐시 사용에 익숙하지 않은 분들의 불편을 덜어드리기 위해 글 작성시 해당 모듈의 모든 캐시를 비워버리도록 되어 있습니다. 그렇게 하지 않으면 오래된 글 조회시 맨 아래에 나오는 목록의 페이지가 어긋나는 등의 문제가 생기거든요.

    새로 글을 쓰더라도 같은 모듈의 오래된 글 캐시가 갱신되지 않도록 하려면 상당히 많은 수정이 필요할 것 같네요.
  • profile profile
    아. 현재 상황으로는 안되는 거 였군요. 캐시 기간을 길~~ 게 줘 볼까 하는 생각 자체가 적용이 안되는거였네요 ㅋㅋ