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

Ⅳ-1. 컴퓨터 시스템 모니터링 지표와 장애 전조 분석

컴퓨터 시스템의 장애는 어느 순간 갑자기 발생한 것처럼 보일 수 있다.

그러나 실제 운영 환경에서는 장애가 발생하기 전 CPU, 메모리, 저장장치, 네트워크, 응답시간, 오류 등의 상태가 평소와 다르게 변하는 경우가 있다.

문제는 모든 변화가 장애의 전조는 아니라는 점이다.

정상적인 업무량 증가 때문에 CPU 사용률이 높아질 수도 있고, 정기적인 백업 때문에 저장장치 I/O가 증가할 수도 있다. 반대로 시스템 자원 사용률이 크게 변하지 않았는데도 특정 애플리케이션 오류나 외부 서비스 장애로 서비스가 중단될 수도 있다.

따라서 모니터링의 목적을 단순히 “수치가 높아졌는가?”로 설정하면 실제 장애 전조를 제대로 구분하기 어렵다.

중요한 것은 정상 상태에서 무엇이 달라졌는지, 그 변화가 얼마나 지속되고 반복되는지, 그리고 과거 장애와 실제로 연결되는 패턴인지를 확인하는 것이다.

1. 컴퓨터 시스템 모니터링의 목적

시스템 모니터링은 하드웨어, 운영체제, 애플리케이션, 데이터베이스, 네트워크 등의 상태를 지속적으로 측정하고 기록하는 과정이다.

하지만 단순히 데이터를 수집하는 것만으로는 장애 예방이 되지 않는다.

모니터링의 목적은 크게 세 가지로 볼 수 있다.

• 현재 시스템 상태 확인
• 정상 상태와 다른 변화 탐지
• 장애 발생 전에 위험한 변화가 반복되는지 분석

즉, 모니터링은 현재 상태를 보는 기능에서 시작하지만 과거 데이터와 비교하면서 장애 예방으로 확장된다.

2. 어떤 지표를 모니터링해야 하는가

컴퓨터 시스템에서는 매우 많은 데이터를 수집할 수 있지만 모든 데이터를 동일한 수준으로 관리할 필요는 없다.

대표적인 모니터링 대상은 다음과 같다.

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

중요한 것은 지표의 개수가 아니다.

장애가 발생했을 때 실제 원인과 영향을 추적할 수 있는 지표를 선택하는 것이 더 중요하다.

3. 하나의 지표만으로 장애 전조를 판단하기 어려운 이유

CPU 사용률이 90%라고 해서 반드시 장애가 발생하는 것은 아니다.

대규모 연산 작업이 정상적으로 수행되는 상황이라면 높은 CPU 사용률이 정상일 수도 있다.

반대로 CPU 사용률이 50%에 불과하더라도 특정 애플리케이션의 오류나 외부 서비스 장애로 서비스가 중단될 수 있다.

따라서 모니터링에서는 개별 수치보다 서비스에 실제 영향을 주는 변화가 발생했는지를 함께 확인해야 한다.

4. 정상 상태 기준선을 먼저 만들어야 한다

장애 전조를 찾으려면 먼저 정상 상태가 무엇인지 정의해야 한다.

예를 들어 서버의 CPU 사용률이 평소 30~50% 수준인데 특정 시간대마다 80% 이상으로 증가한다면 변화 자체를 분석할 가치가 있다.

하지만 평소 70~90%를 유지하는 시스템이라면 같은 80%라는 숫자의 의미가 달라진다.

따라서 정상 기준선은 단순한 평균값 하나가 아니라 다음 조건을 함께 고려하는 것이 좋다.

• 시간대
• 요일
• 업무량
• 사용자 수
• 요청 유형
• 정기 작업
• 시스템 구성
• 계절적 또는 반복적 업무 패턴

정상 기준이 달라지면 같은 수치의 의미도 달라진다.

5. 현재값보다 평소와의 차이를 확인한다

모니터링에서 중요한 질문은 단순히

“현재 CPU가 몇 %인가?”

가 아니다.

더 중요한 질문은

“평소와 비교해서 얼마나 달라졌는가?”

이다.

예를 들어 평소 40%이던 CPU 사용률이 65%로 증가했다면 절대값만 보면 심각하지 않을 수 있다.

하지만 동일한 업무량에서 매일 조금씩 증가하고 있다면 장기적인 자원 부족이나 특정 프로세스의 변화 여부를 조사할 필요가 있다.

6. 변화의 크기보다 변화의 방향과 속도를 본다

같은 20%의 변화라도 의미는 다를 수 있다.

CPU 사용률이 40%에서 60%로 몇 시간에 걸쳐 증가한 경우와 몇 초 사이에 40%에서 60%로 급격하게 증가한 경우는 원인을 다르게 접근해야 한다.

