Ⅳ. 컴퓨터 시스템 모니터링 및 장애 예측 분석

Ⅳ-2. 성능 데이터 기반 이상징후 탐지 분석

컴퓨터 시스템의 장애는 어느 순간 갑자기 발생한 것처럼 보일 수 있지만, 실제 운영 데이터에서는 장애 이전부터 평소와 다른 변화가 나타나는 경우가 있다.

CPU 사용률, 메모리 사용량, 저장장치 I/O, 네트워크 지연시간, 시스템 응답시간, 오류 및 타임아웃 등의 변화가 대표적인 관찰 대상이다.

그러나 성능 데이터가 평소와 달라졌다고 해서 모두 장애 전조라고 볼 수는 없다.

정상적인 백업이나 배치 작업, 사용자 증가, 시스템 변경 등으로도 성능 수치가 달라질 수 있기 때문이다.

따라서 이상징후 탐지의 핵심은 단순히 “수치가 높아졌는가?”를 확인하는 것이 아니다.

정상적인 변화와 비정상적인 변화를 구분하고, 그 변화가 실제 장애와 연결되는지를 검증하는 것이 중요하다.

1. 성능 데이터에서 말하는 이상징후란

이상징후는 시스템이 정상적으로 운영될 때 나타나는 일반적인 성능 패턴에서 벗어난 변화를 의미한다.

여기서 중요한 것은 이상징후와 장애를 동일하게 취급하지 않는 것이다.

예를 들어 CPU 사용률이 순간적으로 90%까지 올라갔다가 정상으로 돌아왔다면 단순한 작업량 증가일 수 있다.

반면 평소 40% 수준이던 CPU 사용률이 계속 상승하면서 응답시간과 오류까지 함께 증가한다면 별도의 분석이 필요하다.

따라서 이상징후는 장애의 확정이 아니라 추가 조사가 필요한 변화로 보는 것이 적절하다.

2. 이상징후 탐지에 사용하는 주요 데이터

이상징후 탐지에서는 특정 성능 지표 하나보다 시스템 전체의 상태를 확인할 수 있는 여러 데이터를 활용한다.

주요 대상은 다음과 같다.

영역	주요 데이터	분석 목적
CPU	사용률, Load, Run Queue, 코어별 사용률	처리 여유와 포화 여부
메모리	사용량, 가용 메모리, Swap/Page 관련 지표	메모리 압박 여부
저장장치	IOPS, 처리량, 응답시간, Queue Depth	I/O 병목 여부
네트워크	지연시간, 패킷 손실, 처리량	통신 품질 변화
서비스	응답시간, 처리량, 오류율, 타임아웃	실제 서비스 영향
프로세스	CPU·메모리 사용량, 프로세스 수	특정 프로세스 이상
로그	오류, 경고, 반복 메시지	성능 지표 외 이상 탐지

이 데이터들은 각각 독립적으로 분석할 수도 있지만, 실제 장애 분석에서는 같은 시간축에서 서로 어떤 관계를 보이는지 확인하는 것이 중요하다.

3. 정상 기준선을 만드는 방법

이상징후를 찾으려면 먼저 정상적인 상태의 범위를 알아야 한다.

가장 단순한 방법은 정상 운영기간의 평균값을 기준으로 사용하는 것이다.

그러나 평균값 하나만으로 정상 범위를 결정하면 문제가 생길 수 있다.

예를 들어 업무시간에는 CPU 사용률이 높고 야간에는 낮은 시스템이라면 하루 전체 평균값은 실제 정상 상태를 제대로 표현하지 못할 수 있다.

따라서 기준선을 만들 때는 다음 조건을 함께 고려할 필요가 있다.

• 시간대
• 요일
• 사용자 수
• 업무량
• 요청 유형
• 정기 작업
• 시스템 구성
• 계절적 변화

즉, 정상 기준선도 시스템의 운영 패턴에 맞게 만들어야 한다.

4. 절대값 비교 방식의 한계

가장 간단한 이상징후 탐지 방법은 특정 값을 기준으로 정상과 이상을 구분하는 것이다.

예를 들어 CPU 사용률이 80%를 넘으면 경보를 발생시키는 방식이다.

이 방법은 단순하고 관리하기 쉽다는 장점이 있지만, 시스템의 실제 정상 상태가 변하면 정확도가 떨어질 수 있다.

평소 CPU가 30%인 시스템과 평소 75%인 시스템에서 동일한 80%라는 기준을 적용하는 것은 적절하지 않을 수 있다.

따라서 고정된 숫자만 사용하는 방식은 초기 경보 기준으로는 유용하지만 정교한 이상징후 탐지에는 한계가 있다.

5. 기준선과 현재값의 차이를 분석한다

현재값이 정상 기준선에서 얼마나 벗어났는지를 확인하면 이상 정도를 판단하는 데 도움이 된다.

