NGINX 로 트래픽 처리 성능 극대화하기

해당 포스트에서는 블랙 프라이데이, 사이버 먼데이 및 기타 트래픽이 많은 이벤트에서 웹 사이트 또는 일반 웹사이트의 성능을 극대화하기 위해서 NGINX 를 사용한 간단한 팁을 알려드립니다.

전형적인 전자 소매업체는 연중의 거의 1/4의 매출을 감사절과 크리스마스 사이에 올립니다. 많은 온라인 상점에서는 연휴 다음날인 블랙 프라이데이와 그다음인 사이버 먼데이가 연말 최대의 판매일로 압도적인 전자상거래 거래량이 발생합니다. 이러한 날들은 매출 급증을 의미하기도 하지만, 동시에 트래픽 증가와 관련된 사이트 성능과 가동 시간에 대한 스트레스와 불확실성을 이야기합니다.

고객들은 사이트로부터 높은 성능과 완벽한 사용자 경험을 요구합니다. 트래픽 증가로 인해 페이지 로드 시간이 단 1초라도 줄어들면 전환율이 7% 감소할 것으로 예상됩니다. 그리고 최대 트래픽 시간에는 온라인 소비자들의 75% 이상이 지연을 견디지 않고 경쟁 업체의 사이트로 이동할 것입니다.

구글 검색 결과는 사이트 성능에 영향을 받기 때문에 빠른 성능은 향상된 검색 결과를 통해 더 많은 고객을 유치할 수 있습니다. 또한 고객들이 더 좋은 경험을 갖게 되므로 전환율도 높아집니다.

사이트의 성능을 향상시키는 방법을 알아보기 위해, 우선 “NGINX로 트래픽 급증에 대한 리스크를 제거하는 방법“이라는 포스트를 참조하십시오. 그런 다음 이 포스트에서 제공하는 자세한 안내를 활용하여 전략을 개선하세요.

목차

1. NGINX HTTP Gateway로 용량 늘리기
2. 사이트 콘텐츠 캐시 및 마이크로캐시
3. 로드 밸런싱으로 여러 애플리케이션 서버 추가
4. 사용자당 수신 요청 제한
5. NGINX 성능 극대화 결론

1. NGINX HTTP Gateway로 용량 늘리기

HTTP Gateway는 기술적으로 리버스 프록시 서버로 알려져 있습니다. 어떤 이름으로든 HTTP Gateway는 웹상에서 사용자 디바이스인 클라이언트로부터 요청을 받은 다음 해당 요청을 로컬 네트워크상의 다른 서버로 전달합니다. 응답이 생성되면 게이트웨이는 해당 응답을 요청한 클라이언트에게 반환합니다.

많은 사이트에서는 간단한 아키텍처를 가지고 있습니다. 웹 서버는 애플리케이션 코드를 실행하여 웹 페이지를 생성하며, 종종 애플리케이션을 지원하는 데이터베이스 서버도 있습니다. 이러한 경우 애플리케이션 서버는 일반적으로 Apache 서버입니다.

그러나 Apache와 많은 다른 웹 애플리케이션 플랫폼은 대규모 트래픽을 처리하는 능력이 제한됩니다. 새로운 브라우저 세션마다 6~8개의 서버 연결이 열리며, 아파치는 각 연결에 상당한 메모리를 할당합니다. 이러한 연결은 페이지 요청, 구성, 반환, 및 확인이 이루어질 때까지 유지됩니다.

한 번에 수천 명 이상의 사용자가 온라인 상태인 경우 수십만 개의 연결이 필요합니다. 하지만 세 가지 상황이 발생할 수 있습니다.

  1. Apache 서버는 메모리가 부족하여 세션을 디스크에 스와핑을 시작하고, 이로 인해 성능이 크게 떨어질 수 있습니다. 연결 요청이 계속해서 증가하면 스와핑이 증가하여 사이트의 더 많은 사용자에게 영향을 미칠 수 있습니다.
  2. Apache 서버에 연결이 부족할 수 있습니다. 메모리를 절약하기 위해 서버 소프트웨어는 동시 연결 수를 제한할 수 있지만, 이는 메모리 부족과 유사한 효과를 가져옵니다. 사용 가능한 연결이 소진되고 새로운 연결 요청이 대기해야 하며, 사용자는 느린 성능을 경험하게 됩니다. 특히 연결 요청이 백업되는 경우 더욱 그렇습니다.
  3. 애플리케이션 서버는 연결 관리와 애플리케이션 실행으로 인해 CPU 용량이 부족할 수 있으며, 이로 인해 사용자가 대기하고 요청이 백업되는 현상이 발생할 수 있습니다.

