H5. T-Map 패턴으로 진단하기 — 16종
Diátaxis: How-to(목표별 가이드) · 대상: 운영자 / 관리자 ← 목차로
"서비스가 이상하다"는 신고가 오면 차트 수십 개를 차례로 여는 대신 T-Map 한 장부터 보세요. T-Map(트랜잭션 히트맵)은 일정 시간의 모든 트랜잭션을 시간(X) × 응답시간(Y) 평면에 그린 차트라, 장애의 종류마다 고유한 시각 패턴(세로줄, 가로줄, 군집, 단절 …)이 나타납니다. 이 문서는 그 16가지 패턴을 모양으로 알아보고, 패턴별로 무엇을 점검하고 조치할지를 정리합니다.
패턴으로 구간을 좁힌 뒤 개별 트랜잭션의 원인(SQL·외부호출)을 파려면 H6. 느린 트랜잭션 원인 찾기로 이어집니다. AI 진단 버튼의 일반 사용법은 H14. AI로 차트·이벤트 분석 받기를 보세요.
여는 법 — 좌측 메뉴 ▸ WAS ▸ 대시보드의 T-Map 위젯, 또는 좌측 메뉴 ▸ WAS ▸ 애플리케이션 ▸ 트랜잭션 맵(T-Map) 탭 (실시간 · 일간 · 이력)
T-Map 읽는 법
- X축 시간, Y축 응답시간(초). 각 셀은 그 시간×응답시간 구간에 속한 트랜잭션 개수입니다.
- 셀 색상은 응답시간(빠를수록 파랑, 느릴수록 주황→빨강), 셀 테두리는 HTTP 오류(4xx 빨강, 5xx 진한 빨강)입니다.
- 정상 운영의 기준은 "정상 base" — 전체 트랜잭션의 95% 이상이 0~1초 구간에 진한 띠로 모여 있는 상태입니다. 정상 base가 유지되면 상단에 일부 점이 있어도 사용자 영향은 제한적이고, 정상 base가 무너졌을 때가 진짜 긴급 상황입니다.
- 셀 영역을 마우스로 드래그하면 그 구간 트랜잭션 목록이 열립니다 — 개별 trace의 SQL·stack trace까지 들어갈 수 있습니다(H6).
자주 쓰는 용어:
| 용어 | 의미 |
|---|---|
| 가로칸 | 시간(X)축을 일정 간격으로 자른 통 (실시간 4초 / 이력은 구간 비례) — 패턴은 가로칸 단위로 판단 |
| 세로칸 | 응답시간(Y)축을 일정 간격으로 자른 통 (실시간 200ms / 이력 300ms) |
| 셀 | 가로칸 × 세로칸의 교차점 — 그 위치로 응답한 트랜잭션 수 |
| 정상 base | 0~1초 구간의 진한 정상 띠 — 패턴 판단 시 기준선 |
| P95 | 한 가로칸 안 응답시간의 상위 5% 경계값 — 튀는 값에 흔들리지 않는 지표 |
트랜잭션 목록을 URL로 바로 열기
드래그로 여는 대신, 주소(URL)에 조건을 담아 트랜잭션 목록을 바로 열 수 있습니다. 장애 상황을 동료에게 전달하거나, 알림·보고서에서 문제 구간으로 바로 보낼 때 씁니다.
주소 끝(# 뒤) 에 조건을 붙이면 어느 화면에서든 그 자리에서 목록 팝업이 열립니다
(페이지가 통째로 넘어가지 않습니다).
| 무엇으로 여나 | 형식 |
|---|---|
| 트랜잭션 하나 (TID를 알 때) | #/...?tid=<TID값> |
| 그룹 + 기간 | #/...?app=<그룹명>&minx=<시작>&maxx=<종료> |
| 인스턴스 + 기간 | #/...?hosts=<IP>&instances=<인스턴스명>&minx=<시작>&maxx=<종료> |
minx·maxx는 밀리초 단위 시각입니다. 그룹 또는 인스턴스 조건과 함께 있어야 인식됩니다.- 응답시간 범위(
miny·maxy), URL, 오류만 보기(err), 클라이언트 IP 등으로 더 좁힐 수 있습니다.
참고 링크를 받은 사람도 그 대상을 볼 권한이 있어야 목록이 열립니다 (→ H18. 그룹 권한 관리).
어느 패턴부터 볼까 — 진단 우선순위
여러 패턴이 동시에 보이면 다음 순서로 확인하세요.
| 순위 | 패턴 | 의미 | 첫 점검 위치 |
|---|---|---|---|
| 1 | 트래픽 단절 | 가장 심각 — 서비스 자체가 응답 못 함 | WAS 프로세스 / 에이전트 / LB |
| 2a | 5xx 군집 (빠른 응답) | 사용자가 즉시 500을 받음 (≤ 2초) | 배포 이력 / Circuit Breaker / WAF |
| 2b | 5xx 군집 (느린 응답) | timeout 후 500 (≥ 4초) | backend / connection pool / 외부 API |
| 2c | 5xx 군집 (혼합) | 응답시간이 섞임 | 양쪽 모두 검토 |
| 3 | 연쇄 장애 | 장애 진행 중 + 사용자 이탈 시작 | downstream + 처리량 추세 |
| 4 | 세로줄 | JVM 이슈 가능성 | JVM 힙 / GC / 스레드 |
| 5 | 느린 응답 다발 | 외부 의존성 지연 | 느린 URL / 외부 API |
| 6 | 4xx 군집 | 클라이언트 / API 명세 이슈 | 배포 이력 / WAF / client IP |
| 7 | 누적 성능 저하 | 메모리 누수 등 누적성 문제 | JVM 힙 / DB Active 추세 |
핵심 같은 "5xx 군집"이라도 응답시간 분포에 따라 점검할 곳이 정반대입니다. 5xx가 빠르게(≤ 2초) 떨어지면 차단·배포 회귀 쪽(backend 아님), 느리게(≥ 4초) 떨어지면 timeout·풀 고갈 쪽(배포 아님)부터 봅니다. 평소 5xx가 거의 없는 환경에서 갑자기 빠른 5xx가 보이면 거의 항상 직전 배포가 1순위 의심입니다.
상태 표시 원과 AI 진단
T-Map의 AI 버튼 왼쪽 작은 원(상태 표시 원) 이 감지된 패턴의 심각도를 알려 줍니다.
| 색 | 의미 | 동작 |
|---|---|---|
| 초록 | 정상 — 패턴 없음 | 정적 |
| 노랑 | Info(약함) — 관찰 권장 | 정적 |
| 주황 | Warning(주의) — 깊이 확인 | 깜빡임 |
| 빨강 | Critical(위험) — 즉시 조치 | 빠른 깜빡임 |
원에 마우스를 올리면 감지된 패턴 목록이 표시되고, 원이 깜빡이면 AI 버튼을 클릭해 상세 진단을 받으세요. AI 응답은 ① 한 줄 요약 ② 감지된 패턴(어디서) ③ 원인 가능성(확률 순) ④ 점검 권장 메뉴 — 네 부분으로 나옵니다.
AI 진단을 쓸 수 있는 곳 — WAS ▸ 대시보드의 T-Map 위젯, WAS ▸ 애플리케이션의 개요 탭 미니 T-Map과 트랜잭션 맵(T-Map) 탭(실시간 · 일간 · 이력).
참고 이력 모드는 기간 2일 이내에서만 AI 진단을 지원합니다(초과 시 버튼이 숨겨집니다). 또 Warning/Info 패턴은 30초 안에 2~3회 반복 감지될 때만 깜빡이도록 완충되어 있어(알림 피로 방지) 순간 노이즈에는 반응하지 않습니다 — Critical은 1회 감지 즉시 깜빡이고, 패턴이 해소되면 다음 갱신(10초)에 바로 초록으로 돌아옵니다.
실제 화면으로 보는 패턴 예시
본격적인 패턴 목록에 들어가기 전에, 테스트 부하로 패턴을 재현해 실제 콘솔에서 캡처한 화면 네 장을 먼저 봅니다. 상태 표시 원에 마우스를 올리면 아래처럼 패턴 감지 팝업이 떠서 감지된 패턴 이름·의심 원인·심각도를 요약해 줍니다 — 모양과 팝업을 함께 읽는 감각을 익혀 두면 뒤의 16종 목록이 훨씬 빨리 읽힙니다.
세로줄 (패턴 1) — 주의(주황)
특정 시점의 가로칸 하나에서 응답시간이 위아래 전 구간으로 동시에 퍼졌습니다. 팝업이 세로줄과 함께 나타난 고지연 영역·상단 가로줄까지 짚어 줍니다 — 그 "순간"에 인스턴스 전체가 함께 멈춘 것이므로 JVM GC stop-the-world / 락 경합부터 의심합니다.
5xx 군집 (패턴 3a — 빠른 응답) — 위험(빨강)
정상 base 안에 5xx 테두리 셀이 무더기로 나타났고 응답은 빠릅니다(≤ 2초). 상태 원이 빨강(위험)으로 바뀌고 팝업도 즉시 AI 진단을 권합니다 — 빠른 5xx는 backend가 아니라 차단기(Circuit Breaker)·WAF·직전 배포부터 봅니다. 응답이 느린 변형(3b)과 섞인 변형(3c)은 점검 위치가 달라지니 아래 갤러리의 3a·3b·3c 구분을 보세요.
파도치기 (패턴 9) — 주의(주황)
응답시간 상단이 일정한 주기로 오르내리는 물결을 그립니다. 팝업(제품 라벨 "파도형")이 말하듯 GC 주기·배치 작업처럼 주기적인 내부 작업이 원인인 경우가 많아 보통은 정상 범주입니다 — 주기가 점점 짧아지거나 마루가 점점 높아질 때만 깊이 봅니다.
P95 점진 상승 (패턴 8) — 약함(노랑) · 누적 성능 저하(11)와 같은 "우상향" 가족
시간이 갈수록 상단 경계(P95)가 계단처럼 우상향합니다. 지금 당장은 약함( 노랑)이지만 이 모양이 유지되면 connection pool 고갈·메모리 누수처럼 누적되는 자원 문제의 초기 신호입니다 — 같은 우상향 가족인 **누적 성능 저하(11)·단계적 성능 저하(13)**로 진행하기 전에 H7. 메모리 누수 점검으로 힙·GC 추세를 확인하세요.
패턴 16종 한눈에 보기
패턴 갤러리 — 모양과 주요 증상
| # | 패턴 모양 | 제목 · 주요 증상 (한 줄) |
|---|---|---|
| 1 |  | 세로줄 (Vertical Spike) — 특정 순간에 응답시간이 위아래로 한꺼번에 퍼짐 — 메모리 정리 멈춤 / 데이터베이스 락 의심 |
| 2a |  | 상단 가로줄 (Horizontal Band) — 응답시간이 한 값에 머무름 — 느린 쿼리 / 외부 서비스 지연 |
| 2b |  | 다중 가로줄 (Multi Band) — 여러 응답시간 군집이 동시에 지속 — 다중 워크로드 / 비동기 작업 / 다중 엔드포인트 |
| 3a |  | 5xx 군집 (빠른 응답) (Fast Fail) — 서버 오류 다발 — 응답이 빠름 (즉시 차단 / 자동 차단기 / 새 배포 직후 의심) |
| 3b |  | 5xx 군집 (느린 응답) (Slow Fail) — 서버 오류 다발 — 응답이 느림 (응답 대기 초과 연쇄 / 연결 자원 부족 의심) |
| 3c |  | 5xx 군집 (혼합) (Mixed) — 서버 오류 다발 — 응답시간이 섞임 (양쪽 모두 점검 권장) |
| 4 |  | 4xx 군집 (4xx Cluster) — 클라이언트 오류 다발 — 요청 규격 / 인증 만료 / 비정상 접근 의심 |
| 5 |  | 응답시간 정체 (Plateau) — 응답시간이 특정 값에 멈춰있음 — 응답 대기 한계점 직전 |
| 6 |  | 이중 분포 (Bimodal Distribution) — 응답시간이 두 곳에 몰림 — 캐시 적중/실패 또는 경로 분기 |
| 7 |  | 느린 응답 다발 (High Latency Band) — 일부 응답이 매우 느림 (위쪽에 흩어짐) — 느린 쿼리 / 외부 서비스 |
| 8 |  | P95 점진 상승 (Gradual P95 Rise) — 상위 응답시간이 시간 따라 점점 올라감 — 연결 자원 / 메모리 누수 의심 |
| 9 |  | 파도치기 (Sinusoidal) — 응답시간이 주기적으로 오르내림 — 메모리 정리 주기 / 배치 작업 |
| 10 |  | 트래픽 단절 (Empty Gap) — 트래픽이 끊김 — 서비스 멈춤 / 에이전트 연결 끊김 / 서비스 중단 의심 |
| 11 |  | 누적 성능 저하 (Cumulative Degradation) — 응답시간 상한이 점점 쌓여 올라감 — 메모리 누수 / 연결 미해제 누적 |
| 12 |  | 연쇄 장애 (Cascading Failure) — 서버 오류 + 트래픽 감소가 동시 — 백엔드 서비스 장애 + 사용자 이탈 |
| 13 |  | 단계적 성능 저하 (Stepwise Degradation) — 응답시간이 계단처럼 단계별 점프 — 연결 자원 / 파일 / 메모리 정리 단계적 부족 |
번호(#)는 위 "어느 패턴부터 볼까" 표의 순위와 별개인 패턴 번호입니다. 패턴별 점검·조치는 아래 심각도별 상세 절을, 위험한 순서는 위 진단 우선순위 표를 보세요.
Critical (위험) — 즉시 조치
트래픽 단절 (Empty Gap)
T-Map의 셀이 일정 시간(보통 1분 이상) 완전히 비는 상태입니다 — 요청이 도착하지 않거나 WAS가 응답을 만들지 못하고 있습니다. 가장 심각한 1순위 신호입니다.
- 원인 — WAS 프로세스 hang(OOM · Full GC 정지 · deadlock) / 에이전트 연결 끊김(실제 트래픽은 살아 있을 수 있음 — false alarm) / LB·프록시가 health check 실패로 제외 / 진짜 0 트래픽(휴면 시간대 · DNS 장애)
- 확인·조치 — ① WAS 프로세스가 실행 중인지 확인(
ps/jps) — 종료됐으면 즉시 재시작 + heap dump 보존 → ② 에이전트 연결 상태(H20. 에이전트 상태 점검) — 에이전트만 끊겼고 LB·로그에 트래픽 흔적이 있으면 false alarm, 에이전트 재배포 → ③ LB health check 정책 점검 → ④ 이벤트 목록에서 직전 5xx 폭증 여부 — 있었다면 "장애 → 사용자 이탈 → 다운" 시퀀스(연쇄 장애의 끝)일 수 있으니 그 시점 trace와 스레드 덤프를 분석하세요.
구분 연쇄 장애와 달리 5xx 없이 트래픽 자체가 사라집니다. 단순 공백이면 WAS hang / 에이전트 끊김 쪽입니다.
5xx 군집 — 빠른 응답 (Fast Fail)
한 시간대에 5xx가 몰리는데 응답이 빠릅니다(평균 2초 이하). 요청을 거의 처리하지 않고 즉시 거절했다는 양상입니다.
- 원인 — 배포 직후 회귀(새 코드가 즉시 reject) / Circuit Breaker open(의도된 차단) / WAF · rate limit 발동 / 인증·세션 만료 폭주
- 확인·조치 — ① 최근 배포 이력(30분 이내면 회귀 강력 의심 → rollback 검토) → ② Circuit Breaker 상태 — 의도된 차단인지 확인 후 backend 정상화 → close → ③ WAF·rate limit 로그 — 정상 트래픽 차단이면 룰 완화 → ④ 인증 로그의 401/403 비율과 토큰 만료 시점 일치 여부.
구분 느린 응답 5xx와 진단이 정반대입니다 — 이 패턴에서는 backend가 아니라 차단·배포부터 봅니다.
5xx 군집 — 느린 응답 (Slow Fail)
한 시간대에 5xx가 몰리는데 응답이 느립니다(평균 4초 이상). backend나 외부 의존성의 timeout을 기다리다 실패한 양상입니다.
- 원인 — 외부 API·DB timeout 후 500 / 커넥션 풀 고갈 후 timeout / retry가 모두 실패한 뒤 fallback 500 / thread pool 고갈
- 확인·조치 — ① DBMS 대시보드의 Active Sessions · Lock — 풀 사용률 100%, lock 경합 확인 → ② 외부 의존성 응답시간 차트 → ③ 커넥션 풀 사용률(H8. DB 커넥션 풀 고갈 진단) → ④ retry 설정(backoff 없으면 storm) → ⑤ WAS ▸ JVM 탭의 스레드 상태 — BLOCKED 다수면 thread pool 고갈. 조치는 downstream 정상화가 1순위이고, Circuit Breaker로 fail fast 시켜 storm을 끊습니다.
5xx 군집 — 혼합 (Mixed)
5xx의 응답시간이 빠른 쪽과 느린 쪽 사이에 섞여 있습니다. 두 변종이 동시에 진행 중이거나 한쪽으로 옮겨 가는 전이 상태라 단일 진단이 어렵습니다.
- 확인·조치 — 빠른 응답 변종의 점검(배포·CB·WAF)과 느린 응답 변종의 점검(DB·풀· downstream)을 모두 수행하세요. AI 진단이 어느 쪽 신호가 더 강한지 안내합니다. 5xx 비율이 2% 이상이면 위험, 5% 이상이면 즉각 조치 단계입니다.
참고 같은 시간에 빠른 그룹과 느린 그룹이 모두 있으면 두 변종이 동시에 감지되어 tooltip에 둘 다 표시됩니다 — 별도 설정은 필요 없습니다.
연쇄 장애 (Cascading Failure)
5xx가 다발하면서 트래픽이 동시에 줄어드는 패턴입니다. 응답을 못 받은 사용자가 이탈하기 시작했다는, outage 초기의 결합 신호입니다.
- 진행 흐름 — downstream(DB · 외부 API · 캐시) timeout → 5xx 다발 → 사용자 retry·이탈 → 트래픽 감소. Circuit Breaker가 제때 열리지 않으면 retry storm으로 가속됩니다.
- 확인·조치 — ① 어느 downstream이 응답하지 않는지 식별(DBMS 대시보드의 Active Sessions · Slow Query, 외부 의존성 응답시간) → ② WAS 대시보드의 처리량(TPS) 추세로 이탈 진행 확인 → ③ Circuit Breaker를 열어 fail fast(storm 차단) → ④ 5xx trace를 drill-down해 실패한 호출 지점 확인. 사용자에게 서비스 상태 안내를 띄우는 것도 조치의 일부입니다.
구분 트래픽 단절과 달리 5xx가 함께 나타납니다 — 장애가 "진행 중"인 신호입니다.
Warning (주의) — 깊이 확인
참고 5xx 군집 세 변종은 5건 이상이면 warning, 10건 이상이면 critical로 표시됩니다. warning 단계에서는 위 Critical 절의 같은 점검을 관찰 + 추세 확인 위주로 수행하세요 — 변종을 미리 식별해 두면 critical로 커졌을 때 점검 순서가 명확합니다.
세로줄 (Vertical Spike)
특정 한 시점에 모든 응답시간이 위아래로 한꺼번에 퍼지는 패턴입니다. 한 자원의 정지(stop-the-world)가 그 순간의 모든 요청을 함께 잡았다는 뜻입니다.
- 원인 — Full GC stop-the-world(가장 흔함) / DB 락 경합(한 long transaction이 다수 lock 점유) / thread pool 고갈 / 외부 API 일시 hang
- 확인·조치 — ① 세로줄의 정확한 시점을 식별(이후 점검의 기 준) → ② WAS ▸ JVM 탭의 힙 — 그 시점 Old 영역 100% 근접이면 GC 정지 의심 → ③ GC 차트 — Full GC 발생·소요가 세로줄 길이와 일치하면 확정 → ④ 스레드 덤프 — BLOCKED 다수 + 같은 모니터 대기면 락 경합 → ⑤ DBMS 대시보드의 Lock — 같은 시점 급증 여부. Full GC가 잦으면 힙 증설 또는 힙 오브젝트 분석(H7. 메모리 누수 점검), 락 경합이면 트랜잭션 범위 축소입니다.
구분 다중 가로줄과 달리 순간적입니다 — 양옆 시간대는 정상입니다.
4xx 군집 (4xx Cluster)
한 시간대에 4xx 클라이언트 오류가 몰립니다. 4xx 자체는 운영 영향이 작지만, 갑작스러운 폭증은 변경 또는 비정상 접근의 신호입니다.
- 원인 — 배포 직후 API 명세 변경(400 폭주) / 인증·세션 만료 시점 일치(401 폭주) / 스캐너·bot 등 abuse(403 · 404 · 429 폭주)
- 확인·조치 — ① 어느 status가 많은지부터(400 입력 규격 / 401 인증 / 404 endpoint 변경 / 429 rate limit) → ② client IP 분포 — 특정 IP 대역 집중이면 abuse, WAF 룰 강화 → ③ 최근 배포의 API 명세 변경 여부 — 회귀면 rollback 또는 클라이언트팀 알림.
상단 가로줄 (Horizontal Band)
응답시간이 한 값(예: 5초)에 일관되게 머무는 띠가 생깁니다. 한 의존성이나 한 쿼리가 항상 그 시간을 소요한다는 뜻입니다.
- 원인 — 특정 SQL이 항상 느림(실행계획 불량 · 인덱스 누락) / 동기 외부 API의 응답시간 고정 / 네트워크 지연(원거리 backend · keep-alive 미사용)
- 확인·조치 — ① WAS ▸ 트랜잭션에서 URL별 P95 정렬 — 어느 URL이 띠를 만드는지 →
② DBMS 대시보드의 Top Slow Query → ③ 해당 쿼리
EXPLAIN으로 인덱스 점검 → ④ 외부 의존성 응답시간과 띠 높이가 일치하는지. 쿼리면 인덱스·튜닝, 외부 호출이면 비동기화 + 캐시 + circuit breaker입니다.
구분 응답시간 정체(plateau)와 달리 위아래가 비어 있을 필요가 없는 단순 띠이고, 다중 가로줄과 달리 띠가 하나입니다.
응답시간 정체 (Plateau)
응답시간이 특정 값에 정확히 모여 멈춰 있고 그 위아래는 비어 있습니다. 그 값은 보통 timeout 설정값 직전입니다 — 모든 요청이 한계까지 기다리고 있다는 뜻입니다.
- 원인 — HTTP client의 connect/read timeout 직전 응답 / DB connection timeout 직전 / JDBC fetch timeout 직전
- 확인·조치 — ① 설정된 timeout 값과 정체 높이가 일치하는지(application 설정 · HTTP client 설정) → ② downstream(backend · DB · 외부 API)이 실제로 느려지는 중인지 → ③ trace를 drill-down해 어느 호출이 한계에 닿는지. timeout 임계값을 재검토하고 Circuit Breaker로 누적을 차단한 뒤, downstream 응답성(root cause)을 개선합니다.
주의 정체 직후 실제 timeout 단계(느린 응답 5xx)로 넘어갈 수 있습니다 — 전조 신호로 취급하세요.
이중 분포 (Bimodal Distribution)
응답시간이 두 군데(예: 0.2초와 5초)에 동시에 몰립니다. 같은 시점에 빠른 경로와 느린 경로 두 가지가 공존한다는 뜻입니다.
- 원인 — 캐시 적중(빠름) vs 실패(느림) / 조건 분기(일부만 DB 조회) / feature flag · A/B의 두 경로
- 확인·조치 — ① URL별 P95 분리 — 어느 URL이 느린 봉우리에 속하는지 → ② 캐시 적중률 확인 — 낮은 시간대·endpoint가 느린 봉우리의 원인인지 → ③ 최근 배포로 추가된 느린 경로인지. 자연스러운 캐시 적중/실패 분포면 관찰만으로 충분하고, 느린 경로가 문제면 캐시 도입·쿼리 최적화로 줄입니다.
구분 파도치기와 닮았지만, 이중 분포는 두 봉우리가 같은 시점에 동시에 존재하고 파도치기는 번갈아 나타납니다.
Info (약함) — 관찰
느린 응답 다발 (High Latency Band)
차트 상단에 드문드문 흩어진 점들 — 트래픽의 일부만 매우 느린 long tail 상태입니다.
- 원인 — 일부 SQL만 느림(데이터 증가 · 통계/인덱스 노후) / 외부 API의 일부 endpoint만 hang / 자원 경합의 시작
- 확인·조치 — ① WAS ▸ 트랜잭션의 P95 정렬로 상단 점의 URL 식별 → ② DBMS Top Slow Query → ③ JVM CPU·메모 리 추세 — 점이 점점 늘면 누적 성능 저하로 번질 수 있습니다. 영향이 5% 이하면 관찰, 지속·증가하면 해당 trace를 drill-down해 병목을 찾으세요.
구분 상단 가로줄과 달리 일관된 띠가 아니라 드문 점입니다.
P95 점진 상승 (Gradual P95 Rise)
차트 후반부의 상위 응답시간(P95)이 전반부보다 눈에 띄게(1.5배+) 올라가는 연속 추세 — 자원 누적·누수의 초기 신호입니다.
- 원인 — 커넥션 미반환 누적 / 메모리 누수(힙 압박 → GC 빈도 증가) / 데이터 증가로 쿼리 점진 저하 / 캐시 효율 저하
- 확인·조치 — ① JVM 힙 Old 영역이 시간 따라 차오르는지(H7) → ② DB Active Sessions · 커넥션 풀 사용률의 점진 증가(H8) → ③ 누수 의심이면 힙 오브젝트 분석으로 누적 객체 식별. 추세가 며칠 지속되면 누적 성능 저하로 격상됩니다 — 그 전에 root cause를 찾으세요.
다중 가로줄 (Multi Band)
응답시간 띠가 둘 이상 동시에 지속됩니다. 한 WAS에 성격이 다른 워크로드가 섞여 있다는 뜻으로, 그 자체는 장애가 아닌 경우가 많습니다.
- 원인 — 빠른 API + 느린 API가 한 WAS에 혼재 / 동기 응답 + 비동기 polling + 배치가 각자 다른 띠 / tenant별 데이터 양 차이 / 정상 경로 + 재시도 fallback 경로
- 확인·조치 — ① URL별 P95로 띠마다 어느 endpoint 집합인지 매핑 → ② 느린 띠의 쿼리가 무거운지 → ③ 배치 시간표가 상단 띠와 일치하는지. 운영상 자연스러운 패턴이면 관찰만으로 충분하고, SLA를 분리하려면 느린 endpoint를 별도 풀로 격리하거나 배치를 별도 스레드풀/프로세스로 분리합니다.
주의 띠가 위로 자라거나 새 띠가 추가되는 추세면 누적 성능 저하로 번질 수 있습니다 — 추세를 관찰하세요.
파도치기 (Sinusoidal)
응답시간이 일정 주기로 오르내리는 패턴입니다. 보통은 정상 운영 신호입니다.
- 원인 — GC 주기(분 단위 spike) / 정기 배치 작업의 트리거 주기 / 캐시 TTL 만료 → 적중 실패 spike → 갱신 → 안정의 반복
- 확인·조치 — ① 봉우리 사이 간격을 재서 분/시/일 단위인지 → ② GC 간격과 일치하면 GC 압박 — 힙 증설 또는 GC 알고리즘 튜닝 → ③ 배치 시간표와 일치하면 트리거 시점 분산 → ④ 캐시 TTL과 일치하면 만료 시점 분산(stagger). 정상 GC·배치 주기면 관찰만 합니다.
구분 이중 분포와 달리 두 높이가 번갈아 나타납니다(동시에 공존하지 않음).
누적 성능 저하 (Cumulative Degradation)
응답시간의 상한이 시간 따라 부드럽게 우상향합니다. P95 점진 상승과 같은 원인이지만 신호가 더 강한 단계입니다.
- 원인 — 메모리 누수(Old 영역 점진 fill) / DB 커넥션 누적 미해제 / 데이터 증가로 쿼리 점진 저하 / 캐시 효율 저하
- 확인·조치 — P95 점진 상승과 같은 점검을 며칠 단위 장기 추세로 수행하세요 — JVM 힙 Old 영역 추세, DB Active 추세, 시점이 다른 heap dump 비교로 누적 객체 식별. 주기적 WAS 재시작은 단기 완화일 뿐이며 root cause(누수·미해제 코드) 해소가 필수입니다.
구분 단계적 성능 저하와 달리 부드러운 곡선으로 오릅니다.
단계적 성능 저하 (Stepwise Degradation)
응답시간이 계단처럼 점프 → 안정 → 또 점프를 반복합니다. 자원이 임계점에 닿을 때마다 한 단계씩 느려지는, 자원의 단계적 고갈 양상입니다.
- 원인 — 커넥션 풀 슬롯이 하나씩 막힘 / file descriptor 누적(OS limit 근접) / 힙 압박 누적으로 GC 빈도 단계적 증가
- 확인·조치 — ① 각 계단 시점의 자원 지표(DB Active · Open Files · GC 빈도)를 비교해 어느 자원이 계단을 만들었는지 식별 → ② 그 자원의 max 한계(풀 max · FD limit · 힙 max) 대비 현재 위치 확인 → ③ 각 계단의 trace에서 늘어난 호출 확인. 영향이 큰 자원의 증설 또는 누적 미해제 코드 차단이 조치입니다. 계단이 며칠 반복되면 누적 성능 저하로 격상됩니다.
조치 체크리스트
장애가 의심될 때 다음 순서로 진행하세요.
- T-Map 상태 표시 원의 색 확인 (빨강 → 주황 → 노랑 순으로 대응)
- 원에 마우스를 올려 어떤 패턴이 감지됐는지 확인
- AI 버튼 클릭 — 요약 · 패턴 · 원인 가능성 · 점검 권장 메뉴 응답 받기
- 응답의 "점검 권장 항목" 메뉴로 이동해 cross-check (JVM 힙 / GC / 스레드 / DB Active 등)
- 필요하면 해당 구간을 드래그해 개별 트랜잭션으로 drill-down (H6)
- root cause 확인 후 조치
- 조치 후 상태 표시 원이 초록으로 돌아오는지 확인
잘 안될 때
| 증상 | 점검 |
|---|---|
| 여러 패턴이 한꺼번에 감지됨 | 진단 우선순위 표의 순서대로(critical → warning → info) — AI 진단의 점검 권장 항목도 우선순위 순입니다 |
| 상태 표시 원이 너무 자주 깜빡임 | Warning/Info는 반복 감지 시에만 깜빡이도록 완충돼 있습니다 — 그래도 잦으면 실제 추세일 가능성, AI 진단으로 확인 |
| T-Map이 통째로 비어 있음 | 트래픽 단절 패턴이거나 에이전트 미연결 — H20. 에이전트 상태 점검 |
| 이력 모드에서 AI 버튼이 없음 | 기간 2일 초과 — 2일 이내로 좁히면 버튼이 나 타납니다 |
| 패턴은 보이는데 사용자 신고가 없음 | 정상 base(0~1초 95%+)가 유지되는지 확인 — 유지되면 영향 제한적, 관찰 단계 |
관련 문서
- H6. 느린 트랜잭션 원인 찾기 — 드래그한 구간의 개별 트랜잭션 진단 (문제 패턴 20종)
- H7. 메모리 누수 점검 — 세로줄 · P95 상승 · 누적 저하의 힙/GC 분석
- H8. DB 커넥션 풀 고갈 진단 — 느린 5xx · 정체 · 계단식 저하의 풀 점검
- H14. AI로 차트·이벤트 분석 받기 — AI 진단 버튼의 일반 사용법
- H20. 에이전트 상태 점검 — 트래픽 단절의 false alarm 구분
- R3. 이벤트 종류 레퍼런스 — 5xx · 임계 초과 이벤트의 의미
- R1. 화면 지도 — 점검에 쓰는 메뉴 전체 위치