대규모 트래픽으로 인한 서버 과부하 해결

이강용·2024년 6월 28일

CS

목록 보기

74/109

서버 과부하의 의미

서버 리소스를 소진하여 들어오는 요청을 처리하지 못할 때 발생
이 때 서버는 사용자의 웹 요청을 처리하지 못해 응답 없음 또는 지연이 발생하게 됨

서버 과부하는 웹사이트 또는 애플리케이션의 성능을 저하시켜 사용자 경험을 크게 손상시킬 수 있음
- 이는 트래픽이 급증할 때 특히 두드러지며, 이러한 상황을 적절히 대처하지 못하면 서비스 중단으로 이어질 수 있음

해결 방법

모니터링을 통한 자원 할당

서버 과부하의 주요 원인 중 하나는 서버 자원의 한계점 도달임
- 보통 서버의 CPU 사용량이 80 - 90%에 도달하거나 메모리가 부족해 계속해서 스와핑이 발생하면 과부하 상태가 됨
  👉🏻 모니터링을 통해 자원의 사용 현황을 지속적으로 관찰하고 필요에 따라 자원을 적절히 할당함으로써 서버 과부하를 예방할 수 있음 (자원은 CPU, 메모리, 대역폭 포함)
  
  AWS 오토스케일링
- 애플리케이션을 모니터링하고 자원의 용량을 자동으로 조정하는 서비스
  - 서비스 이용 불가능 상태가 발생하기 전에 AWS의 CloudWatch가 서버 상태를 지속적으로 모니터링하여 필요 시 서버 대수를 자동적으로 늘려줌
  - 이를 통해 트래픽 급증 시에도 안정적인 서비스 제공이 가능함
  NETDATA를 이용한 모니터링
  
  https://github.com/netdata/netdata (무료 모니터링 서비스)
- Netdata는 무료로 사용할 수 있는 모니터링 도구로 시스템 자원의 실시간 모니터링을 제공함
- 이를 통해 서버 상태를 실시간으로 파악하고 문제 발생 시 즉작적인 대응이 가능함
- slack과 연동하여 설정한 임계치(Threshold)를 기반으로 알림 서비스를 구축할 수 있음
  
  로드밸런서
- 트래픽을 여러 서버에 분산시켜 특정 서버에 과부하가 걸리지 않도록 함
  - 한 서버에 장애가 발생하면 로드 밸런서는 트래픽을 다른 가능 서버로 리디렉션하여 시스템 중단을 방지할 수 있음
  블랙스완 프로토콜
- 예측할 수 없는 사고가 발생하는 것
  - 사후에는 이 사고의 원인 등을 분석할 수 있지만 사전에는 이 사고를 예측할 수 없는 것을 말함
    
    구글의 블랙스완 수칙
  1. 영향을 받는 시스템과 각 시스템의 상대적 위험 수준을 확인
    - 체계적으로 데이터를 수집하고 원인에 대한 가설을 수립한 후 이를 테스팅
  2. 잠재적으로 영향을 받을 수 있는 내부의 모든 팀에 연락
  3. 최대한 빨리 취약점에 영향을 받는 모든 시스템을 업데이트
  4. 복원계획을 포함한 우리의 대응 과정을 파트너와 고객 등 외부에 전달
  모니터링을 왜 할까?
- 서버 과부하로 인해 발생할 수 있는 서버 중지에 대한 사전 대처가 가능함
  - 1. 어떤 페이지에서 어떤 트래픽이 얼마나 발생했는지 파악할 수 있음
  - 1. 어떤 네트워크에서 병목현상이 일어나는지 분석할 수 있음
- 이를 통해 활용도가 낮은 페이지와 높은 페이지를 파악하여 서비스 개선에 도움이 됨

서킷 브레이커

