컴퓨터 시스템에서 저장장치는 운영체제, 데이터베이스, 애플리케이션 데이터가 지속적으로 읽히고 기록되는 핵심 자원이다.

저장장치의 물리적인 고장뿐만 아니라 I/O 처리 성능이 점진적으로 저하되는 현상도 시스템 장애의 전조가 될 수 있다.

특히 서버와 데이터베이스 환경에서는 저장장치의 응답시간이 증가하면 애플리케이션 처리 지연과 대기 요청 증가가 함께 나타날 수 있다.

그러나 여기서 중요한 것은 I/O 성능 저하가 곧 저장장치 자체의 고장을 의미하지 않는다는 점이다.

애플리케이션 요청 증가, 데이터베이스 작업량 증가, 백업 작업, 스토리지 네트워크 혼잡 등으로도 I/O 지연이 발생할 수 있다.

따라서 저장장치를 단순히 정상 또는 고장으로 구분하기보다 I/O 성능이 왜 변했는지, 그 변화가 실제 서비스 장애로 이어지고 있는지를 함께 분석해야 한다.

1. 저장장치 I/O란

I/O(Input/Output)는 저장장치와 컴퓨터 시스템 사이에서 데이터를 읽고 쓰는 작업을 의미한다.

저장장치 I/O 성능을 분석할 때 대표적으로 확인하는 지표는 다음과 같다.

• IOPS: 초당 처리되는 입출력 작업 수
• 처리량(Throughput): 일정 시간 동안 전송되는 데이터의 양
• I/O 응답시간(Latency): 하나의 I/O 요청이 완료되는 데 걸리는 시간
• Queue Depth: 처리되지 않고 대기 중인 I/O 요청의 규모
• 읽기·쓰기 비율: 읽기와 쓰기 작업의 구성 비율
• I/O Wait: 프로세스 또는 CPU가 I/O 완료를 기다리는 상태와 관련된 지표

이 지표들은 서로 영향을 주기 때문에 하나의 숫자만으로 저장장치 상태를 판단하기 어렵다.

예를 들어 IOPS가 높다는 사실만으로 성능이 좋다고 판단할 수 없다.

요청량이 증가하면서 IOPS는 높아졌지만 응답시간과 Queue Depth가 함께 증가하고 있다면 저장장치가 증가한 요청을 처리하는 과정에서 병목이 발생하고 있을 가능성을 검토해야 한다.

따라서 현재 값뿐 아니라 평상시와 비교한 변화량, 변화속도, 지속시간을 함께 확인하는 것이 중요하다.

2. I/O 성능 저하가 발생하는 주요 원인

저장장치 성능이 떨어지는 원인은 물리적인 고장에만 한정되지 않는다.

대표적인 원인은 다음과 같다.

• 저장장치 자체의 성능 저하
• 과도한 읽기·쓰기 요청
• 애플리케이션 처리량 증가
• 데이터베이스 작업량 증가
• 백업 및 로그 기록 증가
• 파일 시스템의 부담 증가
• 저장공간 부족
• RAID 재구성 또는 장애 디스크 복구 작업
• 스토리지 네트워크 혼잡
• 저장장치 오류와 재시도 증가
• 공유 스토리지의 다른 시스템 작업 증가

특히 I/O 성능 저하가 발생했을 때 저장장치만 먼저 의심하는 것은 위험하다.

예를 들어 애플리케이션의 데이터 처리량이 갑자기 증가하면 저장장치에 전달되는 I/O 요청도 증가할 수 있다.

이 경우 저장장치는 정상적으로 동작하고 있더라도 요청량이 처리능력을 초과하면서 응답시간과 대기 요청이 증가할 수 있다.

따라서 분석에서는 항상 다음 두 가지를 구분해야 한다.

저장장치가 느려진 것인가?

아니면 저장장치에 갑자기 더 많은 작업이 들어온 것인가?

3. I/O 응답시간 증가와 시스템 장애 위험

저장장치의 I/O 응답시간이 증가하면 하나의 데이터 요청이 완료되는 데 더 많은 시간이 필요하다.

문제는 새로운 요청이 계속 유입되는 경우다.

