[네트워크] 대규모 트래픽으로 인한 서버 과부하 해결 방법 5가지

서버 과부하란 서버가 리소스를 소진하여 들어오는 요청을 처리하지 못할 때 발생한다.

이 때 서버는 사용자의 웹 요청을 처리하지 못하며, 사용자에게 응답 없음이 뜬다.

 

이런 서버 과부하를 예방하거나, 해결할 수 있는

대표적인 방법 5가지를 알아보자.

 

1. 모니터링을 통한 자원 할당

서버 과부하로 서버가 응답없음이 드는 데에는 여러 이유가 있지만,

그 중 하나가 자원의 한계점 도달이다.

 

보통 서버의 CPU 사용량이 80~90%에 도달하거나

메모리가 부족하여 스와핑이 계속 발생하면 과부하 상태가 된다.

 

이는 모니터링을 통한 자원의 적절한 할당으로 해결할 수 있다.

자원은 CPU, 메모리, 대역폭을 포함한다.

 

AWS 오토스케일링 (auto scaling)

AWS 오토스케일링이란 서비스 이용 불가 상태 발생 이전에

cloud watch가 계속해서 모니터링하여 서버 대수를 늘려주는 방법이다.

애플리케이션을 자동으로 모니터링하고 자원을 용량을 자동으로 조정한다.

 

netdata를 이용한 모니터링

AWS를 사용하지 않는 경우, 무료 모니터링 서비스를 사용할 수 있다.

https://github.com/netdata/netdata

GitHub - netdata/netdata: Monitor your servers, containers, and applications, in high-resolution and in real-time!

이를 기반으로 지속적인 모니터링, 자원할당을 하여 해결할 수 있다.

 

개발자는 모니터링 대시보드를 매번 확인할 필요 없이,

slack과 연동하여 설정한 특정 임계치를 기반으로 알림 서비스를 구축할 수 있다.

 

모니터링의 효용성

1. 서버 과부하로 인한 서버 중지에 대한 대처가 가능하다. 아래 두 정보 등을 알 수 있다.
   1. 어떤 페이지에 어떤 트래픽이 얼마나 발생했는지
   2. 어떤 네트워크에서 병목 현상이 일어났는지