예를 들어 평소 응답시간이 200ms 수준인데 현재 300ms라면 단순히 300ms라는 숫자만 보는 것보다 평소보다 얼마나 증가했는지를 함께 확인하는 것이 유용하다.

다만 모든 데이터에 동일한 계산법을 적용할 수 있는 것은 아니다.

특히 기준값이 0에 가까운 지표는 단순 변화율이 지나치게 크게 나타날 수 있기 때문에 절대적인 차이, 기준 범위, 발생 빈도 등의 다른 방법을 함께 사용하는 것이 적절하다.

6. 평균값만으로 이상을 판단하면 놓치는 것이 생긴다

평균값은 전체적인 상태를 파악하는 데 유용하지만 순간적인 이상이나 특정 구간의 급격한 변화를 숨길 수 있다.

예를 들어 대부분의 요청이 100ms에 처리되지만 일부 요청이 5초 이상 걸리는 경우 평균값만 보면 큰 문제가 없어 보일 수 있다.

따라서 서비스 응답시간처럼 일부 요청의 지연이 중요한 지표에서는 평균뿐 아니라 다음과 같은 값도 함께 확인할 필요가 있다.

• 최소값
• 최대값
• 중앙값
• 상위 백분위값
• 특정 구간의 분포

이렇게 해야 평균적으로 정상인 것처럼 보이지만 일부 요청에서 심각한 지연이 발생하는 상황을 발견할 수 있다.

7. 이동평균을 이용해 일시적인 변동을 줄인다

성능 데이터에는 순간적인 변동이 포함될 수 있다.

이때 일정 구간의 값을 평균하여 이동평균을 계산하면 일시적인 변동보다 전체적인 변화 방향을 확인하기 쉬워진다.

예를 들어 최근 5개 측정값을 이용한 이동평균이 다음과 같이 계속 상승한다면 단일 측정값의 상승보다 지속적인 변화로 판단할 근거가 높아진다.

50 → 52 → 55 → 58 → 61

이 방법은 단기적인 잡음을 줄이는 데 도움이 되지만, 너무 긴 구간을 사용하면 급격한 장애 전조를 늦게 발견할 수 있다.

따라서 이동평균의 기간은 시스템의 변화 속도와 장애 발생 특성을 고려해야 한다.

8. 정상 범위를 벗어난 정도를 함께 확인한다

이상징후 탐지에서는 단순히 기준선을 넘었는지 여부뿐 아니라 얼마나 벗어났는지도 중요하다.

예를 들어 정상 응답시간이 200~300ms 범위인데 310ms가 한 번 발생한 것과 800ms가 반복적으로 발생하는 것은 같은 수준의 이상으로 보기 어렵다.

따라서 이상 탐지에서는

정상 범위 → 경미한 이탈 → 주의 수준 → 심각한 이탈

처럼 변화 정도를 구분하는 방법을 사용할 수 있다.

이렇게 하면 단순한 경보 발생보다 실제 대응 우선순위를 정하기 쉬워진다.

9. 변화속도가 빠른 이상을 별도로 확인한다

현재값이 아직 위험한 수준에 도달하지 않았더라도 변화속도가 지나치게 빠르면 주의가 필요할 수 있다.

예를 들어 메모리 사용량이

60% → 65% → 70% → 75% → 80%

처럼 짧은 시간에 계속 증가한다면 현재 80%라는 값만 보는 것보다 증가 과정 자체가 중요한 정보가 된다.

특히 이러한 변화가 정상적인 업무량 증가로 설명되지 않는다면 메모리 누수나 특정 프로세스의 비정상적인 증가 등을 조사할 필요가 있다.

10. 지속되는 이상과 순간적인 이상을 구분한다

이상징후가 얼마나 오래 지속되는지도 탐지 결과의 신뢰성에 영향을 준다.

예를 들어 CPU 사용률이 95%를 5초 동안 기록한 것과 95% 이상을 30분 동안 유지한 것은 운영상 의미가 다르다.

따라서 이상징후 조건을 설정할 때는

수치 + 지속시간

을 함께 사용하는 방법이 효과적일 수 있다.

예를 들어 단순히 “CPU 90% 초과”가 아니라 “CPU 90% 초과 상태가 일정 시간 이상 지속”되는 조건으로 설정하면 일시적인 작업 때문에 발생하는 경보를 줄일 수 있다.

11. 반복되는 이상은 하나의 패턴으로 분석한다

한 번 발생한 이상보다 특정 조건에서 반복되는 이상이 더 중요한 정보가 될 수 있다.

예를 들어 매일 같은 시간에 I/O가 증가한다면 정기 백업이나 배치 작업의 영향일 가능성이 있다.

