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

2023_1_26_TIL

서버과부화

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

모니터링을 통한 자원 할당으로 해결

• 가장 큰 이유는 '자원의 한계점 도달'
• 서버의 CPU 사용량이 80-90%에 도달하거나 메모리가 부족해 계속해서 스와핑이 발생하면 과부화 상태가 됨
  • 모니터링을 통한 자원의 적절한 할당으로 해결
  • 자원 -> CPU 메모리 대역폭 등 포함
• AWS 오토스케일링
  • 서비스 이용불가능 상태 발생 이전 cloud watch가 계속해서 모니터링을 하여 서버 대수를 늘려주는 방법
    
  • AWS 오토스케일링은 에플리케이션을 모니터링하고 자원의 용량으 자동으로 조정
• netdata를 이용한 모니터링
  
  • AWS를 사용 하지 않을 경우
  • 이를 기반으로 지속적인 모니터링 자원할당을 해서 해결
  • 슬랙과 연동 가능
• 모니터링 하는 이유
  • 1. 어떤 페이지에 어떤 트래픽이 얼마나 발생?
  • 2. 어떤 네트워크에서 병목현상이 발생?
  • 모니터링을 하면 활용도가 낮은 페이지, 높은 페이지를 파악할 수 있어 나중에 서비스 개선이도 도움이 됨
  • 즉, 해결하기 위한 문제점을 파악하기 위해 모니터링(필수)
• 로드 밸런서
  • AWS 오토스케일링은 빠르긴 하나 구성에 시간이 걸림 -> 앞단에 로드벨런서를 둬 트래픽 분산
    
  • 한 서버에 장애가 발생하면 로드벨런서는 트래픽을 다른 기능 서버로 리디렉션하여 시스템 중단을 방지
• 블랙스완 프로토콜
  • 1. 영향을 받은 시스템고 각시스템의 상대적 위험 수준을 확인
    • 체계적으로 데이터를 수집하고 원인에 대한 가설을 수립한 후 이를 테스팅
  • 2. 잠재적으로 영향을 바을 수 있는 내부의 모든 팀에 연락
  • 3. 최대한 빨리 취약점에 영향을 받는 모든 시스템을 업데이트
  • 4. 복원계획을 포함한 우리의 대응 과정을 파트너와 고객 등 외부에 전달

서킷 브레이커 -> 실패 포용 전략

• 외부 서비스의 장애로 인한 연쇄적 장애 전파를 막기 위해 자동을 외부 서비스와 연결을 차단 및 복구하는 것을 말함(방화벽)
• 보통 MSA(RPC HTTP gRPC기반으로 각각의 서비스들이 네트워크로 묶여있음)를 할 때 서킷 브레이커를 장착
• 트래픽 폭증 -> 오류 -> 연쇄적으로 발생 가능성 있음
  • 따라서 서비스와 서비스 사이에 스킷브레이커를 넣자는 것
  • 서킷 브레이커에 관련 함수 mapping
    • 특정 서비스가 timeout으로 설정된 시간을 초과하면 몇번의 요청을 한 이후 계속해서 timeout으로 설전된 시간을 처과하면 장애로 인식
    • 서킷 브레이커 발동 -> trip되며 이후 추가적인 호출은 발생 X(fail fast)
• 서킷 브레이커 상태값
  • open -> trip 이후, 임계치 이상의 상태, 요청을 전송하지 않고 바로 오류를 반환
    • closed 상태라면 기본적인 요청을 수행하지만 open된 상태라면 오류를 기본적인 요청을 수행하지 않고 빠르게 오류를 변환
  • closed -> 네트워크 요청의 실패율이 임계치보다 낮음(정상)
  • half - open(실눈 뜬것)
    • open상태에서 일정 timeout으로 설정된 시간이 지나면 장애가 해결되었는지 확인하기 위해 half-open상태로 전환
    • 여기서 요청을 전송 후 응답을 확인하고 -> 장애가 풀리는지 확인 closed면 성공 open이면 실패

컨텐츠 확인

• 불필요한 컨텐츠 제거
• CDN을 통한 컨텐츠 제공
  • CDN을 통해 사용자 가까이, 그리고 분산된 대규모 서버 네트워크를 기반으로 컨텐츠를 제공해서 메인 서버에 대한 부하를 줄이기
    
• 컨텐츠 캐싱
  • 브라우저 캐시를 통해 해당 요청에 관한 항목을 캐시에서 응답을 읽어 네트워크 요청에 관한 비용을 모두 제거
• 컨텐츠 압축
  • 텍스트 기반 리소스는 gzip 또는 Brotli를 통해 압축해야 함
  • 압축하면 70%정도 압축 가능
  • 다만 압축했기 때문에 압축을 풀기위해 서버에서 자원(CPU)를 사용하는 양까지 고려해야 함
• 컨텐츠의 우아한 저하(미리 준비된 응답)
  • 시스템의 과도한 부하를 줄이기 위해 제공하는 컨텐츠 및 기능을 일시적으로 줄이는 전략
  • 요청(10) 이지만 응답(1)에 해당하는 서비스만 제공

참조

https://docs.aws.amazon.com/ko_kr/AmazonCloudWatch/latest/monitoring/GettingStarted.html
https://learn.netdata.cloud/docs/overview/what-is-netdata
https://tecoble.techcourse.co.kr/post/2021-11-07-load-balancing/
https://medium.com/@jegasingamjeyanthasingam/circuit-breaker-pattern-for-microservices-eb71569dc44d
https://ko.itpedia.nl/2018/09/24/content-delivery-network-cdn-uitgelegd/