WAS 모니터링 가이드 — JVM 힙·스레드·커넥션 풀까지 봐야 하는 이유

JVM 관측 포인트 — 힙 사용량과 GC는 무엇을 알려 주나?

JVM에서 봐야 할 것은 힙 사용량의 톱니 모양과 GC 빈도·중지 시간입니다. 힙 그래프의 모양 변화가 메모리 누수와 GC 폭주의 조기 신호입니다.

Java 애플리케이션의 객체는 힙(heap) 메모리에 만들어지고, 가비지 컬렉션(GC, garbage collection)이 더 이상 쓰지 않는 객체를 회수합니다. Oracle의 GC 튜닝 가이드는 힙을 젊은 세대(young generation)와 오래된 세대(old generation)로 나누어 관리하는 세대별 수집 구조와, 수집 과정에서 애플리케이션 스레드가 일시 정지(pause)하는 동작을 설명합니다(Oracle — Java Garbage Collection Tuning). 관측 관점에서 이 구조는 두 가지 지표로 요약됩니다.

첫째, 힙 사용량 곡선의 모양입니다. 건강한 힙 그래프는 사용량이 차오르다 GC 때 뚝 떨어지는 톱니 모양을 반복합니다. 주의해야 할 변화는 톱니의 골이 점점 높아지는 패턴입니다. GC를 해도 회수되지 않는 객체가 쌓인다는 뜻으로, 메모리 누수(memory leak)의 전형적 징후입니다. 이 패턴을 방치하면 결국 OOM(OutOfMemoryError)으로 이어집니다. 장애가 난 뒤 힙 덤프를 뜨는 것보다, 골이 높아지는 추세를 며칠 전에 발견하는 편이 비용이 훨씬 쌉니다.

힙·GC·스레드·클래스를 한 화면에 놓으면, 개별 지표로는 정상 범위인 상태에서도 Old 영역이 밀려 올라가는 추세가 드러납니다.

세대별로 나눠 보면 신호가 더 선명해집니다. Eden과 Survivor는 부하를 따라 오르내리는 것이 정상이고, 판단의 기준은 Old 영역입니다. 하루치 그래프에서는 잘 안 보이던 Old 영역의 완만한 우상향이 일주일치를 겹쳐 놓으면 드러납니다. Metaspace도 함께 보는 편이 좋습니다. 클래스 로딩이 계속 늘어나기만 하고 언로드가 따라오지 않는다면, 힙과는 다른 종류의 누수를 의심할 지점입니다.

Eden의 톱니는 정상입니다. 판단 근거는 그 아래에서 완만하게 밀려 올라가는 Old 영역 곡선입니다.

둘째, GC 빈도와 중지 시간(pause time)입니다. GC가 자주 돌면서 한 번의 중지가 길어지면, 그 시간만큼 모든 요청이 멈춥니다. 특히 old 영역을 정리하는 Full GC가 반복되는 상태는 위험 신호입니다. 힙이 부족하거나 객체가 비정상적으로 쌓이고 있다는 뜻이며, GC 시간이 전체 실행 시간의 상당 부분을 차지하기 시작하면 응답시간 p99부터 무너집니다. 응답시간 그래프에 주기적인 스파이크가 있는데 원인을 못 찾겠다면, 그 시각과 GC 발생 시각을 겹쳐 보는 것이 첫 번째 점검입니다.

여기서 흔한 오답이 힙 크기부터 늘리는 대응입니다. 자사 분석 사례에서 OOM의 실제 원인은 힙 부족이 아니라 페이지네이션 없이 전체 주문을 긁어 오는 조회 API였습니다. 한 번의 요청이 대량의 객체를 만들어 내면서 회수 속도가 생성 속도를 따라가지 못한 것이고, 힙을 키웠다면 터지는 시점만 뒤로 밀렸을 것입니다(AI가 어떻게 WAS OOM 에러의 원인을 찾을까요?). 그래서 힙 그래프에서 이상을 확인한 다음 단계는 힙 덤프(heap dump)로 “무엇이 쌓였는가”를 확정하는 일입니다. 객체 종류별 점유율과 GC Root 경로를 따라가면, 늘어난 메모리를 붙잡고 있는 컬렉션이나 캐시가 코드 위치로 특정됩니다.

“메모리가 늘었다”에서 멈추지 않고 어떤 객체가 무엇에 붙들려 회수되지 않는지까지 따라가면, 고칠 코드가 특정됩니다.

