[장애 이력 자동 작성 도구1] 1차 정리

프로젝트 핵심

DB 서버(Redis)의 STOP/DOWN 등 장애 원인과 이력을 시간 순서대로 기록

 

context

담당자가 장애 알림을 받으면, 원활한 서비스를 위해 서비스 정상화를 원인 파악보다 먼저 진행할 수 있으므로

추후 상황 보고 시 장애 이력을 시간 순서대로 정리해 놓은 타임라인이 필요

 

최종 선정된 파이프라인 흐름 추상화

alert 받고 담당자가 스크립트 실행 -> 장애 이력 타임라인 작성(발생부터 완료까지의 일)

 

[구체화]

1. 담당자가 alert 인지

2. 담당자가 스크립트 실행(input = 알림 메시지) - 처음에 원인 파악 용도로 한번 실행하고, 마지막에 최종 타임라인 작성 용도로 한번 실행

3. 해당되는 DB 서버에서 로그 수집(알람 종류별로 실행할 명령, 조사할 부분 다름)

4. 분석 및 임시 기록(Output 작성 중)

5. Output(두레이 태스크)

 

3번(알람 종류별로 실행할 명령, 조사할 부분 다름) 관련 추가 설명

• 장애 발생 시간대를 기준으로 로그를 넓게 필터링해서 전체를 조회하는 방식보단
• 장애 유형별로 우선적으로 확인할 로그를 미리 정해두고 그 범위 안에서 탐색하는 방식이 더 좋다고 생각함
• => 알람 종류별로 분기 처리 필요(하드코딩도 일종의 방법)

 

파이프라인 선정 이유

처음부터 로그를 몽땅 수집하는 것보다, 장애 난 서버만 조사하는 방식이

• 장애가 그리 빈번하게 발생하는 이벤트가 아니므로 적합
• 수집 부분의 난이도 낮음

 

[참고]

다른 파이프라인 후보군은 '구상' 게시글에 작성됨

모니터링할 DB 서버는 Redis 외에도 MySQL 등이 존재하지만, 이 프로젝트에서 본인은 Redis만을 담당함

---

장애 기준 선정

무엇이 장애인가

로그를 보고 어떤 장애인지, 원인이 뭔지 파악할 수 있는가

 

감지할 장애 종류 최종(증상-원인 매칭)

1. DB 서비스 다운 / 먹통

• 자원 포화: OOM(Out of Memory)으로 인해 OS가 DB 프로세스를 강제 종료 (OOM Killed), 디스크가 꽉 차서 DB 강제 종료, 최대 연결 수 초과 (Too many connections)
• 내부 코드 오류: 로직 수행 도중 segfault 등으로 비정상 종료되면 로그 발생

2. 성능 저하: 쿼리 수행 지연

• 디스크 I/O 병목, CPU 사용률 100% 지속
• 비효율 쿼리 및 락: 인덱스 풀 스캔(풀스캔이더라도 비효율을 장담할 순 없음), 데드락(Deadlock found), 락 대기(Lock wait timeout) 등

3. 마스터-슬레이브 데이터 불일치

1. 자원 포화: 슬레이브 서버의 리소스 부족으로 마스터의 변경 속도를 못 따라감
2. 의존성 문제: 마스터-슬레이브 간 통신 등 외부 요인 장애

 

[고려사항]

메모리 부족을 이유로 OS가 DB를 강제로 죽이면 로그가 안 남음. 그래도 종료 로그 없이 재시작 로그가 나오는 것만으로도 비정상 종료임을 판별할 수 있음. 근데 이건 주먹구구식인 것 같음

=> OS 커널 로그를 수집도 고려해보자

=> sudo 권한이 중요한데, irteamsu로 접속하면 가능

---

알람 예시(Input)

1. 복제중단 사례 : [김성훈0] mpsm-realdb-t1006:13306 모바일포커_CRM Replication stop
2. MySQL 접속 실패 : [김성훈] tc0m-goblindb-p1912:13306 NHNCloud_csap2_goblin MySQL Not Reachable
3. Redis Port 다운 : [전연주] tc0d-lncloredn-p1901:10379 NHNCloud_LogNCrash_GOV_KR1(Redis) Redis Port is Down!

 

=> 알람만 보고는 원인 유추가 어려움

 

알람 중요도 구분

장애 알람의 critical 여부를 따지기(알람 시 바로 장애 상황인 것, 그렇지 않은 것 존재)

*이 알람이 뜨면 로그 수집 스크립트를 실행해야 함

[Redis]

1. 직관적인 DOWN 증상(매우 중요): Redis down, 시스템 다운, Redis port 다운(접속 불가)

