Ⅳ-5. 다중 성능 지표를 이용한 시스템 이상 상태 분석

컴퓨터 시스템은 CPU, 메모리, 저장장치, 네트워크 등 여러 자원이 서로 연결되어 작동한다. 따라서 하나의 성능 지표만으로 시스템 전체의 상태를 판단하기는 어렵다.

CPU 사용률이 정상 범위에 있더라도 저장장치의 I/O 대기시간이 길어지거나 네트워크 지연이 증가하면 서비스 응답이 느려질 수 있다. 반대로 CPU 사용률이 높더라도 서비스에 문제가 없다면 정상적인 작업량 증가일 수 있다.

따라서 시스템 이상 상태를 분석할 때는 개별 지표의 수치뿐 아니라 여러 지표가 언제, 어떤 순서로, 어떤 조합으로 변화했는지를 함께 살펴봐야 한다.

다중 지표 분석의 목적은 여러 수치를 모으는 데 있는 것이 아니라, 지표 사이의 관계를 통해 이상이 발생한 영역과 원인 후보를 좁혀 가는 데 있다.

1. 단일 지표 분석의 한계

CPU 사용률이 낮다고 해서 시스템 전체가 정상이라고 판단할 수는 없다.

예를 들어 프로그램이 저장장치의 데이터를 읽기 위해 대기하고 있다면 CPU가 실제 연산을 수행하지 못해 사용률이 낮게 나타날 수 있다. 네트워크 응답을 기다리는 상황에서도 CPU 사용률이 높지 않은 상태로 서비스 지연이 발생할 수 있다.

반대로 CPU 사용률이 높더라도 정상적인 대량 계산 작업 때문에 발생한 것이라면 반드시 장애라고 볼 수 없다.

단일 지표 분석에서는 다음과 같은 문제가 발생할 수 있다.

• 실제 문제가 발생한 자원이 아닌 다른 지표에만 집중할 수 있다.
• 지표가 정상 범위에 있다는 이유로 이상 상태를 놓칠 수 있다.
• 정상적인 부하 증가를 장애 전조로 오인할 수 있다.
• 서로 다른 자원 사이에서 발생하는 영향을 파악하기 어렵다.

따라서 개별 지표는 독립적으로 확인하되, 최종 판단에서는 다른 지표와의 관계를 함께 검토해야 한다.

2. 주요 성능 지표를 영역별로 구분한다

다중 지표 분석을 시작하려면 먼저 어떤 데이터를 함께 살펴볼 것인지 정해야 한다.

영역	주요 지표	확인할 내용
CPU	사용률, 실행 대기열, 부하	연산 부하와 처리 대기
메모리	사용량, 가용 메모리, 스왑 사용량	메모리 부족과 페이지 교체
저장장치	I/O 대기시간, 처리량, 대기열	입출력 지연과 처리 병목
네트워크	지연시간, 패킷 손실률, 재전송	통신 지연과 전송 오류
서비스	응답시간, 오류율, 타임아웃	사용자에게 나타나는 실제 영향
프로세스	프로세스 수, 스레드 수, 상태	작업 증가와 대기 상태

모든 지표를 무조건 수집할 필요는 없다. 시스템의 구조와 서비스 특성에 따라 핵심 지표를 선정하고, 장애가 발생했을 때 원인을 좁히는 데 필요한 보조 지표를 추가하는 방식이 효율적이다.

또한 지표마다 의미와 단위가 다르므로 수치를 단순히 비교하기보다는 각 지표가 나타내는 상태와 변화 방향을 해석해야 한다.

3. 여러 지표가 동시에 변화하는지 확인한다

여러 지표가 같은 시간대에 함께 변화한다면 공통된 작업이나 조건이 영향을 주었는지 확인할 필요가 있다.

예를 들어 CPU 사용률과 메모리 사용량이 동시에 증가하고 응답시간까지 길어진다면 특정 프로그램의 작업량 증가, 요청 집중, 데이터 처리량 변화 등을 원인 후보로 검토할 수 있다.

반면 네트워크 지연과 패킷 손실률이 증가하는 동안 CPU와 저장장치 지표가 평상시 수준을 유지한다면 네트워크 영역을 우선적으로 조사할 수 있다.

이때 중요한 것은 단순히 지표가 동시에 변했다는 사실만으로 원인을 확정하지 않는 것이다.

동시에 발생한 변화는 공통 원인을 찾기 위한 단서이며, 실제 원인인지는 로그, 이벤트, 구성 정보와 추가 측정을 통해 검증해야 한다.

4. 지표가 변화하는 순서를 분석한다

성능 지표는 반드시 동시에 변화하지 않는다. 한 영역의 변화가 다른 영역의 변화보다 먼저 나타날 수 있다.

