Ⅱ-11. 컴퓨터 시스템 장애 전조 데이터와 조기탐지 분석

컴퓨터 시스템 장애는 항상 갑작스럽게 발생하는 것은 아니다.

일부 장애는 실제 서비스 중단이 발생하기 전에 CPU 사용률 증가, 메모리 사용량 변화, 디스크 I/O 지연, 네트워크 오류, 반복적인 시스템 로그, 서비스 응답시간 증가와 같은 변화가 먼저 나타날 수 있다.

따라서 장애가 발생한 이후 원인을 분석하는 것뿐만 아니라 장애 발생 전에 나타나는 변화를 찾아 조기에 판단하는 것도 시스템의 신뢰성과 복원력을 높이는 중요한 방법이다.

다만 특정 수치가 높다는 이유만으로 장애 전조라고 판단해서는 안 된다.

정상 상태와 비교했을 때 무엇이 달라졌는지, 그 변화가 얼마나 지속되는지, 다른 지표에서도 같은 현상이 나타나는지를 함께 분석해야 한다.

1. 장애 전조 데이터의 개념

장애 전조 데이터는 심각한 장애가 발생하기 전에 시스템의 정상적인 상태와 다른 변화가 나타나는 데이터를 의미한다.

대표적인 데이터는 다음과 같다.

• CPU 사용률 변화
• 메모리 사용량 증가
• 디스크 I/O 지연
• 저장장치 오류
• 네트워크 지연
• 패킷 손실
• 프로세스 재시작
• 데이터베이스 오류
• 시스템 로그
• 서비스 응답시간 증가

여기서 중요한 것은 특정 값 하나가 아니라 시간에 따른 변화 패턴이다.

예를 들어 CPU 사용률이 일시적으로 90%를 기록한 것과, 평소 30% 수준이던 CPU 사용률이 며칠 동안 지속적으로 상승하는 것은 의미가 다르다.

2. 정상 상태와 이상 상태를 먼저 구분해야 한다

장애 전조를 탐지하려면 먼저 해당 시스템의 정상 상태를 알아야 한다.

예를 들어 업무시간마다 CPU 사용률이 80%까지 증가하는 시스템이라면 80%라는 수치만으로 이상이라고 판단하기 어렵다.

반면 평소 30~40% 수준이던 시스템에서 CPU 사용률이 지속적으로 80% 이상으로 증가하고 동시에 응답시간과 오류 발생 횟수까지 증가한다면 이상 상태일 가능성을 검토해야 한다.

따라서 조기탐지에서는 절대적인 임계값뿐만 아니라 다음 요소를 함께 확인해야 한다.

• 평소 수준
• 변화 폭
• 변화 속도
• 지속시간
• 발생 빈도
• 다른 지표와의 동시 변화

3. CPU 사용률 변화 분석

CPU 사용률은 시스템 부하를 확인하는 대표적인 지표다.

하지만 최대 사용률 하나만으로 장애 가능성을 판단하기는 어렵다.

다음 항목을 함께 확인하는 것이 좋다.

• 평균 CPU 사용률
• 최대 CPU 사용률
• 높은 사용률의 지속시간
• 사용률 증가속도
• 특정 프로세스의 CPU 점유율
• 사용자 응답시간 변화
• 프로세스 재시작 여부

예를 들어 CPU 사용률이 높더라도 정상적인 대량 작업으로 발생한 것이라면 장애 전조가 아닐 수 있다.

반대로 CPU 사용률 증가와 함께 특정 프로세스의 비정상적인 점유 증가, 응답시간 증가, 오류 로그가 동시에 나타난다면 원인을 조사할 필요가 있다.

따라서 CPU 사용률 자체보다 CPU 사용률이 왜 변했는지를 분석하는 것이 중요하다.

4. 메모리 사용량 변화 분석

메모리 문제는 단순히 현재 사용률이 높은 것보다 시간에 따른 지속적인 증가가 중요한 단서가 될 수 있다.

예를 들어 시스템을 재시작한 직후 메모리 사용량이 낮지만 시간이 지나면서 계속 증가하고 결국 가용 메모리가 감소한다면 메모리 누수나 비정상적인 자원 점유 가능성을 검토할 수 있다.

분석할 때는 다음 항목을 함께 확인할 수 있다.

• 메모리 사용량
• 가용 메모리
• 스왑 또는 페이징 발생
• 특정 프로세스의 메모리 증가
• 프로세스 재시작 여부
• 응답시간 변화

