[goorm 세미나] 트래픽이 몰려온다, 장애 대응 - 강대명님
본 포스팅은 강대명님이 발표하신,
goorm 3회 세미나 트래픽이 몰려온다 장애 대응을 요약한 내용 입니다
1. 어느 날 갑자기 장애가 발생한다면?
- 팀이 장애가 난 것을 알고 있는지?
- 고객문의(CS)를 통해서 안다? = 최악의 상황
1.1 만약, 고객이 먼저 장애를 접한다면?
- 고객 불만
- 고객수 감소(이탈)
- 회사 매출 감소
- 내가 짤린다(?)
즉, 고객보다 먼저 장애를 인지 하는 것이 중요하다.
1.2 만약, 회사에서 먼저 인지한다면?
- 장애를 인지한다.
- 고객이 발견하기 전에, 수정한다
- 조용히 배포한다.
- 없던 일로 만든다
운영에서 이를 인지하고 해결하는것이 필요하다.
즉, 서비스가 제대로 돌아가고 있는지 계속 확인해야함.
모니터링을 통해, 현재의 상황을 인지 하는것이 중요
Q) 무엇을 모니터링 하는게 좋은지?
서비스에 영향을 줄 수 있는 모든 것
CPU, RAM, DISK, NETWORK, 에러 로그
심지어는 매출 추이 까지도..!
예) 피크 타임에 매출이 발생하지 않는다? => 장애가 있나?
소프트웨어, 하드웨어 관련 요소 뿐만 아니라, 회사의 도메인과 관련된 항목도 모니터링 대상이 될 수 있다.
=> 어떤 상황이 장애인지에 대해 명확히 정의해놓아야 함.
2. 장애에 대한 정의가 필요하다!
모니터링 요소의 예
- 정상 서버 수
- 현재 요청 수(API 별)
- 현재 요청 실패 수(API 별)
- 디스크 사용량
- 네트워크 사용량
- 로그 크기?
- 로그 크기가 급격히 증가 = 트래픽이 늘었다는 것?
- 이벤트가 없는데 늘었다면, 공격일 가능성도?
- 도메인 관련 다양한 지표
서비스의 도메인에 대한 이해를 바탕으로, 어떤 상황이 장애인가를 정의하여 이상 수치를 정해야 한다.
2.1 장애 알림
이상수치에 대한 알림도 꼭 필요하다.
하지만, 과유불급이다.
- 필요 이상으로 많은 알림으로 인해, 장애의 발견이 늦어질 수 있다.
- 모니터링 수치에 알림 설정
- 해당 알림이 정말 장애를 알려주는지 검토
- 알림 수치를 조절
(1~3 반복)
모니터링 수치도 리펙토링이 필요하다.
3. 장애가 발생하면, 뭘 해야할까?
- 상황 인식
- 장애가 아닐 수 있음
- (가장 중요!!)장애 전파
- 팀내 공유
- 연관 부서 공유
- 기획, CS팀?
- 우리팀 API 를 사용하는 다른 팀
- 전사 장애 페이지 등
- 서비스 복구 & 장애 해결
장애를 남들 몰래 해결하여, 아무일 없었던 것 처럼 하고싶은 충동이 들 수 있다.
그래서, 이를 부담없이 공유하는 것을 장려하는 팀 문화가 중요하다.장애의
시작~대응~종료모든 단계에 대한 내용을 유관 부서에 공유하자.
4. 장애 분석
- 에러 메세지 분석 : 가장 확률이 높음
- 가장 많이 발생하는 오류 순서대로 확인하는것을 추천
- 장애의 90%는 간단히 해결되는 경우가 많음
- 장애 메뉴얼 필요
- 사소하게 작성하고, 점점 개선하기
- 장애 메뉴얼이 있다면, 이를 활용하자
- 장애 메뉴얼 필요
- 우리의 에러(버그)일까?
- 최근 배포된 코드와의 연관성을 고민
- 외부 API 의 오류인가?
- 라이브러리 이슈
- 최근에 수정된 버그가 있는지?
- Non-Bug 가 있는지?
- 버전업/다운 등으로 해결
중요한 것은, 혼자 해결하려 하지 않는 자세가 중요하다.
4.1 에러 메세지 로깅 리펙토링
에러 메세지 로깅도 리펙토링이 필요함
(필요한 정보를 잘 출력하는것이 중요함)
- 일단 필요할 것 같은 정보를 모두 출력하고, 불필요한 로그를 줄여가자
5. 장애 해결 시 무엇을 우선적으로 해야할까?
- 서비스 정상화 : 제일 중요!!
- 장애 원인 파악 : 정상화 후 해도 됨
장애 원인 파악보다는, 원인을 몰라도 일단 서비스 정상화가 가장 중요하다.
(롤백, 재배포가 필요할 수 있다.)
- 잘 구성된 배포 시스템이 필요함
- 기존 코드의 버그라면, 빠르게 수정하여 배포
- DB 스키마 변경으로 인한 장애라면?
- Rollback 하기 어려울테니, 필요한 컬럼을 추가하며 해결한다.
- 나중에 천천히, 꼼꼼히 살펴보며 안쓰는 컬럼을 제거한다.
6. 장애 보고서에는 어떤 내용을 작성할까?
- 장애 요약
- 어떤 장애였는지
- 발생한 원인은 뭔지
- 장애 영향도
- 유저들이 어느정도 영향을 받았는지?
- 영향을 받은 서비스가 있는지
- 우리 뿐 아니라, 우리 API 를 사용하는 팀의 장애도 파악
- 장애 원인
- 장애 처리 타임라인별 대처 사항(걸린 시간)
- 발생 탐지
- 유관 부서 전파
- 장애 해결을 위한 행동
- 장애 재발 방지 대책
- 그 외 필요한 추가 정보
7. 장애 회고를 하자
회고 전, 중요한 것은 누가 문제를 만들었는가 는 절.대.로 언급하면 안됨
그보다, 어떻게 개선할 것인가에 집중하자
7.1 장애 회고의 내용
- 참가자
- 서비스 관련 부서
- 개발팀 / SRE,시스템인프라 / 기획 / 관련 책임자
- 서비스 관련 부서
- 내용
- 개션이 최우선 목표
- 장애 발생을 없앨 수 있는지
- 적절한 테스트 단계가 빠졌는지
- 구조적 문제는 없는지
- 서비스 구조 개선
- 장애 탐지(인지)는 적절했는지
- 모니터링 지표 있는지, 적절한지(추가, 수정, 삭제 등)
- 장애 대응 방식은 적절한지
참고
- LINE의 장애 보고와 후속 절차 문화
- LINE 플랫폼 서버의 장애 대응 프로세스와 문화
7.2 장애를 대비하며
- 모의 장애 훈련도 도움 됨
- 보통 스테이징 단계에서 진행함
장애 처리를 하는 사람만 하게 되는 경우가 있음(시니어, 경험있는 특정 인물)
=> 주체적으로 장애를 대응할 수 있도록 문화 조성 필요
8. 정리
- 장애 처리에는
장애 인지가 가장 중요하다- 이를 위해 모니터링이 필수
- 장애 발생을 인지하였을 경우, 꼭
유관 부서에 공유하자 - 장애보고서/장애 대응 메뉴얼 작성하기
- 반드시,
장애 회고를 하자- 누가 장애를 일으켰는지 언급하면 절대 안됨
- 회고를 통해 조금씩 개선해 나가자
장애 복구 프로세스 자동화가 가능하다면, 해놓는게 좋다
장애 = 막을 수 없는것 = 계속 대응해 나가야 하는 것
Done is better than Perfect
장애 공유에 부담이 없도록 하는 문화 조성이 필요!
9. 세미나를 듣고..
이번 세미나를 통해서는 정말 서비스를 운영해보지 않으면 알 수 없는 내용들을 들을 수 있어서 너무 유익했습니다.
배운 내용 중에서 핵심 내용이라 생각되는 부분은 장애 전파, 장애 회고(with 좋은 조직 문화)입니다.
사실 이 중에서 기반이 되어야 하는 것은 좋은 조직 문화 라는 생각이 들었습니다.
장애가 왜 발생했는지 보다, 누구 때문인지 누구 책임인지 따지는 문화라면 적용하기 힘들 것 같습니다.
그래서 장애를 누군가 의 문제로 가져가기 보다는, 우리 의 문제로 가져가는 문화가 중요하다고 생각되었습니다.
이런 문화가 조성된다면 자연스레 장애 전파의 부담이 줄어들게 될 것입니다.
그리고 장애가 왜 발생했고, 어떻게 해결했는지에 집중해야 발전이 있을 것 입니다.
이 과정이 장애 회고이자 장애 대응 기록이 되어, 추후 같은 장애 발생시 참고하거나 더 나은 과정을 밟을 수 있겠죠.
나중에 개발자로 일하게 된다면 모니터링과 장애 대응에 신경쓰며 좋은 문화 조성을 위해 기여하고 싶다는 생각이 들었습니다.