오버로드된 서버 문제 해결

서버의 병목 현상을 확인하고 신속히 해결하며 서버 성능을 향상시키고 회귀를 방지하는 방법

Katie Hempenius
Katie Hempenius
X

개요

이 가이드에서는 오버로드된 서버를 4단계로 해결하는 방법을 보여줍니다.

  1. 평가: 서버의 병목 현상을 파악합니다.
  2. 안정화: 빠른 수정을 구현하여 영향을 완화합니다.
  3. 개선: 서버 기능을 강화하고 최적화합니다.
  4. 모니터링: 자동화된 도구를 사용하여 향후 문제를 방지합니다.

평가

트래픽이 서버에 과부하가 발생하면 CPU, 네트워크, 메모리 또는 디스크 I/O 중 하나 이상에서 병목 현상이 발생할 수 있습니다. 병목 현상을 식별하면 가장 영향력 있는 완화에 노력을 집중할 수 있습니다.

  • CPU: 지속적으로 80% 를 초과하는 CPU 사용량은 조사하여 해결해야 합니다. 서버 성능은 종종 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 사용' 버튼을 가리키는 화살표
WebPageTest 결과

수정

CDN에서 리소스를 캐시하지 않는 경우 다음 조건이 충족되는지 확인하세요.

컴퓨팅 리소스 확장

컴퓨팅 리소스 확장 결정은 신중하게 내려야 합니다. 컴퓨팅 리소스를 확장해야 하는 경우가 많지만 조기에 확장하면 불필요한 아키텍처 복잡성과 재정적 비용이 발생할 수 있습니다.

진단

첫 바이트 소요 시간 (TTFB)이 높으면 서버가 용량에 거의 도달했다는 신호일 수 있습니다. 이 정보는 Lighthouse 서버 응답 시간 단축 (TTFB) 감사에서 확인할 수 있습니다.

더 자세히 조사하려면 모니터링 도구를 사용하여 CPU 사용량을 평가하세요. 현재 또는 예상 CPU 사용량이 80% 를 초과하면 서버를 늘리는 것이 좋습니다.

수정

부하 분산기를 추가하면 여러 서버로 트래픽을 분산할 수 있습니다. 부하 분산기는 서버 풀 앞에 있으며 트래픽을 적절한 서버로 라우팅합니다. 클라우드 제공업체는 자체 부하 분산기 (GCP, AWS, Azure)를 제공하거나 사용자가 HAProxy 또는 NGINX를 사용하여 직접 부하 분산기를 설정할 수 있습니다. 부하 분산기가 준비되면 서버를 더 추가할 수 있습니다.

부하 분산 외에도 대부분의 클라우드 제공업체는 자동 확장 (GCP, AWS, Azure)을 제공합니다. 자동 확장은 부하 분산과 함께 작동합니다. 자동 확장은 지정된 시간에 컴퓨팅 리소스를 지정된 수요에 따라 자동으로 확장하거나 축소합니다. 그렇지만 자동 확장은 마법과도 같습니다. 새 인스턴스가 온라인 상태가 되는 데 시간이 걸리고 상당한 구성이 필요합니다. 자동 확장에는 복잡성이 가중되므로 더 간단한 부하 분산기 기반 설정을 먼저 고려해야 합니다.

압축 사용 설정

텍스트 기반 리소스는 gzip 또는 brotli를 사용하여 압축해야 합니다. Gzip은 이러한 리소스의 전송 크기를 최대 70%까지 줄일 수 있습니다.

진단

Lighthouse 텍스트 압축 사용 설정 감사를 사용하여 압축해야 하는 리소스를 식별합니다.

수정

서버 구성을 업데이트하여 압축을 사용 설정하세요. 안내:

이미지 및 미디어 최적화

대부분의 웹사이트에서는 이미지가 파일 크기의 대부분을 차지합니다. 이미지를 최적화하면 사이트의 크기를 신속하게 크게 줄일 수 있습니다.