따라서 메모리 조기탐지에서는 현재 사용률보다 증가 추세와 지속성이 중요한 판단 요소가 될 수 있다.

5. 저장장치 데이터 분석

저장장치에서는 단순한 디스크 용량뿐만 아니라 I/O 상태와 오류 데이터를 함께 확인해야 한다.

대표적으로 다음과 같은 항목을 분석할 수 있다.

• 읽기·쓰기 지연시간
• I/O 처리량
• I/O 대기시간
• 읽기·쓰기 오류
• 저장장치 상태 정보
• 파일시스템 오류
• 반복적인 I/O 실패

특정 오류가 한 번 발생했다고 해서 곧바로 저장장치 장애로 판단할 수는 없다.

그러나 동일한 오류가 반복되거나 I/O 지연이 지속적으로 증가하면서 서비스 응답시간까지 악화된다면 저장장치 또는 저장 경로에 대한 점검이 필요할 수 있다.

특히 성능 저하와 오류가 동시에 증가하는지를 확인하는 것이 중요하다.

6. 네트워크 데이터 분석

네트워크에서도 장애 발생 전에 이상 변화가 나타날 수 있다.

대표적인 지표는 다음과 같다.

• 패킷 손실
• 지연시간
• 재전송
• 연결 실패
• 인터페이스 오류
• 연결 끊김
• 트래픽 변화
• TCP 연결 상태 변화

네트워크 사용량이 증가했다고 해서 반드시 장애 전조는 아니다.

정상적인 트래픽 증가일 수도 있기 때문이다.

하지만 트래픽 증가와 동시에 패킷 손실, 재전송, 지연시간, 연결 실패가 함께 증가한다면 단순한 사용량 증가와 구분하여 원인을 분석해야 한다.

따라서 네트워크에서는 트래픽의 양보다 트래픽 증가와 품질 저하가 함께 나타나는지를 확인하는 것이 중요하다.

7. 로그 데이터에서 반복되는 이상징후 찾기

시스템 로그는 장애가 발생한 이후 원인을 확인하는 자료로 많이 사용되지만, 장애 전조를 찾는 데에도 활용할 수 있다.

예를 들어 다음과 같은 변화가 반복된다면 분석 대상이 될 수 있다.

• 동일 오류코드 반복
• 동일 프로세스 반복 재시작
• 반복적인 연결 실패
• 파일시스템 오류
• 데이터베이스 연결 오류
• 인증 실패 증가
• 특정 장치 오류 반복

중요한 것은 오류가 한 번 발생했다는 사실보다 같은 유형의 오류가 일정한 패턴으로 반복되고 있는지를 확인하는 것이다.

반복되는 경고가 실제 장애로 이어진 사례가 있다면 해당 로그는 향후 조기탐지 기준으로 활용할 수 있다.

8. 서비스 응답시간 변화

시스템 자원이 아직 명확한 임계값을 초과하지 않았더라도 서비스 응답시간이 지속적으로 증가한다면 성능 저하가 진행되고 있을 가능성이 있다.

예를 들어 평소 200ms 수준이던 서비스 응답시간이 300ms, 400ms, 600ms로 지속적으로 증가한다면 CPU나 메모리 사용률이 아직 높은 수준이 아니더라도 원인을 확인할 필요가 있다.

특히 다음과 같은 변화가 함께 나타나는지 확인해야 한다.

• 응답시간 증가
• 처리량 감소
• 오류율 증가
• 데이터베이스 지연
• 네트워크 지연
• 서버 자원 사용량 변화

이러한 데이터가 동시에 변화한다면 단순한 일시적 지연인지 시스템 장애로 진행되는 이상징후인지 구분할 수 있다.

9. 단일 지표보다 여러 데이터의 관계를 분석해야 한다

장애 전조 분석에서 가장 주의해야 할 부분은 단일 지표에 지나치게 의존하는 것이다.

CPU 사용률이 높다는 사실만으로 장애를 판단할 수 없고, 메모리 사용량이 증가했다는 사실만으로 메모리 장애라고 단정할 수도 없다.

예를 들어 다음과 같은 변화가 동시에 발생했다고 가정해 보자.

CPU 사용률 증가
→ 서비스 응답시간 증가
→ 특정 프로세스 재시작 증가
→ 오류 로그 증가

