네트워크 전송 관점에서 최적화를 위한 압축 설정 템플릿

 

이전 글에서는 sendfile, tcp_nopush, tcp_nodelay 등 데이터를 어떻게 전송할지에 대한 최적화를 다뤘다.

 

이번에 다룰 압축(Compression)은 네트워크 전송 관점과 CPU 사용량 사이에서의 트레이드 오프 고려가 필요한 내용으로, 단지 Nginx에 국한되지 않고 일반 api서버나 데이터 가공 모듈 등에서 적용 가능한 사항들을 다룬다.

그리고 특히 텍스트 기반의 데이터에서 적용 시, 효율적일 수 있는 내용이다.

 

CPU 사용량 vs 네트워크 전송량 

데이터를 압축하여, 전송한다는 것은 서버 입장에서 압축 연산 비용을 발생시키는 것이다. 

이는 CPU 사용량을 야기하는 것이며, 동시에 네트워크로 보내는 데이터의 크기가 줄어들어 전송량도 감소한다. 

따라서 서버의 CPU 여유가 있고, 네트워크 대역폭의 병목 문제가 발생한다면 파일 압축을 통한 네트워크 전송 관점에서 최적화 하는 것이 이득일 수 있다. 

 

아래의 이미지는 압축을 통한 설정을 적용한 경우와 그렇지 않은 경우의 흐름을 보여준다.

 

압축 과정을 적용하는 경우(gzip on) 100kb 텍스트 파일이 30kb 텍스트 파일로 줄어들어 데이터 양이 70% 가까이 줄어든다.

같은 내용을 100KB 대신 30KB만 전송하면 되므로, 네트워크 사용량이 줄고 로딩 속도가 빨라진다. 이러한 압축이 필요한 환경은 네트워크가 느린 환경에서 특히 효율적이다. 예를 들어, 모바일 환경에서 이런 압축을 제공하면 좋다.

 

압축하면 안되는 타입의 파일

gzip을 사용해서 압축을 적용하는 경우, 모든 파일을 압축하는 것은 좋지않다.

이미 압축된 형태의 파일을 다시 압축하는 것은 압축률이 좋지 않고, CPU는 이 효율적이지 않은 압축률을 위해서  낭비하게 되기 때문이다.

 

주로 텍스트 기반의 파일들이 좋다. 

gzip은 반복되는 패턴을 찾아 압축하는 알고리즘이며, 텍스트 파일은 반복 패턴이 많아 압축률이 높기 때문이다.

 

gzip의 주요 설정 옵션

http {
    # gzip 압축 활성화
    gzip on;

    # 압축 대상 MIME 타입 지정
    gzip_types
        text/plain
        text/css
        text/javascript
        application/javascript
        application/json
        application/xml
        image/svg+xml;

    # 압축 버퍼 — 8KB짜리 16개(총 128KB)를 임시 메모리로 사용
    # 버퍼가 부족하면 디스크 임시 파일에 쓰므로 성능 저하 발생
    gzip_buffers 16 8k;


    # 이 크기 이하는 압축하지 않음
    gzip_min_length 1024;

    # 프록시를 통해 온 요청도 압축
    gzip_proxied any;

    # Vary 헤더 추가 (프록시/CDN 캐시 호환성)
    gzip_vary on;
}

 

위에는 gzip 설정에 있어 주로 사용하는 옵션들이다. 

먼저, on 과 type은 각각 gzip 압축 활성화, 압축 대상의 mimetype 지정하는 기본 설정이다.

 

gzip_buffers

gzip 압축을 수행할 때, 사용할 메모리 버퍼의 개수와 크기를 지정하는 옵션이다. 

버퍼(Buffer)란 데이터를 처리하는 두 주체의 속도 차이를 완충해주는 임시 메모리 공간이다.
gzip 압축은 데이터를 어느 정도 모아서 처리해야 효율적이기 때문에, 중간에 버퍼를 두고 쌓아두면서 압축한다.

버퍼에 데이터를 모아서 압축하면, 데이터 덩어리가 커지고 이는 곧 패턴 분석에 따라 압축률을 높이며 네트워크 전송의 효율성을 상승시키기 때문이다. 

 

따라서, 

gzip_buffers 16 8k;

위의 설정은 → 8KB짜리 버퍼 16개 = 총 128KB의 메모리를 압축 작업에 사용을 의미한다.

 

만약, 버퍼가 꽉 찼는데 처리할 데이터가 남았다면, Nginx는 디스크의 임시 파일에 데이터를 쓴다.이는 디스크 접근을 야기하여 성능을 떨어지게 만든다. 데이터의 크기가 큰 경우는 버퍼를 넉넉하게 잡아두는 것이 좋다.(대부분의 환경에서 16 8k면 충분하다.)

 

상황	조정 방향
응답 크기가 매우 큰 경우 (수MB)	버퍼 크기나 개수 늘리기
메모리가 제한적인 환경	버퍼 크기나 개수 줄이기
기본값 (32 4k 또는 16 8k)	대부분의 환경에서 충분

 

gzip_min_length

만약 아주 작은 파일 단위로 압축한다면, 크기가 거의 줄지않고, 오히려 압축/해제의 과정으로 오버헤드가 더 클 수도 있다.

따라서 일반적으로 아주 작은 파일은 압축하지 않는 것이 바람직하며 위의 설정의 경우 1024(1KB) 이상 크기의 파일인 경우에만 압축 과정을 진행하는 설정이다. 

 

 

gzip_vary

gzip_vary on은 응답 헤더에 Vary: Accept-Encoding을 추가하는 설정이다.

단순해 보이지만 프록시나 CDN이 끼어있는 환경에서는 매우 중요하다.

만약 해당 헤더가 없다면, gzip을 지원하지 않는 클라이언트에게 압축된 파일을 그대로 보낸다. 그리고 클라이언트는 압축된 파일을 해제하지 못해 깨진 응답을 받게된다.

 

Vary: Accept-Encoding이 해결책

gzip_vary on을 설정하면 응답에 Vary: Accept-Encoding 헤더가 붙는다. 이 헤더는 프록시/CDN에게 "Accept-Encoding 값에 따라 다른 버전을 캐시해야 한다" 고 알려주는 신호다.

 

위의 이미지 흐름처럼 gzip 알고리즘으로 클라이언트가 해제하지 못한다면 gzip 형태가 아닌 다른 형태의 응답을 주는 것이다.

(사실상 필수적인 설정으로 볼 수 있다.)

 

gzip_proxied

프록시 서버를 통해 들어온 요청에 대해 압축을 적용할지 여부를 설정한다.

기본적인 설정값에는 아래와 같은 것들이 있다.

값	동작
off	프록시 요청에는 압축 안 함
any	모든 프록시 요청에 압축 적용
no-cache	Cache-Control: no-cache인 경우만 압축