진단

Lighthouse에는 잠재적인 이미지 최적화에 플래그를 지정하는 다양한 감사가 있습니다. 또는 DevTools를 사용하여 가장 큰 이미지 파일을 확인하는 방법도 있습니다. 이 이미지는 최적화에 적합할 수 있습니다.

관련 Lighthouse 감사:

Chrome DevTools 워크플로:

수정

시간이 여의치 않으시다면

대용량 및 자주 로드되는 이미지를 식별하고 Squoosh와 같은 도구를 사용하여 수동으로 최적화하는 데 더 많은 시간을 투자하세요. 히어로 이미지는 대개 최적화에 적합합니다.

주의해야 할 사항은 다음과 같습니다.

  • 크기: 이미지가 필요 이상으로 크지 않아야 합니다.
  • 압축: 일반적으로 품질 수준이 80~85이면 파일 크기는 30~40% 줄어들지만 이미지 품질에 최소한의 영향을 미칩니다.
  • 형식: 사진에 PNG가 아닌 JPEG를 사용하고, GIF가 아닌 애니메이션 콘텐츠에는 MP4를 사용하세요.

시간이 더 있으시다면

이미지가 사이트의 상당 부분을 차지하는 경우 이미지 CDN을 설정하는 것이 좋습니다. Image CDN은 이미지를 제공하고 최적화하도록 설계되었으며 원본 서버에서 이미지 제공을 오프로드합니다. 이미지 CDN을 설정하는 것은 간단하지만 이미지 CDN을 가리키도록 기존 이미지 URL을 업데이트해야 합니다.

추가 자료:

JS 및 CSS 축소

축소를 수행하면 자바스크립트 및 CSS에서 불필요한 문자가 삭제됩니다.

진단

Minify CSS 및 Minify JavaScript Lighthouse 감사를 사용하여 압축이 필요한 리소스를 식별합니다.

수정

시간이 한정되어 있다면 JavaScript를 축소하는 데 집중하세요. 대부분의 사이트는 CSS보다 자바스크립트가 더 많으므로 성능이 더 강력합니다.

모니터링

서버 모니터링 도구는 서버 성능에 관한 데이터 수집, 대시보드, 알림을 제공합니다. 이러한 파일을 사용하면 향후 서버 성능 문제를 방지하고 완화할 수 있습니다.

모니터링 설정은 최대한 간단하게 유지해야 합니다. 과도한 데이터 수집 및 알림에는 비용이 발생합니다. 데이터 수집의 범위나 빈도가 높을수록 수집 및 저장 비용이 높아집니다. 과도한 알림은 필연적으로 페이지를 무시하게 됩니다.

알림은 일관되고 정확하게 문제를 감지하는 측정항목을 사용해야 합니다. 서버 응답 시간 (지연 시간)은 이러한 점에서 특히 효과적인 측정항목입니다. 다양한 문제를 포착하고 사용자 환경과 직접적인 상관관계가 있습니다. CPU 사용량과 같은 하위 수준 측정항목을 기반으로 한 알림은 유용한 보완책이 될 수 있지만 문제의 하위 집합을 포착할 수 있습니다. 또한 알림은 평균이 아닌 꼬리 (즉, 95번째 또는 99번째 백분위수)에서 관찰된 성능을 기반으로 해야 합니다. 그렇지 않으면 평균값으로 일부 사용자에게 영향을 미치지 않는 문제점을 쉽게 파악할 수 있습니다.

수정

모든 주요 클라우드 제공업체는 자체 모니터링 도구 (GCP, AWS, Azure)를 제공합니다. 또한 Netdata는 훌륭한 무료 오픈소스 대안입니다. 어떤 도구를 선택하든 모니터링하려는 각 서버에 도구의 모니터링 에이전트를 설치해야 합니다. 완료되면 알림을 설정해야 합니다.

안내: