엔진엑스를 캐싱 프록시로 사용 * (업스트림) 애플리케이션에서 받아 온 콘텐츠를 로컬 디스크나 메모리에 저장해 두었다가 이후 같은 콘텐츠에 대한 요청이 들어오면 업스트림에 콘텐츠를 요청하지 않고 저장된 것을 사용하는 것 * 캐싱 프록시의 장점은 크게 두 가지다. * 첫 번째는 요청을 처리하는 시간을 줄일 수 있다는 점이다. * 두 번째는 애플리케이션을 오가는 트래픽을 줄일 수 있으므로 그만큼 같은 인프라스트럭처로 더 많은 요청을 처리할 수 있다. * 인증 쿠키가 포함된 요청은 캐싱하지 않도록 하면 개인화된 콘텐츠를 캐시에서 어렵지 않게 제외할 수 있다.
001) # 현재 설정 파일 제거
002) ➜ rm ./nginx/sites-enabled/image-gallery.local
003)
004) # 새로운 설정 파일을 복사하고 엔진엑스를 재시작
005) ➜ cp ./nginx/sites-available/image-gallery-4.local ./nginx/sites-enabled/image-gallery.local
006)
007) ➜ docker-compose -f nginx/docker-compose.yml restart nginx
008)
009) # 애플리케이션에 접근
010) ➜ curl -i --head --insecure https://image-gallery.local
011) ...
012) X-Cache: MISS
013) X-Proxy: 09a7df57ce06
014) X-Upstream: 172.20.0.2:80
015)
016) ➜ curl -i --head --insecure https://image-gallery.local
017) ...
018) X-Cache: HIT
019) X-Proxy: 09a7df57ce06
- 005: 이 설정은 엔진엑스를 image-gallery 애플리케이션의 캐싱 프록시로 사용한다.
- 012: 처음에는 캐시에 아무것도 저장되지 않은 상태다. 업스트림에서 받아 온 콘텐츠를 캐시에 추가한다.
- 014: 콘텐츠를 제공한 컨테이너의 IP 주소
- 018: 두 번째 호출에서는 요청과 일치하는 콘텐츠를 캐시에서 찾아 제공한다. 업스트림에는 요청이 전달되지 않는다.
예제 20-3 image-gallery 애플리케이션과 API의 캐시 프록시 설정 * 캐시 사용은 세세하게 설정할 수 있다. * API의 캐시는 단기 캐시로 설정돼 캐싱되고 나서 1분이 지나면 무효화된다. * 이 설정은 매우 부하가 크면서 항상 새로운 값을 유지해야 할 때 유용하다. * 웹 애플리케이션의 캐시는 여섯 시간 동안 유효하게 설정됐다.
location = /api/image {
proxy_pass http://iotd/image;
proxy_set_header Host $host;
proxy_cache SHORT;
proxy_cache_valid 200 1m;
...
}
location / {
proxy_pass http://image-gallery;
proxy_set_header Host $host;
proxy_cache LONG;
proxy_cache_valid 200 6h;
proxy_cache_use_stale error timeout invalid_header updating
http_500 http_502 http_503 http_504;
...
}
- 캐시 설정 LONG과 SHORT는 diamol/nginx 이미지의 엔진엑스 코어 설정 파일에 정의된 것이다.
- 캐시 규격은 응답 콘텐츠를 저장하는 데 사용할 메모리 및 디스크 용량과 오래 된 캐시 항목의 유효 시간을 설정한다.
proxy_cache_use_stale * 애플리케이션 신뢰성을 개선하는 데 도움이 되는 기능 * 업스트림을 사용할 수 없을 때 유효 시간이 만료된 캐시라도 사용하라는 의미 * 만료된 캐시 콘텐츠라도 제공할 수 있다면, 애플리케이션 컨테이너가 장애를 일으켜도 애플리케이션이 서비스를 제공할 수 있다. * 이 방법은 일시적인 장애나 업데이트로 인한 롤백의 영향을 회피하는 유용한 수단이 된다.
실습 image-gallery 애플리케이션과 API를 몇 번 호출해 캐시가 저장되도록 한 다음, 컨테이너를 제거한 상태에서 다시 애플리케이션에 요청을 보내자
001) # 웹 사이트와 API를 호출
002) ➜ curl -s --insecure https://image-gallery.local
003) ➜ curl -s --insecure https://image-gallery.local/api/image
004)
005) # 웹 컨테이너를 모두 제거
006) ➜ docker container rm -f $(docker container ls -f name=image-gallery_* -q)
007)
008) # 웹 사이트를 다시 한 번 호출
009) ➜ curl -i --head --insecure https://image-gallery.local
010) HTTP/1.1 200 OK
011) ...
012) X-Cache: HIT
013)
014) # API 컨테이너를 제거
015) ➜ docker container rm -f image-gallery_iotd_1
016)
017) # API를 다시 한 번 호출
018) ➜ curl -i --head --insecure https://image-gallery.local/api/image
019) HTTP/1.1 502 Bad Gateway
020) ...
- 009: 웹 컨테이너를 제거하면 캐싱된 콘텐츠가 제공된다.
- 018: API 캐시는 유효 시간이 1분으로 짧아서 이미 만료됐다.
정리 * 엔진엑스는 리버스 프록시로도 매우 유용하며, 그 외에도 HTTP 응답에 Gzip 압축 적용, 클라이언트 캐시 헤더 추가 등 여러 용도로 활용해 사용자가 체감하는 성능을 개선하고 애플리케이션 컨테이너의 부담을 경감할 수 있다. * 엔진엑스는 컨테이너 이전부터 있던 기술이므로 컨테이너 플랫폼 수준에서 통합 되지는 않는다. * 다만 도커 네트워크의 DNS 조회를 통해 네트워크 수준에서 동작할 뿐이다.