대규모 트래픽으로 인한 서버 과부하 해결방법
1. 이해하기
서버 과부하의 의미
서버가 리소스를 소진하여 들어오는 클라이언트의 요청을 처리하지 못할 때 발생한다.
서버는 사용자의 웹 요청을 처리하지 못해서 응답없음이 뜨게 된다.
503 error, 504 error 등
짧은 시간에 트래픽이 극도로 몰리는 이벤트나 티켓구매, 중계 서비스 같은 경우, 종종 발견할 수 있다.
2. 해결방법
2-1. 모니터링을 통한 자원 할당
서버 과부하의 원인은 다양하지만, 가장 큰 원인은 "자원의 한계점 도달" 때문이다.
서버의 CPU 사용량이 보통 80-90% 에 도달하게 되면, 메모리가 부족해서 계속 스와핑이 발생하면서 과부하가 발생하게 된다.
이는 모니터링을 통해서 자원을 적절하게 할당함으로써 미리 예방할 수 있다.
AWS 오토 스케일링
서비스가 이용 불가능해지기 전에 cloud watch 가 계속해서 모니터링 하면서 서버 대수를 늘려주는 방법을 취한다.
AWS 의 Auto Scaling 은 어플리케이션을 모니터링하고, 자원의 용량을 자동으로 조정해준다.
netdata 를 이용한 모니터링
AWS 이용하지 않는다면, 무료 모니터링 서비스도 있다.
이를 기반으로 지속적인 모니터링, 자원할당을 통해서 해결할 수 있다.
모니터링 방법
계속 모니터를 보고 있는 것이 아니다.
Slack 등 업무에서 사용하는 메신저 시스템과 연동하여 실시간으로 알림을 받을 수 있도록 한다.
설정한 임계치 기반으로 알림 서비스를 구축한다.
모니터링을 하는 이유
우선 장애가 발생하기 전에 미리 사전에 예방할 수 있다.
어떤 페이지에 어떤 트래픽이 얼마나 발생했는지, 어떤 네트워크에서 병목현상이 일어났는지 등을 기준으로 해결할 수 있다.
사용자들의 활용도가 높은 페이지, 낮은 페이지 등을 파악할 수 있어서 나중에 서비스 개선에도 도움이 된다.
2-2. 로드 밸런서
모니터링 및 Autu scaling 은 빠르긴 하지만 구성에 시간이 좀 걸린다. 따라서 앞단에서 로드밸런서를 통해 트래픽을 분산하는 것이 좋다.
로드밸런서는 한 서버에장애가 발생하면 다른 기능 서버로 리디렉션하여 시스템 중단을 방지할 수 있다.
보통은 오토스케일링과 로드밸런서를 같이 사용한다.
2-3. 블랙스완 프로토콜
시스템이 다운되면 블랙스완 프로토콜을 발령해서 다음과 같은 수칙을 따른다.
영향 받은 시스템과 각 시스템의 상대적 위험 수준을 확인한다.
체계적으로 데이터 수집, 원인에 대한 가설 수립, 테스팅
잠재적으로 영향받을 수 있는 내부의 모든 팀에 연락한다.
최대한 빨리 취약점에 영향을 받는 모든 시스템을 업데이트한다.
복원 계획을 포함한 우리의 대응 과정을 파트너와 고객 등 외부에 전달한다.
2-4. 서킷 브레이커
외부 서비스의 장애로 인해서 연쇄적 장애 전파를 막기 위해 자동으로 외부 서비스와 연결을 차단 및 복구하는 것을 말한다.
보통 MSA 로 구성된 프로젝트의 경우, 서킷 브레이커를 두는 경우가 많다. RPC 나 gRPC, HTTP 등을 기반으로 각각의 서비스들이 네트워크로 묶여있다.
그런데 네트워크 중 하나가 갑자기 오류가 발생하는 경우, 네트워크와 묶여있는 다른 서비스까지 오류의 영향을 받을 수가 있다.
예를 들면 다음과 같은 상황이 발생될 수 있다.
트래픽이 급증해서 API 서버 등 A 서비스의 응답이 느려진다.
A서비스의 응답이 느려지니, 응답이 지연된 클라이언트는 또 다시 A서비스에 요청을 보낸다.
이전 요청도 다 처리하지 못했는데, 계속 요청을 보내니, A서비스에 장애가 발생하게 된다.
A 서비스의 장애로 인해서 데이터를 제대로 수신하지 못하니, 관련된 다른 서비스에도 장애가 발생하게 된다.
보통은 2-3회 재시도로 정상적인 데이터 수신이 가능하다. 하지만 장애 상황의 경우에는 재시도를 하는 것이 의미도 없고, 오히려 다른 서비스에 영향을 끼칠수 있다.
서킷브레이커 동작
서킷브레이커는 서비스와 서비스 사이에 위치하여 관련한 함수가 함께 래핑된다.
네트워크의 장애를 모니터링 하면서, 특정 서비스가 timeout으로 설정된 시간을 초과하면, 몇 번 재시도를 한다.
여전히 timeout 이 발생하면 장애 상황으로 인식되어 서킷 브레이커가 trip 된다. 그 이후의 초과적인 호출은 발생하지 않도록 한다. -> fail fast
서킷 브레이커는 세 가지의 상태값을 갖는다.
closed : 정상적인 상태로 요청을 수행함. 네트워크 요청의 실패율이 임계치보다 낮은 상황
open : 오류를 기본적인 요청을 수행하지 않고, 빠르게 오류를 반환한다(fail fast). 네트워크 요청이 임계치보다 높은 상황.
일단 서킷 브레이커가 trip 되면, open 상태가 된다.
half-opened : open 상태에서 timeout 으로 설정된 시간이 지나면 장애가 해결되었는지 확인하기 위해서 half-opened 상태로 전환된다. 여기서 요청을 전송하여 응답을 확인한다. 장애가 풀리는지를 확인해서 성공하면 closed, 실패하면 다시 opened 상태로 변경
2-5. 콘텐츠 확인
불필요한 컨텐츠 제거
실제 인프런 장애 부검을 살펴보면, 불필요한 쿼리 등을 제거하여 문제를 해결한 경험을 살펴볼 수 있다.
CDN 을 통한 컨텐츠 제공
CDN 을 통해서 사용자 가까이 분산된 대규모 서버 네트워크를 기반으로 컨텐츠를 제공해서 메인 서버에 대한 부하를 줄여준다.
최초에는 메인 서버로부터 전달받고, 그 이후부터는 가까운 CDN 으로부터 데이터를 전달받음으로써, 속도도 빠르고 부하도 줄인다.
컨텐츠 캐싱
트래픽 해결하는 가장 좋은 방법은 트래픽이 발생하지 않도록 하는 것이다.
브라우저 캐시 (쿠키, 로컬 저장소, 세션 저장소) 등을 잘 활용하여 해당 요청에 관한 항목을 캐시에서 네트워크 응답을 읽어서 네트워크 요청에 대한 비용을 줄인다.
컨텐츠 압축
텍스트 기반 리소스는 보통 gzip, brotli 를 통해서 압축한다. 압축할 경우, 70% 까지 크기를 줄일 수 있기 때문에 효과적이다.
다만 서버에서 이 압출을 풀기위해 사용하는 CPU 자원 비용도 고려되어야 한다. 대부분의 경우는 고려하더라도 이득이다.
컨텐츠의 우아한 저하 - 미리 준비된 응답
시스템의 과도한 부하를 줄이기 위해서 제공하는 컨텐츠나 기능을 일시적으로 줄이는 것을 말한다.
정적 텍스트 페이지를 제공하거나 검색 기능을 비활성화 하거나 더 적은 검색 결과를 반환하거나 필수적이지 않은 기능들을 비활성화 한다.
Last updated
