장애가 발생했다면 추후 재발 방지를 위해
장애 리뷰를 진행합시다
목차
1. 장애 리뷰 문서 형식
2. 올해의 장애 TOP2 (RDS)
3. 장애 리뷰 - 문서 작성 (Rabbit MQ)
4. 장애 리뷰 - 논의가 필요한 부분
회사에서 장애가 발생하면 담당자가 장애 리뷰 문서를 작성하고 개발팀 내에서 장애 리뷰를 진행합니다.
연말에 발생한 Rabbit MQ 장애 사건도 장애 리뷰를 진행하기로 했는데요!
다만 연말인 만큼 모두 휴가를 갔기 때문에 (...) 시간 공백이 생긴 만큼 문서 작성에 좀 더 공을 들여 보았습니다.
이때를 위해 장애 났을 때부터 틈틈이 캡처해 둔 증거 사진 (?) 과 함께 전반적인 타임라인과 개선점을 정리했더니 3시간이 훌쩍 지나가네요...ㅎㅎ
(+ 2월부터 서버 장애를 하도 겪다보니 캡처하는 습관이 생겼는데... 사실 장애가 난 당시에는 급박하다 보니 흘리고 지나가는 것들이 많더라고요. 사건 현장을 사진으로 남겨두면 나중에 복기할 때 좋은 것 같아요!)
▶ 장애 리뷰 문서 형식
장애 리뷰 문서는 기본적으로 ① 발생한 장애를 분석하고 ② 개선할 점을 회고하는 방식으로 구성하고 있는데요!
이렇게 문서를 작성하게 되면 댓글이나 장애 리뷰 시간을 통해 재발 방지 대책을 세우게 됩니다.
- 장애 분석
- 장애 경과 (= 타임 라인)
- 장애 여파 (= 피해 범위)
- 장애 원인 / 대응
- 개선할 점
- 장애 파악/인지 개선
- 장애 대응 게산
- 예방 방안
- 추가로 논의할 내용
올해에는 16개의 장애 리뷰 문서가 작성되었네요! 정말 다산 다난한 해였습니다 (...)
이 중 2개가 제가 진행한 프로젝트에서 발생한 장애 사건이네요 ㅠ.ㅠ
하필 연말에 큰 사고 (...) 가 발생하다니 역시 마음이 느슨해지면 바로 장애로 이어지나 봐요...ㅎㅎ
(앱 스토어 댓글 확인하는데 심장이 너무 아프네요)
▶ 올해의 장애 TOP2 (RDS)
장애 리뷰조차 진행되지 못했던 올해의 큰 사건 사고들도 많았는데요. 올해는 DB 이슈가 참 많았습니다 ㅠ.ㅠ
신입으로는 할 수 있는 일이 많지 않았지만... DB 엔진에 대한 공부의 필요성을 많이 느낀 한 해였습니다!!
(지금도 열심히 책 보고 있는데 너어어어어어무 어렵네요)
- [1] DB Scale Up 을 결정하기 전, 불안정한 RDS CPU & 주기적 서비스 장애
- 기본 RDS CPU 80~90% 유지
- 매일 트래픽이 몰리는 시간대에는 RDS CPU 100% -> 서비스 장애 발생
- 장애 원인
- 레거시 코드 (DB 를 괴롭히는 수많은 로직들)
- 대응 방법
- mysql kill thread_id; 명령어를 통한 임시조치
- AWS RDS 성능 개선 도우미를 통한 DB 에 가장 많은 부하를 일으키는 상위 쿼리 파악 (레거시) -> 리팩토링
- [2] DB Scale Up 을 진행한 후, 높아진 Read Latency + Disk I/O 이슈 & 서비스 장애
- mysql kill thread_id; 명령어를 통한 임시조치
- AWS 모니터링 지표를 통한 원인 분석 -> 디스크 I/O 사용률 100% 돌파
- DB 에 요청되는 데이터 저장량은 초당 1.3G 에 근접 <-> GP2 볼륨의 최대 처리량은 초당 1G
- 디스크 I/O 병목 현상 발생 (쓰기 횟수보다 쓰기 량이 너무 많아 한계에 도달)
- 20Mb/s 는 쓰기 요청. 1G는 테이블 쓰기와 인덱스 갱신 등 전체 물리 디스크 I/O 수치.
- 장애 원인
- [추측 1] DB Scale Up 전에는 CPU 가 병목 지점 -> 이러한 병목이 디스크 I/O 사용률이 100% 에 도달하지 못하도록 하는 안전장치가 됨 -> DB Scale Up 을 함 -> CPU 가 처리하는 요청량이 증가하며 디스크 I/O 사용률도 증가 -> 디스크 I/O 사용률이 100% 를 돌파하며 병목 발생
- [추측 2] 모종의 이유로 이전보다 성능이 낮은 디스크가 할당되었다.
- 대응 방법
- 디스크 크기를 늘린다.
- 인덱스가 과도하게 많은 DB Table 을 정리한다. (불필요한 Index 삭제)
- 높아진 Read Latency 는 3일 경과 후 점차 안정화 (DB Scale Up 의 여파가 며칠 간 존재하는 듯하다.)
다시 생각해도 DB Scale Up 직후는 정말 아찔하네요. 원인을 발견해서 다행이지 그 상황에서 DB Scale Up 작업 자체를 롤백할 수도 없고;;;; 그날은 거의 오후 11시까지 완전 비상이었습니다.
▶ 장애 리뷰 - 문서 작성 (Rabbit MQ)
DB 외적으로 올해의 장애 TOP 1 이 있다면 당연코 연말에 발생한 요번 Rabbit MQ 사건입니다.
Rabbit MQ 를 본격적으로 서비스에 활용한 지 얼마 안 된 시점이라 원인 파악, 장애 대응 모두 미흡한 점이 많았습니다 ㅜ.ㅜ 장애 리뷰 문서를 정리할수록 그 점이 점점 명확해지더라고요.
특히 이런 점들이 많이 아쉬운 부분이었습니다.
- 모니터링 페이지는 있으나 경보 시스템은 없었던 점
- 장애 당일, 서버 개발자 모두 연차로 대응이 늦어진 점
- QA 팀으로부터 챌린지 시스템에 이상이 있음을 장애 발생 전에 전달받았지만 당일 연차로 확인하지 못한 점
- 보안그룹 문제로 재택에서 모니터링 페이지 접근이 되지 않아 큐 상태 확인이 늦은 점
- Rabbit MQ 장애 상황에 대한 경험자가 없는 점
장애 대응 당시에는 2번이 가장 크게 느껴졌는데...ㅎㅎ
근본적으로는 장애를 미리 인지할 수 있는 시스템이 없었다는 점이 문서로 점점 드러나는 것 같습니다!
목차 및 장애 경과
장애 원인 中
대응 및 개선점 中
▶ 장애 리뷰 - 논의가 필요한 부분
장애 대응 개선과 관련해서는 다른 동료도 문서에 의견을 작성해 주었는데요. 생각해보지 못했던 부분들이라 와닿는 부분들이 많았습니다. 특히 circuit breaker 개념은 처음 들어봤는데 지금 상황에 정말 필요한 시스템인 것 같아요!
장애 대응 방식에 대해서도 의견을 남겨주었는데,
메세지 데이터를 삭제한 1번 방식이 아니라 EC2 의 볼륨을 조작, 백업 등을 통해 메세지 데이터를 보존하는 2번 방식이었으면 어땠을까에 대한 의견이었습니다.
- [조치한 방법] Disk Full 발생 -> EC2 인스턴스 터미널 접속 -> 메세지 데이터 삭제
- [제시된 의견] Disk Full 발생 -> EC2 인스턴스 볼륨 확장 -> 볼륨 스냅샷 등 백업 -> 필요 시 메세지 데이터 삭제
사실 장애 당시에는 1번 방식밖에 떠오르는 게 없었는데 2번 방식으로 했다면 확실히 메세지가 보존되어 후속 조치 (유저별 챌린지 달성 마이그레이션...) 에 도움이 되었을 것 같아요.
물론 볼륨 확장에는 돈이 청구된다는 점에서 해당 방식은 장애 리뷰 때 좀 더 논의해보면 좋을 것 같습니다!
'Learn > Error Report' 카테고리의 다른 글
| [Error #2] 연말은 에러와 함께~ (Rabbit MQ) (5) | 2022.12.28 |
|---|---|
| [Error #1] Server - update 가 랜덤하게 성공하는 경우 (0) | 2022.04.24 |
| [Error #0] Braze API - 유효하지 않은 API Key 응답 오류 (0) | 2022.03.04 |