2. STOP 및 DOWN으로 이어지는 증상(중요): 디스크 error, reject된 커넥션, Missing Master, Cluster Flapping(클러스터 내의 특정 노드(서버)나 서비스가 정상과 비정상 상태를 아주 짧은 시간 동안 끊임없이 반복해서 오가는 현상)

3. 성능 저하(심각하면 DOWN으로 이어짐): CPU 사용률, Memory 사용률, 디스크 가용공간, 디스크 Inode 사용량, 디스크 사용률, 커넥션 사용량, 메모리 단편화율, Redis 메모리 사용률

4. 마스터-슬레이브 간 문제: 복제 중단

5. 지금 당장의 장애는 아니지만, 장애 발생 시 무방비 상태(사후 분석 필수): Sentinel port 다운, Redis exporter 다운, Node exporter 다운

 

*5번 증상은 자동 복구된 장애이므로 장애관리팀에 보고할 정도가 아니라 판단함

*exporter 다운: 프로메테우스가 해당 DB 상태(CPU, 메모리, 디스크 정보 등)를 가져가지 못함. 즉각적인 장애는 아니지만, 실제 장애 상황일 때 프로메테우스가 장애를 인지하지 못하는 상황이 벌어질 수 있음

 

장애는 아님

1. Sentinel Failover: 마스터에 장애가 발생. 그래도 failover가 잘 수행되면 괜찮음

2. 삭제된 keys: 데이터 삭제는 장애로 볼 수 없음. 다만 Redis가 꽉 차서 캐시가 지워지는 eviction 경우라면 문제가 될 수 있지만 이는 위의 Redis 메모리 사용률 등으로도 충분히 파악 가능

---

Input 처리 방법

[김성훈] tc0m-goblindb-p1912:13306 NHNCloud_csap2_goblin MySQL Not Reachable

 

추출해야 할 Output

• 알림으로 알 수 있는 것: 대상 리전, 서비스명, 주요 증상, 탐지 시각(담당자에게 이 메시지가 온 시각)
• 그 외 쉽게 작성 가능한 Output: 인지 시각(데몬 프로세스 시작 시각), 담당자 인지 방법(이 알림), 장애 처리 부서(데이터 운영팀), 장애 접수 채널, 장애 처리 결과(어차피 사후 보고용 타임라인 작성이기에 맨 마지막에 '완료'로 작성)
• 추후 알아내야 하는 것: 장애 해결까지의 전체 타임라인(중요), 장애 원인, 최초 발생 시각
• 여러 개 조합 필요: 장애 제목(탐지 날짜, 장애 처리 부서, 서비스명), 탐지 지속 시간(탐지 시각 - 최초 발생 시각)

장애 증상별 탐지 방법

1. 서비스 다운 / 먹통
   • 알림을 파싱 - Redis down, 시스템 다운, 디스크 error, reject된 커넥션, Missing Master, Redis port 다운, Cluster Flapping
2. 성능 저하
   • 알림을 파싱 - CPU 사용률, Memory 사용률, 디스크 가용공간, 디스크 Inode 사용량, 디스크 사용률, 커넥션 사용량, 메모리 단편화율, Redis 메모리 사용률
3. 마스터-슬레이브 데이터 불일치
   • 알림을 파싱 - 복제 중단

 

장애 원인별 탐지 방법(초안)

[성능 저하 중 일부 해당하는 것 + 모든 서비스 다운 증상 시 조사해야 하는 것(장애 별 우선순위는 다를 예정)]

1. OOM killed(메모리 full)

• OS 커널에서 확인: dmesg, syslog, 또는 journalctl에서 "Killed process ... out of memory" 포함 여부

2. 디스크 full 및 병목

• SHOW INNODB STATUS 확인

3. CPU 병목

• OS 커널에서 확인: Python psutil 등 이용

4. Too many connections

• SHOW STATUS LIKE 'Threads_connected' 확인

5. 내부 로직 segfault

• mysqld.err 파일 확인 또는 OS 커널에서 확인

 

[성능 저하 시에만 조사할 것]

1. 데드락 및 락 대기

• SHOW INNODB LOCK 확인

2. 실행 계획 확인(인덱스 사용 여부, 조인 방식 등)

• EXPLAIN [FORMAT=JSON] <쿼리>
• 실행 계획을 확인하는 건 특정 쿼리 튜닝 작업 시 조사하도록 하고, 이 프로젝트에선 생략해도 됨

---

로그 수집 방식

로그 에이전트(프로메테우스 Promtail), cron 등을 이용해

스크립트가 자체적으로 주기적인 체크(Polling)를 하며 정상화 여부를 계속 확인하는 방식은 부적절함