쌓이는 객체로 자주 지목되는 것이 WAS 내장 세션입니다. 세션 객체는 만료 전까지 힙에 남고, 사용자가 늘수록 Old 영역을 그대로 밀어 올립니다. 세션이 많은 시스템에서 Full GC가 잦다면 힙 튜닝 이전에 세션을 어디에 둘지부터 검토할 문제입니다. 이 주제는 엔터프라이즈 세션 관리가 Redis로는 어려운 이유에서 별도로 다뤘습니다.

힙 크기·GC 정책 튜닝은 그 자체로 깊은 주제이지만, 모니터링 관점의 원칙은 단순합니다. 튜닝 이전에 측정이 먼저이고, 측정은 “지금 값”이 아니라 “추세와 모양”을 봐야 합니다.

스레드 풀 — 행(hang) 징후는 무엇으로 잡나?

스레드 풀에서 봐야 할 것은 액티브 스레드 수의 급증이며, 급증이 확인되면 스레드 덤프로 무엇을 기다리는지 확인합니다. 이 두 동작이 행 장애 대응의 기본기입니다.

WAS는 요청마다 스레드 풀(thread pool)에서 스레드를 하나 꺼내 처리를 맡깁니다. 풀의 최대 크기는 정해져 있으므로, 스레드가 제때 반납되지 않으면 새 요청은 대기열에서 기다리게 됩니다. 관측 지표는 액티브(사용 중) 스레드 수와 풀 사용률입니다.

정상 상태에서 액티브 스레드 수는 부하에 비례해 출렁입니다. 경계해야 할 패턴은 트래픽이 그대로인데 액티브 스레드만 계단식으로 차오르는 모양입니다. 스레드들이 일을 끝내지 못하고 어딘가에 붙잡혀 있다는 뜻입니다. 붙잡는 대상은 대개 응답 없는 외부 API, 잠금(lock) 경합, 그리고 뒤에서 다룰 커넥션 풀 대기입니다. 액티브 스레드가 최대치에 닿는 순간 WAS는 새 요청을 받지 못하는 사실상의 서비스 중단 상태가 됩니다.

이때 원인을 확정하는 도구가 스레드 덤프(thread dump)입니다. 덤프는 그 순간 모든 스레드가 어느 코드 지점에서 무엇을 기다리는지의 스냅샷입니다. 수십 개의 스레드가 같은 외부 호출 지점이나 같은 잠금에 몰려 있다면 원인은 그 자리에서 확정됩니다. 실무 요령은 두 가지입니다. 덤프는 한 번이 아니라 몇 초 간격으로 두세 번 떠서, 같은 자리에 계속 멈춰 있는 스레드를 가려내는 것. 그리고 액티브 스레드 급증 경보를 미리 걸어 두어, 덤프를 뜰 “그 순간”을 놓치지 않는 것입니다.

덤프를 뜨는 방법 자체는 간단합니다. JDK에 포함된 jstack <pid>를 쓰거나, 유닉스 계열에서는 WAS 프로세스에 kill -3을 보내면 표준 출력 로그에 덤프가 남습니다(프로세스는 종료되지 않습니다). 실제로 Tomcat 기동이 비정상적으로 느릴 때도 같은 방법으로 원인을 가르는데, 덤프에 TldScanner.scanJar나 파일 입출력 대기가 반복해 찍히면 스캔·I/O 문제로 좁혀집니다(Tomcat 느린 시작? 주요 4가지 원인과 해결책).

덤프를 열었을 때 먼저 볼 것은 스레드 상태 분포입니다. RUNNABLE이 대부분이면 실제로 일이 몰린 것이고, WAITING·TIMED_WAITING이 두꺼우면 응답을 기다리는 중이며, BLOCKED가 쌓여 있으면 잠금 경합입니다. 특히 BLOCKED 스레드의 스택에 적힌 “어떤 잠금을 기다리는가”와 “그 잠금을 누가 쥐고 있는가”를 이어 붙이면 잠금 사슬이 그려지고, 사슬이 순환하면 그것이 교착(deadlock)입니다. 교착은 재기동으로만 풀리는 대신 원인은 명확합니다. 두 코드 경로가 서로 다른 순서로 잠금을 잡고 있다는 뜻이므로, 잠금 획득 순서를 통일하거나 타임아웃이 있는 획득 방식으로 바꾸는 것이 정석입니다.

상태 분포로 성격을 가르고, BLOCKED 스레드의 “무엇을 기다리는가·누가 쥐고 있는가”를 이어 붙이면 잠금 사슬이 그려집니다.

DB 커넥션 풀 — 고갈은 어떤 패턴으로 진행되나?

