오버로드된 서버 문제 해결

서버의 병목 현상을 파악하고, 병목 현상을 빠르게 해결하고, 서버 성능을 개선하고, 회귀를 방지하는 방법

Katie Hempenius
Katie Hempenius
X

개요

이 가이드에서는 다음 4단계에 따라 과부하된 서버를 수정하는 방법을 보여줍니다.

  1. 평가: 서버의 병목 현상을 파악합니다.
  2. 안정화: 영향을 완화하기 위해 빠른 해결 방법을 구현합니다.
  3. 개선: 서버 기능을 보강하고 최적화합니다.
  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의 효과적인 사용' 버튼을 가리키는 화살표
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을 설정하는 것이 좋습니다. 이미지 CDN은 이미지를 제공하고 최적화하도록 설계되었으며 원본 서버에서 이미지 제공을 오프로드합니다. 이미지 CDN을 설정하는 것은 간단하지만 이미지 CDN을 가리키도록 기존 이미지 URL을 업데이트해야 합니다.

추가 자료:

JS 및 CSS 축소

압축은 JavaScript 및 CSS에서 불필요한 문자를 삭제합니다.

진단

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

수정

시간이 부족하다면 자바스크립트를 축소하는 데 집중하세요. 대부분의 사이트에는 CSS보다 JavaScript가 더 많으므로 이 방법이 더 효과적입니다.

모니터링

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

모니터링 설정은 최대한 단순하게 유지해야 합니다. 과도한 데이터 수집 및 알림에는 비용이 따릅니다. 데이터 수집의 범위나 빈도가 클수록 수집 및 저장 비용이 더 많이 들고, 과도한 알림은 필연적으로 페이지를 무시하게 만듭니다.

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

수정

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

안내: