10배의 애플리케이션 성능을 위한 10가지 팁

웹 애플리케이션 성능을 개선하는 것이 그 어느 때보다 중요해졌습니다. 경제 활동에서 온라인이 차지하는 비중은 점점 커지고 있습니다. 현재 선진국 경제의 5% 이상이 인터넷을 통해 이루어지고 있습니다(아래의 인터넷 통계 자료 참조). 항상 연결되어 있고 극도로 연결된 현대 사회에서는 사용자의 기대치가 그 어느 때보다 높아졌습니다. 사이트가 즉각적으로 반응하지 않거나 앱이 지체 없이 작동하지 않으면 사용자는 곧바로 경쟁사로 옮겨갑니다.

예를 들어, Amazon이 약 10년 전에 수행한 연구에 따르면 페이지 로딩 시간이 100밀리초 감소하면 매출이 1% 증가하는 것으로 나타났습니다. 최근 실시된 또 다른 연구에 따르면, 설문 조사에 참여한 사이트 소유자의 절반 이상이 애플리케이션 성능이 좋지 않아 수익이나 고객을 잃었다고 답했습니다.

웹사이트는 얼마나 빨라야 합니까? 페이지가 로드되는 데 걸리는 시간 1초마다 약 4%의 사용자가 해당 페이지를 이탈합니다. 최고의 전자상거래 사이트는 첫 상호작용 시간이 1~3초로 가장 높은 전환율을 제공합니다. 웹 애플리케이션 성능에 대한 위험 요소가 높고 앞으로 더욱 커질 가능성이 크다는 것은 분명합니다.

성과를 개선하고 싶어하는 것은 쉽지만, 실제 결과를 보는 것은 어렵습니다. 여러분의 여정을 돕기 위해 이 블로그 게시물에서는 웹사이트 성능을 최대 10배까지 높이는 데 도움이 되는 10가지 팁을 제공합니다. 이는 잘 테스트된 최적화 기술과 NGINX의 약간의 지원을 통해 애플리케이션 성능을 높이는 방법을 자세히 설명하는 시리즈의 첫 번째입니다. 이 시리즈는 또한 그 과정에서 얻을 수 있는 잠재적인 보안 개선 사항도 설명합니다.

팁 1 – 역방향 프록시 서버를 사용하여 애플리케이션 가속화 및 보안

웹 애플리케이션이 단일 머신에서 실행되는 경우 성능 문제에 대한 해결책은 분명해 보일 수 있습니다. 더 빠른 머신을 구입하고, 더 많은 프로세서, 더 많은 RAM, 빠른 디스크 배열 등을 갖추면 되는 것입니다. 그러면 새로운 머신에서 WordPress 서버, Node.js 애플리케이션, Java 애플리케이션 등을 이전보다 더 빠르게 실행할 수 있습니다. (애플리케이션이 데이터베이스 서버에 접근하는 경우에도 해결책은 간단해 보일 수 있습니다. 더 빠른 머신 두 대를 구입하고 두 머신 간 연결을 더 빠르게 설정하면 됩니다.)

문제는 기계 속도가 문제가 아닐 수도 있다는 것이다. 웹 애플리케이션은 컴퓨터가 여러 가지 작업(예: 수천 개의 연결을 통한 사용자 상호 작용, 디스크에서 파일 액세스, 애플리케이션 코드 실행 등)을 전환하기 때문에 느리게 실행되는 경우가 많습니다. 애플리케이션 서버가 스래싱(Thrashing) 상태일 수 있습니다. 즉, 메모리가 부족해지고, 메모리 청크를 디스크로 스왑하고, 디스크 I/O와 같은 단일 작업을 기다리는 많은 요청을 발생시킬 수 있습니다.

하드웨어를 업그레이드하는 대신 완전히 다른 방법을 사용할 수 있습니다. 즉, 역방향 프록시 서버를 추가하여 이러한 작업 중 일부의 부담을 덜어낼 수 있습니다. 역방향 프록시 서버는 애플리케이션을 실행하는 머신 앞에 위치하여 인터넷 트래픽을 처리합니다. 역방향 프록시 서버만 인터넷에 직접 연결되고, 애플리케이션 서버와의 통신은 빠른 내부 네트워크를 통해 이루어집니다.

역방향 프록시 서버를 사용하면 애플리케이션 서버는 사용자가 웹 앱과 상호작용할 때까지 기다릴 필요가 없고, 역방향 프록시 서버가 인터넷을 통해 전송할 페이지를 작성하는 데 집중할 수 있습니다. 더 이상 클라이언트 응답을 기다릴 필요가 없는 애플리케이션 서버는 최적화된 벤치마크에서 달성한 속도에 가까운 속도로 실행될 수 있습니다.

역방향 프록시 서버를 추가하면 웹 서버 설정의 유연성도 향상됩니다. 예를 들어, 특정 유형의 서버가 과부하 상태이면 같은 유형의 다른 서버를 쉽게 추가할 수 있으며, 서버가 다운되면 쉽게 교체할 수 있습니다.

유연성을 제공하기 때문에 역방향 프록시 서버는 다음과 같은 여러 다른 성능 향상 기능에도 필수적입니다.