각각의 현상만 보면 원인이 불분명할 수 있지만 여러 데이터가 같은 시간대에 함께 변화한다면 하나의 장애 원인이나 성능 저하 과정과 연결될 가능성을 조사할 수 있다.

따라서 조기탐지에서는 개별 수치보다 여러 데이터 사이의 관계가 중요하다.

10. 변화의 방향과 속도를 분석해야 한다

장애 전조를 판단할 때는 현재 값뿐만 아니라 어떤 방향으로 얼마나 빠르게 변하고 있는가를 확인해야 한다.

예를 들어 CPU 사용률이 90%라고 해도 평소에도 90%를 유지하는 시스템이라면 반드시 이상 상태라고 볼 수 없다.

반면 30%에서 50%, 70%, 90%로 지속적으로 증가하고 있다면 현재 수치보다 증가 추세 자체가 중요한 정보가 된다.

따라서 다음과 같은 질문이 필요하다.

• 평소보다 증가하고 있는가?
• 증가속도가 빨라지고 있는가?
• 일정 시간 이상 지속되고 있는가?
• 이전 장애에서도 같은 패턴이 나타났는가?
• 다른 지표에서도 동시에 변화가 발생하고 있는가?

이러한 분석을 통해 단순한 높은 수치와 실제 이상징후를 구분할 수 있다.

11. 장애 전조와 임계값의 한계

시스템 모니터링에서는 특정 수치를 기준으로 경고를 발생시키는 임계값 방식이 많이 사용된다.

예를 들어 CPU 사용률이 일정 수준을 초과하면 경고를 발생시키는 방식이다.

이 방법은 단순하고 운영하기 쉽다는 장점이 있지만 한계도 있다.

정상적인 작업에서도 일시적으로 임계값을 초과할 수 있고, 반대로 실제 장애가 진행되고 있어도 특정 임계값을 넘지 않을 수 있다.

따라서 조기탐지에서는

임계값 + 변화 추세 + 지속시간 + 관련 지표

를 함께 고려하는 것이 더 효과적이다.

12. 장애 전조와 오탐·미탐

조기탐지 시스템에서는 모든 이상징후가 실제 장애로 이어지는 것은 아니다.

정상적인 작업을 장애로 잘못 판단하면 오탐(False Positive)이 발생하고, 실제 장애 전조를 놓치면 미탐(False Negative)이 발생한다.

오탐이 지나치게 많으면 운영자가 경고를 신뢰하지 않게 되고, 미탐이 많으면 실제 장애 대응시간을 확보하기 어렵다.

따라서 좋은 조기탐지 체계는 경고를 많이 발생시키는 것이 목적이 아니다.

실제로 대응할 가치가 있는 이상징후를 적절한 시점에 알려주는 것이 중요하다.

13. 장애 전조 데이터와 실제 장애의 연결

전조 데이터가 실제 장애와 관련이 있는지를 확인하려면 과거 장애 기록과 비교해야 한다.

예를 들어 과거 장애 사례에서

메모리 사용량 증가 → 스왑 증가 → 응답시간 증가 → 프로세스 장애

와 같은 순서가 반복되었다면 이러한 패턴은 향후 조기탐지 기준으로 활용할 수 있다.

반대로 특정 경고가 수천 번 발생했지만 실제 장애와 아무런 관련이 없었다면 해당 경고의 중요도를 낮추거나 다른 지표와 결합할 필요가 있다.

즉, 장애 전조 데이터는 과거 장애와 실제로 연결되는지를 검증하면서 신뢰도를 높여야 한다.

14. 장애 전조 분석의 실제 절차

실제 시스템에서는 다음과 같은 순서로 장애 전조를 분석할 수 있다.

1. 핵심 서비스와 주요 구성요소 선정
2. 정상 운영 데이터 수집
3. 주요 모니터링 지표 선정
4. 정상 상태의 기준 범위 설정
5. 과거 장애 데이터 수집
6. 장애 직전 데이터와 정상 데이터 비교
7. 반복적으로 나타나는 변화 패턴 확인
8. 여러 지표 사이의 상관관계 분석
9. 조기경보 기준 설정
10. 실제 운영환경에서 경보 검증
11. 오탐·미탐 분석
12. 기준값과 탐지조건 개선
13. 개선된 조건으로 재검증

여기서 중요한 것은 처음부터 완벽한 기준을 만드는 것이 아니라 실제 장애 데이터를 통해 계속 보정하는 것이다.

