📌 서버 과부하
- 서버가 리소스를 소진하여 들어오는 요청을 처리하지 못하는 현상
- 서버는 사용자의 웹요청을 처리하지 못해 응답없음 화면이 뜨게됨
⭐ 해결방법 - 모니터링을 통한 자원 할당
- 서버과부하의 대부분 원인은
자원의 한계점 도달 - 서버의 CPU 사용량이 80-90%에 도달하거나 메모리가 부족해 계속해서 스와핑이 발생하면 과부하 상태가 됨
✅ AWS 오토스케일링
- 서비스 이용불가능 상태 발생 이전
Cloud Watch가 계속해서 모니터링하여 서버의 개수를 늘려주는 방법 - 애플리케이션을 자동으로 모니터링하고 자원의 용량을 자동으로 조정함
✅ Netdata를 이용한 모니터링
- AWS를 사용하지 않을 때 사용할 수 있는 무료 모니터링 서비스
- 설정한
임계치를 기반으로 Slack 알림 서비스를 구축할 수 있음
✅ 모니터링을 하는 이유
- 어떤 페이지에서 어떤 트래픽이 얼마나 발생했는지 알 수 있음
- 어떤 네트워크에서 병목현상이 일어났는지 알수 있음
- 모니터링을 통해 활용도가 높고 낮은 페이지를 파악할 수 있어 서비스 개선에 도움이 됨
- 일부 서비스는 모니터링한 결과물을 알려주면서 서비스의 중단 여부를 사용자에게 알려줌
ex) Cloudflare
⭐ 로드밸런서
- AWS 오토스케일링은 빠르긴 하나 구성에 시간이 걸리기 때문에 로드밸런서를 활용해서 트래픽을 분산함
- 한 서버에 장애가 발생하면 로드밸런서는 트래픽을 다른 서버로 리디렉션하여 시스템 중단을 방지할 수 있음
⭐ 블랙스완 프로토콜
- 예측할 수 없는 사고가 일어난 것을 말함
✅ GOOGLE의 블랙스완 발생시 수칙
- 영향을 받은 시스템과 각 시스템의 상대적 위험수준 확인
- 잠재적으로 영향을 받을 수 있는 내부의 모든 팀에 연락
- 최대한 빨리 취약점에 영향을 받는 모든 시스템을 업데이트
- 복원계획을 포함한 우리의 대응과정을 파트너와 고객 등 외부에 전달
⭐ 서킷 브레이커
- 서비스 장애를 감지하고 연쇄적으로 생기는 에러를 방지하는 기법
- 서비스와 서비스 사이에 서킷브레이커 계층을 두고 미리 설정해놓은 TIMEOUT 임계값에 도달하면 서킷브레이커가 그 이후의 추가호출에 대해 무조건 에러를 반환하게 하는 것
연쇄적인 오류전파를 끝냄- 사용자 입장에서 응답을 오래 기다려야하는 것은 좋은 UX가 아님. 성공인지 실패인지가 중요한게 아닌 기다리지 않아야 함
✅ 서킷브레이커 동작과정
✅ 서킷브레이커의 상태
CLOSED(정상)
- 네트워크 요청의 실패율이 임계치보다 낮음
OPEN(에러)
- 임계치 이상의 상태
- 요청을 서비스로 전송하지 않고 바로 오류를 반환
HALF_OPEN(확인중)
- OPEN상태에서 일정 TIMEOUT으로 설정된 시간이 지나면 장애가 해결되었는지 확인하기 위해 HALF_OPEN 상태로 전환
- 요청을 전송해서 응답을 확인 -> 성공하면 CLOSED, 실패하면 OPEN으로 변경
✅ 서킷브레이커의 장점
- 연속적인 에러 발생을 막아줌
- 일부서비스가 종료되더라도 다른 서비스들은 이상없이 동작하게 만들 수 있음
- 사용자의 경험(UX)를 높여줌
✅ 서킷브레이커 라이브러리
- 넷플릭스의 Hystrix
- Resilience4j
⭐ 컨텐츠 관리
-
불필요한 컨텐츠 제거
ex) 불필요 쿼리 -
CDN을 통한 컨텐츠 제공
- 대규모 서버 네트워크를 기반으로 컨텐츠를 제공해서 메인서버에 대한 부하를 줄임
-
컨텐츠 캐싱
- 캐시를 통해 해당 요청에 관한 항목을 캐시에서 응답을 읽어 네트워크 요청에 관한 비용을 제거 -
컨텐츠 압축
- 텍스트 기반 리소스는 압축가능(gzip) -
컨텐츠의 우아한 저하
ex) 정적 페이지 제공, 검색/비필수 기능 비활성화, 경량화된 컨텐츠만 제공