• 부하 분산 ( 팁 2 참조) – 부하 분산 장치는 역방향 프록시 서버에서 실행되어 트래픽을 여러 애플리케이션 서버에 균등하게 공유합니다. 로드 밸런서를 설치하면 애플리케이션을 전혀 변경하지 않고도 애플리케이션 서버를 추가할 수 있습니다.
• 정적 파일 캐싱 ( 팁 3 참조) – 이미지 파일이나 코드 파일과 같이 직접 요청된 파일은 역방향 프록시 서버에 저장하여 클라이언트로 직접 전송할 수 있습니다. 이를 통해 자산을 더 빠르게 제공하고 애플리케이션 서버의 부하를 줄여 애플리케이션을 더 빠르게 실행할 수 있습니다.
• 사이트 보안 – 역방향 프록시 서버는 높은 보안을 위해 구성될 수 있으며 공격을 빠르게 인식하고 대응하도록 모니터링하여 애플리케이션 서버를 보호할 수 있습니다.

NGINX 소프트웨어는 위에 설명된 추가 기능을 갖추고 역방향 프록시 서버로 사용하도록 특별히 설계되었습니다. NGINX는 기존 서버보다 효율적인 이벤트 기반 처리 방식을 사용합니다. NGINX Plus는 애플리케이션 상태 점검 , 특수 요청 라우팅, 고급 캐싱 및 지원과 같은 고급 역방향 프록시 기능을 추가합니다.

팁 2 – 로드 밸런서 추가

로드 밸런서를 추가하는 것은 비교적 쉽게 변경할 수 있으며, 사이트의 성능과 보안을 획기적으로 개선할 수 있습니다. 핵심 웹 서버를 더 크고 강력하게 만드는 대신, 로드 밸런서를 사용하여 트래픽을 여러 서버에 분산합니다. 애플리케이션이 제대로 작성되지 않았거나 확장에 문제가 있는 경우에도 로드 밸런서는 다른 변경 없이도 사용자 경험을 개선할 수 있습니다.

부하 분산 장치는 첫째, 역방향 프록시 서버입니다( 팁 1 참조). 즉, 인터넷 트래픽을 수신하고 다른 서버로 요청을 전달합니다. 비결은 로드 밸런서가 두 개 이상의 애플리케이션 서버를 지원하고 다양한 알고리즘을 사용하여 서버 간의 요청을 분할한다는 것입니다. 가장 간단한 부하 분산 방식은 라운드 로빈 방식으로, 각각의 새로운 요청은 목록에 있는 다음 서버로 전송됩니다. 다른 방법으로는 활성 연결이 가장 적은 서버에 요청을 보내는 방법이 있습니다. NGINX Plus는 동일한 서버에서 주어진 사용자 세션을 지속시키는 기능을 갖추고 있는데, 이를 세션 지속성이라고 합니다.

로드 밸런서는 다른 서버가 트래픽을 기다리는 동안 한 서버에 과부하가 걸리는 것을 방지하므로 성능을 크게 향상시킬 수 있습니다. 또한 비교적 저렴한 서버를 추가하고 최대한 활용할 수 있으므로 웹 서버 용량을 쉽게 확장할 수 있습니다.

부하를 분산할 수 있는 프로토콜로는 HTTP, HTTPS, SPDY, HTTP/2, WebSocket, FastCGI , SCGI, uwsgi, memcached 및 TCP 기반 애플리케이션과 기타 레이어 4 프로토콜을 비롯한 여러 애플리케이션 유형이 있습니다. 웹 애플리케이션을 분석하여 어떤 애플리케이션을 사용하고 어디에서 성능이 떨어지는지 확인하세요.

부하 분산에 사용되는 서버는 SSL 종료, 클라이언트에 의한 HTTP/ 1.x 및 HTTP/2 사용 지원, 정적 파일 캐싱 등 여러 다른 작업도 처리할 수 있습니다.

NGINX는 종종 부하 분산에 사용됩니다. 자세한 내용을 알아보려면 '소프트웨어 로드 밸런서를 선택해야 하는 5가지 이유' 전자책을 다운로드하세요. NGINX 및 NGINX Plus를 사용한 부하 분산, 1부에서 기본 구성 지침을 확인할 수 있으며, NGINX Plus 관리자 가이드 에서 전체 문서를 확인할 수 있습니다. NGINX Plus는 당사의 상용 제품으로서 서버 응답 시간에 따른 부하 라우팅 및 Microsoft의 NTLM 프로토콜에서 부하를 분산하는 기능과 같은 더욱 특수화된 부하 분산 기능을 지원합니다.

팁 3 – 정적 및 동적 콘텐츠 캐시

캐싱은 클라이언트에 콘텐츠를 더 빠르게 전달하여 웹 애플리케이션 성능을 향상시킵니다. 캐싱에는 여러 가지 전략이 포함될 수 있습니다. 필요할 때 빠르게 전달하기 위해 콘텐츠를 사전 처리하거나, 더 빠른 장치에 콘텐츠를 저장하거나, 클라이언트에 더 가깝게 콘텐츠를 저장하거나, 이러한 전략을 결합하는 것입니다.