커넥션 풀 고갈은 슬로우 쿼리와 맞물려 연쇄적으로 진행됩니다. 풀 사용률·대기 스레드 수와 쿼리 실행 시간을 같은 시간축에서 봐야 원인과 결과를 가릴 수 있습니다.

DB 커넥션 풀(connection pool)은 데이터베이스 연결을 미리 만들어 두고 재사용하는 구조입니다. 요청이 커넥션을 빌려 쿼리를 실행하고 반납하는 순환이 원활할 때는 존재감이 없지만, 이 순환이 막히는 순간 WAS 전체가 함께 막힙니다.

전형적인 고갈 시나리오는 이렇게 진행됩니다. 어떤 쿼리가 느려집니다(인덱스를 타지 않는 조건, 통계 변화, 데이터 급증). 그 쿼리를 실행하는 요청들이 커넥션을 평소보다 오래 붙잡습니다. 풀의 여유 커넥션이 줄고, 다른 요청들은 커넥션을 얻으려 대기합니다. 대기하는 동안 스레드도 함께 묶이므로 액티브 스레드가 차오릅니다. 결국 느린 쿼리와 무관한 화면까지 전부 느려지고, 증상만 보면 “시스템 전체 장애”처럼 보입니다.

자사 분석 사례가 이 연쇄를 그대로 보여 줍니다. 세 테이블을 UNION ALL로 묶어 4만여 건을 한 번에 끌어오는 쿼리가 있었고, 그 결과 JVM 힙 사용률이 99%까지 올라 Full GC가 반복됐습니다. GC가 애플리케이션을 멈춰 세우는 동안 커넥션이 반납되지 않으면서 최대 10개짜리 JDBC 풀은 10개 전부 사용 중 상태로 굳었고, 뒤이은 요청들은 30초 넘게 커넥션을 기다리다 예외로 떨어졌습니다(AI가 찾아낸 OOM과 DB 커넥션 풀 고갈의 연결고리). 주목할 점은 증상이 나타난 위치와 원인이 있는 위치가 다르다는 것입니다. 알람은 커넥션 풀에서 울렸지만 고쳐야 할 것은 쿼리였습니다.

이 연쇄 때문에 커넥션 풀은 반드시 두 방향에서 관측해야 합니다. 풀 쪽에서는 사용 중 커넥션 수, 대기 스레드 수, 커넥션 획득 대기 시간을 봅니다. 쿼리 쪽에서는 실행 시간 분포와 슬로우 쿼리 목록을 봅니다. 풀 사용률만 보면 “커넥션이 부족하다”는 결론으로 풀 크기를 늘리기 쉽지만, 원인이 슬로우 쿼리라면 풀 확대는 DB 부하를 키워 상황을 악화시킬 수 있습니다. 반대로 쿼리만 보면 “커넥션 획득 대기 2초”가 쿼리 실행 시간에 섞여 DB 탓으로 오인됩니다. 개별 트랜잭션 안에서 획득 대기와 실행 시간을 구간으로 분해해 보는 방법은 트랜잭션 추적이란에서 다뤘습니다.

호출 수와 평균·P99를 함께 놓으면 “느린 쿼리”와 “자주 불려서 부하를 만드는 쿼리”가 갈립니다. 1위 쿼리는 시간당 125회로 드물지만 평균 3.8초를 붙잡고 있어, 커넥션이 먼저 마르는 쪽입니다.

Tomcat과 JBoss/WildFly에서는 무엇을 어떻게 수집하나?

두 환경 모두 JMX로 핵심 메트릭을 노출하며, 표준 수집은 JMX 기반, 심층 수집은 에이전트 계측 기반입니다. 봐야 할 지표는 같고 노출 경로가 다를 뿐입니다.

Java WAS의 표준 관측 통로는 JMX(Java Management Extensions)입니다. JVM과 WAS가 관리 지표를 MBean이라는 객체로 노출하고, 외부 도구가 이를 읽어 갑니다. Apache Tomcat 공식 문서도 JMX 원격 접속을 열고 MBean으로 모니터링하는 방법을 안내합니다(Apache Tomcat — Monitoring and Managing Tomcat).

Tomcat에서 봐야 할 대표 MBean 지표는 세 묶음입니다. 스레드 풀(ThreadPool)의 currentThreadsBusy·maxThreads, 요청 처리기(GlobalRequestProcessor)의 requestCount·errorCount·processingTime, 그리고 JDBC 풀(DataSource)의 numActive·numIdle입니다. 앞서 정리한 스레드 풀·커넥션 풀 관측 포인트가 그대로 MBean 이름으로 존재하는 셈입니다.