처리할 수 있는 속도보다 요청이 들어오는 속도가 빠르면 대기 중인 I/O가 증가하고 Queue Depth가 높아질 수 있다.

이러한 상태가 지속되면 애플리케이션의 처리시간이 증가하고 서비스 응답시간도 길어질 수 있다.

대표적인 흐름은 다음과 같이 볼 수 있다.

I/O 응답시간 증가 → 대기 요청 증가 → 애플리케이션 처리 지연 → 서비스 응답시간 증가 → 타임아웃·오류 위험 증가

다만 이 흐름이 모든 시스템에서 동일하게 발생하는 것은 아니다.

시스템의 캐시 구조, 저장장치 종류, 애플리케이션 구조, 데이터베이스 구조에 따라 실제 영향은 달라질 수 있다.

따라서 중요한 것은 특정 현상을 공식처럼 적용하는 것이 아니라 실제 시스템에서 이러한 변화가 함께 발생하는지를 데이터로 확인하는 것이다.

4. Queue Depth 증가가 중요한 이유

Queue Depth는 저장장치에 처리되지 않고 대기 중인 I/O 요청이 얼마나 쌓여 있는지를 판단하는 데 활용할 수 있다.

일시적인 Queue Depth 증가는 정상적인 작업에서도 발생할 수 있다.

예를 들어 대규모 데이터 처리나 백업이 실행되는 동안 일시적으로 I/O 요청이 증가할 수 있다.

문제는 평상시보다 높은 Queue Depth가 지속되면서 I/O 응답시간까지 함께 증가하는 경우다.

이때는 다음 항목을 함께 확인해야 한다.

• 애플리케이션 요청량
• 데이터베이스 처리량
• 백업 작업 여부
• 로그 기록량
• I/O 응답시간
• IOPS
• 처리량
• I/O 오류 및 재시도
• CPU의 I/O 대기 관련 지표

Queue Depth 하나만 높다고 장애 위험을 확정할 수는 없다.

하지만 Queue Depth 증가 + 응답시간 증가 + 실제 서비스 지연이 동시에 나타난다면 단순한 순간적인 작업 증가보다 I/O 병목 가능성을 우선적으로 검토할 필요가 있다.

5. I/O Wait 증가와 CPU 사용률의 차이

저장장치 성능을 분석할 때 CPU 사용률만 확인하면 중요한 문제를 놓칠 수 있다.

CPU 사용률이 높지 않더라도 프로세스가 저장장치의 I/O 완료를 기다리고 있다면 애플리케이션의 처리시간은 증가할 수 있다.

따라서 다음 지표를 함께 확인하는 것이 좋다.

• CPU 사용률
• I/O Wait 관련 지표
• 저장장치 I/O 응답시간
• Queue Depth
• 애플리케이션 응답시간

예를 들어 CPU 사용률이 50% 수준으로 유지되고 있는데 애플리케이션 응답시간이 갑자기 증가한다면 CPU 처리능력 부족만으로 설명하기 어렵다.

이 경우 저장장치 I/O 지연이나 다른 대기 자원이 원인인지 확인해야 한다.

즉, CPU 사용률이 낮다는 이유만으로 시스템 자원이 충분하다고 판단해서는 안 된다.

반대로 I/O Wait가 높다고 해서 반드시 저장장치 자체가 고장난 것도 아니다.

애플리케이션의 과도한 I/O 요청 때문에 대기 상태가 증가했을 수도 있기 때문이다.

6. 저장장치 성능 저하와 데이터베이스 장애

데이터베이스 시스템은 저장장치 성능의 영향을 크게 받을 수 있다.

데이터 조회와 기록뿐만 아니라 로그 저장, 인덱스 처리, 임시 데이터 처리 등 다양한 I/O가 지속적으로 발생하기 때문이다.

저장장치 응답시간이 증가하면 데이터베이스 작업 완료시간이 길어지고 동시에 처리되지 못한 요청이 증가할 수 있다.

이러한 상태가 지속되면 다음과 같은 현상으로 확대될 수 있다.

저장장치 지연 → 데이터베이스 작업 지연 → 연결 대기 증가 → 애플리케이션 응답시간 증가 → 타임아웃 또는 작업 실패