고려해야 할 캐싱에는 두 가지 유형이 있습니다.

• 정적 콘텐츠 캐싱 – 이미지 파일(JPEG, PNG) 및 코드 파일(CSS, JavaScript)과 같이 자주 변경되지 않는 파일은 에지 서버에 저장하여 메모리나 디스크에서 빠르게 검색할 수 있습니다.
• 동적 콘텐츠 캐싱 – 많은 웹 애플리케이션은 각 페이지 요청에 대해 새로운 HTML을 생성합니다. 생성된 HTML의 사본 하나를 짧은 시간 동안 캐싱하면 요구 사항을 충족할 만큼 최신 콘텐츠를 제공하면서도 생성해야 하는 총 페이지 수를 획기적으로 줄일 수 있습니다.

예를 들어, 페이지가 초당 10번 조회되고 1초 동안 캐시하면 해당 페이지에 대한 요청의 90%가 캐시에서 유입됩니다. 정적 콘텐츠를 별도로 캐시하는 경우, 새로 생성된 페이지 버전도 대부분 캐시된 콘텐츠로 구성될 수 있습니다.

웹 애플리케이션에서 생성된 콘텐츠를 캐싱하는 데에는 세 가지 주요 기술이 있습니다.

• 콘텐츠를 사용자에게 더 가깝게 이동 - 콘텐츠 사본을 사용자에게 더 가깝게 보관하면 전송 시간이 줄어듭니다.
• 더 빠른 기계로 콘텐츠 이동 – 더 빠른 검색을 위해 더 빠른 기계에 콘텐츠를 보관할 수 있습니다.
• 과도하게 사용되는 기계에서 콘텐츠를 옮기는 것 – 기계는 다른 작업으로 바쁘기 때문에 특정 작업에서 벤치마크 성능보다 훨씬 느리게 작동하는 경우가 있습니다. 다른 컴퓨터에 캐싱하면 캐시된 리소스뿐만 아니라 캐시되지 않은 리소스의 성능도 향상됩니다. 호스트 컴퓨터에 과부하가 덜 걸리기 때문입니다.

웹 애플리케이션의 캐싱은 웹 애플리케이션 서버 내부에서 외부로 구현될 수 있습니다. 첫째, 캐싱은 애플리케이션 서버의 부하를 줄이기 위해 동적 콘텐츠에 사용됩니다. 그런 다음, 정적 콘텐츠(그렇지 않으면 동적 콘텐츠가 될 콘텐츠의 임시 사본 포함)에 캐싱을 사용하여 애플리케이션 서버의 부하를 더욱 줄입니다. 캐싱은 애플리케이션 서버에서 사용자와 더 가깝고 더 빠른 머신으로 옮겨져, 애플리케이션 서버의 부담을 줄이고 검색 및 전송 시간을 단축합니다.

캐싱 기능을 개선하면 애플리케이션 속도가 엄청나게 향상될 수 있습니다. 많은 웹 페이지에서는 대용량 이미지 파일 등의 정적 데이터가 콘텐츠의 절반 이상을 차지합니다. 캐싱하지 않고 이런 데이터를 검색하고 전송하는 데는 몇 초가 걸릴 수 있지만, 데이터가 로컬에 캐싱되어 있으면 몇 분의 1초밖에 걸리지 않습니다.

캐싱이 실제로 어떻게 사용되는지에 대한 예로, NGINX와 NGINX Plus는 캐싱을 설정하기 위해 proxy_cache_path 및 proxy_cache 라는 두 가지 지시어를 사용합니다. 캐시 위치와 크기, 파일이 캐시에 보관되는 최대 시간 및 기타 매개변수를 지정합니다. 세 번째 (꽤 인기 있는) 지시어인 proxy_cache_use_stale을 사용하면 새로운 콘텐츠를 제공하는 서버가 바쁘거나 다운되었을 때 캐시가 오래된 콘텐츠를 제공하도록 지시하여 클라이언트에 아무것도 제공하지 않는 것보다는 무언가를 제공할 수 있습니다. 사용자 관점에서 보면 이는 사이트나 애플리케이션의 가동 시간을 크게 향상할 수 있습니다.

NGINX Plus는 캐시 정리 지원, 실시간 활동 모니터링을 위한 대시 보드 에서 캐시 상태 시각화 등 고급 캐싱 기능을 갖추고 있습니다.

NGINX를 사용한 캐싱에 대한 자세한 내용은 참조 문서 및 NGINX Plus 관리자 가이드를 참조하세요.

메모 : 캐싱은 애플리케이션을 개발하는 사람, 자본 투자 결정을 내리는 사람, 실시간으로 네트워크를 운영하는 사람 간의 조직적 경계를 넘나듭니다. 여기에 언급된 것과 같은 정교한 캐싱 전략은 DevOps 관점 의 가치를 잘 보여주는 예입니다. 여기서 애플리케이션 개발자, 아키텍처 및 운영 관점이 통합되어 사이트 기능, 응답 시간, 보안 및 비즈니스 결과(완료된 거래나 판매 등)에 대한 목표를 달성하는 데 도움이 됩니다.

팁 4 – 데이터 압축