HTTP Gateway 리버스 프록시 서버는 이러한 문제를 방지할 수 있습니다. 리버스 프록시 서버는 웹에서 요청을 받아와서 지역 네트워크를 통해 Apache 서버로 전달합니다. Apache 서버는 그런 다음 애플리케이션 코드를 실행하고 필요한 파일을 리버스 프록시 서버로 반환하며, 리버스 프록시 서버는 신속하게 수신을 확인합니다. Apache 서버는 멀리 떨어진 클라이언트로부터의 확인을 기다리는 동안 수천 개의 연결을 유지할 필요가 없으므로 거의 최대 성능으로 실행될 수 있습니다.

NGINX Open Source 및 NGINX Plus는 필요에 따라 다른 기능을 추가하여 이러한 목적으로 매우 널리 사용됩니다(아래 참조). NGINX는 수십만 개의 연결을 동시에 처리할 수 있는 이벤트 기반 아키텍처를 사용하여 느린 인터넷 측 연결을 고속 로컬 트랜잭션으로 변환합니다.

NGINX 3Tier

NGINX Plus를 사용하면, 단계별로 진행되는 선형적인 아키텍처에서 벗어나 성능, 확장성, 관리성을 향상시킬 수 있는 유연한 아키텍처로 전환할 수 있습니다.

NGINX 또는 NGINX Plus를 리버스 프록시로 사용:

  • Apache 서버는 로컬 영역 네트워크를 통해 요청을 수신하고 응답하면서 최고 속도로 실행할 수 있습니다.
  • 정적 파일은 NGINX Plus 서버와 데이터베이스 서버에 대한 부하가 크게 줄어듭니다.
  • 더 많은 Apache 서버를 추가할 수 있으며 NGINX Plus 서버는 그들 간의 로드 밸런싱을 처리합니다(아래 참조).

2. 사이트 콘텐츠 캐시 및 마이크로캐시

객체 캐싱은 여러 가지 이점을 가지고 있습니다. 전형적인 웹 페이지의 대부분 데이터는 이미지 파일 (JPEG, PNG 파일 등), JavaScript 및 CSS와 같은 코드 파일 등의 정적 객체로 이루어져 있습니다. 이러한 파일들을 캐싱하면 성능이 크게 향상될 수 있습니다. 동적으로 생성된 파일을 짧은 시간 동안 캐싱하는 것도 가능하며, 이를 마이크로캐싱이라고 합니다.

정적 파일에 대한 캐싱에는 세 가지 수준이 있습니다:

  • 로컬 캐싱(local caching) – 정적 자산의 로컬 캐싱은 구성 설정과 여러 페이지에서 동일한 자산을 반복해서 사용하여 지원할 수 있습니다. 아래에 NGINX와 NGINX Plus의 샘플 구성 설정을 제공합니다. (조직 및 서비스 제공자의 캐싱으로 인해 일부 로컬 캐싱 형태의 이점을 얻을 수 있습니다.)
  • 콘텐츠 전달 네트워크 (CDN) 캐싱 – CDN은 콘텐츠를 사용자에게 가까운 위치에 배치하고 요청에 빠르게 응답하는 전용 서버에 배치합니다. 그러나 HTTP/2의 영향으로 CDNs의 이점이 줄어들 수 있으므로 최적화에 주의해야 합니다.
  • 캐싱 서버(caching server) – 웹 및 애플리케이션 서버 앞에 캐싱 서버를 배치할 수 있습니다. NGINX는 정적 객체 캐싱과 웹 서버 기능을 결합하며, NGINX Plus는 최적화된 캐싱 및 모니터링 기능을 추가합니다