따라서 데이터베이스 장애를 분석할 때는 데이터베이스 오류 로그만 확인해서는 부족할 수 있다.

데이터베이스 작업량과 하부 저장장치의 I/O 성능 변화를 동일한 시간축에서 비교하는 것이 중요하다.

7. 평균 I/O 성능만으로 판단하면 발생하는 문제

저장장치 성능 분석에서 평균값은 유용하지만 평균값만으로 전체 상태를 판단하기에는 한계가 있다.

예를 들어 두 시스템의 평균 I/O 응답시간이 모두 10ms라고 가정해 보자.

A 시스템은 대부분의 요청이 8~12ms 범위에서 처리된다.

반면 B 시스템은 대부분 5ms 수준이지만 일부 요청이 100ms 이상 지연될 수 있다.

두 시스템의 평균값이 비슷하더라도 실제 서비스에서 경험하는 지연 특성은 상당히 다르다.

따라서 다음과 같은 항목을 함께 확인하는 것이 바람직하다.

• 평균 응답시간
• 최대 응답시간
• 상위 백분위 응답시간
• IOPS
• 처리량
• Queue Depth
• I/O Wait
• 읽기·쓰기 비율
• 시간대별 변화

특히 데이터베이스나 실시간 서비스에서는 일부 요청의 긴 지연이 전체 평균보다 더 중요한 문제가 될 수 있다.

따라서 평균이 정상이라는 이유만으로 순간적인 심각한 지연을 정상으로 판단해서는 안 된다.

8. 저장공간 부족과 I/O 성능 변화를 구분해서 분석한다

저장공간 부족은 시스템 운영에 영향을 줄 수 있지만, 저장공간 사용률이 높다는 사실만으로 I/O 성능 저하를 직접 판단해서는 안 된다.

실제 장애 위험을 분석하려면 다음 항목을 함께 확인해야 한다.

• 전체 저장공간
• 사용 공간
• 여유 공간
• 사용 공간 증가율
• 로그 증가량
• 임시 파일 증가량
• 데이터 증가 추세
• I/O 응답시간
• 파일 시스템 또는 애플리케이션 오류

특히 중요한 것은 저장공간 사용률과 I/O 성능 저하가 실제로 함께 변화하는지 확인하는 것이다.

예를 들어 저장공간 사용률은 90%까지 증가했지만 I/O 응답시간과 Queue Depth가 정상이라면 저장공간 사용률 자체를 I/O 병목의 원인으로 단정할 수 없다.

반대로 특정 환경에서 저장공간 부족과 성능 저하가 반복적으로 함께 나타난다면 해당 시스템의 구조적 특성을 별도로 분석할 필요가 있다.

9. 저장장치 오류와 I/O 재시도를 함께 확인해야 한다

I/O 성능이 저하될 때 반드시 확인해야 할 항목 중 하나가 오류와 재시도다.

저장장치나 스토리지 경로에서 오류가 발생하면 동일한 I/O 요청이 다시 처리되는 과정에서 실제 응답시간이 증가할 수 있다.

이때는 단순히 IOPS나 처리량만 보는 것보다 다음 항목을 함께 확인해야 한다.

• 저장장치 오류
• I/O 오류
• 명령 재시도
• 연결 오류
• RAID 오류
• 스토리지 경로 오류
• 시스템 로그의 관련 이벤트
• 오류 발생 시점의 응답시간 변화

특히 응답시간 증가와 오류·재시도 증가가 동일한 시간대에 발생하는지를 확인하면 저장장치 또는 저장 경로의 문제 가능성을 좁히는 데 도움이 된다.

이 과정에서 중요한 것은 오류가 있다고 해서 바로 저장장치 고장으로 단정하지 않는 것이다.

저장장치와 서버 사이의 연결 경로나 컨트롤러, RAID, 스토리지 네트워크에서도 문제가 발생할 수 있기 때문이다.

10. I/O 성능 데이터를 이용한 장애 전조 분석

저장장치 장애 위험을 장기적으로 관리하려면 장애가 발생한 후 원인을 찾는 방식에서 벗어나야 한다.

먼저 정상 상태의 I/O 패턴을 확보하고 장애 발생 전의 데이터를 비교해야 한다.