압축은 성능을 크게 가속화할 수 있는 잠재력을 가지고 있습니다. 사진(JPEG 및 PNG), 비디오(MPEG‑4), 음악(MP3) 등을 포함하여 주의 깊게 설계되고 매우 효과적인 압축 표준이 있습니다. 이러한 각 표준은 파일 크기를 10배 이상 줄여줍니다.

HTML(일반 텍스트와 HTML 태그 포함), CSS, JavaScript와 같은 코드를 포함한 텍스트 데이터는 종종 압축되지 않은 상태로 전송됩니다. 이 데이터를 압축하면 웹 애플리케이션 성능에 비해 엄청난 영향을 끼칠 수 있으며, 특히 모바일 연결 속도가 느리거나 제한적인 클라이언트의 경우 더 그렇습니다.

그 이유는 텍스트 데이터만으로도 사용자가 페이지와 상호 작용하기에 충분한 반면, 멀티미디어 데이터는 보다 보조적이거나 장식적일 수 있기 때문입니다. 스마트 콘텐츠 압축은 HTML, Javascript, CSS 및 기타 텍스트 기반 콘텐츠의 대역폭 요구 사항을 일반적으로 30% 이상 줄일 수 있으며, 이에 따라 로드 시간도 단축됩니다.

SSL을 사용하면 압축으로 인해 SSL로 인코딩해야 하는 데이터 양이 줄어들어 데이터를 압축하는 데 걸리는 CPU 시간이 일부 상쇄됩니다.

텍스트 데이터를 압축하는 방법은 다양합니다. 예를 들어, SPDY와 HTTP/2의 새로운 텍스트 압축 방식에 대해서는 팁 6을 참조하세요. 이 방식은 헤더 데이터에 맞게 특별히 적용되었습니다. 텍스트 압축의 또 다른 예로 NGINX에서 GZIP 압축을 켤 수 있습니다. 서비스에서 텍스트 데이터를 사전 압축한 후 gzip_static 지시문을 사용하여 압축된 .gz 파일을 직접 제공할 수 있습니다.

팁 5 – SSL/TLS 최적화

SSL (Secure Sockets Layer) 프로토콜과 그 후속 프로토콜인 TLS(Transport Layer Security) 프로토콜은 점점 더 많은 웹사이트에서 사용되고 있습니다. SSL/TLS는 사이트 보안을 강화하기 위해 원본 서버에서 사용자에게 전송되는 데이터를 암호화합니다. 이러한 추세에 영향을 미치는 요소 중 하나는 Google이 SSL/TLS의 존재를 검색 엔진 순위에 긍정적인 영향을 미치는 요소로 활용하고 있다는 것입니다.

인기가 높아지고 있음에도 불구하고, SSL/TLS와 관련된 성능 저하는 많은 사이트에서 난제로 남아 있습니다. SSL/TLS는 두 가지 이유로 웹사이트 성능을 저하시킵니다.

1. 새로운 연결이 열릴 때마다 암호화 키를 설정하는 데 필요한 초기 핸드셰이크입니다. HTTP/ 1.x를 사용하는 브라우저가 서버당 여러 개의 연결을 설정하는 방식이 해당 히트를 배가시킵니다.
2. 서버에서 데이터를 암호화하고 클라이언트에서 암호를 해독하는 데 따른 지속적인 오버헤드.

SSL/TLS 사용을 장려하기 위해 HTTP/2와 SPDY의 작성자( 다음 팁 에서 설명)는 브라우저에 브라우저 세션당 하나의 연결만 필요하도록 이러한 프로토콜을 설계했습니다. 이를 통해 SSL 오버헤드의 두 가지 주요 원인 중 하나를 크게 줄일 수 있습니다. 하지만 오늘날에는 SSL/TLS를 통해 제공되는 애플리케이션의 성능을 개선하기 위해 훨씬 더 많은 작업을 수행할 수 있습니다.

SSL/TLS를 최적화하는 메커니즘은 웹 서버마다 다릅니다. 예를 들어 NGINX는 표준 상용 하드웨어에서 실행되는 OpenSSL을 사용하여 전용 하드웨어 솔루션과 유사한 성능을 제공합니다. NGINX SSL 성능은 잘 문서화되어 있으며 SSL/TLS 암호화 및 복호화를 수행하는 데 드는 시간과 CPU 패널티를 최소화합니다.

또한, SSL/TLS 성능을 높이는 방법에 대한 자세한 내용은 이 블로그 게시물을 참조하세요. 간단히 요약하면, 기술은 다음과 같습니다.

• 세션 캐싱 – ssl_session_cache 지시어를 사용하여 SSL/TLS로 각각의 새로운 연결을 보호하는 데 사용되는 매개변수를 캐시합니다.
• 세션 티켓 또는 ID – 이는 티켓이나 ID에 특정 SSL/TLS 세션에 대한 정보를 저장하므로 새로운 핸드셰이킹 없이도 연결을 원활하게 재사용할 수 있습니다.
• OCSP 스테이플링 – SSL/TLS 인증서 정보를 캐싱하여 핸드셰이킹 시간을 단축합니다.