따라서 모니터링에서는 다음을 함께 기록하는 것이 좋다.

• 현재값
• 기준값
• 변화량
• 변화율
• 변화속도
• 지속시간
• 반복횟수

이렇게 해야 단순한 일시적 변화와 지속적으로 진행되는 이상을 구분하기 쉬워진다.

7. 지속시간이 짧은 이상과 오래 지속되는 이상을 구분한다

모니터링 데이터에서 한 번 발생한 순간적인 이상과 장시간 지속되는 이상은 동일하게 취급해서는 안 된다.

예를 들어 백업 작업이 시작되는 순간 I/O가 급증했다가 종료 후 정상으로 돌아온다면 정기적인 작업의 영향일 가능성이 있다.

반면 백업이 종료된 후에도 I/O 지연이 계속 증가한다면 다른 원인을 확인해야 한다.

따라서 임계값을 넘었는지만 보는 것보다 얼마나 오래 유지되었는가를 함께 확인해야 한다.

8. 반복되는 이상은 별도로 관리해야 한다

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

예를 들어 매일 14시 전후로 응답시간이 증가한다면 단순한 우연인지, 특정 배치 작업이나 사용자 증가와 관련되어 있는지 확인할 수 있다.

반복성이 확인되면 다음 질문으로 분석을 확장할 수 있다.

• 항상 같은 시간에 발생하는가?
• 같은 업무에서 발생하는가?
• 같은 프로세스가 증가하는가?
• 같은 오류가 함께 발생하는가?
• 실제 장애로 이어진 적이 있는가?

반복되는 패턴은 장애 전조를 찾는 데 중요한 단서가 될 수 있다.

9. 여러 지표를 같은 시간축에서 비교한다

장애 전조를 분석할 때는 서로 다른 지표를 따로 보는 것보다 같은 시간축에 놓고 비교하는 것이 효과적이다.

예를 들어 다음과 같은 변화가 순서대로 나타날 수 있다.

메모리 가용량 감소 → Page 관련 활동 증가 → 저장장치 I/O 증가 → 응답시간 증가 → 타임아웃 증가

이러한 관계가 실제 시스템에서 반복된다면 각각의 지표를 별도로 보는 것보다 하나의 연속적인 변화로 분석할 수 있다.

다만 이러한 순서가 모든 시스템에서 항상 동일하게 발생한다고 단정해서는 안 된다.

10. 서비스 지표를 반드시 함께 확인한다

CPU나 메모리 같은 자원 지표만으로 시스템 상태를 판단하면 실제 사용자 영향이 빠질 수 있다.

따라서 다음과 같은 서비스 지표를 함께 확인하는 것이 중요하다.

• 응답시간
• 처리량
• 오류율
• 타임아웃
• 요청 실패율
• 사용자 요청 성공 여부

결국 시스템 자원이 변화했다는 사실보다 그 변화가 서비스에 실제 영향을 주었는가가 더 중요한 판단 기준이 될 수 있다.

11. 로그와 모니터링 데이터를 연결한다

모니터링 지표만으로 원인을 확정하기 어려운 경우가 많다.

예를 들어 응답시간이 증가했더라도 원인이 CPU인지 데이터베이스인지 네트워크인지 외부 서비스인지 수치 하나만으로는 판단하기 어렵다.

이때 다음 데이터를 같은 시간축에서 연결할 수 있다.

• 운영체제 로그
• 애플리케이션 로그
• 데이터베이스 로그
• 네트워크 장비 로그
• 시스템 변경 이력
• 배치 작업 기록
• 장애 발생 기록

모니터링 데이터는 “무엇이 달라졌는가”를 보여주고, 로그와 변경 이력은 “무슨 일이 있었는가”를 확인하는 데 도움을 준다.

12. 임계값 초과와 장애 전조를 구분한다

모니터링 시스템에서는 특정 수치를 넘으면 경보를 발생시키는 임계값을 설정할 수 있다.

그러나 임계값 초과는 조사가 필요한 조건이지 반드시 장애가 발생한다는 의미는 아니다.

예를 들어 CPU 80%를 넘었다고 해서 즉시 장애라고 판단할 수는 없다.

다음과 같은 추가 정보가 필요하다.

• 얼마나 초과했는가?
• 얼마나 오래 지속되었는가?
• 얼마나 자주 발생했는가?
• 다른 지표도 함께 변했는가?
• 실제 서비스 성능이 저하되었는가?
• 과거 장애와 동일한 패턴인가?

따라서 경보 기준과 장애 판단 기준을 분리하는 것이 중요하다.

13. 장애 발생 전후의 시간 순서를 분석한다

장애 전조 분석에서는 무엇이 먼저 발생했는지가 중요하다.

예를 들어