JBoss EAP/WildFly는 서브시스템 구조로 같은 정보를 노출합니다. undertow(웹 요청 처리)의 워커·요청 통계, datasources 서브시스템의 풀 통계(InUseCount·AvailableCount 등)를 관리 CLI나 관리 콘솔, JMX로 조회할 수 있습니다. JVM 힙·GC 지표는 두 환경 공통으로 JVM 자체의 MemoryPool·GarbageCollector MBean에서 나옵니다. 두 제품의 운영 구조를 더 파고들 계획이라면 Apache Tomcat 기술 지원 서비스와 JBoss EAP 마스터 과정 안내가 참고가 됩니다.

Spring Boot 내장 WAS는 조금 다릅니다. 외장 Tomcat 대신 애플리케이션이 WAS를 품고 있고, 컨테이너로 배포되면 인스턴스가 수시로 뜨고 지므로 “서버 한 대를 계속 지켜보는” 방식의 감시가 성립하지 않습니다. 지표를 인스턴스가 아니라 서비스 단위로 모아 보는 구성이 필요한데, 이 변화는 Spring Boot 컨테이너, 모니터링은 어떻게 달라져야 할까?에서 별도로 정리했습니다.

다만 JMX 기반 수집에는 한계가 있습니다. “지금 풀 사용률이 몇인가”는 알려 주지만, “어느 트랜잭션의 어느 쿼리가 커넥션을 오래 잡았는가”는 알려 주지 못합니다. 지표와 원인 사이의 이 간격을 메우는 것이 에이전트 계측입니다. APM 에이전트는 JVM 안에서 트랜잭션 단위로 실행 경로를 기록하므로, 자원 지표의 이상을 특정 요청·특정 쿼리와 연결할 수 있습니다. 표준 지표는 JMX로 넓게, 원인 분석은 에이전트로 깊게 — 두 층을 함께 쓰는 구성이 실무 표준입니다.

OPENMARU APM으로 WAS 지표를 트랜잭션과 어떻게 연계하나?

OPENMARU APM은 WAS 내부 자원 지표와 트랜잭션 추적을 같은 시간축에 놓고 봅니다. “자원이 이상하다”에서 “이 요청·이 쿼리 때문이다”까지의 거리가 짧아지는 것이 연계의 가치입니다.

OPENMARU APM은 오픈소스 웹 서버와 WAS를 쓰는 Java 애플리케이션에 에이전트를 붙여, 페이지 요청과 데이터베이스 쿼리의 응답시간을 측정하고 모든 트랜잭션을 실시간으로 보여 줍니다(OPENMARU APM 제품 페이지). WAS 운영 관점에서 유용한 동선은 세 가지입니다.

• 힙·GC와 응답시간의 겹쳐 보기: 응답시간 스파이크 시각에 GC 발생과 중지 시간을 대조해, “느림”이 코드 문제인지 GC 문제인지 먼저 가릅니다.
• 액티브 서비스와 스레드 상태: 액티브 서비스가 차오르는 순간 처리 중 트랜잭션 목록을 열어, 어느 구간에서 멈췄는지 확인합니다. 행 징후를 집계 지표보다 빨리 포착하는 경로입니다.
• 커넥션 풀과 슬로우 쿼리의 연결: 풀 대기가 늘어난 시간대의 트랜잭션에서 커넥션 획득 대기와 쿼리 실행 시간을 구간으로 분해해, 풀 크기 문제인지 쿼리 문제인지 판정합니다.

덤프 계열 기능도 같은 맥락에서 붙습니다. 스레드 덤프와 힙 덤프를 임계치 도달 시점에 자동으로 뜨게 해 두면, 앞에서 말한 “덤프를 뜰 그 순간”을 사람이 지키고 있지 않아도 됩니다. 장애가 지나간 뒤 재현을 못 해 원인 규명이 막히는 상황이 여기서 많이 줄어듭니다. 최근에는 이 분석 동선을 질문으로 대신하는 방식도 쓰이는데, WAS 장애 상황을 프롬프트로 물어 원인 후보를 좁히는 과정은 프롬프트로 WAS 장애 분석 — OPENMARU APM AI Agent 데모에서 확인할 수 있습니다.

이렇게 자원 지표와 트랜잭션이 연결되어 있으면, 장애 상황에서 “지표 이상 확인 → 해당 시간대 트랜잭션 → 원인 구간”의 동선이 화면 몇 번의 이동으로 끝납니다. 이 동선을 절차로 정리한 것이 장애 원인 분석 3단계이고, WAS와 APM을 따로 도입했을 때 생기는 운영·비용 문제를 함께 본 글은 WAS·APM 통합 운영 장애 예방 전략입니다. WAS를 운영하는 팀이라면, 오늘 대시보드에 힙 톱니 모양·액티브 스레드·풀 대기 세 그래프가 있는지부터 점검해 보시기 바랍니다. 이 세 그래프가 트랜잭션과 연결되는 순간, WAS 모니터링은 사후 확인에서 사전 경보로 바뀝니다.

