이 문서를 통해 아래 질문들에 답할 수 있게 됩니다.
IO 병목 관찰과 대응에서 붙잡아야 할 핵심 판단 기준은 무엇인가?iowait와 latency를 함께 본다라는 기준은 어떤 JVM/OS 신호로 확인되는가?- Java/Spring 코드에서
IO 병목 관찰과 대응판단 기준은 어떤 장애 신호로 드러나는가?
개요
이 문서의 주제는 IO 병목 관찰과 대응이다. I/O 병목을 CPU, memory, thread 상태와 구분하고 완화하는 루틴을 정리한다.
먼저 붙잡을 기준은 다음 문장이다. iowait와 latency를 함께 본다. 이 문서는 이 기준을 Java/Spring 실행 흐름, JVM/OS 관찰 지표, 장애 판단 순서로 연결한다.
핵심 모델
- 판단 기준: I/O 병목은 thread, disk, file, socket 증거를 함께 봐야 한다.
- Thread dump만으로는 I/O 대기와 CPU 실행을 구분하기 어려울 수 있다.
iostat,vmstat,pidstat,lsof는 서로 다른 층의 증거를 제공한다.- I/O 병목 완화는 요청량 제한, 작업 분리, buffer 조정, storage 분리 중 원인에 맞게 골라야 한다.
- 병목을 옮긴 뒤 다음 saturation 지점을 확인해야 한다.
문서별 핵심 구분
- I/O 병목은 CPU가 낮아도 latency를 크게 만든다.
- iowait, disk await, queue depth를 함께 본다.
- 로그, dump, upload, swap이 같은 disk를 압박할 수 있다.
원리
I/O 병목은 CPU 계산이 아니라 storage나 kernel I/O 경로를 기다리는 병목이다. CPU 사용률이 낮아도 요청 latency와 load average가 올라갈 수 있다.
관찰은 iowait 하나로 끝나지 않는다. device await, util, queue, dirty/writeback page, FD 수, 로그량, upload/export 작업, swap 여부를 같은 시간대에 맞춰야 한다.
Java thread dump에서는 I/O 대기가 RUNNABLE 또는 native method 근처로 보일 수 있다. 그래서 thread state만 보고 CPU bound로 단정하면 안 된다.
IO 병목 관찰과 대응 관점에서 중요한 점은 증상 완화와 원인 수정을 분리하는 것이다. 임시로 유입을 줄이거나 로그를 낮추더라도, 근본 원인이 disk capacity인지, 코드의 대량 I/O인지, 수집 agent 지연인지 다시 좁혀야 한다.
Java/Spring 연결
- 느린 API가 file upload, download, logging, DB, HTTP socket 중 어디에서 기다리는지 stack으로 나눈다.
pidstat -d와 endpoint latency를 맞추면 특정 process의 I/O 증가를 API 증상과 연결할 수 있다.- File I/O와 socket I/O가 동시에 늘면 FD limit과 disk latency를 함께 본다.
- 장애 중 heap dump나 대량 로그 수집은 관찰이면서 추가 I/O 부하다.
- 완화는 기능 차단, batch 중지, log sampling, 별도 volume 분리처럼 원인별로 다르게 잡는다.
코드와 설정 예시
latency 상승
CPU 낮음 또는 load 상승
iostat await/util 증가
thread dump native I/O 또는 file write 주변 반복
로그, dump, upload, swap 시간대 대조예시는 I/O 병목을 확인하는 증거 연결 순서다. 애플리케이션 latency, OS disk 지표, thread dump, 같은 시간대의 로그·dump·upload 작업을 맞춰야 원인 후보를 줄일 수 있다.
관찰 명령
iostat -xz 1 5
vmstat 1 5
top -H -p <pid>
jcmd <pid> Thread.printIO 병목 관찰과 대응 관찰 명령은 결론이 아니라 가설 확인 도구다. 운영 중에는 반복 간격, 대상 PID, 수집 시각을 함께 남기고 출력이 큰 명령은 범위를 제한한다.
지표 해석
| 신호 | 먼저 의심할 것 | 다음 확인 |
|---|---|---|
| open files가 limit에 근접 | FD leak 또는 connection 폭주 | lsof, /proc/<pid>/fd |
| iowait 증가와 latency 상승 | disk 병목, flush 지연 | iostat, vmstat |
| 로그량 급증 후 API 지연 | 동기 로그 또는 log collector 지연 | log rate, appender queue |
| tmp 사용량 증가 | upload/export/temp cleanup 실패 | tmp directory, lsof deleted |
IO 병목 관찰과 대응에서는 핵심 신호와 보조 지표를 같은 시간축에서 맞춘다. 먼저 변한 신호와 뒤따라 포화된 신호를 분리해야 원인과 결과를 구분할 수 있다.
장애 상황에서 보는 순서
- latency spike와 iowait, await, disk util 시각을 맞춘다.
pidstat -d로 어떤 process가 I/O를 만드는지 본다.lsof로 열린 file/socket 종류와 deleted file을 확인한다.- thread dump에서 file/socket read-write stack을 분리한다.
- 원인 경로별로 rate limit, 작업 중단, volume 분리, 코드 수정 중 하나를 선택한다.
이 순서는 I/O 병목을 하나의 명령 결과가 아니라 여러 증거의 교차점으로 판단하기 위한 루틴이다.
실전 팁
iostat,vmstat, thread dump를 같은 시각에 남긴다.- 로그 폭주, heap dump, upload/export, backup이 같은 disk를 쓰는지 확인한다.
- 임시 완화는 로그 레벨 조정, 비필수 batch 중지, upload 제한, dump 중지부터 검토한다.
- 근본 해결은 storage 성능, 작업 분리, streaming, 비동기 export, retention 정책으로 나눈다.
- I/O 병목 후에는 새 병목이 CPU, DB, network 중 어디로 이동했는지 다시 본다.
주니어 팁
IO 병목 관찰과 대응주제는 용어 정의보다 장애 때 어떤 증거로 확인할지까지 연결해 익힌다.- 정상 상태에서 이 문서의 관찰 명령을 실행해
IO 병목 관찰과 대응기준선을 남긴다. - 장애 시에는
IO 병목 관찰과 대응신호가 평소 기준선에서 벗어난 시각과 방향을 먼저 본다.
시니어 팁
IO 병목 관찰과 대응주제의 영향이 pool, queue, retry, timeout으로 번지는 경로를 설계 리뷰에 포함한다.IO 병목 관찰과 대응runbook에는 실행 명령, 정상 범위, 해석 기준, 금지할 대응을 같이 둔다.IO 병목 관찰과 대응판단이 container, LB, 다중 인스턴스 환경에서도 같은 의미인지 확인한다.
Guru급 팁
IO 병목 관찰과 대응주제는 단일 snapshot보다 변화 방향이 중요하다. 같은 명령을 간격을 두고 실행해 상태가 증가, 유지, 회복 중 어디인지 본다.- 고급 도구는
IO 병목 관찰과 대응가설을 좁힐 때만 사용하고 기본 지표와 모순되는지 먼저 확인한다. IO 병목 관찰과 대응조치 후에는 CPU, memory, socket, disk, pool 중 다음 포화 지점이 어디로 이동했는지 확인한다.
위험 신호!
- CPU가 낮으니 서버는 여유 있다고 판단한다.
- iowait만 보고 device await, util, queue를 보지 않는다.
- 장애 중 heap dump를 같은 disk에 남겨 I/O 병목을 키운다.
- 로그량을 줄여 장애가 완화됐는데 원래 로그 폭주 원인을 추적하지 않는다.
- storage capacity와 application I/O 패턴을 서로 다른 팀 문제로 분리해 버린다.
확인 질문
확인 질문
IO 병목 관찰과 대응주제를 장애 중 확인할 때 Application 로그만으로 부족한 이유는 무엇인가?
- 로그는 코드 경로를 보여 주지만
IO 병목 관찰과 대응의 JVM/OS 자원 상태, 대기 위치, 포화 방향은 별도 지표로 확인해야 하기 때문이다.IO 병목 관찰과 대응관련 설정이나 pool 크기를 바꾸기 전에 확인할 것은 무엇인가?
- 먼저 변한 신호, 하위 자원 capacity, 변경이 완화인지 증폭인지 판단할 기준을
IO 병목 관찰과 대응지표로 확인해야 한다.IO 병목 관찰과 대응재발을 막기 위해 장애 기록에 무엇을 남겨야 하는가?
- 발생 시간, 영향 범위, 사용한 명령,
IO 병목 관찰과 대응핵심 지표, 원인 판단, 완화 조치, 근본 수정, 남은 리스크를 남긴다.