웹 애플리케이션 성능 개선이 그 어느 때보다 중요해졌습니다.
선진국 경제의 5% 이상이 인터넷을 통해 이루어지고 있을 정도로
온라인 경제 활동의 비중이 점점 커지고 있습니다
(아래의 인터넷 통계 리소스 참조).
또한 상시 접속이 가능하고 초연결된 현대 사회에서는 사용자의 기대치가 그 어느 때보다 높습니다.
사이트가 즉각적으로 응답하지 않거나 앱이 지연 없이 작동하지 않으면 사용자는 빠르게 경쟁업체로 이동합니다.
예를 들어, 거의 10년 전에 Amazon에서 실시한 연구에 따르면 당시에도
페이지 로딩 시간이 100밀리초 단축되면 매출이 1% 증가했습니다.
최근의 또 다른 연구에서는 설문조사에 참여한 사이트 소유자의 절반 이상이 애플리케이션 성능 저하로 인해
매출이나 고객을 잃었다고 답한 사실을 강조했습니다.
웹사이트는 얼마나 빨라야 할까요? 페이지가 로드되는 데 1초가 걸릴 때마다 약 4%의 사용자가 페이지를 이탈합니다.
상위 이커머스 사이트의 첫 번째 상호 작용 시간은 1~3초로, 전환율이 가장 높은 시간대입니다.
웹 애플리케이션 성능에 대한 요구가 높고 앞으로도 계속 증가할 가능성이 높다는 것은 분명합니다.
성능을 개선하고 싶다는 생각은 쉽지만 실제로 결과를 확인하기는 어렵습니다.
이 블로그 게시물에서는 웹사이트 성능을 최대 10배까지 향상시키는 데 도움이 되는 10가지 팁을 제공합니다.
이 글은 잘 테스트된 최적화 기법과 NGINX의 약간의 지원을 통해
애플리케이션 성능을 향상시킬 수 있는 방법을 자세히 설명하는 시리즈의 첫 번째 글입니다.
이 시리즈에서는 그 과정에서 얻을 수 있는 보안 개선 효과에 대해서도 간략하게 설명합니다.
팁 1: 역방향 프록시 서버로 애플리케이션을 가속하고 보안 강화하기
웹 애플리케이션이 단일 컴퓨터에서 실행되는 경우 성능 문제에 대한 해결책은 더 빠른 프로세서,
더 많은 RAM, 빠른 디스크 어레이 등을 갖춘 더 빠른 컴퓨터를 구입하는 것일 수 있습니다.
그러면 새 컴퓨터에서 이전보다 더 빠르게 워드프레스 서버, Node.js 애플리케이션, Java 애플리케이션 등을 실행할 수 있습니다.
(애플리케이션이 데이터베이스 서버에 액세스하는 경우 해결책은 여전히 간단해 보일 수 있습니다.
더 빠른 컴퓨터 두 대와 그 사이의 더 빠른 연결을 확보하는 것입니다.)
문제는 컴퓨터 속도가 문제가 아닐 수도 있다는 것입니다.
웹 애플리케이션은 컴퓨터가 수천 개의 연결에서 사용자와 상호 작용하고,
디스크에서 파일에 액세스하고, 애플리케이션 코드를 실행하는 등 다양한 종류의 작업을 전환하기 때문에
느리게 실행되는 경우가 많습니다. 애플리케이션 서버는 메모리 부족, 메모리 청크의 디스크 교체,
디스크 I/O와 같은 단일 작업에서 많은 요청을 기다리게 하는 등의 문제를 일으킬 수 있습니다.
하드웨어를 업그레이드하는 대신 완전히 다른 접근 방식을 취할 수 있습니다.
역방향 프록시 서버를 추가하여 이러한 작업 중 일부를 오프로드하는 것입니다.
역방향 프록시 서버는 애플리케이션을 실행하는 컴퓨터 앞에 위치하여 인터넷 트래픽을 처리합니다.
역방향 프록시 서버만 인터넷에 직접 연결되고 애플리케이션 서버와의 통신은 빠른 내부 네트워크를 통해 이루어집니다.
역방향 프록시 서버를 사용하면 애플리케이션 서버는 사용자가 웹 앱과 상호 작용할 때까지 기다릴 필요가 없으며,
역방향 프록시 서버가 인터넷을 통해 전송할 페이지를 구축하는 데 집중할 수 있습니다.
더 이상 클라이언트 응답을 기다릴 필요가 없는
애플리케이션 서버는 최적화된 벤치마크에서 달성한 속도에 가까운 속도로 실행할 수 있습니다.
또한 역방향 프록시 서버를 추가하면 웹 서버 설정에 유연성이 더해집니다.
예를 들어 특정 유형의 서버에 과부하가 걸리면 같은 유형의 다른 서버를 쉽게 추가할 수 있고,
서버가 다운되면 서버를 쉽게 교체할 수 있습니다.
역방향 프록시 서버는 유연성을 제공하기 때문에 다음과 같은 다른 많은 성능 향상 기능을 위한 전제 조건이기도 합니다:
- 로드 밸런싱(팁 2 참조)-로드 밸런서는 역방향 프록시 서버에서 실행되어 여러 애플리케이션 서버에서 트래픽을 균등하게 공유합니다.
- 로드 밸런서를 사용하면 애플리케이션을 전혀 변경하지 않고도 애플리케이션 서버를 추가할 수 있습니다.
- 정적 파일 캐싱(팁 3 참조)- 이미지 파일이나 코드 파일 등 직접 요청되는 파일을 역방향 프록시 서버에 저장하여
- 클라이언트로 직접 전송하면 자산을 더 빠르게 제공하고 애플리케이션 서버의 부하를 줄여 애플리케이션을 더 빠르게 실행할 수 있습니다.
- 사이트 보안 강화 - 리버스 프록시 서버는 높은 보안을 위해 구성하고 공격을 빠르게 인식하고 대응하도록 모니터링하여 애플리케이션 서버를 보호할 수 있습니다.
NGINX 소프트웨어는 위에서 설명한 추가 기능과 함께 역방향 프록시 서버로 사용하도록 특별히 설계되었습니다.
NGINX는 기존 서버보다 더 효율적인 이벤트 중심 처리 방식을 사용합니다.
또한 NGINX는 애플리케이션 상태 확인, 특수 요청 라우팅, 고급 캐싱 및 지원과 같은 고급 역방향 프록시 기능을 추가합니다.
팁 2 - 로드 밸런서 추가하기
로드 밸런서를 추가하는 것은 사이트의 성능과 보안을 획기적으로 개선할 수 있는 비교적 쉬운 변경 사항입니다.
코어 웹 서버를 더 크고 강력하게 만드는 대신
로드 밸런서를 사용하여 여러 서버에 트래픽을 분산시킵니다.
애플리케이션이 잘못 작성되었거나 확장에 문제가 있는 경우에도
로드 밸런서를 사용하면 다른 변경 없이도 사용자 환경을 개선할 수 있습니다.
로드 밸런서는 먼저 인터넷 트래픽을 수신하여 다른 서버로 요청을 전달하는 역방향 프록시 서버(Tip 1 참조)입니다.
비결은 로드 밸런서가 두 개 이상의 애플리케이션 서버를 지원하며,
알고리즘 선택을 사용하여 서버 간에 요청을 분할한다는 것입니다.
가장 간단한 부하 분산 방식은 라운드 로빈으로, 새 요청이 들어올 때마다 목록의 다음 서버로 전송합니다.
다른 방법으로는 활성 연결 수가 가장 적은 서버로 요청을 보내는 방법이 있습니다.
NGINX Plus에는 동일한 서버에서 특정 사용자 세션을 지속하는 기능이 있으며, 이를 세션 지속성이라고 합니다.
로드 밸런서는 다른 서버가 트래픽을 대기하는 동안
한 서버가 과부하되는 것을 방지하기 때문에 성능이 크게 향상될 수 있습니다.
또한 비교적 저렴한 비용으로 서버를 추가하고
이를 최대한 활용할 수 있으므로 웹 서버 용량을 쉽게 확장할 수 있습니다.
로드 밸런싱할 수 있는 프로토콜에는 HTTP, HTTPS, SPDY, HTTP/2,
WebSocket, FastCGI, SCGI, uwsgi, memcached 및 TCP 기반 애플리케이션과
기타 Layer 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는 두 개의 지시문을 사용하여 set up caching을 사용합니다:
proxy_cache_path 및 proxy_cache. 캐시 위치와 크기, 파일이 캐시에 보관되는 최대 시간 및 기타 매개변수를 지정합니다.
세 번째(그리고 꽤 많이 사용되는) 지시어인 proxy_cache_use_stale를 사용하면 새로운 콘텐츠를 제공하는 서버가 사용 중이거나
다운되었을 때 캐시가 오래된 콘텐츠를 제공하도록 지시하여 클라이언트에 아무것도 없는 대신 무언가를 제공할 수도 있습니다.
사용자 입장에서는 사이트나 애플리케이션의 가동 시간을 크게 향상시킬 수 있습니다.
NGINX Plus에는 고급 캐싱 기능이 있으며, 여기에는 캐시 퍼징 지원과
실시간 활동 모니터링을 위한 대시보드의 캐시 상태 시각화 등이 포함됩니다.
NGINX를 사용한 캐싱에 대한 자세한 내용은 참조 문서 및 NGINX Plus 관리자 가이드를 참조하세요.
주: 캐싱은 애플리케이션을 개발하는 사람, 자본 투자 결정을 내리는 사람,
네트워크를 실시간으로 운영하는 사람 사이의 조직 경계를 넘나듭니다.
여기서 언급한 것과 같은 정교한 캐싱 전략은 애플리케이션 개발자, 아키텍처, 운영 관점을 통합하여
사이트 기능, 응답 시간, 보안, 비즈니스 결과(예: 완료된 거래 또는 매출)에 대한 목표를 달성하는 데
도움이 되는 DevOps 관점의 가치를 보여주는 좋은 예시라고 할 수 있습니다.
팁 4 - 데이터 압축
압축은 엄청난 잠재적 성능 가속기입니다.
사진(JPEG 및 PNG), 동영상(MPEG-4), 음악(MP3) 등을 위해 세심하게 설계된 매우 효과적인 압축 표준이 있습니다.
이러한 각 표준은 파일 크기를 수십 배 이상 줄여줍니다.
HTML(일반 텍스트 및 HTML 태그 포함), CSS, JavaScript와 같은 코드를 포함한 텍스트 데이터는
압축되지 않은 상태로 전송되는 경우가 많습니다.
이러한 데이터를 압축하면 특히 모바일 연결이 느리거나 제약이 있는 클라이언트의 경우
웹 애플리케이션 성능에 불균형적인 영향을 미칠 수 있습니다.
사용자가 페이지와 상호 작용하는 데는 텍스트 데이터만으로도 충분하고
멀티미디어 데이터는 보조적이거나 장식적인 역할을 하는 경우가 많기 때문입니다.
스마트 콘텐츠 압축은 HTML, 자바스크립트, CSS 및 기타 텍스트 기반 콘텐츠의 대역폭 요구 사항을 일반적으로 30% 이상 줄일 수 있으며,
그에 따라 로드 시간도 단축됩니다.
SSL을 사용하는 경우 압축을 사용하면 SSL로 인코딩해야 하는 데이터의 양이 줄어들어
데이터 압축에 소요되는 CPU 시간이 일부 상쇄됩니다.
텍스트 데이터를 압축하는 방법은 다양합니다.
예를 들어 헤더 데이터에 맞게 특별히 조정된 SPDY 및 HTTP/2의 새로운 텍스트 압축 체계에 대해서는 팁 6를 참조하세요.
텍스트 압축의 또 다른 예로 NGINX에서 turn on GZIP 압축을 사용할 수 있습니다.
서비스에서 텍스트 데이터를 사전 압축한 후에는 gzip_static 지시어를 사용하여 압축된 .gz> 파일을 직접 제공할 수 있습니다.
팁 5 - SSL/TLS 최적화하기
보안 소켓 계층(SSL) 프로토콜과 그 후속 프로토콜인 전송 계층 보안(TLS) 프로토콜이 점점 더 많은 웹사이트에서 사용되고 있습니다.
SSL/TLS는 원본 서버에서 사용자에게 전송되는 데이터를 암호화하여 사이트 보안을 개선하는 데 도움을 줍니다.
이러한 추세에 영향을 미치는 요인 중 하나는 Google이 SSL/TLS의 존재를 검색 엔진 순위에
긍정적인 영향을 미치는 요소로 활용하고 있다는 점입니다.
인기가 높아지고 있음에도 불구하고 SSL/TLS와 관련된 성능 저하는 많은 사이트의 고질적인 문제입니다.
SSL/TLS는 두 가지 이유로 웹사이트 성능을 저하시킵니다:
- 새 연결이 열릴 때마다 암호화 키를 설정하는 데 초기 핸드셰이크가 필요합니다.
- HTTP/1.x를 사용하는 브라우저가 서버당 여러 연결을 설정하는 방식은 이 수치를 증가시킵니다.
- 서버에서 데이터를 암호화하고 클라이언트에서 암호를 해독하는 데 따른 지속적인 오버헤드가 발생합니다.
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 - 특정 SSL/TLS 세션에 대한 정보를 티켓 또는 ID에 저장하여 새로운 핸드셰이킹 없이도 연결을 원활하게 재사용할 수 있도록 합니다.
- OCSP 스테이플링 - SSL/TLS 인증서 정보를 캐싱하여 핸드셰이킹 시간을 단축합니다.
클라이언트 트래픽의 암호화 및 암호 해독을 처리하고 다른 서버와 일반 텍스트로 통신하면서 SSL/TLS 종료를 위해
NGINX 및 NGINX Plus를 사용할 수 있습니다.
SSL/TLS 종료를 처리하도록 NGINX 또는 NGINX Plus를 설정하려면 HTTPS 연결 및 암호화된 TCP 연결에 대한 지침을 참조하세요.
팁 6 - HTTP/2 또는 SPDY 구현하기
이미 SSL/TLS를 사용하는 사이트의 경우, 단일 연결에 핸드셰이크가 한 번만 필요하므로
HTTP/2 및 SPDY가 성능을 개선할 가능성이 매우 높습니다.
아직 SSL/TLS를 사용하지 않는 사이트의 경우 HTTP/2 및 SPDY를 사용하면
응답성 관점에서 SSL/TLS(일반적으로 성능이 느려짐)로 전환하는 것이 훨씬 더 쉬워집니다.
Google은 HTTP/1.x를 기반으로 더 빠른 성능을 달성하기 위한 방법으로 2012년에 SPDY를 도입했습니다.
HTTP/2는 SPDY를 기반으로 최근 승인된 IETF 표준입니다.
SPDY는 광범위하게 지원되지만 곧 더 이상 사용되지 않고 HTTP/2로 대체될 예정입니다.
SPDY와 HTTP/2의 주요 특징은 다중 연결이 아닌 단일 연결을 사용한다는 점입니다.
단일 연결은 다중화되어 있어 여러 요청과 응답을 동시에 전달할 수 있습니다.
이러한 프로토콜은 하나의 연결을 최대한 활용함으로써
브라우저에서 HTTP/1.x를 구현하는 방식에 따라 여러 연결을 설정하고
관리해야 하는 오버헤드를 피할 수 있습니다.
단일 연결을 사용하면 SSL/TLS가 보안 연결을 설정하는 데
필요한 시간 소모적인 핸드셰이킹을 최소화할 수 있으므로 SSL에 특히 유용합니다.
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는 2015년 9월 현재 NGINX 오픈 소스 및 NGINX Plus에서 HTTP/2에 대한 선구적인 지원을 하고 있으며, 지원을 제공하고 있습니다.
시간이 지나면 대부분의 사이트가 SSL을 완전히 활성화하고 HTTP/2로 전환할 것으로 예상합니다.
이렇게 하면 보안이 강화되고 새로운 최적화가 발견되고 구현됨에 따라 더 간단한 코드로 더 나은 성능을 발휘할 수 있습니다.
팁 7 - 소프트웨어 버전 업데이트
애플리케이션 성능을 향상시키는 간단한 방법 중 하나는 안정성과 성능에 대한 평판을 기준으로
소프트웨어 스택에 사용할 컴포넌트를 선택하는 것입니다.
또한 고품질 컴포넌트의 개발자는 시간이 지남에 따라 성능 향상을 추구하고
버그를 수정할 가능성이 높기 때문에 안정적인 최신 버전의 소프트웨어를 사용하는 것이 좋습니다.
새 릴리스는 개발자와 사용자 커뮤니티로부터 더 많은 관심을 받습니다.
또한 최신 빌드는 새로운 하드웨어에 대한 튜닝을 포함하여 새로운 컴파일러 최적화를 활용합니다.
안정적인 새 릴리스는 일반적으로 이전 릴리스보다 호환성이 뛰어나고 성능이 더 높습니다.
또한 소프트웨어 업데이트를 최신 상태로 유지하면 최적화 조정, 버그 수정 및 보안 경고를 파악하기가 더 쉽습니다.
오래된 소프트웨어를 계속 사용하면 새로운 기능을 활용하지 못할 수도 있습니다.
예를 들어, 위에서 설명한 HTTP/2는 현재 OpenSSL 1.0.1이 필요합니다.
2016년 중반부터 HTTP/2에는 2015년 1월에 릴리스된 OpenSSL 1.0.2가 필요합니다.
소켓 샤딩 및 스레드 풀과 같은 새로운 기능(NGINX 또는 NGINX Plus가 포함된 최신 버전으로 이동하여 시작할 수 있으며,
두 버전 모두 성능을 위해 지속적으로 튜닝되고 있습니다(<데이터-dl-uid="145">Tip 9 참조).
그런 다음 스택에서 소프트웨어를 더 자세히 살펴보고 가능한 경우 최신 버전으로 이동하세요.
팁 8: 성능을 위해 Linux 조정하기
Linux는 오늘날 대부분의 웹 서버 구현을 위한 기본 운영 체제이며,
인프라의 기초로서 성능을 개선할 수 있는 중요한 기회를 제공합니다.
기본적으로 많은 Linux 시스템은 리소스를 거의 사용하지 않고 일반적인 데스크톱 워크로드에 맞게 보수적으로 조정됩니다.
즉, 웹 애플리케이션 사용 사례는 성능을 극대화하기 위해 최소 어느 정도의 튜닝이 필요합니다.
Linux 최적화는 웹 서버별로 다릅니다. 다음은 NGINX를 예로 들어 Linux 속도를 높이기 위해 고려할 수 있는 몇 가지 주요 변경 사항입니다:
- 백로그 대기열 - 연결이 지연되는 것으로 보이는 경우, NGINX에서 대기할 수 있는 최대 연결 수인 net.core.somaxconn를 늘리는 것을 고려하세요. 기존 연결 제한이 너무 작으면 오류 메시지가 표시되며 오류 메시지가 멈출 때까지 이 매개 변수를 서서히 늘릴 수 있습니다.
- 파일 설명자 - NGINX는 각 연결에 대해 최대 2개의 파일 설명자를 사용합니다. 시스템에서 많은 연결을 처리하는 경우 파일 설명자에 대한 시스템 전체 제한인 sys.fs.file_max와 사용자 파일 설명자 제한인 nofile를 늘려서 증가된 부하를 지원해야 할 수 있습니다.
- 임시 포트 - 프록시로 사용하는 경우 NGINX는 각 업스트림 서버에 대해 임시("임시") 포트를 생성합니다. net.ipv4.ip_local_port_range로 설정한 포트 값의 범위를 늘려 사용 가능한 포트의 수를 늘릴 수 있습니다.
- 또한 net.ipv4.tcp_fin_timeout 설정으로 비활성 포트가 재사용되기까지의 시간 초과를 줄여 더 빠른 전환이 가능하도록 할 수 있습니다.
NGINX의 경우 NGINX 성능 튜닝 가이드를 확인하여 대량의 네트워크 트래픽을
무리 없이 처리할 수 있도록 Linux 시스템을 최적화하는 방법을 알아보세요!
팁 9 - 웹 서버 성능 튜닝하기
어떤 웹 서버를 사용하든 웹 애플리케이션 성능을 위해 웹 서버를 튜닝해야 합니다. 다음 권장 사항은 일반적으로 모든 웹 서버에 적용되지만 NGINX에 대한 특정 설정이 제공됩니다. 주요 최적화 사항은 다음과 같습니다:
- 액세스 로깅 - 모든 요청에 대한 로그 항목을 디스크에 즉시 기록하는 대신 메모리에 항목을 버퍼링하고 그룹으로 디스크에 기록할 수 있습니다. NGINX의 경우, 메모리 버퍼가 가득 차면 로그 항목을 디스크에 기록하려면 buffer=size 매개 변수를 access_log 지시어에 추가합니다. flush=time 파라미터를 추가하면 지정된 시간이 지나면 버퍼 내용도 디스크에 기록됩니다.
- 버퍼링 - 버퍼링은 버퍼가 채워질 때까지 응답의 일부를 메모리에 보관하여 클라이언트와의 통신을 보다 효율적으로 만들 수 있습니다. 메모리에 맞지 않는 응답은 디스크에 기록되므로 성능이 느려질 수 있습니다. NGINX 버퍼링이 on인 경우 proxy_buffer_size 및 proxy_buffers 지시어를 사용하여 이를 관리할 수 있습니다.
- 클라이언트 킵얼라이브 - 킵얼라이브 연결은 특히 SSL/TLS를 사용할 때 오버헤드를 줄여줍니다. NGINX의 경우 클라이언트가 주어진 연결에 대해 수행할 수 있는 최대 keepalive_requests 수를 기본값인 100에서 늘릴 수 있으며, keepalive_timeout을 늘려 킵얼라이브 연결이 더 오래 열려 있도록 하여 후속 요청이 더 빨라질 수 있도록 설정할 수 있습니다.
- 업스트림 킵얼라이브 - 업스트림 연결(애플리케이션 서버, 데이터베이스 서버 등에 대한 연결)도 킵얼라이브 연결의 이점을 누릴 수 있습니다. 업스트림 연결의 경우 각 작업자 프로세스에 대해 열려 있는 유휴 킵얼라이브 연결의 수인 keepalive를 늘릴 수 있습니다. 이렇게 하면 연결 재사용이 증가하여 새로운 연결을 열 필요가 줄어듭니다. 자세한 내용은 HTTP 킵얼라이브 연결 및 웹 성능 블로그 게시물을 참조하세요.
- 한도 - 클라이언트가 사용하는 리소스를 제한하면 성능과 보안이 향상될 수 있습니다. NGINX의 경우 limit_conn 및 limit_conn_zone 지시어는 지정된 소스의 연결 수를 제한하고, limit_rate는 대역폭을 제한하는 역할을 합니다. 이러한 설정은 합법적인 사용자가 리소스를 '독식'하는 것을 막고 공격을 방지하는 데 도움이 될 수 있습니다. limit_req 및 limit_req_zone 지시어는 클라이언트 요청을 제한합니다. 업스트림 서버에 연결하려면 max_conns 파라미터를 서버 구성 블록의 업스트림 지시어에 사용합니다. 이렇게 하면 업스트림 서버에 대한 연결이 제한되어 과부하를 방지할 수 있습니다. 연결된 queue 지시어는 max_conns 제한에 도달한 후 지정된 시간 동안 지정된 수의 요청을 보관하는 큐를 생성합니다.
- 워커 프로세스 - 워커 프로세스는 요청 처리를 담당합니다. NGINX는 이벤트 기반 모델과 OS 종속 메커니즘을 사용하여 작업자 프로세스 간에 요청을 효율적으로 분산합니다. worker_processes 값을 CPU당 1개로 설정하는 것이 좋습니다. 필요한 경우 대부분의 시스템에서 최대 512개(기본값 512개)의 worker_connections 수를 안전하게 늘릴 수 있으므로 실험을 통해 자신의 시스템에 가장 적합한 값을 찾아보세요.
- 소켓 샤딩 - 일반적으로 단일 소켓 리스너가 모든 작업자 프로세스에 새 연결을 배포합니다. 소켓 샤딩은 각 작업자 프로세스에 대해 소켓 리스너를 생성하고, 커널은 소켓 리스너가 사용 가능해지면 연결을 할당합니다. 이렇게 하면 멀티코어 시스템에서 잠금 경합을 줄이고 성능을 향상시킬 수 있습니다. 소켓 샤딩을 사용하려면 재사용 보고서 매개변수를 listen 지시어에 포함하세요.
- 스레드 풀 - 모든 컴퓨터 프로세스는 느린 단일 작업으로 인해 지연될 수 있습니다. 웹 서버 소프트웨어의 경우 디스크 액세스는 메모리에서 정보를 계산하거나 복사하는 등의 많은 빠른 작업을 지연시킬 수 있습니다. 스레드 풀을 사용하면 느린 작업은 별도의 작업 집합에 할당되고 주 처리 루프는 더 빠른 작업을 계속 실행합니다. 디스크 작업이 완료되면 결과는 다시 주 처리 루프로 돌아갑니다. NGINX에서는 두 가지 작업, 즉 read() 시스템 호출과 sendfile()가 thread pools에 오프로드됩니다.
팁. 운영 체제 또는 지원 서비스에 대한 설정을 변경할 때는 한 번에 하나의 설정을 변경한 다음 성능을 테스트하세요.
변경으로 인해 문제가 발생하거나 사이트가 더 빠르게 실행되지 않으면 다시 변경하세요.
NGINX 웹 서버 튜닝에 대한 자세한 내용은 블로그 글 성능을 위한 NGINX 튜닝를 참조하세요.
팁 10: 실시간 활동을 모니터링하여 문제 및 병목 현상 해결
애플리케이션 개발 및 전송에 대한 고성능 접근 방식의 핵심은
애플리케이션의 실제 성능을 실시간으로 면밀히 관찰하는 것입니다.
특정 디바이스 내 및 웹 인프라 전반의 활동을 모니터링할 수 있어야 합니다.
사이트 활동 모니터링은 대부분 수동적이며, 무슨 일이 일어나고 있는지 알려주고
문제를 발견하고 해결하는 것은 사용자에게 맡깁니다.
모니터링은 여러 가지 종류의 문제를 포착할 수 있습니다. 여기에는 다음이 포함됩니다:
- 서버가 다운되었습니다.
- 서버가 절뚝거리며 연결이 끊어지고 있습니다.
- 서버에 캐시 누락 비율이 높습니다.
- 서버가 올바른 콘텐츠를 전송하지 않습니다.
뉴렐릭이나 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) - 버퍼링 최적화, 킵얼라이브 연결 사용, 시간 집약적인 작업을 별도의 스레드 풀로 오프로드하는 등의 수정으로 성능을 크게 향상시킬 수 있으며, 예를 들어 스레드 풀은 디스크 집약적인 작업 속도를 거의 <데이터-dl-uid="242">수배 가까이 끌어올릴 수 있습니다.
위 내용과 같이 NGINX Plus를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
전문가에게 상담받기
웹 애플리케이션 성능 개선이 그 어느 때보다 중요해졌습니다.
선진국 경제의 5% 이상이 인터넷을 통해 이루어지고 있을 정도로
온라인 경제 활동의 비중이 점점 커지고 있습니다
(아래의 인터넷 통계 리소스 참조).
또한 상시 접속이 가능하고 초연결된 현대 사회에서는 사용자의 기대치가 그 어느 때보다 높습니다.
사이트가 즉각적으로 응답하지 않거나 앱이 지연 없이 작동하지 않으면 사용자는 빠르게 경쟁업체로 이동합니다.
예를 들어, 거의 10년 전에 Amazon에서 실시한 연구에 따르면 당시에도
페이지 로딩 시간이 100밀리초 단축되면 매출이 1% 증가했습니다.
최근의 또 다른 연구에서는 설문조사에 참여한 사이트 소유자의 절반 이상이 애플리케이션 성능 저하로 인해
매출이나 고객을 잃었다고 답한 사실을 강조했습니다.
웹사이트는 얼마나 빨라야 할까요? 페이지가 로드되는 데 1초가 걸릴 때마다 약 4%의 사용자가 페이지를 이탈합니다.
상위 이커머스 사이트의 첫 번째 상호 작용 시간은 1~3초로, 전환율이 가장 높은 시간대입니다.
웹 애플리케이션 성능에 대한 요구가 높고 앞으로도 계속 증가할 가능성이 높다는 것은 분명합니다.
성능을 개선하고 싶다는 생각은 쉽지만 실제로 결과를 확인하기는 어렵습니다.
이 블로그 게시물에서는 웹사이트 성능을 최대 10배까지 향상시키는 데 도움이 되는 10가지 팁을 제공합니다.
이 글은 잘 테스트된 최적화 기법과 NGINX의 약간의 지원을 통해
애플리케이션 성능을 향상시킬 수 있는 방법을 자세히 설명하는 시리즈의 첫 번째 글입니다.
이 시리즈에서는 그 과정에서 얻을 수 있는 보안 개선 효과에 대해서도 간략하게 설명합니다.
팁 1: 역방향 프록시 서버로 애플리케이션을 가속하고 보안 강화하기
웹 애플리케이션이 단일 컴퓨터에서 실행되는 경우 성능 문제에 대한 해결책은 더 빠른 프로세서,
더 많은 RAM, 빠른 디스크 어레이 등을 갖춘 더 빠른 컴퓨터를 구입하는 것일 수 있습니다.
그러면 새 컴퓨터에서 이전보다 더 빠르게 워드프레스 서버, Node.js 애플리케이션, Java 애플리케이션 등을 실행할 수 있습니다.
(애플리케이션이 데이터베이스 서버에 액세스하는 경우 해결책은 여전히 간단해 보일 수 있습니다.
더 빠른 컴퓨터 두 대와 그 사이의 더 빠른 연결을 확보하는 것입니다.)
문제는 컴퓨터 속도가 문제가 아닐 수도 있다는 것입니다.
웹 애플리케이션은 컴퓨터가 수천 개의 연결에서 사용자와 상호 작용하고,
디스크에서 파일에 액세스하고, 애플리케이션 코드를 실행하는 등 다양한 종류의 작업을 전환하기 때문에
느리게 실행되는 경우가 많습니다. 애플리케이션 서버는 메모리 부족, 메모리 청크의 디스크 교체,
디스크 I/O와 같은 단일 작업에서 많은 요청을 기다리게 하는 등의 문제를 일으킬 수 있습니다.
하드웨어를 업그레이드하는 대신 완전히 다른 접근 방식을 취할 수 있습니다.
역방향 프록시 서버를 추가하여 이러한 작업 중 일부를 오프로드하는 것입니다.
역방향 프록시 서버는 애플리케이션을 실행하는 컴퓨터 앞에 위치하여 인터넷 트래픽을 처리합니다.
역방향 프록시 서버만 인터넷에 직접 연결되고 애플리케이션 서버와의 통신은 빠른 내부 네트워크를 통해 이루어집니다.
역방향 프록시 서버를 사용하면 애플리케이션 서버는 사용자가 웹 앱과 상호 작용할 때까지 기다릴 필요가 없으며,
역방향 프록시 서버가 인터넷을 통해 전송할 페이지를 구축하는 데 집중할 수 있습니다.
더 이상 클라이언트 응답을 기다릴 필요가 없는
애플리케이션 서버는 최적화된 벤치마크에서 달성한 속도에 가까운 속도로 실행할 수 있습니다.
또한 역방향 프록시 서버를 추가하면 웹 서버 설정에 유연성이 더해집니다.
예를 들어 특정 유형의 서버에 과부하가 걸리면 같은 유형의 다른 서버를 쉽게 추가할 수 있고,
서버가 다운되면 서버를 쉽게 교체할 수 있습니다.
역방향 프록시 서버는 유연성을 제공하기 때문에 다음과 같은 다른 많은 성능 향상 기능을 위한 전제 조건이기도 합니다:
NGINX 소프트웨어는 위에서 설명한 추가 기능과 함께 역방향 프록시 서버로 사용하도록 특별히 설계되었습니다.
NGINX는 기존 서버보다 더 효율적인 이벤트 중심 처리 방식을 사용합니다.
또한 NGINX는 애플리케이션 상태 확인, 특수 요청 라우팅, 고급 캐싱 및 지원과 같은 고급 역방향 프록시 기능을 추가합니다.
팁 2 - 로드 밸런서 추가하기
로드 밸런서를 추가하는 것은 사이트의 성능과 보안을 획기적으로 개선할 수 있는 비교적 쉬운 변경 사항입니다.
코어 웹 서버를 더 크고 강력하게 만드는 대신
로드 밸런서를 사용하여 여러 서버에 트래픽을 분산시킵니다.
애플리케이션이 잘못 작성되었거나 확장에 문제가 있는 경우에도
로드 밸런서를 사용하면 다른 변경 없이도 사용자 환경을 개선할 수 있습니다.
로드 밸런서는 먼저 인터넷 트래픽을 수신하여 다른 서버로 요청을 전달하는 역방향 프록시 서버(Tip 1 참조)입니다.
비결은 로드 밸런서가 두 개 이상의 애플리케이션 서버를 지원하며,
알고리즘 선택을 사용하여 서버 간에 요청을 분할한다는 것입니다.
가장 간단한 부하 분산 방식은 라운드 로빈으로, 새 요청이 들어올 때마다 목록의 다음 서버로 전송합니다.
다른 방법으로는 활성 연결 수가 가장 적은 서버로 요청을 보내는 방법이 있습니다.
NGINX Plus에는 동일한 서버에서 특정 사용자 세션을 지속하는 기능이 있으며, 이를 세션 지속성이라고 합니다.
로드 밸런서는 다른 서버가 트래픽을 대기하는 동안
한 서버가 과부하되는 것을 방지하기 때문에 성능이 크게 향상될 수 있습니다.
또한 비교적 저렴한 비용으로 서버를 추가하고
이를 최대한 활용할 수 있으므로 웹 서버 용량을 쉽게 확장할 수 있습니다.
로드 밸런싱할 수 있는 프로토콜에는 HTTP, HTTPS, SPDY, HTTP/2,
WebSocket, FastCGI, SCGI, uwsgi, memcached 및 TCP 기반 애플리케이션과
기타 Layer 4 프로토콜을 포함한 여러 애플리케이션 유형이 포함됩니다.
웹 애플리케이션을 분석하여 사용 중인 애플리케이션과 성능 저하가 발생하는 위치를 파악하세요.
로드 밸런싱에 사용되는 동일한 서버는 SSL 종료, 클라이언트의 HTTP/1.x 및 HTTP/2 사용 지원,
정적 파일 캐싱 등 여러 다른 작업도 처리할 수 있습니다.
NGINX는 로드 밸런싱에 자주 사용됩니다.
자세히 알아보려면 소프트웨어 로드 밸런서를 선택해야 하는 5가지 이유 전자책을 다운로드하세요.
기본 구성 지침은 NGINX 및 NGINX Plus를 사용한 부하 분산,
1부에서, 전체 설명서는 NGINX Plus 관리자 가이드에서 확인할 수 있습니다.
NGINX Plus는 당사의 상용 제품이며 서버 응답 시간에 기반한 부하 라우팅 및 Microsoft의 NTLM 프로토콜에서
부하 분산 기능 등 보다 전문적인 부하 분산 기능을 지원합니다.
팁 3 - 정적 및 동적 콘텐츠 캐시하기
캐싱은 콘텐츠를 클라이언트에 더 빠르게 전송하여 웹 애플리케이션 성능을 향상시킵니다.
캐싱에는 필요할 때 빠른 전송을 위해 콘텐츠 사전 처리, 더 빠른 디바이스에 콘텐츠 저장,
클라이언트에 더 가까운 곳에 콘텐츠 저장 등 여러 가지 전략이 포함될 수 있습니다.
고려해야 할 캐싱에는 두 가지 유형이 있습니다:
웹 애플리케이션에서 생성된 콘텐츠를 캐싱하는 데는 세 가지 주요 기술이 있습니다:
웹 애플리케이션 캐싱은 웹 애플리케이션 서버 내부에서 구현할 수도 있고 외부에서 구현할 수도 있습니다.
먼저 캐싱은 애플리케이션 서버의 부하를 줄이기 위해 동적 콘텐츠에 사용됩니다.
그런 다음 캐싱은 정적 콘텐츠(동적 콘텐츠의 임시 복사본 포함)에 사용되어 애플리케이션 서버의 부하를 더욱 분산시킵니다.
그런 다음 캐싱이 애플리케이션 서버에서 더 빠르거나 사용자와 더 가까운 컴퓨터로 이동하여
애플리케이션 서버의 부담을 덜어주고 검색 및 전송 시간을 단축합니다.
캐싱을 개선하면 애플리케이션 속도를 크게 높일 수 있습니다.
많은 웹 페이지의 경우 대용량 이미지 파일과 같은 정적 데이터가 콘텐츠의 절반 이상을 차지합니다.
캐싱 없이 이러한 데이터를 검색하고 전송하는 데 몇 초가 걸릴 수 있지만
데이터가 로컬에 캐시되어 있으면 몇 분의 1초밖에 걸리지 않습니다.
실제로 캐싱이 어떻게 사용되는지 보여주는 예로, NGINX와 NGINX Plus는 두 개의 지시문을 사용하여 set up caching을 사용합니다:
proxy_cache_path 및 proxy_cache. 캐시 위치와 크기, 파일이 캐시에 보관되는 최대 시간 및 기타 매개변수를 지정합니다.
세 번째(그리고 꽤 많이 사용되는) 지시어인 proxy_cache_use_stale를 사용하면 새로운 콘텐츠를 제공하는 서버가 사용 중이거나
다운되었을 때 캐시가 오래된 콘텐츠를 제공하도록 지시하여 클라이언트에 아무것도 없는 대신 무언가를 제공할 수도 있습니다.
사용자 입장에서는 사이트나 애플리케이션의 가동 시간을 크게 향상시킬 수 있습니다.
NGINX Plus에는 고급 캐싱 기능이 있으며, 여기에는 캐시 퍼징 지원과
실시간 활동 모니터링을 위한 대시보드의 캐시 상태 시각화 등이 포함됩니다.
NGINX를 사용한 캐싱에 대한 자세한 내용은 참조 문서 및 NGINX Plus 관리자 가이드를 참조하세요.
주: 캐싱은 애플리케이션을 개발하는 사람, 자본 투자 결정을 내리는 사람,
네트워크를 실시간으로 운영하는 사람 사이의 조직 경계를 넘나듭니다.
여기서 언급한 것과 같은 정교한 캐싱 전략은 애플리케이션 개발자, 아키텍처, 운영 관점을 통합하여
사이트 기능, 응답 시간, 보안, 비즈니스 결과(예: 완료된 거래 또는 매출)에 대한 목표를 달성하는 데
도움이 되는 DevOps 관점의 가치를 보여주는 좋은 예시라고 할 수 있습니다.
팁 4 - 데이터 압축
압축은 엄청난 잠재적 성능 가속기입니다.
사진(JPEG 및 PNG), 동영상(MPEG-4), 음악(MP3) 등을 위해 세심하게 설계된 매우 효과적인 압축 표준이 있습니다.
이러한 각 표준은 파일 크기를 수십 배 이상 줄여줍니다.
HTML(일반 텍스트 및 HTML 태그 포함), CSS, JavaScript와 같은 코드를 포함한 텍스트 데이터는
압축되지 않은 상태로 전송되는 경우가 많습니다.
이러한 데이터를 압축하면 특히 모바일 연결이 느리거나 제약이 있는 클라이언트의 경우
웹 애플리케이션 성능에 불균형적인 영향을 미칠 수 있습니다.
사용자가 페이지와 상호 작용하는 데는 텍스트 데이터만으로도 충분하고
멀티미디어 데이터는 보조적이거나 장식적인 역할을 하는 경우가 많기 때문입니다.
스마트 콘텐츠 압축은 HTML, 자바스크립트, CSS 및 기타 텍스트 기반 콘텐츠의 대역폭 요구 사항을 일반적으로 30% 이상 줄일 수 있으며,
그에 따라 로드 시간도 단축됩니다.
SSL을 사용하는 경우 압축을 사용하면 SSL로 인코딩해야 하는 데이터의 양이 줄어들어
데이터 압축에 소요되는 CPU 시간이 일부 상쇄됩니다.
텍스트 데이터를 압축하는 방법은 다양합니다.
예를 들어 헤더 데이터에 맞게 특별히 조정된 SPDY 및 HTTP/2의 새로운 텍스트 압축 체계에 대해서는 팁 6를 참조하세요.
텍스트 압축의 또 다른 예로 NGINX에서 turn on GZIP 압축을 사용할 수 있습니다.
서비스에서 텍스트 데이터를 사전 압축한 후에는 gzip_static 지시어를 사용하여 압축된 .gz> 파일을 직접 제공할 수 있습니다.
팁 5 - SSL/TLS 최적화하기
보안 소켓 계층(SSL) 프로토콜과 그 후속 프로토콜인 전송 계층 보안(TLS) 프로토콜이 점점 더 많은 웹사이트에서 사용되고 있습니다.
SSL/TLS는 원본 서버에서 사용자에게 전송되는 데이터를 암호화하여 사이트 보안을 개선하는 데 도움을 줍니다.
이러한 추세에 영향을 미치는 요인 중 하나는 Google이 SSL/TLS의 존재를 검색 엔진 순위에
긍정적인 영향을 미치는 요소로 활용하고 있다는 점입니다.
인기가 높아지고 있음에도 불구하고 SSL/TLS와 관련된 성능 저하는 많은 사이트의 고질적인 문제입니다.
SSL/TLS는 두 가지 이유로 웹사이트 성능을 저하시킵니다:
SSL/TLS 사용을 장려하기 위해 HTTP/2 및 SPDY(다음 팁에 설명된)의 작성자는 브라우저 세션당 하나의 연결만 필요하도록
이러한 프로토콜을 설계했습니다. 이로써 SSL 오버헤드의 두 가지 주요 원인 중 하나를 크게 줄일 수 있습니다.
그러나 오늘날에는 SSL/TLS를 통해 전송되는 애플리케이션의 성능을 개선하기 위해 더 많은 작업을 수행할 수 있습니다.
SSL/TLS 최적화를 위한 메커니즘은 웹 서버에 따라 다릅니다.
예를 들어, NGINX는 표준 상용 하드웨어에서 실행되는 OpenSSL를 사용하여 전용 하드웨어 솔루션과 유사한 성능을 제공합니다.
NGINX SSL 성능은 잘 문서화되어 있으며 SSL/TLS 암호화 및 복호화 수행에 따른 시간 및 CPU 페널티를 최소화합니다.
또한 SSL/TLS 성능을 향상시키는 방법에 대한 자세한 내용은 이 블로그 게시글를 참조하세요.
간단히 요약하면 다음과 같습니다:
클라이언트 트래픽의 암호화 및 암호 해독을 처리하고 다른 서버와 일반 텍스트로 통신하면서 SSL/TLS 종료를 위해
NGINX 및 NGINX Plus를 사용할 수 있습니다.
SSL/TLS 종료를 처리하도록 NGINX 또는 NGINX Plus를 설정하려면 HTTPS 연결 및 암호화된 TCP 연결에 대한 지침을 참조하세요.
팁 6 - HTTP/2 또는 SPDY 구현하기
이미 SSL/TLS를 사용하는 사이트의 경우, 단일 연결에 핸드셰이크가 한 번만 필요하므로
HTTP/2 및 SPDY가 성능을 개선할 가능성이 매우 높습니다.
아직 SSL/TLS를 사용하지 않는 사이트의 경우 HTTP/2 및 SPDY를 사용하면
응답성 관점에서 SSL/TLS(일반적으로 성능이 느려짐)로 전환하는 것이 훨씬 더 쉬워집니다.
Google은 HTTP/1.x를 기반으로 더 빠른 성능을 달성하기 위한 방법으로 2012년에 SPDY를 도입했습니다.
HTTP/2는 SPDY를 기반으로 최근 승인된 IETF 표준입니다.
SPDY는 광범위하게 지원되지만 곧 더 이상 사용되지 않고 HTTP/2로 대체될 예정입니다.
SPDY와 HTTP/2의 주요 특징은 다중 연결이 아닌 단일 연결을 사용한다는 점입니다.
단일 연결은 다중화되어 있어 여러 요청과 응답을 동시에 전달할 수 있습니다.
이러한 프로토콜은 하나의 연결을 최대한 활용함으로써
브라우저에서 HTTP/1.x를 구현하는 방식에 따라 여러 연결을 설정하고
관리해야 하는 오버헤드를 피할 수 있습니다.
단일 연결을 사용하면 SSL/TLS가 보안 연결을 설정하는 데
필요한 시간 소모적인 핸드셰이킹을 최소화할 수 있으므로 SSL에 특히 유용합니다.
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는 2015년 9월 현재 NGINX 오픈 소스 및 NGINX Plus에서 HTTP/2에 대한 선구적인 지원을 하고 있으며, 지원을 제공하고 있습니다.
시간이 지나면 대부분의 사이트가 SSL을 완전히 활성화하고 HTTP/2로 전환할 것으로 예상합니다.
이렇게 하면 보안이 강화되고 새로운 최적화가 발견되고 구현됨에 따라 더 간단한 코드로 더 나은 성능을 발휘할 수 있습니다.
팁 7 - 소프트웨어 버전 업데이트
애플리케이션 성능을 향상시키는 간단한 방법 중 하나는 안정성과 성능에 대한 평판을 기준으로
소프트웨어 스택에 사용할 컴포넌트를 선택하는 것입니다.
또한 고품질 컴포넌트의 개발자는 시간이 지남에 따라 성능 향상을 추구하고
버그를 수정할 가능성이 높기 때문에 안정적인 최신 버전의 소프트웨어를 사용하는 것이 좋습니다.
새 릴리스는 개발자와 사용자 커뮤니티로부터 더 많은 관심을 받습니다.
또한 최신 빌드는 새로운 하드웨어에 대한 튜닝을 포함하여 새로운 컴파일러 최적화를 활용합니다.
안정적인 새 릴리스는 일반적으로 이전 릴리스보다 호환성이 뛰어나고 성능이 더 높습니다.
또한 소프트웨어 업데이트를 최신 상태로 유지하면 최적화 조정, 버그 수정 및 보안 경고를 파악하기가 더 쉽습니다.
오래된 소프트웨어를 계속 사용하면 새로운 기능을 활용하지 못할 수도 있습니다.
예를 들어, 위에서 설명한 HTTP/2는 현재 OpenSSL 1.0.1이 필요합니다.
2016년 중반부터 HTTP/2에는 2015년 1월에 릴리스된 OpenSSL 1.0.2가 필요합니다.
소켓 샤딩 및 스레드 풀과 같은 새로운 기능(NGINX 또는 NGINX Plus가 포함된 최신 버전으로 이동하여 시작할 수 있으며,
두 버전 모두 성능을 위해 지속적으로 튜닝되고 있습니다(<데이터-dl-uid="145">Tip 9 참조).
그런 다음 스택에서 소프트웨어를 더 자세히 살펴보고 가능한 경우 최신 버전으로 이동하세요.
팁 8: 성능을 위해 Linux 조정하기
Linux는 오늘날 대부분의 웹 서버 구현을 위한 기본 운영 체제이며,
인프라의 기초로서 성능을 개선할 수 있는 중요한 기회를 제공합니다.
기본적으로 많은 Linux 시스템은 리소스를 거의 사용하지 않고 일반적인 데스크톱 워크로드에 맞게 보수적으로 조정됩니다.
즉, 웹 애플리케이션 사용 사례는 성능을 극대화하기 위해 최소 어느 정도의 튜닝이 필요합니다.
Linux 최적화는 웹 서버별로 다릅니다. 다음은 NGINX를 예로 들어 Linux 속도를 높이기 위해 고려할 수 있는 몇 가지 주요 변경 사항입니다:
NGINX의 경우 NGINX 성능 튜닝 가이드를 확인하여 대량의 네트워크 트래픽을
무리 없이 처리할 수 있도록 Linux 시스템을 최적화하는 방법을 알아보세요!
팁 9 - 웹 서버 성능 튜닝하기
어떤 웹 서버를 사용하든 웹 애플리케이션 성능을 위해 웹 서버를 튜닝해야 합니다. 다음 권장 사항은 일반적으로 모든 웹 서버에 적용되지만 NGINX에 대한 특정 설정이 제공됩니다. 주요 최적화 사항은 다음과 같습니다:
팁. 운영 체제 또는 지원 서비스에 대한 설정을 변경할 때는 한 번에 하나의 설정을 변경한 다음 성능을 테스트하세요.
변경으로 인해 문제가 발생하거나 사이트가 더 빠르게 실행되지 않으면 다시 변경하세요.
NGINX 웹 서버 튜닝에 대한 자세한 내용은 블로그 글 성능을 위한 NGINX 튜닝를 참조하세요.
팁 10: 실시간 활동을 모니터링하여 문제 및 병목 현상 해결
애플리케이션 개발 및 전송에 대한 고성능 접근 방식의 핵심은
애플리케이션의 실제 성능을 실시간으로 면밀히 관찰하는 것입니다.
특정 디바이스 내 및 웹 인프라 전반의 활동을 모니터링할 수 있어야 합니다.
사이트 활동 모니터링은 대부분 수동적이며, 무슨 일이 일어나고 있는지 알려주고
문제를 발견하고 해결하는 것은 사용자에게 맡깁니다.
모니터링은 여러 가지 종류의 문제를 포착할 수 있습니다. 여기에는 다음이 포함됩니다:
뉴렐릭이나 Dynatrace와 같은 글로벌 애플리케이션 성능 모니터링 도구는
원격 위치에서 페이지 로딩 시간을 모니터링하는 데 도움이 되며,
NGINX는 애플리케이션 전송 측면을 모니터링하는 데 도움이 됩니다.
애플리케이션 성능 데이터는 최적화가 사용자에게 실질적인 차이를 가져오는 시점과 트래픽을 유지하기 위해
인프라에 용량 추가를 고려해야 하는 시점을 알려줍니다.
문제를 신속하게 식별하고 해결할 수 있도록 NGINX Plus는 정기적으로 반복되어 문제를 알리는 데
사용되는 합성 트랜잭션인 애플리케이션 인식 상태 확인을 추가합니다.
또한 NGINX Plus에는 기존 작업이 완료되는 동안 새 연결을 중지하는 세션 배수와
부하가 분산된 그룹 내에서 복구된 서버의 속도를 높일 수 있는 슬로우 스타트 기능도 있습니다.
상태 검사를 효과적으로 사용하면 사용자 경험에 큰 영향을 미치기 전에 문제를 파악할 수 있으며,
세션 드레이닝 및 슬로우 스타트 기능을 사용하면 서버를 교체하고
이 프로세스가 체감 성능이나 가동 시간에 부정적인 영향을 미치지 않도록 할 수 있습니다.
이 그림은 서버, TCP 연결, 캐싱이 있는 웹 인프라에 대한 기본 제공 NGINX Plus 라이브 활동 모니터링 대시보드를 보여줍니다.
결론 - 10배의 성능 향상 확인
하나의 웹 애플리케이션에 적용할 수 있는 성능 향상은 매우 다양하며, 실제 이득은 예산, 투자할 수 있는 시간, 기존 구현의 격차에 따라 달라집니다. 그렇다면 자체 애플리케이션에서 10배의 성능 향상을 달성하려면 어떻게 해야 할까요?
각 최적화의 잠재적 영향에 대한 가이드를 제공하기 위해 위에 설명된 각 팁을 통해 얻을 수 있는 개선 효과에 대한 포인트를 알려드리며, 각 팁의 마일리지는 다를 수 있습니다:
위 내용과 같이 NGINX Plus를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
전문가에게 상담받기