15. 장애 전조 데이터의 정량적 판단

장애 전조를 정량적으로 분석할 때는 단순한 현재값뿐 아니라 시간과 변화량을 함께 기록할 수 있다.

예를 들어 다음과 같은 항목을 관리할 수 있다.

분석 항목	확인 내용
현재값	현재 시스템 상태
기준값	정상 운영 시의 일반적인 수준
변화량	기준값과 현재값의 차이
변화율	일정 시간 동안 증가·감소한 정도
지속시간	이상 상태가 유지된 시간
발생빈도	동일 현상이 발생한 횟수
동시변화	다른 지표와 함께 변했는지 여부
장애 연관성	실제 장애와 연결된 사례가 있는지

이렇게 분석하면 단순히 “CPU가 높다”가 아니라

“평균보다 얼마나 증가했고, 얼마나 오래 지속되었으며, 다른 이상징후와 함께 나타났는가”

라는 방식으로 판단할 수 있다.

16. 조기탐지가 복원력에 미치는 영향

조기탐지는 그 자체가 목적이 아니다.

중요한 것은 장애를 조금이라도 일찍 발견함으로써 장애가 확대되기 전에 대응할 시간을 확보하는 것이다.

예를 들어 장애가 발생한 후 탐지하면 이미 서비스가 중단될 수 있지만, 장애 전조를 미리 발견하면 다음과 같은 대응이 가능하다.

• 문제 프로세스 재시작
• 부하 분산
• 장애 장비 교체
• 저장공간 확보
• 네트워크 경로 점검
• 트래픽 조정
• 서비스 우회
• 계획된 유지보수 수행

따라서 조기탐지는 Ⅱ-10에서 다룬 복원력 가운데 장애가 커지기 전에 대응할 수 있는 시간을 확보하는 기능으로 볼 수 있다.

17. 장애 전조 분석에서 확인할 핵심 질문

실제 시스템에 적용할 때는 다음 질문을 통해 판단할 수 있다.

1. 우리 시스템의 정상 상태는 무엇인가?
2. 정상 상태에서 벗어나는 대표적인 변화는 무엇인가?
3. 특정 지표가 아니라 여러 지표가 동시에 변하고 있는가?
4. 해당 변화가 얼마나 오래 지속되는가?
5. 변화 속도가 점점 빨라지고 있는가?
6. 과거 장애 직전에 동일한 패턴이 나타났는가?
7. 현재 경고 중 실제 장애와 관련된 경고는 무엇인가?
8. 현재 모니터링에서 오탐과 미탐이 어느 정도 발생하는가?
9. 장애 전조를 발견했을 때 실제 대응할 시간이 확보되는가?
10. 조기탐지 후 수행할 대응절차가 실제로 준비되어 있는가?

18. 최종 판단 — 조기탐지는 데이터를 많이 보는 것이 아니라 변화를 먼저 알아채는 것이다

컴퓨터 시스템의 장애 전조 분석은 수많은 모니터링 데이터를 수집하는 것만으로 완성되지 않는다.

중요한 것은 정상 상태를 알고, 그 상태에서 벗어나는 변화를 찾고, 여러 지표 사이의 관계를 분석하여 실제 장애와 연결되는 패턴을 확인하는 것이다.

특히 다음 네 가지를 함께 보는 것이 중요하다.

현재값 → 변화 추세 → 지속시간 → 다른 지표와의 관계

그리고 조기탐지의 최종 목적은 경고를 많이 발생시키는 것이 아니다.

장애가 발생하기 전에 실제로 대응할 수 있는 시간을 확보하는 것이다.

따라서 좋은 조기탐지 체계는

“장애가 발생했는가?”

를 알려주는 수준을 넘어,

“지금 나타나는 변화가 장애로 이어질 가능성이 있는가?”

를 판단할 수 있어야 한다.

핵심정리

• 장애 전조는 높은 수치 하나가 아니라 정상 상태에서 벗어나는 변화와 패턴으로 판단해야 한다.
• 조기탐지의 목적은 경고를 많이 발생시키는 것이 아니라 장애가 확대되기 전에 대응할 시간을 확보하는 것이다.

결국 중요한 것은 “우리 시스템에서 장애가 발생하기 직전에 반복적으로 나타나는 변화는 무엇인가?”를 찾아내는 것이다.