NGINX와 NGINX Plus는 SSL/TLS 종료에 사용할 수 있습니다. 즉, 클라이언트 트래픽에 대한 암호화와 복호화를 처리하는 동시에 다른 서버와는 일반 텍스트로 통신할 수 있습니다. SSL/TLS 종료를 처리하기 위해 NGINX 또는 NGINX Plus를 설정하려면 HTTPS 연결 및 암호화된 TCP 연결 에 대한 지침을 참조하세요.

팁 6 – HTTP/2 또는 SPDY 구현

이미 SSL/TLS를 사용하는 사이트의 경우 HTTP/2와 SPDY를 적용하면 성능이 크게 향상될 가능성이 높습니다. 단일 연결에 핸드셰이크가 한 번만 필요하기 때문입니다. 아직 SSL/TLS를 사용하지 않는 사이트의 경우 HTTP/2와 SPDY를 사용하면 일반적으로 성능이 저하되는 SSL/TLS로 전환해도 반응성 측면에서 아무런 문제가 없습니다.

Google은 2012년에 HTTP/ 1.x 상에서 더 빠른 성능을 달성하는 방법으로 SPDY를 도입했습니다. HTTP/2는 SPDY를 기반으로 하는 최근 승인된 IETF 표준입니다. SPDY는 광범위하게 지원되지만 곧 사용이 중단되고 HTTP/2로 대체될 예정입니다.

SPDY와 HTTP/2의 주요 특징은 여러 연결이 아닌 단일 연결을 사용한다는 것입니다. 단일 연결은 다중화되어 있으므로 여러 요청과 응답의 일부를 동시에 전달할 수 있습니다.

이러한 프로토콜은 하나의 연결에서 최대한의 이점을 얻음으로써 브라우저가 HTTP/ 1.x 를 구현하는 방식에서 요구되는 여러 연결을 설정하고 관리하는 오버헤드를 방지합니다. 단일 연결을 사용하면 SSL을 사용하는 데 특히 유용합니다. SSL/TLS가 보안 연결을 설정하는 데 필요한 시간 소모적인 핸드셰이킹을 최소화할 수 있기 때문입니다.

SPDY 프로토콜은 SSL/TLS를 사용해야 하지만 HTTP/2에서는 공식적으로 요구하지 않지만, 지금까지 HTTP/2를 지원하는 모든 브라우저는 SSL/TLS가 활성화된 경우에만 이를 사용합니다. 즉, HTTP/2를 지원하는 브라우저는 해당 웹사이트가 SSL을 사용하고 해당 서버가 HTTP/2 트래픽을 허용하는 경우에만 이를 사용합니다. 그렇지 않으면 브라우저는 HTTP/ 1.x 를 통해 통신합니다.

SPDY 또는 HTTP/2를 구현하면 도메인 샤딩, 리소스 병합, 이미지 스프라이팅과 같은 일반적인 HTTP 성능 최적화가 더 이상 필요하지 않습니다. 이러한 변경으로 코드와 배포가 더 간편해지고 관리하기 쉬워집니다. HTTP/2가 가져오는 변화에 대해 자세히 알아보려면 웹 애플리케이션 개발자를 위한 HTTP/2 백서를 읽어보세요.

이러한 프로토콜에 대한 지원의 예로, NGINX는 일찍부터 SPDY를 지원했으며, 오늘날 SPDY를 사용하는 대부분의 사이트는 NGINX에서 실행됩니다. NGINX는 또한 HTTP/2에 대한 지원을 개척하고 있으며, 2015년 9월부터 NGINX 오픈 소스와 NGINX Plus에서 HTTP/2를 지원합니다 .

NGINX에서는 시간이 지남에 따라 대부분 사이트가 SSL을 완전히 활성화하고 HTTP/2로 전환할 것으로 예상합니다. 이를 통해 보안이 강화되고, 새로운 최적화 방법이 발견되어 구현됨에 따라 더 간소하고 성능이 더 뛰어난 코드가 탄생합니다.

팁 7 – 소프트웨어 버전 업데이트

애플리케이션 성능을 높이는 간단한 방법 중 하나는 안정성과 성능에 대한 평판을 바탕으로 소프트웨어 스택의 구성 요소를 선택하는 것입니다. 또한, 고품질 구성요소의 개발자는 시간이 지남에 따라 성능 향상을 추구하고 버그를 수정할 가능성이 높으므로 최신 안정적인 소프트웨어 버전을 사용하는 것이 좋습니다. 새로 출시되는 제품은 개발자와 사용자 커뮤니티로부터 더 많은 관심을 받습니다. 최신 빌드는 새로운 하드웨어에 맞춰 조정하는 것을 포함하여 새로운 컴파일러 최적화도 활용합니다.

안정적인 새 릴리스는 일반적으로 이전 릴리스보다 호환성이 뛰어나고 성능이 더 좋습니다. 소프트웨어 업데이트를 최신 상태로 유지하면 튜닝 최적화, 버그 수정 및 보안 알림을 최신 상태로 유지하는 것도 더 쉽습니다.

