서버의 병목 현상을 파악하고 신속히 해결하여 서버 성능을 개선하고 회귀를 방지하는 방법
개요
이 가이드에서는 4단계로 과부하된 서버를 해결하는 방법을 보여줍니다.
- 평가: 서버의 병목 현상을 파악합니다.
- 안정화: 빠른 수정사항을 구현하여 영향을 완화합니다.
- 개선: 서버 기능을 보강하고 최적화합니다.
- 모니터링: 자동화된 도구를 사용하여 향후 발생할 수 있는 문제를 방지합니다.
평가
트래픽으로 인해 서버에 과부하가 발생하면 CPU, 네트워크, 메모리 또는 디스크 I/O 중 하나 이상이 병목 현상을 일으킬 수 있습니다. 이러한 요소 중 병목 현상을 일으키는 요소를 파악하면 가장 효과적인 완화 조치에 집중할 수 있습니다.
- CPU: CPU 사용량이 지속적으로 80% 를 초과하면 조사하고 수정해야 합니다. CPU 사용량이 약 80~90%에 도달하면 서버 성능이 저하되는 경우가 많으며 사용량이 100%에 가까워질수록 성능 저하가 더 심해집니다. 단일 요청을 제공하는 데 드는 CPU 사용량은 무시할 수 있지만 트래픽 급증 시 발생하는 규모로 이를 실행하면 서버가 과부하될 수 있습니다. 제공을 다른 인프라로 오프로드하고, 비용이 많이 드는 작업을 줄이고, 요청 수를 제한하면 CPU 사용률이 줄어듭니다.
- 네트워크: 트래픽이 많은 기간에는 사용자 요청을 처리하는 데 필요한 네트워크 처리량이 용량을 초과할 수 있습니다. 호스팅 업체에 따라 누적 데이터 전송과 관련된 한도에 도달하는 사이트도 있습니다. 서버와 전송되는 데이터의 크기와 수량을 줄이면 이 병목 현상이 제거됩니다.
- 메모리: 시스템에 메모리가 충분하지 않으면 저장을 위해 데이터를 디스크로 오프로드해야 합니다. 디스크는 메모리보다 액세스 속도가 훨씬 느리므로 전체 애플리케이션 속도가 느려질 수 있습니다. 메모리가 완전히 소진되면 메모리 부족 (OOM) 오류가 발생할 수 있습니다. 메모리 할당을 조정하고, 메모리 누수를 수정하고, 메모리를 업그레이드하면 이 병목 현상을 제거할 수 있습니다.
- 디스크 I/O: 디스크에서 데이터를 읽거나 쓸 수 있는 속도는 디스크 자체에 의해 제한됩니다. 디스크 I/O가 병목 현상인 경우 메모리에 캐시된 데이터의 양을 늘리면 이 문제를 완화할 수 있습니다 (메모리 사용량이 증가함). 그래도 문제가 해결되지 않으면 디스크를 업그레이드해야 할 수 있습니다.
이 가이드의 기법은 CPU 및 네트워크 병목 현상을 해결하는 데 중점을 둡니다. 대부분의 사이트에서 트래픽이 급증할 때 가장 관련성이 높은 병목 현상은 CPU와 네트워크입니다.
영향을 받는 서버에서 top를 실행하는 것이 병목 현상을 조사하는 좋은 출발점이 될 수 있습니다. 가능한 경우 호스팅 업체 또는 모니터링 도구의 이전 데이터로 보완합니다.
손떨림 보정
서버에 과부하가 발생하면 시스템의 다른 위치에서 연쇄적 장애가 빠르게 발생할 수 있습니다. 따라서 더 중요한 변경사항을 적용하기 전에 서버를 안정화하는 것이 중요합니다.
비율 제한
비율 제한은 수신 요청 수를 제한하여 인프라를 보호합니다. 서버 성능이 저하될수록 이 문제가 점점 더 중요해집니다. 응답 시간이 길어지면 사용자는 페이지를 적극적으로 새로고침하는 경향이 있어 서버 부하가 더욱 커집니다.
수정
요청을 거부하는 것은 상대적으로 비용이 적게 들지만 서버를 보호하는 가장 좋은 방법은 부하 분산기, 역방향 프록시 또는 CDN을 통해 서버의 업스트림 어딘가에서 비율 제한을 처리하는 것입니다.
안내:
추가 자료:
HTTP 캐싱
콘텐츠를 더 적극적으로 캐시하는 방법을 모색합니다. 리소스를 HTTP 캐시 (브라우저 캐시 또는 CDN)에서 제공할 수 있으면 출처 서버에서 요청할 필요가 없으므로 서버 부하가 줄어듭니다.
Cache-Control, Expires, ETag와 같은 HTTP 헤더는 HTTP 캐시에서 리소스를 캐시하는 방법을 나타냅니다. 이러한 헤더를 감사하고 수정하면 캐싱이 개선됩니다.
서비스 워커는 캐싱에도 사용할 수 있지만 별도의 캐시를 활용하며 적절한 HTTP 캐싱을 대체하는 것이 아니라 보완하는 역할을 합니다. 따라서 과부하된 서버를 처리할 때는 HTTP 캐싱 최적화에 집중해야 합니다.
진단
Lighthouse를 실행하고 효율적인 캐시 정책으로 정적 애셋 제공 감사를 확인하여 TTL (수명)이 짧거나 중간인 리소스 목록을 확인합니다. 나열된 각 리소스에 대해 TTL을 늘려야 하는지 고려합니다. 대략적인 가이드라인은 다음과 같습니다.
- 정적 리소스는 긴 TTL (1년)로 캐시해야 합니다.
- 동적 리소스는 TTL (3시간)이 짧게 캐시되어야 합니다.
수정
Cache-Control 헤더의 max-age 지시문을 적절한 초 수로 설정합니다.
안내:
단계적 성능 저하
단계적 저하란 시스템에서 과도한 부하를 제거하기 위해 일시적으로 기능을 줄이는 전략입니다. 이 개념은 다양한 방식으로 적용할 수 있습니다. 예를 들어 모든 기능이 포함된 애플리케이션 대신 정적 텍스트 페이지를 제공하거나, 검색을 사용 중지하거나 검색 결과를 더 적게 반환하거나, 비용이 많이 들거나 중요하지 않은 특정 기능을 사용 중지할 수 있습니다. 비즈니스 영향이 최소화되도록 안전하고 쉽게 삭제할 수 있는 기능을 삭제하는 데 중점을 두어야 합니다.
개선
콘텐츠 전송 네트워크 (CDN) 사용
정적 애셋 제공을 서버에서 콘텐츠 전송 네트워크 (CDN)로 오프로드하여 부하를 줄일 수 있습니다.
CDN의 기본 기능은 사용자와 가까운 위치에 있는 대규모 서버 네트워크를 제공하여 사용자에게 콘텐츠를 빠르게 전송하는 것입니다. 그러나 대부분의 CDN은 압축, 부하 분산, 미디어 최적화와 같은 성능 관련 기능도 추가로 제공합니다.
CDN 설정
CDN은 확장으로 이점을 얻으므로 자체 CDN을 운영하는 것은 거의 적절하지 않습니다. 기본 CDN 구성은 설정이 매우 빠르며 (~30분) CDN을 가리키도록 DNS 레코드를 업데이트하는 것으로 구성됩니다.
CDN 사용량 최적화
진단
WebPageTest를 실행하여 CDN에서 제공되지 않지만 제공되어야 하는 리소스를 식별합니다. 결과 페이지에서 'CDN 효과적인 사용' 위의 정사각형을 클릭하여 CDN에서 제공해야 하는 리소스 목록을 확인합니다.
수정
CDN에서 리소스를 캐시하지 않는 경우 다음 조건이 충족되는지 확인합니다.
Cache-Control: public헤더가 있습니다.Cache-Control: s-maxage,Cache-Control: max-age또는Expires헤더가 있습니다.Content-Length,Content-Range또는Transfer-Encoding header가 있습니다.
컴퓨팅 리소스 확장
컴퓨팅 리소스를 확장할지 여부는 신중하게 결정해야 합니다. 컴퓨팅 리소스를 확장해야 하는 경우가 많지만, 너무 일찍 확장하면 불필요한 아키텍처 복잡성과 금전적 비용이 발생할 수 있습니다.
진단
첫 바이트 소요 시간 (TTFB)이 길면 서버의 용량이 거의 다 찼다는 신호일 수 있습니다. 이 정보는 Lighthouse 서버 응답 시간 (TTFB) 단축 감사에서 확인할 수 있습니다.
자세히 조사하려면 모니터링 도구를 사용하여 CPU 사용량을 평가하세요. 현재 또는 예상 CPU 사용량이 80% 를 초과하면 서버를 늘려야 합니다.
수정
부하 분산기를 추가하면 여러 서버에 트래픽을 분산할 수 있습니다. 부하 분산기는 서버 풀 앞에 배치되어 트래픽을 적절한 서버로 라우팅합니다. 클라우드 제공업체에서 자체 부하 분산기 (GCP, AWS, Azure)를 제공하거나 HAProxy 또는 NGINX를 사용하여 직접 설정할 수 있습니다. 부하 분산기가 설정되면 서버를 추가할 수 있습니다.
대부분의 클라우드 제공업체는 부하 분산 외에도 자동 확장 (GCP, AWS, Azure)을 제공합니다. 자동 확장은 부하 분산과 함께 작동합니다. 자동 확장은 특정 시점에 주어진 수요에 따라 컴퓨팅 리소스를 자동으로 확장 및 축소합니다. 하지만 자동 확장은 마법이 아닙니다. 새 인스턴스가 온라인 상태가 되기까지 시간이 걸리고 상당한 구성이 필요합니다. 자동 확장에는 추가적인 복잡성이 수반되므로 더 간단한 부하 분산기 기반 설정을 먼저 고려해야 합니다.
압축 사용
텍스트 기반 리소스는 gzip 또는 brotli를 사용하여 압축해야 합니다. Gzip을 사용하면 이러한 리소스의 전송 크기를 최대 70%까지 줄일 수 있습니다.
진단
Lighthouse 텍스트 압축 사용 감사를 사용하여 압축해야 하는 리소스를 식별합니다.
수정
서버 구성을 업데이트하여 압축을 사용 설정합니다. 안내:
이미지 및 미디어 최적화
대부분의 웹사이트에서 이미지가 파일 크기의 대부분을 차지합니다. 이미지를 최적화하면 사이트 크기를 빠르고 크게 줄일 수 있습니다.
진단
Lighthouse에는 잠재적인 이미지 최적화를 표시하는 다양한 감사 기능이 있습니다. 또는 DevTools를 사용하여 가장 큰 이미지 파일을 식별하는 방법도 있습니다. 이러한 이미지는 최적화하기에 적합할 수 있습니다.
관련 Lighthouse 감사:
Chrome DevTools 워크플로:
- 네트워크 활동 로깅
- Img를 클릭하여 이미지가 아닌 리소스를 제외합니다.
- 크기 열을 클릭하여 이미지 파일을 크기순으로 정렬합니다.
수정
시간이 부족한 경우…
자주 로드되는 대용량 이미지를 식별하고 Squoosh와 같은 도구로 수동으로 최적화하는 데 시간을 할애하세요. 히어로 이미지는 최적화하기에 좋은 이미지입니다.
주의사항:
- 크기: 이미지는 필요한 크기보다 크지 않아야 합니다.
- 압축: 일반적으로 품질 수준이 80~85이면 이미지 품질에 미치는 영향은 최소화되며 파일 크기는 30~40% 줄어듭니다.
- 형식: 사진에는 PNG 대신 JPEG를 사용하고 애니메이션 콘텐츠에는 GIF 대신 MP4를 사용하세요.
시간이 더 있는 경우…
이미지가 사이트의 상당 부분을 차지하는 경우 이미지 CDN을 설정해 보세요. 이미지 CDN은 이미지를 게재하고 최적화하도록 설계되었으며 원본 서버에서 이미지 게재를 오프로드합니다. 이미지 CDN을 설정하는 것은 간단하지만 기존 이미지 URL을 이미지 CDN을 가리키도록 업데이트해야 합니다.
추가 자료:
JS 및 CSS 축소
축소하면 JavaScript 및 CSS에서 불필요한 문자가 삭제됩니다.
진단
CSS 축소 및 JavaScript 축소 Lighthouse 감사를 사용하여 축소가 필요한 리소스를 식별합니다.
수정
시간이 제한되어 있다면 자바스크립트 축소에 집중하세요. 대부분의 사이트에는 CSS보다 JavaScript가 더 많으므로 이 변경사항의 영향이 더 큽니다.
모니터링
서버 모니터링 도구는 서버 성능과 관련된 데이터 수집, 대시보드, 알림을 제공합니다. 이를 사용하면 향후 서버 성능 문제를 방지하고 완화하는 데 도움이 됩니다.
모니터링 설정은 최대한 간단하게 유지해야 합니다. 과도한 데이터 수집 및 알림에는 비용이 발생합니다. 데이터 수집 범위 또는 빈도가 클수록 수집 및 저장하는 데 더 많은 비용이 듭니다. 과도한 알림은 피드백을 무시하게 됩니다.
알림은 문제를 일관되게 정확하게 감지하는 측정항목을 사용해야 합니다. 서버 응답 시간 (지연 시간)은 이 작업에 특히 적합한 측정항목입니다. 다양한 문제를 포착하고 사용자 환경과 직접적인 관련이 있습니다. CPU 사용량과 같은 하위 수준 측정항목을 기반으로 알림을 보내는 것도 유용하지만 문제의 일부만 포착할 수 있습니다. 또한 알림은 평균이 아닌 꼬리에서 관찰된 성능 (즉, 95번째 또는 99번째 백분위수)을 기반으로 해야 합니다. 그렇지 않으면 평균으로 인해 일부 사용자에게만 영향을 미치는 문제가 쉽게 가려질 수 있습니다.
수정
모든 주요 클라우드 제공업체는 자체 모니터링 도구 (GCP, AWS, Azure)를 제공합니다. 또한 Netdata는 훌륭한 무료 오픈소스 대안입니다. 어떤 도구를 선택하든 모니터링하려는 각 서버에 도구의 모니터링 에이전트를 설치해야 합니다. 완료되면 알림을 설정해야 합니다.
안내: