brunch

You can make anything
by writing

- C.S.Lewis -

by 강진우 Jul 26. 2016

nginx micro caching

정말 오랜만에 글을 씁니다. ^^ 오늘 주제는 nginx micro caching이라는 주제로 이야기해 볼까 합니다. 이전까지의 글들을 통해서 nginxreverse proxy로 동작할 때 upstream 설정을 어떻게 해야 하는지 등에 대해서 이야기를 했었는데요, 오늘은 거기서 조금 더 성능을 낼 수 있도록 하는 micro caching이라는 것이 대해 이야기해 보려고 합니다.


micro caching


micro caching이라는 개념은 아래 nginx 공식 홈페이지의 문서에서 나온 개념입니다. 

https://www.nginx.com/blog/benefits-of-microcaching-nginx/

한마디로 요약하자면 micro라는 단어가 주는 느낌 그대로

아주 짧은 시간 동안의 캐싱

을 의미합니다.


nginxreverse proxy로 동작하는 사이트의 경우 nginxstatic resource를 캐싱해서 제공하고 dynamic resource 같은 경우는 upstream 설정을 통해서 백엔드에 있는 tomcat, netty 혹은 unicorn 등의 애플리케이션 서버로 제공하는 형태로 동작합니다. micro caching은 바로 이때, dynamic resource에 대해 아주 짧은 시간 동안 캐싱을 해서 백엔드 앱 서버로 보내는 요청을 줄여 성능을 최대화 하자는 개념입니다.

사실 dynamic resource라고 해도 초단위로 페이지가 갱신되어야 하는 경우는 드뭅니다. 그래서 1초 정도라도 캐싱을 해 두면 다량의 트래픽이 들어오게 되는 사이트의 경우 더 많은 양을 처리할 수 있게 됩니다.


성능 개선 효과


그렇다면 micro caching을 통해서 얼마나 많은 성능 개선 효과를 볼 수 있을까요? 한 사이트의 이야기를 들어보면 비교도 할 수 없을 정도의 높은 트래픽을 처리할 수 있게 됨을 볼 수 있습니다.

https://tghw.com/blog/microcaching-for-a-faster-site

위 사이트에서 캡쳐한 테스트 결과 입니다.

ab툴을 이용한 간단한 테스트이지만 차이가 명확합니다.


테스트


다른 사이트들을 통해서 좋다는 이야기들을 많이 들어 봤지만 그래도 역시 직접 해보는 게 확실하겠죠.

테스트 환경은 아주 간단합니다. spring boot 프레임워크를 이용해서 간단한 API를 만들어서 테스트해 봤습니다. 조금이라도 더 CPU를 사용하도록 for 문을 살짝 넣어 주고 Date 객체를 통해 현재 시간을 ms 단위로 출력하도록 했습니다.

테스트용 코드

그리고 앞 단에 nginx를 붙여 보겠습니다. 포트는 80, 81 두 개의 포트를 띄우고, 80은 일반적인 reverse proxy, 81은 micro caching을 적용한 reserver proxy로 설정했습니다. 

nginx.conf

curl 명령을 이용해서 세팅이 잘 되었는지 확인해 봅니다.

curl 테스트 결과

80 포트, 81번 포트 둘 다 정상적으로 동작하는 것을 확인할 수 있습니다. 결과를 보시면 흥미로운 부분이 있습니다. 80번 포트에 대한 요청은 보낼 때마다 timestamp가 다르게 찍히지만 81번 포트에 대한 요청은 1초 이내의 요청이라면 같은 timestamp를 찍는 걸 볼 수 있습니다. 81번 포트는 nginx가 캐싱된 내용을 서빙해 주기 때문입니다.

ab 테스트를 통한 결과도 차이가 좀 나는 것을 볼 수 있습니다.

80번 포트의 결과
81번 포트의 결과

로직이 가볍기 때문에 생각보다 많이 차이가 나진 않았지만 로직이 복잡하면 복잡할수록 그 효과는 더 클 수 있습니다.



주의해야 할 점


지금까지 micro caching에 대해 좋은 이야기만 했는데요, 역시 모든 상황에 사용할 수 있는 만능 기능은 없듯이 여기에도 주의해야 할 부분이 있습니다.


1. dynamic resource에 대해 캐싱을 하는 것이기 때문에 1초 동안의 캐싱이 서비스에 영향이 없는지 확실한 검증이 필요합니다.

2. 캐싱이 디스크에 저장되기 때문에 아주 드문 경우로 더 낮은 성능을 보여주는 경우도 있습니다. 이는 dynamic resource를 생성하는 로직이 가벼우면 가벼울수록 영향을 줄 수 있습니다. 즉, 캐싱을 통해서 제공하는 것보다 앱 서버에서 생성해서 넘겨주는 게 더 빠를 경우도 존재한다는 의미입니다.


모든 기능들이 그렇지만 서비스 적용에는 충분한 테스트와 검증을 통해서 하셔야 합니다. 그럼에도 불구하고 분명 nginx micro caching은 한 번쯤은 시도해 볼 만한 좋은 설루션이라고 생각합니다. 잘 적용하셔서 좀 더 적은 양의 서버로 좀 더 많은 트래픽을 처리할 수 있는 시스템을 만드실 수 있으셨으면 좋겠습니다.

매거진의 이전글 리눅스의 페이지 캐시와 버퍼 캐시

매거진 선택

키워드 선택 0 / 3 0
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari