Table of Contents
서비스 장애
- 서버 인프라, 애플리케이션 코드 등의 문제로 요청 실패가 계속 발생할 때 서비스에 장애가 발생했다고 한다
- 서비스 장애는 얼마나 많은 요청이 일정 시간 동안 실패하는지에 따라 장애의 단계가 결정된다
- 예를 들어, 요청 수를 3분 단위로 집계했을 때, 요청 실패의 비율이 3~5% 인 경우 minor, 5~10% 인 경우 major, 10~20%인 경우 critical 등
- 서비스 장애가 심각해질 경우 이용자 이탈, 피해 보상과 같은 문제로 이어지기 때문에 신속하고 정확하게 대응하는 것이 중요하다
장애 대응
- 서비스 장애의 원인은 예측 가능한 범주 내에 있는 것도 있지만, 예측 할 수 없는 범주에 있는 경우도 있기 때문에, 장애가 발생 했을 때 이를 어떻게 대응하는지가 중요하다
- 장애 대응을 하기 위해서는, 장애라고 판단할 만한 지표를 구하는데 필요한 값들을 로깅∙모니터링 하고, 지표가 장애가 발생했다고 판단되는 기준값을 넘어서는 경우 사내 전체에 알림을 보내야 한다
- 장애를 대응할 때는, 원인 분석보다는 서비스 정상화에 가장 먼저 초점을 맞춘다
장애 지표
- 회원가입 / 검색 / 주문 / 등록 과 같은 서비스의 주요 요청
- CPU, 메모리, DB 커넥션 등과 같은 시스템 정보
알림 방식
- 전화, 이메일, 카카오톡, 슬랙 등
- 장애 단계, 발생 시간, 장애 원인(지표) 등과 같은 요소를 포함한 메세지를 사내 전체에 위의 방식으로 전파한다
장애 대응 절차
- 장애가 발생한 경우, 사내 전체에 알림을 전파한다
- 관련 관리자들을 선정하고, 관련 관리자들을 위한 소통 채널을 생성한다
- 채널에 모인 관리자들은 대응 방안을 모색하고 장애 해결을 시도하고 관련 과정을 공유한다
- 장애가 해결된 경우, 이에 대한 결과를 사내 전체에 공유한다
- 이 후 장애가 발생했던 이유와 해결 방법에 관한 내용을 기록하고 공유함으로써 재발을 방지한다
장애 대응 예시
- 장애를 대응할 때는, 원인 분석보다는 서비스 정상화에 가장 먼저 초점을 맞춘다
- 정상적으로 동작하던 때의 버전으로 롤백한다
- 트래픽 문제일 경우 서버를 스케일 아웃한다
- 장애의 연쇄적으로 전파되지 않도록 장애가 발생한 부분을 일시 중지시킨다