반면 특정 작업 이후에만 I/O 증가와 응답시간 증가가 반복된다면 해당 작업과 시스템 성능의 관계를 조사할 필요가 있다.

반복 패턴을 분석할 때는 다음을 확인할 수 있다.

• 발생 시간
• 발생 빈도
• 지속시간
• 선행 작업
• 함께 변화하는 지표
• 실제 장애 발생 여부

12. 여러 지표가 함께 변하는지 확인한다

이상징후 탐지에서 가장 중요한 분석 중 하나는 여러 지표의 변화가 같은 시간대에 발생하는지 확인하는 것이다.

예를 들어

메모리 가용량 감소 → Page 관련 활동 증가 → I/O 응답시간 증가 → 애플리케이션 응답시간 증가

가 반복된다면 단일 지표보다 전체적인 변화 흐름을 분석하는 것이 더 유용하다.

다만 여러 지표가 동시에 변했다고 해서 서로 직접적인 인과관계가 있다고 단정해서는 안 된다.

어떤 지표가 먼저 변화했는지와 실제 장애 이력까지 함께 확인해야 한다.

13. 시간적 선후관계를 분석한다

이상징후 탐지에서는 단순한 동시 발생보다 어떤 변화가 먼저 발생했는가가 중요하다.

예를 들어 장애 발생 30분 전에 특정 프로세스의 메모리 사용량이 증가하고, 20분 전에 I/O가 증가하고, 5분 전에 응답시간이 급격히 증가했다면 이 순서를 과거 장애 사례와 비교할 수 있다.

반대로 장애가 먼저 발생한 뒤 CPU나 I/O가 증가했다면 해당 성능 변화는 장애의 원인이 아니라 결과일 수 있다.

따라서 이상징후 탐지는 단순한 상관관계보다 시간적 순서를 포함한 분석으로 발전해야 한다.

14. 정상적인 반복 작업을 탐지 기준에서 구분한다

시스템에서는 일정한 작업이 반복적으로 실행된다.

예를 들어

• 백업
• 로그 압축
• 데이터 정리
• 배치 작업
• 정기 업데이트
• 데이터베이스 유지보수

등은 일정한 시간에 CPU나 I/O를 증가시킬 수 있다.

이러한 변화가 장애와 연결되지 않는다면 매번 이상징후로 판단할 필요가 없다.

따라서 탐지 기준을 만들 때는 정상적인 반복 패턴을 먼저 식별하고 그 범위를 별도로 관리하는 것이 오탐을 줄이는 데 도움이 된다.

15. 오탐과 미탐을 함께 관리한다

이상징후 탐지에서는 경보를 많이 발생시키는 것이 목표가 아니다.

정상적인 작업을 이상으로 판단하면 오탐이 증가하고, 반대로 기준을 지나치게 느슨하게 설정하면 실제 장애 전조를 놓치는 미탐이 증가할 수 있다.

따라서 탐지 기준은 다음 두 가지를 함께 고려해야 한다.

오탐 감소 → 불필요한 대응 최소화

미탐 감소 → 실제 장애 전조 누락 방지

두 목표 사이의 균형을 찾기 위해서는 과거 정상 데이터와 실제 장애 데이터를 함께 사용해야 한다.

16. 이상징후 탐지 결과를 점수화할 수도 있다

여러 조건이 동시에 발생할 때 단순한 경보 여부 대신 위험도를 단계적으로 관리할 수도 있다.

예를 들어 다음과 같이 구성할 수 있다.

관찰 조건	판단
단일 지표의 일시적 변화	관찰
동일 지표의 반복 변화	주의
여러 지표의 동시 변화	분석 필요
성능 저하 + 오류 증가	높은 관심
과거 장애와 동일한 패턴 반복	우선 조사

이러한 방식은 하나의 숫자로 장애 가능성을 확정하는 것이 아니라 여러 관찰 결과를 종합하여 조사 우선순위를 정하는 방법이다.

17. 이상징후와 실제 장애를 연결하는 방법

이상징후 탐지의 최종적인 가치는 실제 장애 예방에 있다.

따라서 탐지된 패턴이 실제로 의미가 있는지를 과거 장애와 비교해야 한다.

예를 들어 과거 10건의 장애 중 7건에서 특정 프로세스의 메모리 증가가 장애 전에 반복되었다면 해당 변화는 향후 중요한 관찰 대상으로 관리할 근거가 생긴다.

그러나 10건 중 1건에서만 나타났다면 아직 일반적인 장애 전조라고 판단하기에는 근거가 부족할 수 있다.

즉, 탐지 → 장애 이력 비교 → 반복성 검증 → 기준 보완의 과정이 필요하다.

18. 이상징후 탐지에서 원인과 증상을 구분한다

성능 데이터의 이상은 원인일 수도 있지만 결과일 수도 있다.