I/O 응답시간 증가 → 애플리케이션 응답시간 증가 → 타임아웃 증가 → 서비스 장애

라는 순서가 반복된다면 I/O 변화가 장애 과정의 초기 신호인지 검토할 수 있다.

반대로 서비스 오류가 먼저 발생하고 그 이후 CPU나 I/O가 증가했다면 성능 변화가 원인이 아니라 장애에 따른 결과일 가능성도 있다.

따라서 같은 시간에 발생했다는 사실만으로 인과관계를 확정해서는 안 된다.

14. 모니터링 수집 주기도 분석 목적에 맞춰야 한다

모든 시스템에 동일한 수집 주기를 적용할 필요는 없다.

수 초 단위로 발생하는 장애를 분석해야 하는 시스템에서 수십 분 단위로 데이터를 수집하면 중요한 순간을 놓칠 수 있다.

반대로 지나치게 짧은 간격으로 모든 데이터를 수집하면 저장해야 할 데이터가 크게 증가하고 일시적인 변화가 과도하게 기록될 수 있다.

따라서 수집 주기는 다음을 고려해 설정하는 것이 좋다.

• 시스템 특성
• 장애 발생 속도
• 장애 지속시간
• 분석 목적
• 저장 가능한 데이터 규모

15. 오탐을 줄이는 것도 모니터링의 중요한 목표다

모니터링 시스템이 이상을 많이 발견한다고 반드시 좋은 시스템은 아니다.

정상적인 백업이나 업데이트, 일시적인 업무량 증가를 계속 장애 전조로 판단하면 불필요한 경보가 반복된다.

경보가 너무 많아지면 운영자가 실제로 중요한 경보를 놓칠 가능성도 생긴다.

따라서 과거 데이터를 이용해 실제로 장애와 연결되지 않았던 정상적인 변화도 함께 확인하고 경보 조건을 조정할 필요가 있다.

16. 미탐도 함께 관리해야 한다

반대로 경보를 줄이는 데만 집중하면 실제 장애 전조를 놓칠 수 있다.

예를 들어 특정 애플리케이션 오류나 외부 API 장애처럼 CPU, 메모리, I/O에 큰 변화가 나타나지 않는 장애도 존재한다.

따라서 모니터링 범위를 자원 사용량에만 제한하지 않고 다음과 같이 확대할 필요가 있다.

자원 상태 + 서비스 상태 + 오류 + 로그 + 외부 의존성

이렇게 해야 자원 지표가 정상인데도 서비스가 장애를 일으키는 경우를 확인할 수 있다.

17. 과거 장애 이력과 비교해야 전조의 신뢰성을 높일 수 있다

모니터링 데이터 자체만으로는 어떤 변화가 중요한지 판단하기 어렵다.

과거 실제 장애가 발생했던 시점을 찾아 장애 이전의 데이터를 다시 확인하면 중요한 패턴을 발견할 수 있다.

예를 들어 여러 장애에서 공통적으로

• 특정 프로세스 메모리 증가
• I/O 응답시간 증가
• 특정 오류 반복
• 응답시간 증가
• 타임아웃 증가

등이 순서대로 나타났다면 해당 변화는 향후 모니터링에서 우선적으로 관찰할 가치가 있다.

중요한 것은 한 번 발견된 패턴을 바로 장애 전조라고 확정하지 않고 여러 사례에서 반복되는지 검증하는 것이다.

18. 장기간 모니터링 데이터의 가치

장기간 데이터가 축적되면 단순한 장애 감시를 넘어 시스템의 변화 자체를 분석할 수 있다.

예를 들어 사용자 수가 증가하면서 평균 응답시간이 조금씩 증가하거나 데이터 증가에 따라 저장장치 I/O가 지속적으로 증가하는 패턴이 나타날 수 있다.

이러한 데이터는 다음과 같은 의사결정에도 활용할 수 있다.

• 용량 증설 시점 판단
• 성능 개선 우선순위 결정
• 임계값 조정
• 시스템 구성 변경
• 장애 예방 계획
• 향후 용량 계획

즉, 모니터링 데이터는 장애가 발생했을 때만 사용하는 자료가 아니라 시스템의 장기적인 변화를 확인하는 운영 데이터가 된다.

19. 모니터링 데이터만으로 장애 원인을 확정할 수 없는 이유

모니터링에서 이상이 발견되었다고 해서 그 지표가 곧 장애 원인이라고 볼 수는 없다.

예를 들어 응답시간 증가와 CPU 사용률 증가가 동시에 발생했더라도 CPU가 원인일 수도 있고, 다른 문제 때문에 처리 대기가 증가하면서 CPU 사용률이 함께 변했을 수도 있다.

따라서 장애 원인을 판단할 때는 다음 정보를 함께 검토해야 한다.