=> 그러므로 스크립트 실행 시에만 로그를 수집하는 스크립트 작성 필요

=> 스크립트는 처음에 원인 파악 용도로 한번 실행하고, 마지막에 최종 타임라인 작성 용도로 한번 실행

 

[이유]

초기 장애 파악과 정상화 이후 최종 타임라인 작성에만 이 프로그램이 필요함

이미 장애가 난 서버에서 로그를 추출하는 행위는 추가적인 부하에 해당함

정상화되기 전까지 원인이 해결됐는지 주기적으로 체크하는 행위는 이미 사내 모니터링&알림 서비스가 하고 있음

 

스크립트 작성하기: C vs Python

=> Python 최종 선정

 

[이유]

• Python이 구현 난이도가 쉬움
• 1초 미만 단위의 초고속 처리 시엔 멀티 스레딩 측면에서 C가 유리하겠지만, 이 프로젝트에선 로그를 초 단위로 수집하진 않으므로 C를 쓰지 않아도 됨

 

스크립트 작성 후 테스트

Redis 장애상황 연출

- 강제로 kill

- 로직으로 죽이기: 임시 테이블에 데이터 insert 한꺼번에 실행, select 한꺼번에 실행(keys 명령어로 모든 키 조회하기)

 

일단 최소 기능만 구현한 이후 혹은 꾸준히 생각할 고민거리

1. 비효율 쿼리 정의 어떻게?(N초 이상 쿼리 비율이 X% 이상 등)

2. 장애 시작 시점 찾기(고민 진행중): alert를 받은 시점 직전 1분 전부터 조사? 아니면 alert에서 제공한 시각이 곧 장애 시작 시점인가? 언제부터의 로그를 분석에 사용할 건지?(종료 시점은 별 문제 안됨)

3. 각 단계별 어떤 기술 쓸지(kafka, ai 등 과한 기술을 쓸건지)

4. 그 외: 데이터 유실 방지 대책, 재해 복구, 저장장치별 일관성 유지 방법(어렵지만 가치있음)

5. 고도화: 두레이 태스크 등록 알림 기능 추가, 시각화 및 장애 유형별 재발 빈도 통계, 비슷한 장애 사례 찾기, 알아서 장애 해결까지 자동화 등

 

[추가 고민거리]

규정된 5가지 장애 원인의 세부 원인 파악이 필요할 수 있음

이를테면 Redis 메모리 사용량이 크게 올라간 경우, 응답시간이 길어진 경우 세부 원인을 파악하기 위해 레디스의 데이터 파악을 진행해야 할 수도 있음(키별 데이터 크기, ttl 등)

 

담당자의 수동 실행은 문제가 안되지만, 스크립트 실행 명령어에 알람 메시지 복붙 시 오타 및 특수문자 이슈가 발생할 수 있음

NHN Cloud 모니터링 시스템이 장애 발생 시 웹훅(HTTP POST 요청)을 쏘는 기능을 지원한다면, 알람 시 자동으로 데몬 서버에 웹훅(JSON)을 전송해 데몬이 자동으로 동작할 수 있음

---

Output(두레이 태스크에 등록될 항목)

타임라인 = 장애 발생 시점부터 정상화 시점까지의 단위 시간별 장애 이력(언제 어디서 문제가 발생했고 언제까지 계속 발생했는지)

반드시 넣기