예를 들어 데이터베이스 장애 때문에 애플리케이션 응답시간이 증가하고 CPU 사용량까지 변할 수 있다.

이 경우 CPU 증가만 보고 CPU가 장애 원인이라고 판단하면 잘못된 분석이 된다.

따라서 이상징후가 발견되면 다음 순서로 확인하는 것이 좋다.

무엇이 변했는가 → 무엇이 먼저 변했는가 → 무엇이 함께 변했는가 → 실제 서비스에 어떤 영향이 있었는가 → 과거에도 같은 순서가 반복되었는가

이 과정을 통해 단순한 증상과 실제 원인 후보를 구분할 수 있다.

19. 장기간 데이터를 이용해 탐지 기준을 계속 보완한다

이상징후 탐지 기준은 한 번 설정하고 영구적으로 사용하는 것이 적절하지 않을 수 있다.

사용자 수가 증가하거나 시스템이 증설되고 애플리케이션이 변경되면 정상적인 성능 범위도 달라질 수 있기 때문이다.

따라서 장기간 데이터를 이용해 다음과 같은 변화를 지속적으로 확인할 필요가 있다.

• 정상 범위의 변화
• 평균 및 분포의 변화
• 반복 작업의 변화
• 장애 발생 조건의 변화
• 새로운 이상 패턴
• 기존 탐지 기준의 오탐·미탐

이러한 재검증을 통해 탐지 기준을 실제 운영 환경에 맞게 유지할 수 있다.

20. 성능 데이터 기반 이상징후 탐지의 실제 절차

실제 시스템에서는 다음과 같은 순서로 접근할 수 있다.

1단계 — 정상 데이터 확보

장애가 없는 기간의 성능 데이터를 수집한다.

2단계 — 정상 패턴 구분

시간대, 요일, 업무량, 정기 작업에 따른 정상적인 변동을 구분한다.

3단계 — 기준선 설정

평균, 범위, 분포 등의 방법으로 정상 상태를 정의한다.

4단계 — 이상 변화 탐지

현재값이 정상 범위에서 벗어나는지 확인한다.

5단계 — 변화 특성 분석

변화량, 변화속도, 지속시간, 반복성을 확인한다.

6단계 — 복수 지표 비교

같은 시간대에 CPU, 메모리, I/O, 네트워크, 응답시간, 오류 등이 함께 변했는지 확인한다.

7단계 — 시간적 선후관계 확인

어떤 변화가 먼저 나타났는지 확인한다.

8단계 — 정상 작업과 비교

백업, 배치, 업데이트 등의 정상 작업이 원인인지 확인한다.

9단계 — 과거 장애와 비교

동일한 패턴이 실제 장애 이전에 반복되었는지 확인한다.

10단계 — 탐지 기준 재검증

분석 결과를 반영하여 경보와 이상징후 기준을 보완한다.

21. 성능 데이터 기반 이상징후 탐지의 한계

성능 데이터를 정교하게 분석하더라도 모든 장애를 미리 발견할 수 있는 것은 아니다.

시스템 자원 사용량이 정상 범위에 있어도 애플리케이션 내부 오류, 외부 서비스 장애, 잘못된 설정, 인증 문제 등의 원인으로 서비스가 중단될 수 있다.

또한 같은 이상 패턴이 나타나더라도 실제 원인은 서로 다를 수 있다.

따라서 성능 데이터 기반 이상징후 탐지는 장애를 자동으로 예측하는 완전한 방법이 아니라 장애 가능성을 조기에 발견하기 위한 분석 수단으로 이해해야 한다.

22. 최종 판단 — 이상징후 탐지는 ‘비정상’을 찾는 것이 아니라 ‘의미 있는 변화’를 찾는 것이다

성능 데이터 기반 이상징후 탐지는 단순히 높은 수치를 찾아내는 작업이 아니다.

정상 기준선을 만들고, 현재 데이터가 그 기준에서 얼마나 벗어났는지 확인하며, 변화의 속도와 지속시간, 반복성, 여러 지표의 동시 변화와 시간적 선후관계를 함께 분석해야 한다.

또한 정상적인 반복 작업에서 발생하는 변화와 실제 장애 이전에 나타나는 변화를 구분해야 한다.

가장 중요한 것은 탐지된 이상을 곧바로 장애 전조라고 확정하지 않는 것이다.

과거 장애와 비교하고, 동일한 패턴이 반복되는지 검증한 뒤 실제 운영 기준으로 활용해야 한다.

결국 좋은 이상징후 탐지는

정상 패턴 파악 → 변화 탐지 → 변화 특성 분석 → 복수 지표 비교 → 시간적 관계 확인 → 장애 이력 검증 → 탐지 기준 보완

으로 이어지는 반복적인 분석 과정이다.

23. 핵심정리

.