예를 들어 다음과 같은 흐름을 관찰했다고 하자.

저장장치 I/O 대기시간 증가 → 서비스 응답시간 증가 → 타임아웃 증가

이러한 순서가 반복적으로 관찰된다면 저장장치의 상태 변화와 서비스 지연 사이에 어떤 관계가 있는지 조사할 수 있다.

또 다른 사례로 메모리 사용량이 증가한 후 스왑 사용이 늘고, 이후 응답시간이 길어지는 흐름이 나타날 수도 있다.

시간 순서는 원인 후보를 좁히는 데 도움이 되지만, 먼저 발생한 지표가 반드시 직접적인 원인이라는 뜻은 아니다. 두 현상이 더 앞선 공통 원인에 의해 발생했을 가능성도 확인해야 한다.

따라서 분석할 때는 각 지표의 변화 시작 시점과 서비스 영향이 나타난 시점을 함께 기록하는 것이 좋다.

5. 정상 상태의 지표 조합을 기준으로 삼는다

정상 기준선은 개별 지표에만 필요한 것이 아니다. 여러 지표가 함께 나타나는 정상적인 조합도 파악할 필요가 있다.

예를 들어 특정 시간대에 CPU 사용률이 높아지더라도 응답시간과 오류율이 안정적으로 유지된다면 정상적인 대량 처리 작업일 수 있다.

반대로 CPU 사용률이 평소와 비슷하더라도 I/O 대기시간과 응답시간이 함께 증가한다면 평소와 다른 상태일 수 있다.

따라서 정상 상태를 분석할 때는 다음을 확인한다.

• 평상시 각 지표의 일반적인 범위
• 업무 시간과 비업무 시간의 차이
• 정상적인 고부하 작업에서 나타나는 지표 조합
• 여러 지표가 함께 변할 때의 일반적인 응답 특성
• 서비스 오류나 지연 없이 유지되는 상태의 특징

이렇게 하면 특정 수치가 높거나 낮다는 사실만으로 판단하지 않고, 현재 시스템이 평소와 다른 상태에 있는지를 살펴볼 수 있다.

6. 지표 사이의 관계와 원인 관계를 구분한다

두 지표가 함께 증가한다고 해서 하나가 다른 하나를 직접적으로 유발했다고 단정할 수는 없다.

예를 들어 메모리 사용량과 응답시간이 동시에 증가했다면 다음과 같은 가능성을 검토할 수 있다.

• 메모리 부족이 성능 저하에 영향을 주었을 가능성
• 요청량 증가가 메모리 사용량과 응답시간을 함께 높였을 가능성
• 특정 프로그램의 처리 지연이 두 지표에 동시에 영향을 주었을 가능성
• 별개의 원인이 우연히 같은 시간대에 나타났을 가능성

따라서 지표 사이의 관계를 발견했다면 다음 단계에서는 원인 후보를 검증해야 한다.

로그에서 관련 이벤트를 확인하고, 프로세스별 자원 사용량을 비교하며, 설정 변경이나 작업량 변화를 함께 살펴보면 판단에 도움이 된다.

지표 사이의 상관관계는 분석의 출발점이지, 원인을 확정하는 근거 그 자체는 아니다.

7. 여러 지표의 조합으로 장애 영역을 좁힌다

다중 지표 분석은 장애가 어느 영역에 집중되어 있는지 판단하는 데 유용하다.

관찰된 지표 조합	우선 검토할 영역	추가 확인 사항
CPU 사용률과 실행 대기열 증가	CPU 처리 부하	특정 프로세스와 작업량
메모리 사용량 증가와 스왑 증가	메모리	가용 메모리와 프로세스별 사용량
I/O 대기시간과 서비스 응답시간 증가	저장장치 또는 입출력 경로	디스크 대기열과 I/O 처리량
네트워크 지연과 패킷 손실 증가	네트워크	경로, 재전송, 인터페이스 오류
여러 자원 지표와 오류율이 함께 악화	복합 부하 또는 공통 원인	공통 작업, 의존 서비스, 시스템 이벤트
자원 지표는 안정적이나 응답시간만 증가	애플리케이션 또는 외부 의존성 등	프로그램 내부 처리, 외부 서비스 응답

이 표는 원인을 확정하는 진단표가 아니라 조사 우선순위를 정하기 위한 출발점이다.

같은 지표 조합도 시스템 구조에 따라 다른 원인으로 나타날 수 있으므로, 실제 환경의 로그와 관측 결과를 통해 검증해야 한다.

8. 지표 사이의 영향이 다른 영역으로 전파되는지 확인한다