• 발생 시각
• 탐지 시각
• 인지 시각
• 담당자 인지 방법(장애 접수 채널. 죄다 '이 프로젝트’로 기입하면 됨)
• 장애 발생 원인(중요. 이 프로젝트의 핵심)
• 장애 처리 부서(데이터운영으로 기입)
  • 이 프로젝트에선 db 관련된 장애만 수집하므로 죄다 '데이터운영’으로 기입하면 됨
  • db 외 복합적인 문제라도 최초 발견은 '데이터운영’ 부서가 했으므로 '데이터운영’으로 기입해도 문제는 없을 듯

장애해결 이후에 작성될 부분

• 해결 시각
• 장애 지속 시간(장애 발생부터 해결까지 걸린 시간)
• 처리 지속 시간(장애 인지부터 해결까지 걸린 시간)

장애관리팀 작성 영역이지만 output에 넣으면 좋을 부분

• 장애 제목
• 장애 등급 - 적절한 사내 규정, 매뉴얼이 없다면 넣기 애매
• 주요 증상
• 대상 리전
• 장애 접수 채널(alert라면 alert로 기입)
• 장애 처리 결과(죄다 진행중으로 넣으면 됨)
• 탐지 지속 시간(장애 발생부터 탐지까지 걸린 시간)
  • 탐지 시각은 이 프로그램이 '수집한 로그를 장애라고 판정한 시각' 또는 alert가 발생한 시각
• 인지 지속 시간(장애 탐지부터 인지까지 걸린 시간)

*장애관리팀 = NHN Enterprise 산하 장애관리팀을 의미한다고 가정

굳이 들어가야 되나 싶은 부분

• 공지 게시 시각
• 공지 시간

=> 그냥 인지 시각 값과 동일하게 작성하면 될 듯

 

구현 가능할지 모르겠는 부분

• 영향 범위
  • 장애 대상 고객사
  • 인프라 영향 범위 - 예를 들어 하이퍼바이저 장애라면 영향받은 VM 목록. 네트워크 장비 장애라면 영향받은 서비스 목록
  • 서비스 영향 범위 - 예시: 고객 VM 생성 불가, 홈페이지 접속 불가 등
• 변경작업에 의한 장애인지 여부(고도화 후보1)
  • 정기점검이나 장비 업그레이드 직후 발생했다면 관련 태스크 링크 첨부
  • 이게 가능하려면 정기점검 정보도 수집해서 저장하고 있어야 함
  • 변경 작업 직후 장애가 발생했어도, 장애의 실제 원인이 변경 작업인지는 알기 어려움
  • => 장애 타임라인을 이 프로그램이 자체적으로 판단해 결과를 내는 건 어려우므로 일단은 배제
• 반복장애(고도화 후보2)
  • 이게 가능하려면 과거 장애 이력, 종류 정보도 수집해서 저장하고 있어야 함
  • => 하면 좋지만 우선 구현할 기능은 아님
• 후속 조치 체크리스트

---

그 외 고민(완료)

고민1: 담당자의 확인 없이 장애 이력 태스크를 자동 등록하게 할까? 아니면 다 작성시켜 놓은 걸 담당자가 확인 후에 클릭 한번으로 등록되도록 할까?

=> 담당자가 alert 발생 시 '장애 이력 생성' 스크립트를 실행한다면 바로 공지로 올려도 됨

혹은 공지 전에 팀 내부 공개용 태스크만 올려도 됨. 이후 공지에 올리는 건 담당자가 최종 수정 후 올리기

 

고민2: output을 어떻게 두레이에 바로 올릴까?

=> 두레이 API를 사용하면 가능. 안되면 웹에 띄워도 괜찮음

 

---

[고민거리]

1안: 사후(장애 해결 이후) 스크립트를 한번만 실행해 장애 발생부터 해결까지의 타임라인을 정리하기

vs

2안: 장애 발생 직후 1차적으로 스크립트를 실행(원인 분석 및 휘발성 상태 정보 보존 목적) -> 1차 실행 때 수집한 정보를 사후 2차 실행에서 재활용하기

 

1안 선정 시 이유

• 구현이 간단
• 장애 원인 분석 기능은 사내 모니터링&알람 시스템이 이미 해주고 있을 수 있음
• os 커널 로그, redis 에러 로그, 전반적인 리소스 사용량 기록은 휘발되지 않으므로 이 정보만으로 타임라인을 작성해볼 수 있음

 

2안 선정 시 이유

• 사후 타임라인 작성 외, 장애 원인 분석에도 기여해 프로젝트의 가치가 높아짐

• ⁃ 담당자가 정상화를 위해 시스템을 재시작하면 장애 직후 당시의 '디테일한 커넥션(클라이언트 IP) 정보', 'CPU full, OOM의 주범이 정확히 어떤 프로세스의 어떤 스레드인지', 'redis 내부 메모리 지표(메모리 단편화율, 캐시미스 비율, 명령 처리량)' 및 데이터 상태(키별 데이터 내용, ttl 등) 등은 휘발됨 => 2안 선정 시 더 많은 정보를 활용해 타임라인을 작성할 수 있음

 

[질문거리]

디테일한 정보(OOM이 발생했다고 가정했을 때, 정확히 어떤 프로세스의 어떤 스레드가 주범인지)는 OS 커널 로그에 남지 않는다.

그러므로 장애 발생 직후의 휘발성 상태 정보를 가져오는게 낫지 않나?

 

하지만 장애 발생 직후, 담당자가 스크립트를 실행해 top같은 명령어로 현 시점 메모리 사용량이 높은 프로세스&스레드 ID를 가져온다면, 메모리 사용량이 높은 프로세스&스레드가 시시각각 변동돼서 정확히 어떤 ID의 프로세스가 OOM의 주범인지 알아내지 못하는 경우가 생길 수 있다. 그럼에도 이런 디테일한 정보도 수집해서 타임라인 작성에 반영해야 하나?