오래된 소프트웨어를 계속 사용하면 새로운 기능을 활용하지 못할 수도 있습니다. 예를 들어, 위에서 설명한 HTTP/2에는 현재 OpenSSL 1.0.1이 필요합니다. 2016년 중반부터 HTTP/2에는 2015년 1월에 출시된 OpenSSL 1.0.2가 필요합니다.

NGINX 사용자는 최신 버전의 NGINX 또는 NGINX Plus 로 이동하여 시작할 수 있습니다. 이 버전에는 소켓 샤딩 및 스레드 풀과 같은 새로운 기능이 포함되어 있으며( 팁 9 참조) 두 기능 모두 성능을 위해 지속적으로 조정되고 있습니다. 그런 다음 스택의 깊숙한 곳에 있는 소프트웨어를 살펴보고 가능한 한 최신 버전으로 이동하세요.

팁 8 – 성능을 위한 Linux 조정

Linux는 오늘날 대부분의 웹 서버 구현에 사용되는 기본 운영 체제이며, 인프라의 기반으로서 Linux는 성능을 향상시킬 수 있는 중요한 기회를 제공합니다. 기본적으로 많은 Linux 시스템은 적은 리소스를 사용하고 일반적인 데스크톱 작업 부하에 맞게 보수적으로 조정됩니다. 즉, 최대 성능을 위해 웹 애플리케이션 사용 사례에는 최소한 어느 정도의 조정이 필요하다는 의미입니다.

Linux 최적화는 웹 서버에 따라 다릅니다. NGINX를 예로 들면 Linux 속도를 높이기 위해 고려할 수 있는 몇 가지 변경 사항은 다음과 같습니다.

• 백로그 큐 - 연결이 멈추는 것처럼 보이는 경우 NGINX에서 주의를 기다리며 큐에 넣을 수 있는 최대 연결 수인 net.core.somaxconn을 늘리는 것을 고려하세요. 기존 연결 제한이 너무 작으면 오류 메시지가 표시되고 오류 메시지가 멈출 때까지 이 매개변수를 점진적으로 늘릴 수 있습니다.
• 파일 설명자 – NGINX는 각 연결에 대해 최대 두 개의 파일 설명자를 사용합니다. 시스템이 많은 연결을 처리하는 경우 파일 설명자에 대한 시스템 전체 제한인 sys.fs.file_max 와 사용자 파일 설명자 제한인 nofile을 늘려서 증가된 부하를 지원해야 할 수도 있습니다.
• 임시 포트 – 프록시로 사용되는 경우 NGINX는 각 업스트림 서버에 대해 임시("임시") 포트를 생성합니다. net.ipv4.ip_local_port_range 로 설정된 포트 값의 범위를 늘려 사용 가능한 포트 수를 늘릴 수 있습니다. net.ipv4.tcp_fin_timeout 설정을 사용하면 비활성 포트가 재사용되기 전의 시간 초과를 줄여 더 빠른 교체가 가능합니다.

NGINX의 경우 NGINX 성능 튜닝 가이드를 확인하여 Linux 시스템이 땀 한 방울 흘리지 않고도 대량의 네트워크 트래픽을 처리할 수 있도록 최적화하는 방법을 알아보세요!

팁 9 – 성능을 위해 웹 서버 조정

어떤 웹 서버를 사용하든 웹 애플리케이션 성능을 위해 웹 서버를 조정해야 합니다. 다음 권장 사항은 일반적으로 모든 웹 서버에 적용되지만 NGINX에 대한 특정 설정이 제공됩니다. 주요 최적화는 다음과 같습니다.