자주 묻는 질문 (FAQ)

WAS 모니터링에서 가장 중요한 지표는 무엇인가요?

JVM 힙 사용량과 GC 중지 시간, 액티브 스레드 수, DB 커넥션 풀 사용률·대기 수 세 묶음입니다. 이 세 자원이 요청 처리 파이프라인의 병목 지점이며, 응답시간·TPS 같은 증상 지표의 원인 층에 해당합니다.

CPU·메모리가 정상인데 왜 WAS가 멈추나요?

행(hang)·풀 고갈·GC 폭주는 모두 OS 지표가 정상인 채로 진행되기 때문입니다. 스레드가 외부 응답이나 커넥션을 기다리며 묶이면 CPU는 오히려 한가해 보입니다. 프로세스가 아니라 요청 처리 내부 상태를 봐야 잡히는 장애 유형입니다.

메모리 누수는 어떤 신호로 조기에 잡나요?

힙 사용량 그래프의 톱니 모양에서 골(GC 직후 사용량)이 점점 높아지는 추세가 조기 신호입니다. GC를 해도 회수되지 않는 객체가 쌓인다는 뜻이며, 방치하면 Full GC 반복과 OOM으로 이어집니다.

스레드 덤프는 언제, 어떻게 떠야 하나요?

액티브 스레드가 트래픽과 무관하게 급증할 때가 적기입니다. 몇 초 간격으로 두세 번 떠서 같은 지점에 계속 멈춰 있는 스레드를 찾으면, 행의 원인(외부 호출·잠금·커넥션 대기)이 코드 위치로 확정됩니다.

커넥션 풀 크기를 늘리면 고갈이 해결되나요?

원인이 풀 크기일 때만 해결됩니다. 느린 쿼리가 커넥션을 오래 붙잡아 생긴 고갈이라면, 풀을 키우는 것은 그 쿼리를 동시에 더 많이 돌리는 결과가 되어 DB 부하를 키웁니다. 풀 사용률과 쿼리 실행 시간을 같은 시간축에서 확인한 뒤 판단해야 합니다.

JMX 수집만으로는 부족한가요?

JMX는 풀 사용률·요청 수 같은 표준 지표를 넓게 보여 주지만, 이상의 원인이 된 특정 트랜잭션·쿼리는 지목하지 못합니다. 표준 지표는 JMX로, 트랜잭션 단위 원인 분석은 APM 에이전트 계측으로 — 두 층을 함께 쓰는 구성이 실무 표준입니다.

참고 리소스

자사 콘텐츠 (OPENMARU)
– APM이란? 서버 지표로 못 잡는 장애, 개념부터 도입까지 — OPENMARU
– WAS란 무엇인가 — 구조와 기능, 제품 선택 기준까지 — OPENMARU
– APM 핵심 지표 읽는 법 — 응답시간·TPS·에러율, 숫자 너머의 의미
– 트랜잭션 추적이란 — 느린 요청 하나를 코드 레벨까지 따라가는 기술
– 장애 원인 분석 — APM으로 골든타임 안에 근본 원인 찾는 3단계
– APM 옵저버빌리티 차이 — 무엇이 다르고, 무엇부터 갖춰야 하나
– WAS와 웹서버의 차이 — 요청 흐름부터 분리 배치 이유까지
– AI가 어떻게 WAS OOM(Out Of Memory) 에러의 원인을 찾을까요?
– 범인은 무심코 짠 SQL이었다 — OOM과 DB 커넥션 풀 고갈의 연결고리
– Tomcat 느린 시작? 주요 4가지 원인과 해결책
– Spring Boot 컨테이너, 모니터링은 어떻게 달라져야 할까?
– 프롬프트로 WAS 장애 분석 — OPENMARU APM AI Agent 데모
– WAS·APM 통합 운영 장애 예방 전략
– 엔터프라이즈 세션 관리가 Redis로는 어려운 이유
– Apache Tomcat 기술 지원 서비스
– JBoss EAP 마스터 과정 — 1 Day 전문가 과정
– OPENMARU APM 제품 소개

표준·공식 문서 (외부)
– Java Garbage Collection Tuning Guide — Oracle
– Monitoring and Managing Tomcat — Apache Tomcat 공식 문서