캐싱의 이점에 대한 대부분의 분석은 빠른 파일 검색에 초점을 맞추고 있습니다. 그러나 모든 형태의 캐싱은 측정하기 어려우나 고성능 웹사이트에 매우 중요한 추가 이점이 있습니다. 바로 웹 및 애플리케이션 서버로부터 트래픽을 얼리는 것으로, 이를 통해 높은 성능을 제공할 수 있으며 과부하로 인한 문제를 방지할 수 있습니다.

다음 코드는 NGINX 또는 NGINX Plus 구성에서 proxy_cache_path 및 proxy_cache 지시문을 사용하는 방법을 보여줍니다. 자세한 내용은 NGINX Plus 관리자 가이드를 참조하고 캐싱 구성에 대한 개요는 NGINX 및 NGINX Plus를 사용한 캐싱 가이드를 참조하세요.

# Define a content cache location on disk
proxy_cache_path /tmp/cache keys_zone=mycache:10m inactive=60m;

server {
    listen 80;
    server_name localhost;
 
    location / {
        proxy_pass http://localhost:8080;
 
        # reference the cache in a location that uses proxy_pass
        proxy_cache mycache;
    }
}

PHP 또는 유사한 서버를 실행하는 아이디어는 모든 사용자에게 최신으로 조합된 콘텐츠를 제공하는 것입니다. 이는 간단하고 매력적인 접근 방식이지만, 트래픽이 급증하고 애플리케이션 서버가 따라가지 못하는 경우에는 문제가 발생할 수 있습니다.

위에서 언급한 마이크로캐싱은 동적으로 생성된 페이지를 매우 짧은 기간 동안(1초로 매우 짧은 경우도 있음) 캐싱하는 것을 의미합니다. 이 형태의 캐싱은 동적으로 생성된 객체를 잠깐의 유용한 정적 객체로 변환합니다. 초당 수십 개 또는 수백 개의 요청이 발생하는 웹 페이지의 경우, 대부분의 요청은 이제 캐시에서 나오며 페이지 신선도에는 최소한의 영향을 미칩니다.

마젠토(Magento)와 같은 다른 PHP 기반 프레임워크도 마이크로캐싱의 이점을 잘 보여주는 좋은 예입니다. 마젠토는 유연하고 강력한 전자상거래용 콘텐츠 관리 시스템으로 널리 사용됩니다. 마젠토는 페이지 조합을 위해 PHP를 실행하는 웹 및 애플리케이션 서버로 구현되며, 콘텐츠에 대한 데이터베이스 서버를 호출합니다. 이러한 구성은 일정 수준까지는 잘 작동하지만, 트래픽이 애플리케이션 서버의 처리 능력을 초과하는 경우에는 문제가 발생할 수 있습니다. 특히 휴일 기간에는 전자상거래 사이트에서 쉽게 발생할 수 있습니다.

과부하를 방지하기 위해 마젠토 애플리케이션 서버 앞에 NGINX 또는 NGINX Plus와 같은 리버스 프록시 서버를 두고, NGINX Plus 서버를 마이크로캐싱에 사용합니다. NGINX Plus 서버를 앞에 두면 마젠토에서의 인터넷 트래픽 처리와 캐싱을 외부로 오프로드하며, 동시에 애플리케이션 서버의 최대 처리 요구를 1~2배 줄입니다. 또한, 여러 개의 애플리케이션 서버로의 확장, 로드 밸런싱, 모니터링 등을 가능하게 하여, 핵심 애플리케이션 로직을 변경하지 않고도 사이트의 확장성을 확보할 수 있게 됩니다.

3. 로드 밸런싱으로 여러 애플리케이션 서버 추가

만약 간단한 웹 서버 아키텍처를 가지고 있다면, 로드 밸런싱을 추가하는 것은 더 유연하고 견고한 시스템으로 만들기 위한 가장 빠른 단계입니다. (NGINX Plus 관리자 가이드에는 로드 밸런싱에 대한 상세한 내용이 포함되어 있습니다.)