• 액세스 로깅 – 모든 요청에 대한 로그 항목을 즉시 디스크에 쓰는 대신, 메모리에 항목을 버퍼링하고 이를 그룹으로 디스크에 쓸 수 있습니다. NGINX의 경우 메모리 버퍼가 가득 찰 때 로그 항목을 디스크에 기록하려면 access_log 지시문에 buffer= size 매개변수를 추가합니다. flush= time 매개변수를 추가하면, 버퍼 내용도 지정된 시간이 지난 후에 디스크에 기록됩니다.
• 버퍼링 – 버퍼링은 버퍼가 채워질 때까지 응답의 일부를 메모리에 보관하므로 클라이언트와의 통신을 더 효율적으로 만들 수 있습니다. 메모리에 맞지 않는 응답은 디스크에 기록되므로 성능이 저하될 수 있습니다. NGINX 버퍼링이 켜져 있으면 proxy_buffer_size 및 proxy_buffers 지침을 사용하여 버퍼링을 관리합니다.
• 클라이언트 keepalives – keepalive 연결은 특히 SSL/TLS를 사용 중일 때 오버헤드를 줄여줍니다. NGINX의 경우 클라이언트가 지정된 연결에 대해 만들 수 있는 keepalive_requests 의 최대 수를 기본값인 100에서 늘릴 수 있으며 keepalive_timeout 을 늘려 keepalive 연결을 더 오랫동안 열어 둘 수 있으며, 그 결과 후속 요청이 더 빠르게 처리됩니다.
• 업스트림 keepalives – 업스트림 연결(애플리케이션 서버, 데이터베이스 서버 등에 대한 연결)도 keepalive 연결의 이점을 얻습니다. 업스트림 연결의 경우 각 작업자 프로세스에 대해 열려 있는 유휴 keepalive 연결 수인 keepalive를 늘릴 수 있습니다. 이를 통해 연결 재사용성이 늘어나 새로운 연결을 열 필요성이 줄어듭니다. 자세한 내용은 블로그 게시물 ' HTTP Keepalive 연결 및 웹 성능'을 참조하세요.
• 제한 – 클라이언트가 사용하는 리소스를 제한하면 성능과 보안을 향상할 수 있습니다. NGINX의 경우 limit_conn 및 limit_conn_zone 지시어는 지정된 소스에서의 연결 수를 제한하는 반면, limit_rate는 대역폭을 제한합니다. 이러한 설정은 합법적인 사용자가 리소스를 "독점"하는 것을 막고 공격을 예방하는 데에도 도움이 됩니다. limit_req 및 limit_req_zone 지시어는 클라이언트 요청을 제한합니다. 업스트림 서버에 연결하는 경우 업스트림 구성 블록의 server 지시문에 max_conns 매개변수를 사용합니다. 이렇게 하면 업스트림 서버에 대한 연결이 제한되어 과부하가 방지됩니다. 연관된 대기열 지시문은 max_conns 한도에 도달한 후 지정된 시간 동안 지정된 수의 요청을 보관하는 대기열을 생성합니다.
• 작업자 프로세스 - 작업자 프로세스는 요청 처리를 담당합니다. NGINX는 이벤트 기반 모델과 OS 종속 메커니즘을 사용하여 작업자 프로세스 간에 요청을 효율적으로 분산합니다. 권장사항은 worker_processes 값을 CPU당 하나로 설정하는 것입니다. 대부분의 시스템에서는 필요한 경우 최대 worker_connections 수(기본값 512)를 안전하게 늘릴 수 있습니다. 시스템에 가장 적합한 값을 찾으려면 실험을 하세요.
• 소켓 샤딩 - 일반적으로 단일 소켓 리스너가 모든 작업자 프로세스에 새로운 연결을 분산합니다. 소켓 샤딩은 각 작업자 프로세스에 대한 소켓 리스너를 생성하고, 커널은 소켓 리스너에 연결이 사용 가능해지면 해당 연결을 할당합니다. 이를 통해 잠금 경합이 줄어들고 멀티코어 시스템의 성능이 향상될 수 있습니다. 소켓 샤딩을 활성화하려면 listen 지시문에 reuseport 매개변수를 포함하세요.
• 스레드 풀 – 모든 컴퓨터 프로세스는 단일의 느린 작업으로 인해 지연될 수 있습니다. 웹 서버 소프트웨어의 경우 디스크 액세스로 인해 메모리에 있는 정보를 계산하거나 복사하는 등 더 빠른 작업이 지연될 수 있습니다. 스레드 풀을 사용하면 느린 작업은 별도의 작업 세트에 할당되고, 기본 처리 루프는 더 빠른 작업을 계속 실행합니다. 디스크 작업이 완료되면 결과는 주 처리 루프로 돌아갑니다. NGINX에서는 read() 시스템 호출과 sendfile() 의 두 가지 작업이 스레드 풀로 오프로드됩니다.

팁 . 운영 체제나 지원 서비스에 대한 설정을 변경할 때는 한 번에 하나씩 설정을 변경한 다음 성능을 테스트하세요. 변경으로 인해 문제가 발생하거나, 사이트 속도가 향상되지 않는 경우 원래대로 변경하세요.

NGINX 웹 서버 튜닝에 대한 자세한 내용은 블로그 게시물 ' 성능을 위한 NGINX 튜닝'을 참조하세요.

팁 10 – 문제 및 병목 현상을 해결하기 위해 라이브 활동 모니터링

고성능 애플리케이션 개발 및 제공 접근 방식의 핵심은 애플리케이션의 실제 성능을 실시간으로 면밀히 관찰하는 것입니다. 특정 장치와 웹 인프라 전반의 활동을 모니터링할 수 있어야 합니다.

사이트 활동 모니터링은 대부분 수동적입니다. 즉, 무슨 일이 일어나고 있는지 알려주고 문제를 발견하고 해결하는 일은 사용자에게 맡겨집니다.

모니터링을 통해 여러 가지 종류의 문제를 포착할 수 있습니다. 여기에는 다음이 포함됩니다.

• 서버가 다운되었습니다.
• 서버가 제대로 작동하지 않아 연결이 끊어집니다.
• 서버는 캐시 미스 비율이 높은 상태입니다.
• 서버가 올바른 콘텐츠를 전송하지 않습니다.

New Relic이나 Dynatrace와 같은 글로벌 애플리케이션 성능 모니터링 도구를 사용하면 원격 위치에서 페이지 로드 시간을 모니터링할 수 있고, NGINX를 사용하면 애플리케이션 전송 측면을 모니터링할 수 있습니다. 애플리케이션 성능 데이터를 통해 최적화가 사용자에게 실질적인 변화를 가져다주는지, 그리고 트래픽을 유지하기 위해 인프라에 용량을 추가해야 하는 시점을 알 수 있습니다.