한 자원에서 시작된 문제가 다른 자원이나 서비스에 영향을 주는 경우도 있다.

예를 들어 저장장치 처리 지연으로 요청이 오래 대기하면 대기 중인 작업이 쌓일 수 있다. 이후 메모리 사용량이나 처리 대기열이 증가하고, 최종적으로 서비스 응답시간과 오류율이 악화될 가능성이 있다.

이때 처음 나타난 지표만 확인하면 문제의 전체 흐름을 놓칠 수 있다.

분석에서는 다음과 같은 질문을 활용할 수 있다.

1. 가장 먼저 변화한 지표는 무엇인가?
2. 이후 어떤 지표가 추가로 변화했는가?
3. 변화 사이에 시간적 간격이 있었는가?
4. 지표 변화가 다른 서비스나 자원으로 확산되었는가?
5. 실제 서비스 영향은 어느 시점에 나타났는가?

이러한 순서를 파악하면 개별 자원의 이상을 확인하는 데서 나아가, 시스템 안에서 문제가 전파되는 과정을 조사할 수 있다.

9. 시간축을 통일해 비교한다

다중 지표를 함께 분석하려면 각 데이터의 시간 기준을 맞춰야 한다.

CPU 데이터는 10초마다 수집되고 네트워크 데이터는 1분마다 수집된다면, 단순히 같은 행에 놓고 비교할 경우 변화 시점을 잘못 해석할 수 있다.

따라서 다음 사항을 확인해야 한다.

• 각 지표의 수집 주기
• 서버와 수집 시스템의 시계 차이
• 시간대 설정
• 데이터 수집 지연
• 결측값과 누락된 이벤트
• 평균값이 짧은 급변을 가리고 있는지 여부

시간축을 맞춘다는 것은 모든 데이터를 무조건 같은 간격으로 바꾸는 것만을 뜻하지 않는다. 원래 수집 주기와 데이터 특성을 고려해 비교 가능한 형태로 정렬하는 것이 중요하다.

특히 짧은 장애 전조를 분석할 때는 긴 수집 간격 때문에 중요한 변화가 누락되지 않았는지도 확인해야 한다.

10. 그래프를 활용해 변화 관계를 확인한다

여러 지표를 시간 순서대로 시각화하면 개별 수치만 볼 때 놓치기 쉬운 관계를 확인할 수 있다.

예를 들어 장애 발생 시점을 기준으로 CPU, 메모리, I/O 대기시간, 네트워크 지연, 서비스 응답시간을 각각 그래프로 나타내고 변화 시작 시점을 비교할 수 있다.

이때 다음과 같은 방식이 유용하다.

• 지표별 그래프의 시간축을 통일한다.
• 장애 발생 시점과 주요 이벤트를 표시한다.
• 지표가 정상 범위를 벗어난 시점을 표시한다.
• 각 지표의 변화 시작 시점과 종료 시점을 비교한다.
• 서비스 응답과 오류가 나타난 시점을 함께 확인한다.

단, 단위와 값의 범위가 다른 지표를 하나의 축에 무리하게 표시하면 작은 변화가 가려질 수 있다. 필요하다면 지표별 그래프를 분리하되 시간축을 동일하게 유지하는 방식이 더 적절하다.

그래프는 관계를 발견하기 위한 도구이며, 원인 확정에는 추가 검증이 필요하다.

11. 실제 분석 사례를 구성한다

다음은 여러 성능 지표의 관계를 분석하는 방법을 보여 주기 위한 가상의 사례다.

시점	I/O 대기시간	응답시간	오류율	관찰 내용
10:00	정상	정상	정상	평상시 상태
10:05	증가 시작	정상	정상	저장장치 지표 변화
10:08	높게 유지	증가 시작	정상	서비스 지연 발생
10:12	높게 유지	높게 유지	증가 시작	오류가 추가로 발생
10:15	변동	높게 유지	증가	원인 조사 필요

이 사례에서는 I/O 대기시간의 변화가 응답시간과 오류율의 변화보다 먼저 나타났다.

따라서 저장장치나 입출력 경로를 원인 후보로 검토할 수 있다. 하지만 이 시간적 순서만으로 저장장치가 직접적인 원인이라고 확정할 수는 없다.

같은 시간대에 발생한 배치 작업, 요청량 증가, 외부 서비스 지연 등의 가능성을 함께 확인해야 한다.

이처럼 다중 지표 분석은 관찰된 사실과 아직 검증되지 않은 원인 가설을 구분해 기록하는 것이 중요하다.

12. 실무 분석 절차

다중 성능 지표를 활용한 분석은 다음 순서로 진행할 수 있다.

① 핵심 지표를 선정한다