예를 들어 다음과 같은 패턴이 여러 장애 사례에서 반복된다고 가정할 수 있다.

I/O 응답시간 증가 → Queue Depth 증가 → I/O 대기 증가 → 애플리케이션 응답시간 증가 → 서비스 오류

이러한 변화가 여러 장애 사례에서 반복된다면 앞부분의 변화가 장애 전조를 탐지하기 위한 관찰 지표로 활용될 가능성이 있다.

그러나 정기적인 백업이나 대규모 데이터 처리처럼 정상적인 작업에서도 유사한 변화가 나타날 수 있다.

따라서 한 번의 사례보다 여러 장애 사례에서 같은 순서와 시간 관계가 반복되는지를 확인하는 것이 중요하다.

11. 저장장치 성능 저하와 실제 장애를 연결하는 방법

성능 지표의 변화만으로 장애 위험을 판단하면 오탐이 발생할 수 있다.

따라서 다음 세 가지를 구분해서 분석하는 것이 좋다.

① 성능 변화가 발생했는가

정상 범위와 비교하여 I/O 응답시간, Queue Depth, 처리량 등이 어떻게 변했는지 확인한다.

② 성능 변화가 실제 서비스에 영향을 주었는가

애플리케이션 응답시간, 데이터베이스 처리시간, 사용자 요청 실패율, 타임아웃 등을 함께 확인한다.

③ 이러한 변화가 장애와 반복적으로 연결되는가

과거 장애 사례를 동일한 시간축으로 비교하여 성능 변화가 장애 전에 반복적으로 나타났는지 확인한다.

결국 중요한 것은 “I/O 수치가 높다”가 아니라 “그 변화가 실제 서비스 장애와 어떤 관계를 가지고 있는가”이다.

12. 저장장치 장애 위험의 정량적 평가

저장장치 성능 데이터를 정량적으로 분석하려면 정상 상태와 특정 시점의 차이를 수치로 비교할 수 있다.

정상 상태의 평균 I/O 응답시간을 T₀, 특정 시점의 응답시간을 Tₜ라고 하면 다음과 같이 증가율을 계산할 수 있다.

I/O 응답시간 증가율 = (Tₜ – T₀) / T₀ × 100

예를 들어 정상 상태의 평균 응답시간이 10ms이고 특정 시점에 15ms가 되었다면 증가율은 50%다.

하지만 증가율이 50%라는 사실만으로 장애 위험이 50% 증가했다고 해석해서는 안 된다.

성능 변화율과 장애 발생확률은 서로 다른 개념이기 때문이다.

따라서 실제 위험을 평가하려면 응답시간 증가율과 함께 다음과 같은 데이터를 비교해야 한다.

• Queue Depth 변화
• IOPS 변화
• 처리량 변화
• 오류 및 재시도 횟수
• 애플리케이션 응답시간
• 타임아웃 발생
• 실제 장애 발생 이력

이러한 데이터를 장기간 축적하면 특정 성능 변화가 실제 장애와 얼마나 자주 연결되는지 확인할 수 있다.

13. 저장장치 I/O 장애 위험을 분석하는 실제 순서

실제 시스템에서는 다음과 같은 순서로 접근하면 분석 효율을 높일 수 있다.

① 정상 기준 확보

정상 운영 기간의 IOPS, 처리량, 응답시간, Queue Depth, 읽기·쓰기 비율 등을 수집한다.

가능하면 시간대별 정상 범위까지 확보한다.

② 성능 변화 탐지

평상시보다 응답시간이나 Queue Depth가 증가했는지 확인한다.

단발성 변화인지 지속적인 추세인지 구분한다.

③ 요청량 변화 확인

애플리케이션과 데이터베이스의 작업량이 함께 증가했는지 확인한다.

저장장치가 느려진 것인지, 저장장치로 들어오는 요청이 증가한 것인지 구분하는 단계다.

④ 저장장치 및 경로 상태 확인

저장장치 오류, 재시도, RAID 상태, 컨트롤러, 스토리지 네트워크 등 하부 계층을 확인한다.

⑤ 서비스 영향 확인

애플리케이션 응답시간, 데이터베이스 지연, 타임아웃, 오류율 등을 확인한다.

⑥ 과거 장애와 비교