문제를 빠르게 식별하고 해결하는 데 도움이 되도록 NGINX Plus는 애플리케이션 인식 상태 검사를 추가합니다. 이는 정기적으로 반복되고 문제에 대한 경고를 위해 사용되는 합성 트랜잭션입니다. NGINX Plus에는 기존 작업이 완료되는 동안 새로운 연결을 중단하는 세션 드레이닝 기능과, 로드 밸런싱된 그룹 내에서 복구된 서버가 속도에 맞춰 돌아올 수 있게 하는 슬로우 스타트 기능이 있습니다. 상태 점검을 효과적으로 사용하면 문제가 사용자 경험에 큰 영향을 미치기 전에 이를 식별할 수 있으며, 세션 드레이닝과 슬로우 스타트를 통해 서버를 교체하고 프로세스가 성능이나 가동 시간에 부정적인 영향을 미치지 않도록 할 수 있습니다. 그림은 서버, TCP 연결 및 캐싱을 갖춘 웹 인프라에 대한 내장 NGINX Plus 라이브 활동 모니터링 대시 보드를 보여줍니다.

결론 - 10배의 성능 향상을 확인

각 웹 애플리케이션에서 얻을 수 있는 성능 개선 사항은 엄청나게 다르며, 실제 이득은 예산, 투자할 수 있는 시간, 기존 구현의 차이점에 따라 달라집니다. 그러면 어떻게 하면 자신의 애플리케이션 성능을 10배 향상시킬 수 있을까요?

각 최적화의 잠재적 영향에 대한 안내를 돕기 위해 위에서 자세히 설명한 각 팁으로 가능한 개선 사항에 대한 포인터를 제공합니다. 그러나 마일리지는 거의 확실히 다를 것입니다.

• 역방향 프록시 서버 및 로드 밸런싱 – 로드 밸런싱이 없거나 로드 밸런싱이 제대로 이루어지지 않으면 성능이 매우 저하되는 상황이 발생할 수 있습니다. NGINX와 같은 역방향 프록시 서버를 추가하면 웹 애플리케이션이 메모리와 디스크 사이에서 맴도는 현상을 방지할 수 있습니다. 로드 밸런싱을 통해 과부하된 서버에서 사용 가능한 서버로 처리를 옮기고 확장을 쉽게 할 수 있습니다. 이러한 변경 사항을 통해 극적인 성능 향상이 가능하며, 현재 구현에서 가장 나쁜 순간과 비교했을 때 10배의 성능 향상을 쉽게 달성할 수 있고, 전반적인 성능에서는 규모는 작지만 상당한 성과를 달성할 수 있습니다.
• 동적 및 정적 콘텐츠 캐싱 – 애플리케이션 서버를 겸하는 과부하된 웹 서버가 있는 경우, 동적 콘텐츠만 캐싱함으로써 피크 타임 성능을 10배 향상시킬 수 있습니다. 정적 파일을 캐싱하면 성능을 한 자릿수 배수로 향상시킬 수도 있습니다.
• 데이터 압축 – 사진의 경우 JPEG, 그래픽의 경우 PNG, 영화의 경우 MPEG‑4, 음악 파일의 경우 MP3와 같은 미디어 파일 압축을 사용하면 성능을 크게 향상시킬 수 있습니다. 이러한 모든 요소를 활용하면 텍스트 데이터(코드와 HTML)를 압축하여 초기 페이지 로드 시간을 두 배로 단축할 수 있습니다.
• SSL/TLS 최적화 - 보안 핸드셰이크는 성능에 큰 영향을 미칠 수 있으므로 이를 최적화하면 특히 텍스트가 많은 사이트의 경우 초기 응답성이 약 2배 향상될 수 있습니다. SSL/TLS에서 미디어 파일 전송을 최적화해도 성능 향상 효과는 미미할 것으로 보입니다.
• HTTP/2 및 SPDY 구현 – SSL/TLS와 함께 사용하면 이러한 프로토콜을 통해 전체 사이트 성능이 점진적으로 향상될 가능성이 높습니다.
• Linux 및 웹 서버 소프트웨어(예: NGINX) 조정 – 버퍼링 최적화, Keepalive 연결 사용, 시간 소모적인 작업을 별도의 스레드 풀로 오프로드하는 것과 같은 수정 사항을 통해 성능을 크게 향상시킬 수 있습니다. 예를 들어, 스레드 풀은 디스크 소모적인 작업의 속도를 거의 10배 까지 높일 수 있습니다.

여러분께서 직접 이러한 기술을 시도해 보시기 바랍니다. 귀하가 어떤 종류의 애플리케이션 성능 개선을 달성할 수 있는지 알려 주시기 바랍니다. 아래의 댓글란에 여러분의 결과를 공유하거나, 해시태그 #NGINX 및 #webperf와 함께 여러분의 이야기를 트윗하세요!

인터넷 통계를 위한 리소스

Statista.com – 2016년 G-20 국가의 국내총생산(GDP)에서 인터넷 경제가 차지하는 비중

Kissmetrics – 로딩 시간이 최종 수익에 미치는 영향(인포그래픽)

Econsultancy – 사이트 속도: 전환율 개선을 위한 사례 연구, 팁 및 도구