이 문서를 통해 아래 질문들에 답할 수 있게 됩니다.
OS JVM Application 경계에서 붙잡아야 할 핵심 판단 기준은 무엇인가?경계를 나누면 지표가 말하는 위치가 보인다라는 기준은 어떤 JVM/OS 신호로 확인되는가?- Java/Spring 코드에서
OS JVM Application 경계판단 기준은 어떤 장애 신호로 드러나는가?
개요
이 문서의 주제는 OS JVM Application 경계이다. Application, JVM, OS가 각각 어떤 책임을 갖고 어떤 지표 언어를 쓰는지 구분한다.
먼저 붙잡을 기준은 다음 문장이다. 경계를 나누면 지표가 말하는 위치가 보인다. Application은 요청과 업무 상태를, JVM은 Java runtime과 heap/GC/thread를, OS는 process, file, socket, page, scheduler를 관리한다. 따라서 장애 분석에서는 어떤 지표가 어느 계층의 언어인지 먼저 붙여야 한다.
핵심 모델
- 판단 기준: 경계를 나누면 지표가 말하는 위치가 보인다.
- Application 계층은 endpoint, trace id, 예외, business state, framework metric으로 증상을 표현한다.
- JVM 계층은 heap, metaspace, GC pause, Java thread state, JIT, JVM option으로 Java runtime의 상태를 표현한다.
- OS 계층은 PID/TID, CPU scheduling, RSS, page cache, file descriptor, socket, cgroup limit으로 실행 자원을 표현한다.
- 같은 memory 문제도 heap 사용량, RSS, native memory, container limit 중 어디가 먼저 움직였는지에 따라 원인이 달라진다.
- 결론은 한 계층의 지표만으로 내리지 않고 Application, JVM, OS 중 최소 두 계층의 증거를 맞춰 낸다.
문서별 핵심 구분
- Application은 업무 코드와 framework 상태를, JVM은 Java runtime과 heap/GC/thread를, OS는 process와 자원을 관리한다.
- 같은 memory 문제도 heap 문제인지 RSS/native 문제인지에 따라 보는 도구가 다르다.
- OS limit이 낮으면 Java 설정이 충분해도 file/socket 생성이 실패할 수 있다.
원리
Application 계층은 사용자가 보는 기능과 가장 가깝다. 어떤 endpoint가 느린지, 어떤 예외가 늘었는지, 어떤 요청이 같은 trace id로 묶이는지 보여 준다. 하지만 이 계층만으로는 thread가 CPU를 기다리는지, GC pause에 멈췄는지, socket 대기 중인지 알 수 없다.
JVM 계층은 Java 코드가 실행되는 runtime을 보여 준다. thread dump, heap 사용량, GC log, JFR, JVM flag는 Java 객체와 thread 관점의 증거를 제공한다. 다만 JVM 지표도 process RSS, file descriptor limit, kernel socket 상태까지 모두 설명하지는 못한다.
OS 계층은 Java process가 실제로 얻는 실행 자원을 보여 준다. CPU run queue, per-thread CPU, /proc/<pid>/limits, /proc/<pid>/fd, socket state, cgroup memory limit은 JVM 바깥의 제약을 드러낸다.
OS JVM Application 경계 관점에서 중요한 점은 증거의 언어를 섞지 않는 것이다. “메모리가 부족하다”는 말은 heap이 찼다는 뜻일 수도 있고, native memory나 page cache까지 포함한 RSS가 limit에 닿았다는 뜻일 수도 있다. 먼저 어느 계층의 memory인지 분리해야 한다.
Java/Spring 연결
- Spring MVC 요청은 대개 Tomcat worker thread 위에서 실행되므로 요청 지연은 thread 점유 시간과 직접 연결된다.
- Actuator의
http.server.requests,jvm.*,tomcat.*지표는 애플리케이션과 JVM 경계를 이어 주는 최소 관찰점이다. - Repository 호출이 느려도 원인은 DB SQL만이 아니라 connection pool 대기, socket 대기, GC pause, CPU 포화일 수 있다.
- 로그의 trace id와 thread name을 남기면 OS thread 관찰 결과와 애플리케이션 로그를 맞추기 쉽다.
- 운영 설정은 Spring property 하나가 아니라 OS limit, JVM option, WAS connector 설정과 함께 읽어야 한다.
- Spring 코드 리뷰에서는
OS JVM Application 경계판단 기준이 어떤 thread, pool, timeout, resource 설정으로 드러나는지 확인한다.
코드와 설정 예시
Application: endpoint, trace id, exception, Actuator metric
JVM: heap, GC pause, Java thread state, JVM flags, JFR
OS: PID/TID, CPU run queue, RSS, file descriptor, socket, limit예시는 특정 문법을 외우기 위한 것이 아니라 같은 증상을 세 계층의 언어로 나눠 보는 표다. 장애 중에는 “느리다”를 endpoint 지연, Java thread state, OS 자원 포화 중 어디에서 먼저 관찰했는지 분리해야 한다.
관찰 명령
jcmd <pid> VM.system_properties
jcmd <pid> VM.flags
cat /proc/<pid>/status
cat /proc/<pid>/limitsOS JVM Application 경계 관찰 명령은 결론이 아니라 가설 확인 도구다. 운영 중에는 반복 간격, 대상 PID, 수집 시각을 함께 남기고 출력이 큰 명령은 범위를 제한한다.
지표 해석
| 신호 | 먼저 의심할 것 | 다음 확인 |
|---|---|---|
| 신호 | 먼저 의심할 것 | 다음 확인 |
| --- | --- | --- |
| Application latency만 증가 | 코드 경로, 하위 의존성, pool 대기 | trace, executor, DB/client timeout |
| JVM heap은 여유인데 RSS 증가 | native memory, thread stack, direct buffer | NMT, /proc/<pid>/status, container limit |
| Java thread는 WAITING인데 OS CPU 높음 | 다른 native thread, GC, logging, profiling | top -H, jcmd Thread.print, GC log |
| OS limit 도달 | fd/socket/thread/process 제한 | /proc/<pid>/limits, lsof, service 설정 |
OS JVM Application 경계에서는 핵심 신호와 보조 지표를 같은 시간축에서 맞춘다. 먼저 변한 신호와 뒤따라 포화된 신호를 분리해야 원인과 결과를 구분할 수 있다.
장애 상황에서 보는 순서
- 증상을 Application 언어로 고정한다. endpoint, error, latency, trace id를 먼저 잡는다.
- JVM 언어로 같은 시간대를 확인한다. thread dump, GC, heap, JVM option을 본다.
- OS 언어로 process 자원을 확인한다. CPU, RSS, fd, socket, limit을 본다.
- 세 계층의 timestamp를 맞춰 원인과 결과를 구분한다.
- 수정은 어느 계층의 계약을 바꾸는 일인지 명시한다.
이 순서는 OS JVM Application 경계 후보를 빠르게 좁히기 위한 기본 루틴이다. 결론을 내리기 전에는 애플리케이션 증거와 JVM/OS 증거를 최소 한 번 이상 맞춘다.
실전 팁
jcmd VM.command_line과/proc/<pid>/limits를 함께 확인한다.- Application metric, JVM metric, OS metric을 한 대시보드에서 시간축으로 맞춘다.
- heap과 RSS를 비교해 JVM 내부 문제인지 OS 관점 문제인지 나눈다.
- 장애 보고서에는 어느 계층에서 확인한 증거인지 표시한다.
- Spring property 변경과 JVM option 변경을 같은 배포 이력으로 관리한다.
주니어 팁
OS JVM Application 경계주제는 용어 암기보다 정상 상태와 장애 상태에서 어떤 증거가 달라지는지 연결해 익힌다.- 처음에는
OS JVM Application 경계를 재현 가능한 기본 명령과 Actuator 지표로 확인하는 습관부터 만든다. OS JVM Application 경계숫자는 크기 자체보다 평소 기준선에서 얼마나 벗어났는지로 판단한다.
시니어 팁
OS JVM Application 경계주제의 영향이 pool, queue, retry, timeout으로 번지는 경로를 설계 리뷰에 포함한다.OS JVM Application 경계runbook에는 실행 명령, 정상 범위, 해석 기준, 금지할 대응을 같이 둔다.OS JVM Application 경계판단이 container, LB, 다중 인스턴스 환경에서도 같은 의미인지 확인한다.
Guru급 팁
OS JVM Application 경계주제는 단일 snapshot보다 변화 방향이 중요하다. 같은 명령을 간격을 두고 실행해 상태가 증가, 유지, 회복 중 어디인지 본다.- 고급 도구는
OS JVM Application 경계가설을 좁힐 때만 사용하고 기본 지표와 모순되는지 먼저 확인한다. OS JVM Application 경계조치 후에는 CPU, memory, socket, disk, pool 중 다음 포화 지점이 어디로 이동했는지 확인한다.
위험 신호!
- JVM heap만 보고 process memory를 다 설명했다고 생각한다.
- OS file descriptor limit을 모르고 socket 장애를 분석한다.
- Application log를 OS 이벤트보다 신뢰도 높은 단일 증거로 취급한다.
- 컨테이너 limit과 JVM option의 관계를 확인하지 않는다.
- 계층 용어를 섞어 팀 소통이 흐려진다.
확인 질문
확인 질문
OS JVM Application 경계주제를 장애 중 확인할 때 Application 로그만으로 부족한 이유는 무엇인가?
- 로그는 코드 경로를 보여 주지만
OS JVM Application 경계의 JVM/OS 자원 상태, 대기 위치, 포화 방향은 별도 지표로 확인해야 하기 때문이다.OS JVM Application 경계관련 설정이나 pool 크기를 바꾸기 전에 확인할 것은 무엇인가?
- 먼저 변한 신호, 하위 자원 capacity, 변경이 완화인지 증폭인지 판단할 기준을
OS JVM Application 경계지표로 확인해야 한다.OS JVM Application 경계재발을 막기 위해 장애 기록에 무엇을 남겨야 하는가?
- 발생 시간, 영향 범위, 사용한 명령,
OS JVM Application 경계핵심 지표, 원인 판단, 완화 조치, 근본 수정, 남은 리스크를 남긴다.