동일한 현상이 과거 장애 발생 전에 반복되었는지 확인한다.

⑦ 예방 기준 설정

반복성이 확인된 지표를 모니터링 기준에 반영하고, 실제 장애 발생 여부를 다시 검증한다.

이렇게 해야 단순한 “임계값 초과 감시”가 아니라 실제 시스템에 맞는 장애 위험 분석으로 발전할 수 있다.

14. 저장장치 I/O 분석의 장기적 가치

저장장치 데이터는 현재 성능을 확인하기 위한 자료에만 그치지 않는다.

장기간 축적하면 시스템의 성능 변화와 작업량 증가에 따른 부담 변화를 확인할 수 있다.

이를 통해 다음과 같은 판단에도 활용할 수 있다.

• 저장장치 성능 확장 시점
• 저장공간 증설 시점
• 데이터베이스 성능 개선
• 백업 작업 시간 조정
• 스토리지 구성 변경
• 서버 증설 또는 작업 분산
• 장애 전조 모니터링 기준 설정

특히 성능 저하가 저장장치의 노후화 때문인지, 업무량 증가 때문인지, 특정 작업 때문인지를 장기간 데이터로 비교할 수 있다는 점이 중요하다.

즉, I/O 데이터는 장애 대응 자료인 동시에 향후 시스템 설계와 용량 계획을 위한 자료가 된다.

15. 저장장치 I/O 장애 위험 분석에서 반드시 확인할 질문

저장장치 성능을 분석할 때는 단순히 “I/O가 느려졌는가?”라는 질문에서 끝내면 안 된다.

다음 질문을 순서대로 확인하는 것이 좋다.

• 평상시보다 응답시간이 얼마나 증가했는가?
• 증가가 일시적인가, 지속적인가?
• Queue Depth도 함께 증가했는가?
• IOPS와 처리량은 어떻게 변했는가?
• 읽기와 쓰기 중 어느 쪽의 변화가 큰가?
• 애플리케이션 요청량도 함께 증가했는가?
• 데이터베이스 작업량이 변했는가?
• 백업이나 대량 작업이 실행되었는가?
• 저장장치 오류나 재시도가 증가했는가?
• 실제 애플리케이션 응답시간이 악화되었는가?
• 과거 장애에서도 같은 패턴이 나타났는가?

이 질문을 통해 성능 변화 → 원인 후보 → 실제 영향 → 장애와의 관계를 단계적으로 좁혀갈 수 있다.

16. 최종 판단 — 저장장치의 숫자보다 변화의 관계를 봐야 한다

저장장치 장애 위험은 특정 IOPS나 응답시간 숫자 하나만으로 판단하기 어렵다.

중요한 것은 정상 상태와 비교하여 무엇이 달라졌는지를 확인하는 것이다.

그리고 그 변화가 단순한 작업량 증가인지, 저장장치 자체의 성능 저하인지, 저장 경로의 문제인지 구분해야 한다.

그다음에는 해당 변화가 실제로 애플리케이션과 데이터베이스의 응답시간을 악화시키고 있는지 확인해야 한다.

마지막으로 같은 현상이 과거 장애에서도 반복되었는지를 비교해야 한다.

결국 저장장치 I/O 분석의 핵심은 다음과 같이 정리할 수 있다.

“I/O가 높다”가 중요한 것이 아니라, 평상시와 비교해 어떻게 변했으며 그 변화가 실제 서비스 장애와 연결되고 있는가가 중요하다.

17. 핵심정리

• I/O 성능 저하는 저장장치 자체의 고장과 동일한 의미가 아니다. 요청량 증가, 데이터베이스 작업, 백업, 스토리지 경로 문제 등 다양한 원인을 함께 확인해야 한다.
• I/O 응답시간, Queue Depth, 오류·재시도, 실제 서비스 응답시간을 하나의 시간축에서 비교해야 장애 위험을 제대로 판단할 수 있다.

저장장치 분석에서 가장 중요한 질문은 이것이다.

“우리 시스템에서 I/O 성능이 평상시와 달라질 때, 그 변화는 단순한 작업량 증가인가, 아니면 실제 서비스 장애로 이어지는 반복적인 신호인가?”