웹 성능 최적화 NGINX로 구성하기
이 포스트에서는 웹 성능 최적화 NGINX 구성을 변경함으로써 할 수 있는 몇 가지 간단하지만 강력한 변경 사항을 소개합니다.
2014년 텍사스 대학교에서 열린 유명한 연설에서 William H. McRaven 장군은 세상을 바꾸고 싶다면 먼저 침대를 정리하라고 말했습니다. 아침에 침대를 정리하거나 웹 사이트의 HTTP 서버 구성을 거의 변경하지 않는 등 작은 일이 큰 영향을 미칠 수 있습니다.
과장된 표현 같나요? 2020년의 처음 몇 달은 우리 세상에서 정상적이고 합리적인 것에 대한 모든 정의를 낭비했습니다. COVID-19 팬데믹으로 인해 지구 인구의 절반이 집에 갇혀 있는 상황에서 인터넷은 유일한 커뮤니케이션, 엔터테인먼트, 식품 구매, 작업 및 교육 수단이 되었습니다. 그리고 매주 인터넷은 이전보다 더 높은 네트워크 트래픽과 서버 부하를 경험하고 있습니다.
Netflix와 YouTube와 같은 주요 미디어 플랫폼은 네트워크 링크를 보호하기 위해 전송 품질을 제한하여 사람들이 작업하거나 가족과 소통하거나 학교에서 가상 수업을 듣는 데 사용할 수 있는 대역폭을 더 많이 확보하고 있습니다. 하지만 여전히 이는 충분하지 않으며, 네트워크 품질이 점차 악화되고 많은 서버가 과부하 상태가 됩니다.
목차
1. 웹 성능 최적화 하면 사이트에 도움이 될 수 있습니다.
2. HTML, CSS 및 JavaScript 파일에 대한 Gzip 압축 활성화
3. 캐시 헤더 설정
4. HTTP/2 프로토콜 지원 활성화
5. 로깅 최적화
5-1. 방법 1: 페이지 리소스 요청 로깅 비활성화
5-2. 방법 2: 성공한 요청의 로깅 비활성화
5-3. 방법 3: 버퍼링으로 I/O 작업 최소화
6. 특정 URL에 대한 대역폭 제한
7. 결론
1. 웹 성능 최적화 하면 사이트에 도움이 될 수 있습니다.
만약 웹사이트를 소유하고 해당 웹사이트의 HTTP 서버 구성을 관리할 수 있다면 도움이 될 수 있습니다. 몇 가지 작은 변경을 통해 사용자가 생성하는 네트워크 대역폭과 서버 부하를 줄일 수 있습니다. 이는 서로 win-win인 상황입니다. 현재 웹사이트가 과부하 상태에 있는 경우 이를 줄일 수 있어 더 많은 사용자에게 서비스를 제공하고 비용을 낮출 수 있습니다. 과부하 상태가 아닌 경우 빠른 로딩은 사용자 경험을 향상시킵니다(때로는 Google 검색 결과에서 귀하의 위치에 긍정적인 영향을 미침).
매달 수백만 명의 사용자가 사용하는 애플리케이션이든 베이킹 레시피가 있는 작은 블로그가 있든 상관없습니다. 네트워크 트래픽의 1킬로바이트(KB)를 제거할 때마다 의료 테스트 결과를 온라인으로 확인하거나 친척에게 중요한 물건을 보내기 위해 소포 라벨을 만들어야 하는 사람들을 위해 용량을 확보할 수 있습니다.
실제 예시로, NGINX는 친환경 화장품 제조업체인 Rogalove의 전자 상거래 사이트를 사용합니다. 이 사이트는 웹 서버로 NGINX를 실행하는 상당히 표준적인 WooCommerce 설치입니다. 계산을 위해 하루에 100명의 고유한 사용자가 방문하고, 사용자의 30%가 반복 방문자이며, 각 사용자는 세션 동안 평균 4개의 페이지에 접근한다고 가정합니다.
이러한 팁은 성능을 향상시키고 네트워크 대역폭을 줄이기 위해 즉시 취할 수 있는 간단한 단계입니다. 대량의 트래픽을 처리하고 있다면, 운영체제 및 NGINX 조정, 올바른 하드웨어 용량 프로비저닝, 가장 중요한 캐싱 활성화 및 조정과 같이 상당한 영향을 미치기 위해 더 복잡한 변경 사항을 구현해야 할 수 있습니다. 자세한 내용은 다음 포스트를 확인하세요.
2. HTML, CSS 및 JavaScript 파일에 대한 Gzip 압축 활성화
아시다시피, 현대 웹사이트에서 페이지를 구성하는 데 사용되는 HTML, CSS 및 JavaScript 파일은 굉장히 크기가 클 수 있습니다. 대부분의 상황에서 웹 서버는 이와 같은 텍스트 파일 및 기타 파일을 압축하여 네트워크 대역폭을 절약할 수 있습니다.
웹 서버가 파일을 압축하는지 확인하는 한 가지 방법은 브라우저의 개발자 도구를 사용하는 것입니다. 많은 브라우저에서 F12키로 도구에 액세스하고 관련 정보는 네트워크 탭에 있습니다. 예를 들면 다음과 같습니다.
왼쪽 하단에서 볼 수 있듯이 압축이 없습니다. 텍스트 파일의 크기는 1.15MB이고 그만큼의 데이터가 전송되었습니다.
기본적으로 압축은 NGINX에서 비활성화 되어 있지만 설치 또는 Linux 배포에 따라 기본 nginx.conf 파일에서 일부 설정을 통해 활성화할 수 있습니다. 여기서는 NGINX 구성 파일에서 gzip 압축을 활성화합니다.
gzip on;
gzip_types application/xml application/json text/css text/javascript application/javascript;
gzip_vary on;
gzip_comp_level 6;
gzip_min_length 500;다음 스크린샷에서 볼 수 있듯이 압축을 사용하면 데이터 전송이 약 80% 감소한 260KB로 줄어듭니다! 페이지의 각 새 사용자에 대해 약 917KB의 데이터 전송을 절약합니다. WooCommerce 설치의 경우 하루 62MB 또는 한 달에 1860MB입니다.
3. 캐시 헤더 설정
브라우저가 웹 페이지를 위해 파일을 검색할 때, 해당 파일을 로컬 하드 디스크 캐시에 복사본을 보관하여 해당 페이지를 다시 방문할 때 서버에서 파일을 다시 가져올 필요가 없도록 합니다. 각 브라우저는 서버에서 파일이 변경되었을 때 로컬 파일을 사용할지 다시 가져올지를 결정하기 위해 자체적인 논리를 사용합니다. 그러나 웹사이트 소유자로서 HTTP 응답에 캐시 제어와 만료 헤더를 설정하여 브라우저의 캐싱 동작을 더 효율적으로 조정할 수 있습니다. 장기적으로 많은 불필요한 HTTP 요청을 줄일 수 있습니다.
좋은 시작을 위해 자주 변경되지 않는 글꼴 및 이미지에 대해 긴 캐시 만료 시간을 설정할 수 있습니다(변경되더라도 일반적으로 새 파일 이름을 가집니다). 다음 예시에서는 한 달 동안 로컬 캐시에 글꼴과 이미지를 보관하도록 클라이언트 브라우저에 지시합니다.
location ~* \.(?:jpg|jpeg|gif|png|ico|woff2)$ {
expires 1M;
add_header Cache-Control "public";
}4. HTTP/2 프로토콜 지원 활성화
HTTP/2는 웹 페이지를 제공하기 위한 차세대 프로토콜로서, 네트워크와 호스트 서버의 활용도를 개선하기 위해 설계되었습니다. Google 설명서에 따르면, HTTP/2를 사용하면 페이지 로딩 속도가 훨씬 빨라집니다.
결과적으로, HTTP/2는 이전 버전인 HTTP/1.x와 비교하여 TCP 연결을 적게 사용하기 때문에 네트워크에 더 친숙합니다. 이는 다른 흐름과의 경쟁이 적어지고 더 오래 지속되는 연결을 의미하며, 이는 가능한 네트워크 용량을 더 잘 활용할 수 있도록 도와줍니다.
NGINX 1.9.5 및 NGINX Plus R7 이상은 HTTP/2 프로토콜을 지원하며 활성화하기만 하면 됩니다😀. 이렇게 하려면 NGINX 구성 파일의 listen 지시문에 http2 매개변수를 포함합니다.
listen 443 ssl http2;대부분의 경우 HTTP/2를 사용하려면 TLS도 활성화해야 합니다.
사이트가 HTTP2.Pro 서비스를 사용하여 HTTP/2를 지원하는지 확인할 수 있습니다.
5. 로깅 최적화
좋아하는 음료를 한 잔 만들어 편안하게 앉아 생각해보세요. Access log 파일을 마지막으로 본 것이 언제였습니까? 지난 주, 지난 달, 아니면 한 번도 확인한 적이 없나요? 웹사이트의 일반적인 모니터링을 위해 사용하더라도, 아마도 주로 오류(400과 500 상태 코드 등)에만 초점을 맞추고 성공적인 요청에 대해서는 관심을 두지 않았을 것입니다.
불필요한 로깅을 줄이거나 제거함으로써 서버에서 디스크 저장 공산, CPU 및 I/O 작업을 절약할 수 있습니다. 이로 인해 서버가 약간 더 빨라질 뿐만 아니라 클라우드 환경에서 배포된 경우, 해제된 I/O 처리량과 CPU 사이클은 동일한 물리적인 머신에 상주한 다른 가상 머신이나 애플리케이션에게 생명을 구할 수도 있습니다.
로깅을 줄이고 최적화하는 방법에는 여러가지가 있습니다. 여기서는 세 가지를 강조합니다.
5-1. 방법 1: 페이지 리소스 요청 로깅 비활성화
만약 이미지, JavaScript 파일, CSS 파일 등과 같은 보통의 페이지 자원을 검색하는 요청을 로깅할 필요가 없다면, 이는 빠르고 쉬운 해결책입니다. 해당 파일 유형과 일치하는 새로운 location 블록을 생성하고, 내부에서 로깅을 비활성화하면 됩니다. (이 access_log 지시문을 Cache-Control 헤더를 설정하는 위의 location 블록에 추가할 수도 있습니다.)
location ~* \.(?:jpg|jpeg|gif|png|ico|woff2|js|css)$ {
access_log off;
}5-2. 방법 2: 성공한 요청의 로깅 비활성화
이 방법은 2xx 또는 3xx 응답 코드를 가진 쿼리를 제외하고, 오류만을 로깅하여 더 강력한 방법입니다. NGINX 로깅이 어떻게 구성되어 있는지에 따라 약간 더 복잡할 수 있습니다. 예시에서는 Ubuntu Server 배포판에 포함된 표준 nginx.conf를 사용하여 가상 호스트에 관계없이 모든 요청이 /var/log/nginx/access.log에 로깅되도록 설정되어 있습니다.
공식 NGINX 문서의 예를 사용하여 조건부 로깅을 설정해 보겠습니다. $loggable 변수를 만들고 응답 코드가 2xx 및 3xx인 요청에 대해 0으로 설정하고 그렇지 않으면 1로 설정합니다. 그런 다음 이 변수를 access_log 지시문의 조건으로 참조합니다.
다음은 /etc/nginx/nginx.conf의 http 컨텍스트에 있는 원래 지시문입니다.
access_log /var/log/nginx/access.log;map 블록을 추가하고 access_log 지시문에서 참조하십시오.
map $status $loggable {
~^[23] 0;
default 1;
}
access_log /var/log/nginx/access.log combined if=$loggable;Combine이 기본 로그 형식이지만 if 매개변수를 포함할 때 명시적으로 지정해야 합니다.
5-3. 방법 3: 버퍼링으로 I/O 작업 최소화
모든 요청을 기록하려는 경우에도 access log 버퍼링을 켜면 I/O 작업을 최소화할 수 있습니다. 이 지시문을 사용하면 NGINX는 512KB 버퍼가 채워치거나 마지막 플러시 이후 1분이 경과할 때까지 로그 데이터를 디스크에 쓰기 위해 대기합니다.
access_log /var/log/nginx/access.log combined buffer=512k flush=1m;
6. 웹 성능 최적화 를 위한 특정 URL에 대한 대역폭 제한
만약 서버가 큰 파일(또는 양식이나 보고서와 같이 작지만 매우 많이 사용되는 파일)을 제공하는 경우 클라이언트가 파일을 다운로드할 수 있는 최대 속도를 설정하는 것이 유용할 수 있습니다. 사이트에 이미 높은 네트워크 부하가 있는 경우 다운로드 속도를 제한함으로써 애플리케이션의 중요한 부분이 응답 가능한 상태를 유지할 수 있는 대역폭을 확보할 수 있습니다. 이는 하드웨어 제조업체에서 널리 사용되는 인기 있는 해결책입니다. 예를 들어 3GB 크기의 프린터 드라이브를 다운로드할 때 더 많은 대기 시간이 발생할 수 있지만, 동시에 많은 사람들이 다운로드를 수행해도 여전히 다운로드를 완료할 수 있습니다.😉
특정 URL에 대한 대역폭을 제한하려면 limit_rate 지시문을 사용하십시오. 여기서는 /download 아래의 각 파일에 대한 전송 속도를 초당 50KB로 제한합니다.
location /download/ {
limit_rate 50k;
}다음은 웹사이트에서 limit_rate_after 지시문을 사용해 큰 파일만 제한하는 예시입니다. 이 예시에서는 모든 디렉토리에서 전송되는 모든 파일 맨 앞의 500KB는 속도 제한 없이 전송되며, 그 이후에는 모두 50KB/s의 속도로 제한합니다. 이렇게 함으로써 웹사이트의 중요한 부분은 더 빠르게 전달하고, 나머지 부분은 느리게 전송할 수 있습니다.
location / {
limit_rate_after 500k;
limit_rate 50k;
}참고할 사항으로, 속도 제한은 브라우저와 NGINX 간의 개별 HTTP 연결에 적용되며, 다운로드 관리자를 사용하여 속도 제한(Rate Limit)을 우회하는 것을 방지하지 않습니다.
마지막으로, 서버로의 동시 접속 수나 요청 속도도 제한할 수 있습니다. 자세한 방법은 NGINX STORE의 가이드를 참조하시기 바랍니다.
7. 웹 성능 최적화 결론
이러한 5가지 팁이 웹사이트의 성능 최적화에 도움이 되었으면 좋겠습니다. 속도 및 대역폭 향상은 각 웹사이트마다 다릅니다. NGINX 구성을 조정해도 대역폭이 크게 해제되지 않거나 속도가 향상되지 않더라도, 수천 개의 웹사이트가 NGINX 구성을 개별적으로 조정하는 전반적인 영향이 합산됩니다. 이렇게 함으로써 전체적으로 글로벌 네트워크를 더욱 효율적으로 사용할 수 있으며, 가장 중요한 서비스가 필요할 때 제공된다는 것을 의미합니다.
NGINX Plus를 직접 사용해 보시려면 30일 무료 평가판을 신청하거나 NGINX STORE에 연락하여 문의하십시오.
아래 뉴스레터를 구독하고 NGINX의 최신 정보들을 빠르게 전달 받아보세요.
댓글을 달려면 로그인해야 합니다.