모니터링 데이터 → 로그 → 구성정보 → 변경 이력 → 장애 이력 → 실제 서비스 영향

이 과정을 거쳐야 단순한 동시 발생과 실제 원인을 구분할 수 있다.

20. 장애 전조 분석의 실제 판단 순서

실제 운영 환경에서는 다음과 같은 순서로 접근하는 것이 효율적이다.

1단계 — 정상 기준선 확인

평소 시스템의 CPU, 메모리, I/O, 네트워크, 응답시간 등의 범위를 확인한다.

2단계 — 변화 탐지

현재 데이터가 평소와 비교해 무엇이 달라졌는지 확인한다.

3단계 — 변화 특성 분석

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

4단계 — 연관 지표 확인

같은 시간대에 다른 자원이나 서비스 지표도 변화했는지 확인한다.

5단계 — 로그와 변경 이력 확인

오류, 배치 작업, 업데이트, 구성 변경 등이 있었는지 확인한다.

6단계 — 과거 장애와 비교

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

7단계 — 전조 후보 선정

반복적으로 장애와 연결되는 변화만 별도의 장애 전조 후보로 관리한다.

8단계 — 재검증

새로운 장애 또는 정상 운영 데이터가 축적되었을 때 기존 판단이 계속 유효한지 다시 검증한다.

21. 모니터링의 최종 목적은 ‘예측 가능한 변화’를 찾는 것이다

여기서 한 단계 더 생각해볼 필요가 있다.

모니터링을 잘한다고 해서 모든 장애를 미리 예측할 수 있는 것은 아니다.

중요한 것은 모든 이상을 예측하는 것이 아니라 우리 시스템에서 실제 장애와 반복적으로 연결되는 변화를 찾아내는 것이다.

예를 들어 특정 서버에서

메모리 증가 → I/O 증가 → 응답시간 증가 → 타임아웃 증가

라는 변화가 여러 장애 사례에서 반복된다면 이 시스템에서는 해당 흐름 자체가 중요한 관찰 대상이 될 수 있다.

반면 같은 CPU 80% 초과라도 정상적인 배치 작업에서만 발생하고 장애와 전혀 연결되지 않는다면 장애 전조로 볼 근거가 약하다.

따라서 모니터링의 수준은 데이터를 얼마나 많이 모으느냐가 아니라 수집한 데이터에서 실제로 판단할 수 있는 패턴을 얼마나 정확하게 찾아내느냐로 평가하는 것이 더 적절하다.

22. 최종 판단 — 모니터링은 ‘현재 상태’보다 ‘변화의 의미’를 보는 작업이다

컴퓨터 시스템 모니터링은 CPU, 메모리, 저장장치, 네트워크 등의 수치를 계속 확인하는 작업에서 시작한다.

하지만 숫자를 많이 수집한다고 장애 예측이 자동으로 이루어지는 것은 아니다.

중요한 것은 정상 상태를 기준으로 무엇이 달라졌는지, 그 변화가 얼마나 지속되고 반복되는지, 다른 지표와 어떤 시간적 관계를 가지는지, 그리고 실제 장애와 반복적으로 연결되는지를 확인하는 것이다.

또한 임계값 초과를 장애와 동일하게 판단하지 않고 오탐과 미탐을 함께 관리해야 한다.

결국 좋은 모니터링은

데이터 수집 → 변화 탐지 → 연관관계 분석 → 과거 장애와 비교 → 전조 후보 검증 → 예방조치 → 재검증

으로 이어지는 하나의 분석 과정이다.

23. 핵심정리

• 모니터링의 핵심은 수치를 많이 모으는 것이 아니라 정상 상태와 다른 변화를 찾는 것이다.
• 높은 CPU, 메모리, I/O 수치 하나만으로 장애 전조를 판단할 수 없다.
• 변화량뿐 아니라 변화속도·지속시간·반복성을 함께 확인해야 한다.
• 여러 지표는 같은 시간축에서 비교해야 장애로 이어지는 흐름을 확인하기 쉽다.
• 임계값 초과는 장애 확정이 아니라 추가 분석이 필요한 경보 조건이다.
• 과거 실제 장애와 비교하여 반복되는 패턴을 검증해야 전조의 신뢰성을 높일 수 있다.
• 오탐을 줄이는 것과 동시에 실제 장애 전조를 놓치는 미탐도 관리해야 한다.
• 모니터링 데이터는 로그, 변경 이력, 구성정보, 서비스 상태와 함께 분석해야 한다.

가장 중요한 질문은 이것이다.

“우리 시스템에서 평소와 다른 변화 중 실제 장애 이전에 반복적으로 나타나는 것은 무엇이며, 그 변화를 장애가 발생하기 전에 식별할 수 있는가?”

Ⅳ-1. 컴퓨터 시