서비스 장애를 감지하고 연쇄적으로 생기는 에러를 방지하는 기법
서비스와 서비스 사이에 서킷 브레이커 계층을 두고 미리 설정해 놓은 timeout 임계값에 도달하면 서킷 브레이커가 그 이후의 추가 호출에 무조건 에러를 반환하게 함으로써 연쇄적 오류 전파를 막음

Cascading Failure 현상

Cascading Failure는 하나 이상의 부품 또는 서비스 등의 고장이 연결된 다른 부품이나 서비스의 고장으로 이어지는 현상을 말함

👉🏻 사용자 입장에서 응답을 오래 기다려야 하는 것은 좋은 UX가 아님, 성공인지 실패인지는 중요하지 않음
❗️ 중요한 것은 사용자가 기다리지 않아야 한다는 점

서킷브레이커 동작 과정

응답 성공 시	응답 실패 시

서킷브레이커의 상태

서킷브레이커는 closed, open, half_open의 상태값을 가짐

closed[정상] : 네트워크 요청의 실패율이 임계치보다 낮은 상태, 모든 요청이 정상적으로 처리

open[에러] : 임계치 이상의 상태로, 요청을 서비스로 전송하지 않고 바로 오류를 반환

이를 fail fast라고 함

half_open[확인중] : open 상태에서 일정 timeout 시간이 지나면 장애가 해결됐는지 확인하기 위해 half_open상태로 전환됨, 이때 일부 요청을 전송하여 응답을 확인, 장애가 해결되면 closed 상태로, 실패하면 다시 open 상태로 전환

서킷브레이커의 장점

연속적인 에러 발생을 방지하여 시스템의 안정성을 높임
일부 서비스가 종료되더라도 다른 서비스들이 정상적으로 동작하게 만들어 사용자 경험을 개선
시스템 전체의 과부하를 방지하여 안정적인 서비스 제공이 가능

서킷브레이커가 구현된 라이브러리

https://github.com/Netflix/Hystrix
👉🏻 넷플릭스가 개발한 서킷 브레이커 라이브러리로, 마이크로서비스 아키텍처에 널리 사용
https://github.com/resilience4j/resilience4j
👉🏻 서킷 브레이커, 레이트 리미터, 리트라이 등의 기능을 제공하는 경량의 폴리시 라이브러리

컨텐츠 관리

불필요한 컨텐츠 제거

인프런의 장애 복구 사례 - 불필요한 쿼리 제거

https://tech.inflab.com/202201-event-postmortem/

CDN을 통한 컨텐츠 제공

CDN(Content Delivery Network)는 지리적으로 분산된 서버 네트워크를 통해 사용자에게 컨텐츠를 빠르게 전달하는 기술
CDN을 사용하면 웹 페이지 로딩 속도가 빨라지고 서버 부하가 감소하며 DDoS 공격으로부터 보호할 수 있음

컨텐츠 캐싱

네트워크 트래픽을 줄이는 가장 좋은 방법은 해당 트래픽이 발생하지 않도록 하는 것
브라우저 캐시(쿠키, 로컬 저장소, 세션 저장소)를 통해 이전에 요청한 항목을 캐시에서 응답으로 읽어 네트워크 요청을 회피할 수 있음, 이를 통해 서버 부하를 크게 줄일 수 있음

컨텐츠 압축

텍스트 기반 리소스는 gzip 또는 Brotli를 통해 압축해야 함
압축하면 70% 정도까지 압축할 수 있음, 다만 압축했기 때문에 압축을 풀기위해 서버에서 자원(CPU)을 사용하는 양까지 고려해야 함

컨텐츠의 우아한 성능 저하(미리 준비된 응답)

시스템의 과도한 부하를 줄이기 위해 제공하는 컨텐츠 및 기능을 일시적으로 줄이는 전략
- 예를들어, 정적 테스트 페이지를 제공하거나 검색을 비활성화하거나 더 적은 수의 검색 결과를 반환하거나 필수적이지 않는 기능을 비활성화 함
  
  실제 사례
  
  정상 상태 대규모 트래픽 발생 당시