CS 전공지식 정리 - 네트워크 심화

제훈·2025년 3월 4일

Study

목록 보기

30/30

대규모 트래픽으로 인한 서버 과부하 해결방법에 대해 알아보자.

서버 과부하

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

이 때 서버는 사용자의 웹요청을 처리하지 못해 응답없음이 뜨게 된다.

해결방법

모니터링을 통한 자원 할당

서버가 응답없음이 뜨는 것은 여러가지 이유가 있지만 그 중 하나가 바로 자원의 한계점 도달 이다.

보통 서버의 CPU 사용량이 80-90%에 도달하거나 메모리가 부족해 계속해서 스와핑이 발생하면 과부화 상태가 됩니다.

스와핑에 대해

가상 메모리는 존재하는데 실제 메모리인 RAM 에는 현재 없는 데이터 or 코드에 접근하는 경우
-> 페이지 폴트 발생

스와핑 : 메모리에서 당장 사용하지 않는 영역을 하드디스크로 옮기고 하드디스크의 일부를 메모리처럼 불러와 쓰는 것

마치 페이지 폴트가 발생하지 않은 것처럼 만든다.

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

자원에 속하는 것들

CPU
메모리
대역폭

AWS 오토스케일링

AWS 오토스케일링이란 인스턴스가 있을 때 사용자가 몰리게 돼서 서비스 이용 불가능 상태 발생하기 이전에 cloud watch가 계속해서 모니터링하여 서버 대수를 늘려주는 방법입니다.

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

netdata를 이용한 모니터링

만약 AWS를 사용하지 않는다고 했을 때 무료 모니터링 서비스도 있다.

https://github.com/netdata/netdata
이를 기반으로 지속적인 모니터링, 그리고 이를 기반으로 자원할당을 해서 해결할 수도
있다.

위와 같은 화면은 slack 과 연동해 임계치를 기반으로 알림 서비스 또한 구축 가능하다.

모니터링 하는 이유

모니터링을 왜 할까?

먼저 서버과부화로 인해 서버 중지에 대한 대처를 할 수 있다.
1. 어떤 페이지에 어떤트래픽이 얼마나 발생했느냐.
2. 어떤 네트워크에서 병목현상이 일어났냐.

등을 모니터링에서는 알려준다.

또한 모니터링을 하면 활용도가 낮은 페이지, 높은 페이지를 파악할 수 있어 나중에 서비스 개선에도 도움이 된다.

즉, 해결하기 위한 문제점을 파악하기 위해 모니터링은 필수

또 일부 서비스는 모니터링한 결과물을 알려주면서 서비스의 중단 등의 여부를 사용자에게 알려주기도 한다.

ex) cloudflare -> https://www.cloudflarestatus.com/

로드밸런서

앞서 설명한 AWS 오토스케일링은 빠르긴 하나 구성에 시간이 걸리기 때문에 앞단에 로드밸런서를 통해 트래픽을 분산해야 한다.

또한, 로드밸런서는 한 서버에 장애가 발생하면 로드 밸런서는 트래픽을 다른 기능 서버로 리디렉션하여 시스템 중단을 방지할 수도 있다.

블랙스완 프로토콜

블랙스완 : 예측할 수 없는 사고

중요한 것은 이러한 블랙스완은 매번 일어나기 때문에 이에 따라 대비를 해야 한다.

구글의 블랙스완이 발생 시 수칙

영향을 받은 시스템과 각 시스템의 상대적 위험 수준을 확인

체계적으로 데이터를 수집하고 원인에 대한 가설을 수립한 후 이를 테스팅

잠재적으로 영향을 받을 수 있는 내부의 모든 팀에 연락
최대한 빨리 취약점에 영향을 받는 모든 시스템을 업데이트
복원계획을 포함한 우리의 대응 과정을 파트너와 고객 등 외부에 전달

서킷 브레이커

서비스 장애를 감지하고 연쇄적으로 생기는 에러를 방지하는 기법

서비스와 서비스 사이에 서킷브레이커 계층을 두고 미리 설정해놓은 timeout 임계값에 도달하면 서킷브레이커가 그 이후의 추가 호출에 무조건 에러를 반환

만약 서비스 A, B, C가 있고 결제 서비스라고 했을 때 A는 개인정보, B는 장바구니, C는 미리 결정해둔 카드 정보들을 관리. 그리고 A, B, C 끼리 HTTP로 통신한다고 하자.

만약 스레드가 100개 중 98개는 A에 요청, 나머지 2개는 각각 B, C에 요청한다고 하자.

근데 A가 고장나버린다면.. 기다리는 동안 B와 C에 대해서도 스레드가 차단될 수도 있다.

이것을 스레드 차단이라고 한다.

혹은

A <-> B
B <-> C

가 연결돼 있는데 A가 고장나버리면 B가 멈추게 되고, 연쇄적으로 C도 멈추게 된다.

이것을 계단식 에러라고 한다.

이럴 때를 대비해서 서비스 사이에 서킷 브레이커를 두고 에러를 방지하는 것이다.

에러가 고쳐질 때까지 기다리는게 뭐가 어때서? 라고 생각한다면.

사용자 입장에서 응답을 오래 기다려야 하는 것은 좋은 UX가 아니다. 성공인지 실패인지는 중요하지 않다. 중요한 것은 사용자가 기다리지 않아야 한다는 점이다.

동작과정

이렇게 정상적으로 작동하던 서비스가 있다고 가정했을 때

아래 사진처럼 Supplier Microservice 가 고장나게 된다면 바로 에러를 반환한다.

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

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