시스템 구조와 서비스 특성에 맞춰 CPU, 메모리, 저장장치, 네트워크, 서비스 지표를 선정한다.

② 정상 기준선을 확보한다

평상시와 정상적인 고부하 상황에서 각 지표가 어떻게 나타나는지 확인한다.

③ 장애 및 이상 발생 시점을 정리한다

장애 발생 시각, 응답 지연 시작 시각, 오류 발생 시각을 기록한다.

④ 동일한 시간축에서 데이터를 정렬한다

수집 주기와 시계 차이를 고려해 지표를 비교할 수 있는 형태로 정리한다.

⑤ 개별 지표의 변화를 확인한다

각 지표가 언제 정상 범위를 벗어났으며 얼마나 오래 지속되었는지 확인한다.

⑥ 동시 변화와 순차 변화를 구분한다

여러 지표가 함께 변했는지, 일정한 순서로 변했는지 분석한다.

⑦ 원인 후보를 설정한다

변화 순서와 지표 조합을 바탕으로 조사할 영역을 좁힌다.

⑧ 로그와 이벤트를 비교한다

관련 프로세스, 작업량, 설정 변경, 외부 의존 서비스 등의 정보를 확인한다.

⑨ 가설을 검증한다

추가 측정과 과거 사례 비교를 통해 원인 후보가 관찰 결과를 설명하는지 확인한다.

⑩ 탐지 기준을 개선한다

반복적으로 확인되는 지표 조합과 시간적 패턴을 활용해 조기탐지 기준을 보완한다.

13. 다중 지표 분석의 한계

여러 지표를 함께 분석한다고 해서 모든 장애 원인을 정확하게 찾을 수 있는 것은 아니다.

지표 사이의 관계가 복잡하거나 수집 데이터가 부족하면 원인 후보를 잘못 설정할 수 있다. 또한 서로 다른 장애가 비슷한 지표 조합으로 나타날 수도 있다.

다음 사항에 주의해야 한다.

• 지표의 동시 변화만으로 원인을 확정하지 않는다.
• 먼저 변화한 지표를 무조건 근본 원인으로 판단하지 않는다.
• 정상적인 작업량 증가와 실제 이상 상태를 구분한다.
• 데이터 수집 간격과 누락 여부를 확인한다.
• 시스템 외부의 서비스나 네트워크 의존성도 검토한다.
• 분석 결과는 추가 측정과 실제 운영 사례로 검증한다.

따라서 다중 지표 분석은 장애 원인을 자동으로 확정하는 방법이라기보다, 복잡한 시스템에서 조사 범위를 좁히고 검증 순서를 정하는 방법으로 활용하는 것이 적절하다.

14. 최종 판단은 지표의 개수가 아니라 관계의 설명력에 있다

여러 지표를 수집했다고 해서 분석의 정확도가 자동으로 높아지는 것은 아니다.

중요한 것은 각 지표가 어떤 상태를 나타내며, 변화가 언제 시작되었고, 다른 지표와 어떤 시간적 관계를 보였으며, 실제 서비스 영향과 어떻게 연결되었는지를 확인하는 것이다.

CPU 사용률이 높다는 사실만으로는 원인을 알기 어렵다. 하지만 CPU 사용률, 실행 대기열, 응답시간, 오류율을 함께 비교하면 조사 방향을 더 구체적으로 설정할 수 있다.

마찬가지로 I/O 대기시간과 응답시간이 함께 증가하더라도, 그 관계가 반복적으로 나타나는지와 다른 원인 후보가 있는지를 확인해야 한다.

결국 다중 지표 분석의 핵심은 여러 지표의 변화를 하나의 시간 흐름으로 연결하고, 그 관계를 통해 원인 후보를 좁힌 뒤 실제 데이터로 검증하는 것이다.

핵심정리

첫째, 단일 성능 지표가 정상이라고 해서 시스템 전체가 정상인 것은 아니다. CPU, 메모리, 저장장치, 네트워크, 서비스 지표를 함께 살펴야 실제 이상 상태를 놓칠 가능성을 줄일 수 있다.

둘째, 여러 지표가 동시에 또는 순차적으로 변했다는 사실은 원인 후보를 찾는 단서이지, 원인을 확정하는 증거는 아니다. 시간적 관계를 확인하고 로그·이벤트·운영 조건과 비교해 검증해야 한다.

Ⅳ-3에서는 장애 이전의 변화와 순서를, Ⅳ-4에서는 그 변화의 지속시간과 반복성을 분석했다. 이어서 Ⅳ-5에서는 여러 지표 사이의 관계를 분석해 시스템 이상 상태와 원인 후보를 좁히는 방법을 다룬다.