Ⅳ-4. 장애 발생 전 성능 변화 패턴 분석
컴퓨터 시스템 장애를 사후에만 분석하면 이미 발생한 문제의 원인을 찾는 데 집중하게 된다.
반면 장애가 발생하기 이전의 성능 데이터를 함께 분석하면 장애 직전에 어떤 변화가 나타났는지, 그리고 그 변화가 과거 장애 사례에서도 반복되었는지를 확인할 수 있다.
이러한 분석은 단순히 장애를 예측하는 것이 목적이 아니다.
과거 장애에서 반복적으로 나타난 변화를 찾아 조기탐지 기준과 사전 대응 기준을 만드는 것이 핵심이다.
1. 장애 전 성능 변화의 의미
장애가 발생하기 전에는 시스템 자원 사용량, 응답시간, I/O, 네트워크 지연, 오류 발생량 등에서 평소와 다른 변화가 나타날 수 있다.
예를 들어 다음과 같은 변화가 나타날 수 있다.
- 메모리 사용량이 지속적으로 증가
- 저장장치 응답시간이 점진적으로 증가
- 특정 시간대에 CPU 사용량이 반복적으로 상승
- 네트워크 지연시간의 변동폭 증가
- 서비스 응답시간과 오류 발생량이 동시에 증가
하지만 장애 이전에 변화가 있었다는 사실만으로 그 변화가 장애 전조라고 판단해서는 안 된다.
정상적인 작업에서도 동일한 변화가 나타날 수 있기 때문이다.
따라서 장애 전 패턴 분석에서는 변화의 존재보다 장애와의 반복적인 관계를 확인하는 과정이 중요하다.
2. 대표적인 장애 전 성능 변화 패턴
장애 발생 전에는 다양한 형태의 변화가 나타날 수 있다.
- 점진적인 증가
- 갑작스러운 상승
- 반복적인 상승과 하락
- 일정 수준 이상의 지속
- 변동폭 확대
- 여러 지표의 동시 변화
- 여러 지표의 순차적인 변화
- 특정 시간대의 반복적인 변화
같은 수치라도 변화 형태에 따라 해석이 달라질 수 있다.
예를 들어 CPU 사용률이 80%라는 사실만 보는 것과 평소 40% 수준이던 CPU가 장애 직전부터 80%까지 지속적으로 상승했다는 사실은 분석 가치가 다르다.
따라서 절대적인 수치뿐만 아니라 변화 방향, 속도, 지속시간, 반복성, 시간적 순서를 함께 확인해야 한다.
3. 점진적으로 증가하는 성능 변화
성능 지표가 일정한 방향으로 계속 변화한다면 누적적인 원인이 있는지 확인할 필요가 있다.
예를 들어 동일한 작업량에서 특정 프로세스의 메모리 사용량이 계속 증가한다면 메모리 누수나 비정상적인 객체 증가 등을 조사할 수 있다.
저장장치의 여유 공간이 지속적으로 감소한다면 로그, 데이터 파일, 임시 파일 등의 증가량을 함께 확인할 수 있다.
중요한 것은 증가했다는 사실보다 증가 속도와 지속시간이다.
하루에 조금씩 증가하는 현상과 짧은 시간 동안 급격히 증가하는 현상은 장애 위험을 판단하는 방법이 다를 수 있다.
4. 갑작스럽게 나타나는 성능 변화
갑작스러운 변화는 변화가 발생한 시점의 이벤트를 함께 확인하는 것이 중요하다.
예를 들어 다음과 같은 사건이 변화 시점과 일치하는지 확인할 수 있다.
- 프로그램 설치
- 소프트웨어 업데이트
- 설정 변경
- 서비스 재시작
- 특정 작업 시작
- 대량 데이터 처리
- 백업 또는 보안 검사
- 네트워크 구성 변경
특히 장애 직전에 특정 프로세스가 시작되거나 특정 자원의 사용량이 급격하게 변했다면 해당 이벤트는 원인 후보 또는 장애 촉발 요인으로 조사할 가치가 있다.
그러나 시간적으로 일치한다는 이유만으로 원인이라고 확정해서는 안 된다.
5. 반복적으로 나타나는 성능 변화
일정한 시간 간격으로 성능이 악화된다면 주기적인 작업과의 관계를 확인해야 한다.
대표적으로 다음과 같은 작업이 있다.
- 백업
- 데이터베이스 정리
- 보안 검사
- 로그 압축
- 배치 작업
- 데이터 집계
- 정기적인 파일 처리
예를 들어 매일 오전 특정 시간에 I/O 사용량과 응답시간이 함께 증가하고 동일한 시간대에 장애가 반복된다면 단순한 우연인지 반복적인 관계인지 비교할 수 있다.
이러한 반복성이 확인되면 장애 발생 조건을 보다 구체적으로 정의할 수 있다.
6. 평균값은 정상인데 변동성이 증가하는 경우
평균값이 크게 변하지 않더라도 데이터의 변동폭이 커지는 것은 중요한 변화일 수 있다.
예를 들어 네트워크 지연시간의 평균이 평소와 비슷하더라도 순간적으로 높은 지연이 반복된다면 일부 요청의 응답시간이 악화될 수 있다.
따라서 평균값만으로 상태를 판단하면 중요한 변화를 놓칠 수 있다.
필요한 경우 다음과 같은 지표를 함께 확인할 수 있다.
- 최소값
- 최대값
- 중앙값
- 표준편차
- p95
- p99
특히 응답시간이나 지연시간처럼 일부 요청에서만 문제가 발생하는 지표는 평균보다 상위 백분위수에서 변화가 먼저 나타날 수 있다.
7. 여러 지표가 순차적으로 변화하는 경우
장애가 하나의 지표 변화로 바로 나타나지 않고 여러 지표의 변화가 시간 순서에 따라 이어지는 경우도 있다.
예를 들어 다음과 같은 흐름이 반복될 수 있다.
저장장치 I/O 증가 → I/O 대기 증가 → 처리 지연 증가 → 응답시간 증가 → 서비스 오류 증가
이러한 시간 순서가 여러 장애 사례에서 반복된다면 각 지표를 별개의 현상으로 보는 것보다 하나의 장애 진행 과정에서 나타나는 연속적인 변화로 분석할 수 있다.
다만 실제 시스템에서는 처리 구조와 부하에 따라 순서가 달라질 수 있으므로 특정 순서를 일반적인 법칙처럼 적용해서는 안 된다.
8. 변화의 시작점을 찾는 것이 중요하다
장애 직전에 여러 지표가 동시에 변했다고 해서 모든 지표가 원인인 것은 아니다.
예를 들어 CPU, 메모리, I/O, 응답시간이 모두 증가했다면 먼저 어느 지표의 변화가 시작되었는지 확인해야 한다.
이를 위해 동일한 시간축에 주요 지표를 배치하면 분석하기 쉽다.
변화 시작 → 다른 지표 변화 → 서비스 영향 → 장애 발생
이러한 순서를 확인하면 장애의 초기 변화와 이후에 나타난 결과를 구분하는 데 도움이 된다.
9. 장애 직전의 데이터만 보면 안 되는 이유
장애 직전 5분 또는 10분의 데이터만 보면 중요한 정보를 놓칠 수 있다.
어떤 문제는 몇 시간 또는 며칠 동안 서서히 진행되다가 마지막 단계에서 장애로 나타날 수 있기 때문이다.
예를 들어 메모리 사용량이 수시간 동안 계속 증가한 뒤 장애 직전에 급격히 상승했다면 마지막 급상승만 보는 것보다 그 이전부터 존재했던 증가 추세를 함께 확인해야 한다.
따라서 분석 구간은 장애 유형에 따라 적절하게 설정해야 한다.
10. 과거 장애 데이터를 비교해야 한다
한 번의 장애 사례에서 특정 패턴을 발견했다고 해서 바로 전조로 정의해서는 안 된다.
과거에 동일하거나 유사한 장애가 발생했다면 각각의 장애 이전 데이터를 비교해야 한다.
예를 들어 세 번의 장애에서 다음과 같은 변화가 반복되었다고 가정할 수 있다.
| 장애 사례 | 장애 전 주요 변화 |
|---|---|
| 1회 | 메모리 사용량 지속 증가 → 응답시간 증가 |
| 2회 | 메모리 사용량 지속 증가 → 응답시간 증가 |
| 3회 | 메모리 사용량 지속 증가 → 응답시간 증가 |
이처럼 여러 사례에서 비슷한 변화 순서가 반복된다면 해당 패턴은 단일 사례보다 높은 분석 가치를 가진다.
11. 장애가 발생하지 않은 사례도 비교해야 한다
장애가 발생한 사례만 분석하면 정상적인 성능 변화까지 장애 전조로 잘못 판단할 수 있다.
예를 들어 매일 백업 시간에 CPU 사용률이 80%까지 증가하지만 장애가 발생하지 않는다면 CPU 80% 자체를 장애 전조라고 정의하기 어렵다.
따라서 다음 두 가지를 함께 비교해야 한다.
- 특정 패턴 이후 실제 장애가 발생한 경우
- 동일하거나 유사한 패턴이 나타났지만 장애가 발생하지 않은 경우
이 비교를 통해 정상적인 변동과 실제 장애와 관련된 변화를 구분할 수 있다.
12. 변화의 크기보다 변화의 조건을 함께 봐야 한다
같은 변화량이라도 시스템의 부하와 운영 조건에 따라 의미가 달라질 수 있다.
예를 들어 CPU 사용률이 50%에서 70%로 증가했다는 사실만으로 장애 위험을 판단할 수는 없다.
평소 정상적인 배치 작업에서 발생하는 변화인지, 정상적인 작업량에서도 발생한 비정상적인 변화인지에 따라 해석이 달라진다.
따라서 다음 조건을 함께 확인해야 한다.
- 당시 작업량
- 사용자 요청량
- 실행 중인 작업
- 시스템 자원 상태
- 시간대
- 서비스 응답시간
- 오류 발생 여부
- 과거 동일 사례
13. 장애 전 패턴과 로그 이벤트를 함께 확인한다
성능 데이터만 분석하면 변화가 발생했다는 사실은 확인할 수 있지만 그 시점에 어떤 시스템 이벤트가 있었는지는 알기 어려울 수 있다.
따라서 Ⅳ-3에서 살펴본 것처럼 장애 전 성능 변화와 시스템 로그를 동일한 시간축에서 비교할 필요가 있다.
예를 들어 다음과 같은 관계를 확인할 수 있다.
특정 프로세스 시작 → CPU 사용량 증가 → 응답시간 증가 → 오류 로그 증가
이러한 관계가 여러 장애 사례에서 반복된다면 해당 이벤트와 성능 변화의 관계를 보다 구체적으로 조사할 수 있다.
14. 조기탐지 기준으로 만들기 위한 조건
장애 전 패턴을 실제 모니터링 기준으로 사용하려면 단순한 변화 발견만으로는 부족하다.
다음 조건을 확인하는 것이 좋다.
- 정상 상태에서 얼마나 벗어났는가
- 변화가 얼마나 빠르게 발생했는가
- 얼마나 오래 지속되었는가
- 과거 장애에서도 반복되었는가
- 장애가 발생하지 않은 경우에도 흔하게 나타나는가
- 다른 지표의 변화와 함께 나타나는가
- 장애보다 먼저 발생하는가
- 실제 서비스 영향과 연결되는가
이러한 조건이 반복적으로 확인될수록 조기탐지 기준으로 활용할 가치가 높아진다.
15. 단순 임계값과 장애 전 패턴은 다르다
CPU 90%, 메모리 90%, 응답시간 3초와 같은 단일 임계값은 모니터링의 시작점으로 사용할 수 있다.
그러나 임계값을 넘었다는 사실만으로 장애가 발생한다고 판단해서는 안 된다.
반대로 임계값에 도달하지 않았더라도 평소와 다른 변화가 반복되고 실제 장애와 연결된다면 중요한 전조가 될 수 있다.
따라서 조기탐지는 절대적인 수치 하나보다 변화의 방향과 지속시간, 반복성, 다른 지표와의 관계를 함께 보는 방식이 더 적합할 수 있다.
16. 정상적인 주기 작업과 장애 전조를 구분한다
모든 반복적인 성능 변화가 장애 전조는 아니다.
예를 들어 매일 새벽 백업 과정에서 저장장치 I/O가 증가하지만 서비스 영향이 없고 장애도 발생하지 않는다면 해당 변화는 정상적인 운영 패턴일 가능성이 높다.
반면 동일한 백업 과정에서 최근부터 응답시간 증가와 오류 발생이 함께 나타나기 시작했다면 기존의 정상 패턴이 변화했는지 다시 확인해야 한다.
즉, 반복된다는 사실만 보는 것이 아니라 반복되는 패턴 자체가 정상 범위 안에 있는지도 확인해야 한다.
17. 장애 전 패턴의 신뢰도를 높이는 방법
하나의 지표에서 한 번 나타난 변화보다 다음 조건을 만족하는 패턴이 더 높은 분석 가치를 가진다.
- 여러 장애 사례에서 반복됨
- 장애 발생 전에 나타남
- 일정한 시간적 순서가 존재함
- 장애가 발생하지 않은 사례에서는 상대적으로 적음
- 다른 성능 지표나 로그와 함께 나타남
- 실제 서비스 영향과 연결됨
이러한 조건을 만족하는 패턴이라면 단순한 이상 현상을 넘어 실제 조기탐지 후보로 검토할 수 있다.
18. 장애 전 패턴을 원인으로 단정하면 안 되는 이유
장애 전에 나타난 모든 변화가 장애의 원인은 아니다.
예를 들어 장애 직전에 응답시간이 증가했다면 응답시간 증가는 장애의 원인이 아니라 이미 발생한 내부 문제의 결과일 수도 있다.
따라서 장애 전 패턴을 분석할 때는 다음을 구분해야 한다.
원인 후보 → 중간 변화 → 서비스 영향 → 최종 장애
이 구분이 없으면 장애 결과를 원인으로 잘못 판단할 수 있다.
19. 실제 분석에서는 시간축을 하나로 맞춘다
장애 전 패턴을 분석할 때 가장 유용한 방법 중 하나는 주요 데이터를 동일한 시간축에 놓는 것이다.
예를 들어 다음 데이터를 같은 시간대별로 비교할 수 있다.
| 시간 | CPU | 메모리 | I/O | 응답시간 | 오류 |
|---|---|---|---|---|---|
| T-30분 | 정상 | 정상 | 정상 | 정상 | 없음 |
| T-20분 | 상승 | 정상 | 상승 | 정상 | 없음 |
| T-10분 | 상승 | 상승 | 높음 | 증가 | 일부 |
| T-5분 | 높음 | 상승 | 높음 | 크게 증가 | 증가 |
| T | 과부하 | 높음 | 높음 | 장애 수준 | 다수 |
이렇게 보면 단순히 각 지표가 높았다는 사실보다 어떤 변화가 먼저 시작되었는지를 확인하기 쉬워진다.
20. 장애 전 패턴 분석의 실무 절차
실제 시스템에서는 다음과 같은 순서로 분석할 수 있다.
① 과거 장애 발생시간 정리
→ ② 장애 이전 분석 구간 설정
→ ③ 주요 성능 데이터 추출
→ ④ 정상 상태와 비교
→ ⑤ 변화 방향·크기·속도 확인
→ ⑥ 지속시간과 반복성 확인
→ ⑦ 여러 지표의 시간 순서 비교
→ ⑧ 관련 로그 및 운영 이벤트 확인
→ ⑨ 장애가 발생하지 않은 사례와 비교
→ ⑩ 여러 장애 사례에서 공통 패턴 검증
→ ⑪ 조기탐지 후보 선정
→ ⑫ 실제 운영에서 재검증
이 과정을 거쳐야 특정 수치를 단순 경보 기준으로 사용하는 것이 아니라 실제 장애 이전에 반복되는 의미 있는 변화를 탐지 기준으로 발전시킬 수 있다.
21. 분석 결과를 실제 예방으로 연결한다
장애 전 패턴을 찾는 것만으로 분석이 끝나는 것은 아니다.
반복적인 패턴이 확인되었다면 다음 단계에서는 해당 변화가 나타났을 때 무엇을 확인하고 어떤 조치를 취할 것인지 정해야 한다.
예를 들어 다음과 같이 연결할 수 있다.
메모리 지속 증가 감지
→ 프로세스별 메모리 증가 확인
→ 특정 프로세스 집중 확인
→ 과거 장애 사례와 비교
→ 서비스 영향 여부 확인
→ 필요 시 프로세스 재시작 또는 원인 수정
이처럼 패턴 탐지 → 원인 확인 → 영향 판단 → 대응 → 결과 검증으로 연결되어야 실제 예방 효과를 만들 수 있다.
22. 장애 전 패턴 분석의 한계
모든 장애가 사전에 명확한 성능 변화를 보여주는 것은 아니다.
갑작스러운 하드웨어 고장, 전원 장애, 물리적 연결 단절 등은 성능 데이터만으로 사전에 예측하기 어려울 수 있다.
또한 데이터 수집 간격이 너무 길거나 필요한 로그와 성능 지표가 충분히 저장되지 않았다면 장애 직전의 변화를 놓칠 수도 있다.
따라서 장애 전 패턴 분석은 모든 장애를 예측하는 방법이 아니라 과거 데이터에서 반복적으로 확인되는 장애 전 변화를 찾아 조기탐지 가능성을 높이는 방법으로 이해해야 한다.
23. 최종 판단 — 장애 전 변화와 장애 전조는 구분해야 한다
장애가 발생하기 전에 성능 변화가 나타났다는 사실만으로 그것을 장애 전조라고 판단해서는 안 된다.
중요한 것은 그 변화가 장애보다 먼저 나타났는지, 여러 장애 사례에서 반복되었는지, 장애가 발생하지 않은 정상 사례에서는 어떻게 나타났는지, 다른 지표와 어떤 시간적 관계를 갖는지를 함께 확인하는 것이다.
결국 장애 전 패턴 분석의 목적은 특정 숫자를 찾아내는 것이 아니다.
정상 상태에서 벗어난 변화 중 실제 장애와 반복적으로 연결되는 패턴을 찾아내고, 이를 조기탐지와 예방에 활용할 수 있는 수준까지 검증하는 것이다.
24. 핵심정리
- 장애 전 성능 변화는 점진적 증가, 급격한 변화, 반복 패턴, 변동성 증가, 여러 지표의 순차적 변화 등 다양한 형태로 나타날 수 있다.
- 단일 수치보다 변화의 방향·속도·지속시간·반복성·시간적 순서를 함께 보는 것이 중요하다.
- 장애가 발생한 사례뿐 아니라 같은 패턴이 나타났지만 장애가 발생하지 않은 사례도 비교해야 한다.
- 장애 전 변화와 실제 장애 전조는 같은 개념이 아니다. 반복적인 검증을 거쳐야 조기탐지 기준으로 활용할 수 있다.
가장 중요한 판단 기준은 이것이다.
“이 변화가 장애 직전에 한 번 나타난 것인가, 아니면 여러 장애 사례에서 반복적으로 나타나 실제로 조기탐지에 사용할 수 있는 패턴인가?”
댓글 0
첫 댓글을 남겨보세요.