로드 밸런싱은 성능 향상을 위한 몇 가지 전제를 가정합니다. 이 전제들은 각각 성능 향상의 통로가 될 수도 있고, 성능 병목 현상을 일으킬 수도 있으므로 명확하게 설명해야 합니다. 다음은 그러한 전제들입니다:

  • 웹 및/또는 애플리케이션 서버 – 리버스 프록시 서버는 하나의 애플리케이션 서버만 있는 경우에도 성능을 개선할 수 있습니다. 인터넷 트래픽을 애플리케이션 서버에서 분산 처리하고, 정적 캐싱을 구현하며, 더 견고한 구성을 위한 첫 번째 구성 요소를 제공합니다. 그러나 더 견고한 구성의 장점은 여러 개의 웹 및/또는 애플리케이션 서버를 사용하고 이들 간에 로드 밸런싱을 수행할 때에만 완전히 실현됩니다.
  • 스마트 로드 밸런싱 전략 – 웹 애플리케이션에 적합한 로드 밸런싱 전략이 필요합니다. “다음 요청은 다음 서버로”라고도 알려진 순환 방식은 좋은 시작점입니다. 그러나 덜 사용되는 서버로 트래픽을 보내거나, 특정 클라이언트를 동일한 세션 동안 동일한 서버로 유지하거나, 처리가 진행되는 동안 모니터링하는 등의 단계는 효과적인 로드 밸런싱 전략의 중요한 요소입니다. (NGINX Plus의 고급 로드 밸런싱 및 모니터링 기능에 대한 자세한 정보를 보려면 클릭하세요.)
  • 자원 확장성과 유연성 – 스마트 로드 밸런싱 전략을 사용하면 트래픽을 거의 자유롭게 라우팅하고, 물리적 서버 또는 클라우드에서 실행 중인 자원을 추가하여 수요의 급증 및 장기적인 증가를 충족할 수 있습니다.
  • 추가 기능의 활용 – 리버스 프록시 서버를 사용하여 콘텐츠 캐싱(위에서 언급한 것처럼), SSL termination, HTTP/2 termination 등과 같은 추가 기능을 지원하는 것은 복잡한 사이트 아키텍처에 대한 투자를 극대화하고 애플리케이션 서버와 인터넷 사이에 중간자를 배치함으로써 발생하는 영향을 최소화하기 위한 중요한 단계입니다.

4. 사용자당 수신 요청 제한

일반적인 웹 페이지에는 핵심 HTML 파일, 이미지 및 코드 파일을 포함하여 100개 이상의 자산이 있을 수 있습니다. 일반적인 브라우저는 사용자 세션당 약 반 다스의 연결을 엽니다. 사용자가 사이트를 신속하게 이동할 경우 작은 규모의 요청 블리자드가 발생할 수 있습니다.

그러나 정상적이고 부정한 비인간 사용자는 실제 방문자보다 훨씬 많은 요청을 생성할 수 있습니다. 번잡한 시기에는 일반 사용자를 위한 사이트 성능을 보존하는 데 특별한 주의가 필요합니다.

검색 엔진의 스파이더는 비인간적이고 리소스 집약적인 사용자의 한 예입니다. 스파이더는 사이트에 과도한 요청을 보내어 일반 사용자의 성능을 늦출 수 있습니다. HTTP 게이트웨이를 사용하여 액세스를 제한하고, 고용량(일반적으로 인간이 아닌) 사용자를 차단할 수 있습니다. 제한 사항에는 IP 주소당 연결 수, 요청률 및 연결당 허용된 다운로드 속도가 포함됩니다. 또한 분산 서비스 거부(Distributed Denial of Service, DDoS) 공격을 방지하기 위해 추가적인 조치를 취할 수도 있습니다.

5. NGINX 성능 극대화 결론

블랙 프라이데이, 사이버 먼데이, 신제품 출시 및 기타 실제 이벤트는 느린 응답 시간과 다운타임으로 이어질 수 있는 약점에 대해 웹 사이트 아키텍처를 검사할 수 있는 기회입니다. 그러나 효과적인 성능 최적화는 지속적인 과정입니다.

목표를 설정하고 아키텍처를 검토한 다음 약점과 취약성을 찾는 것이 중요합니다. NGINX와 NGINX Plus는 웹 사이트 성능 문제를 해결하기 위해 널리 알려진 솔루션으로 다양한 최적화 기술을 제공합니다.

NGINX Plus를 직접 사용해 보시려면 30일 무료 평가판을 신청하거나 NGINX STORE에 연락하여 문의하십시오.

사용 사례에 대해 최신 소식을 빠르게 전달받고 싶으시면 아래 뉴스레터를 구독하세요.