2. 활용도가 낮은 페이지, 높은 페이지를 파악하여 추후 서비스 개선에 활용할 수 있다. 즉, 문제점 파악을 위해 모니터링은 필수적이다.
3. 일부 서비스는 모니터링한 결과물과 함께 서비스 중단 등의 여부를 사용자에게 알려주기도 한다. (e.g., cloudflare https://www.cloudflarestatus.com

Cloudflare Status

 

2. 로드 밸런서

위 설명된 AWS 오토스케일링은 빠르긴 하나, 구성에 시간이 걸리기 때문에

앞단에 로드 밸런서를 설치하여 트래픽을 분산해야 한다.

 

로드 밸런서는 한 서버에 장애가 발생하면 트래픽을 다른 기능 서버로 리디렉션하여

시스템 중단을 방지할 수도 있다.

 

3. 블랙스완 프로토콜

블랙스완은 단어 그대로는 흑조를 뜻하지만, 프로그래밍에서는 예측할 수 없는 사고가 일어난 것을 말한다.

흑조의 존재를 미리 알지 못했던 인류가 처음 흑조를 발견하고 충격에 빠졌다가, 이후 흑조를 분석한 것에서 유래했다. 

즉, 사후에는 이 사고의 원인을 분석할 수 있지만, 사전에는 예측할 수 없는 상황을 말한다.

 

블랙스완은 언제든 발생할 수 있기 때문에, 블랙스완에 대한 대비를 해야 한다.

 

아래는 구글의 블랙스완 발생 대비 수칙이다.

서비스를 운영할 때에 이러한 규칙을 정해두는 것이 좋다.

1. 영향을 받은 시스템과 각 시스템의 상대적 위험 수준을 확인한다. - 체계적으로 데이터를 수집하고 원인에 대한 가설을 수립한 후 이를 테스팅함
2. 잠재적으로 영향을 받을 수 있는 내부의 모든 팀에 연락한다.
3. 최대한 빨리 취약점에 여향을 받는 모든 시스템을 업데이트한다.
4. 복원 계획을 포함한 우리의 대응 과정을 파트너, 고객 등 외부에 전달한다.

 

4. 서킷 브레이커

서킷 브레이커 패턴이라고도 불리며,

서비스 장애를 감지하고, 연쇄적으로 발생하게 되는 에러를 방지하는 기법이다.

 

서비스와 서비스 사이에 서킷 브레이커 계층을 두고

미리 설정해둔 timeout 임계값에 도달하면

서킷 브레이커가 그 이후의 추가 호출에 무조건 에러를 반환하게 한다. 

 

아래는 서킷 브레이커가 필요한 사례 예시이다.

1. 스레드의 차단: 하나의 스레드가 차단되는 것은 괜찮다. 그러나 100개의 스레드가 있고, 그 중 98개의 요청이 에러가 있는 서비스에 요청한다면 나머지 2개의 요청은 차단된다.
2. 계단식 실패 발생: 서비스들이 서로 연결되어 있는 상황에서는 한 서비스에 에러가 발생하면, 나머지 서비스 응답도 지연되게 되어, 계단식 실패가 발생한다. 계단식 실패(cascading failure)는 하나 이상의 부품, 서비스 등의 고장이 연결된 다른 부품, 서비스의 고장으로 이어지는 것을 말한다.

사용자 입장에서 응답을 오래 기다리는 것은 좋은 UX가 아니다. 성공, 실패 여부보다도 기다리지 않는 것이 더 중요하다.

 

상태

서킷 브레이커의 상태에는 아래 3가지가 있다.

• closed(정상): 네트워크 요청의 실패율이 임계치보다 낮음
• open(에러): 실패율이 임계치 이상인 상태. 요청을 서비스로 전송하지 않고, 바로 오류를 반환한다. Fail Fast라고 한다.
• half_open(확인 중): open 상태에서 일정 timeout으로 설정된 시간이 지나면, 장애가 해결되었는지 확인하기 위해 half_open 상태로 전환된다. 여기서 요청을 전송하여 다시 응답을 확인한다. 장애가 풀렸는지 확인하여, 성공하면 closed, 실패하면 open으로 상태를 변경한다.

 

장점

연속적인 에러 발생을 막아주고, 일부 서비스가 종료되더라도

다른 서비스들은 이상 없이 동작하게 만들 수 있어 사용자 경험을 높인다.

 

서킷 브레이커가 구현된 라이브러리로는 넷플릭스의 Hystrix와 Resilience4j가 대표적이다.

 

5. 콘텐츠 관리

1) 불필요한 콘텐츠 제거

불필요하게 호출되거나, 전송되는 콘텐츠를 제거한다.

 

2) CDN을 통한 콘텐츠 제공

CDN을 통해 사용자 가까이, 분산된 대규모 서버 네트워크를 기반으로 콘텐츠를 제공하여

메인 서버에 대한 부하를 줄인다.

 

3) 콘텐츠 캐싱

네트워크 트래픽을 해결하는 가장 좋은 방법은 해당 트래픽이 발생하지 않도록  하는 것이다.

브라우저 캐시(쿠키, 로컬 스토리지, 세션 스토리지)를 통해

요청 항목을 캐시에서 응답을 읽어

네트워크 요청에 대한 비용을 제거할 수 있다.

 

4) 콘텐츠 압축

텍스트 기반 리소스는 gzip 또는 Brotli를 통해 압축해야 한다.

압축을 통해 70%까지 줄일 수 있다.

다만, 압축을 풀기 위해 서버에서 자원(CPU)를 사용해야 함을 고려해야 하지만, 

보통은 압축하는 것이 더 효율적이다.

 

5) 콘텐츠의 우하한 저하(미리 준비된 응답)

시스템의 과도한 부하를 줄이기 위해

제공하는 콘텐츠 및 기능을 일시적으로 줄이는 전략이다.

예컨대, 정적 텍스트 페이지를 제공하거나,

검색을 비활성화 하거나,

더 적은 수의 검색 결과를 반환하거나,

필수적이지 않은 기능을 비활성화 한다.

 

실제로 일본의 nhk가 최근 트래픽이 많이 발생한 상황에서

이미지 동영상 등을 제외하고 주요한 텍스트만 제공하는 방식으로 대처했다.

 

참고: inflearn 강의 'CS 지식의 정석 - 큰돌'