장애 원인 분석 — APM으로 골든타임 안에 근본 원인 찾는 3단계
서비스가 느려졌을 때 APM 데이터를 읽는 순서를 3단계로 정리했습니다. 지표로 범위 좁히기, 트랜잭션 추적으로 파고들기, 자원 상관 분석으로 확정하기 — 슬로우 쿼리·커넥션 고갈·GC 폭주 실전 시나리오와 포스트모템까지 안내합니다.
장애 대응의 두 시계 — 복구와 원인 규명은 왜 다른 작업인가?
복구는 서비스를 되살리는 일이고, 원인 규명은 재발을 막는 일입니다. 두 작업의 목표와 시간 감각이 다르다는 것을 인정하는 데서 좋은 장애 대응이 시작됩니다.
장애 상황에는 두 개의 시계가 동시에 돌아갑니다. 첫 번째 시계는 MTTR(Mean Time To Recovery, 평균 복구 시간)입니다. 사용자 피해를 멈추는 것이 최우선이므로, 원인을 다 몰라도 서비스를 되살리는 조치 — 재기동, 트래픽 우회, 이전 버전 롤백 — 가 정당화됩니다. 두 번째 시계는 원인 규명입니다. 왜 발생했는지를 데이터로 확정해야 같은 장애의 재발을 막을 수 있습니다.
문제는 두 시계가 충돌하는 지점입니다. 가장 흔한 복구 조치인 재기동은 힙 상태, 스레드 상태, 처리 중이던 트랜잭션 같은 휘발성 증거를 지워 버립니다. 급한 불을 끄고 나면 “원인은 알 수 없음, 재기동으로 정상화”라는 보고서가 남고, 같은 장애는 몇 주 뒤에 반복됩니다.
두 시계의 간격을 벌리는 것은 결국 “대응을 언제 시작했는가”입니다. 사용자 불만이 접수된 뒤에 로그를 뒤지기 시작하면 원인 규명은 며칠 단위로 늘어지고, 그 사이 피해는 계속 쌓입니다. 경보를 먼저 받고 시작하면 같은 세 단계(Identify → Isolate → Repair)가 분 단위로 압축됩니다.
그림 1. 대응 시작 시점의 차이. 두 경로의 조치 단계는 같지만, 출발점이 “사용자 불만”이냐 “경보 수신”이냐에 따라 소요 단위가 DAYS와 MINUTES로 갈립니다. 골든타임을 만드는 것은 조치 속도보다 인지 시점입니다. (OPENMARU APM 제품 소개 발표 자료)
APM이 이 충돌을 완화하는 방식은 단순합니다. 트랜잭션·지표·자원 상태가 이미 수집 서버에 기록되고 있으므로, 재기동으로 프로세스의 순간 증거가 사라져도 “장애 시점에 무슨 일이 있었는가”는 데이터로 남습니다. 복구 시계와 규명 시계를 분리할 수 있게 되는 것입니다. 그래서 아래 3단계 중 1단계는 장애 중에, 2·3단계는 상황에 따라 복구 후에 수행해도 됩니다. 단, 스레드 덤프처럼 지금이 아니면 못 뜨는 증거는 복구 조치 전에 확보하는 것이 원칙입니다.
1단계 — 지표로 장애 범위를 어떻게 좁히나?
1단계의 목표는 원인 확정이 아니라 탐색 범위 축소입니다. 응답시간·에러율·액티브 서비스의 급변 구간을 특정해 “언제부터, 어디가, 어떻게”를 확정합니다.
이 단계를 건너뛰면 각자 자기 담당 구간만 들여다보게 됩니다. 웹 담당은 웹을, DB 담당은 DB를 보고 “우리 쪽은 정상”이라고 말하는 사이 원인은 계속 어긋납니다.
그림 2. 범위 축소를 건너뛴 대응. 같은 장애를 두고 WAS·DB·애플리케이션이라는 세 개의 답이 동시에 나오는 상황은 정보가 없어서가 아니라, 각자 서로 다른 부분 정보를 보고 있어서 생깁니다. 1단계는 팀 전체가 같은 시각·같은 구간을 보게 만드는 작업입니다. (OPENMARU APM 제품 소개 발표 자료)
Google SRE 북의 표현을 빌리면 이 단계는 분류(triage)와 검사(examine)에 해당합니다(Google SRE Book — Effective Troubleshooting). APM 대시보드에서 세 가지 질문에 답을 만듭니다.
언제부터인가. 응답시간·에러율 그래프를 뒤로 돌려 정상이던 마지막 시점을 찾습니다. 급변 시각이 확정되면 그 직전의 변경 이력 — 배포, 설정 변경, 배치 시작, 트래픽 유입 — 과 대조할 기준점이 생깁니다. 장애의 상당수는 “무언가 바뀐 직후”에 시작되므로, 시각 확정만으로 용의선상이 크게 줄어듭니다.
어디가 느린가. 전 트랜잭션이 고르게 느리면 공용 자원(DB, 커넥션 풀, GC, 네트워크)을, 특정 URL만 느리면 해당 기능의 코드·쿼리를 의심합니다. 특정 서버 인스턴스만 느리면 그 인스턴스의 상태(디스크, 로컬 캐시)로 범위가 좁혀집니다.
어떻게 나빠졌나. 패턴이 정보입니다. 계단식 악화는 자원 고갈(커넥션·스레드·힙)이 진행 중이라는 뜻이고, 순간 스파이크의 반복은 GC나 주기 작업을 가리키며, 특정 시각의 절벽식 악화는 배포·외부 연계 단절 같은 이벤트성 원인을 가리킵니다. 에러율과 응답시간 중 무엇이 먼저 움직였는지도 봅니다. 응답시간이 먼저면 “느려지다 타임아웃으로 실패”하는 경로, 에러율이 먼저면 코드·연계의 명시적 실패 경로입니다.
이 단계에서 지표를 읽는 감각 — 평균이 아니라 백분위수, 절대값이 아니라 기준선 대비 — 이 흔들리면 범위 축소가 산으로 갑니다. 그 기준은 APM 핵심 지표 읽는 법에서 정리했습니다.
2단계 — 트랜잭션 추적으로 어떻게 파고드나?
2단계의 목표는 느린 트랜잭션의 내부에서 시간이 소비된 구간을 확정하는 일입니다. 대표 트랜잭션의 호출 스택과 SQL 구간을 열면 원인 후보가 코드 위치로 좁혀집니다.
1단계에서 “언제·어디”가 나왔으니, 이제 그 시간대·그 URL의 느린 트랜잭션들을 엽니다. 트랜잭션 추적은 요청 한 건의 처리 과정을 호출 구간(span) 단위로 기록하므로, 전체 응답시간이 어느 구간에서 소비됐는지가 시간축으로 펼쳐집니다. OpenTelemetry 문서가 트레이스를 “요청이 지나간 전체 경로의 그림”으로 설명하는 그대로입니다(OpenTelemetry — Traces).
여기서 확인하는 것은 세 갈래입니다.
- SQL 구간이 길다 — 쿼리 문장과 실행 횟수를 봅니다. 한 방 쿼리가 느린 경우(실행계획 문제)와 같은 쿼리가 수백 번 반복되는 경우(N+1 패턴)는 처방이 다릅니다. 쿼리 실행 시간 자체와 커넥션 획득 대기 시간도 구분합니다.
- 외부 호출 구간이 길다 — 연계 시스템의 응답 지연입니다. 우리 코드가 아니라 상대 시스템과 타임아웃 설정이 대상이 됩니다.
- 애플리케이션 구간이 길다 — 메서드 프로파일에서 반복 호출·장시간 실행 메서드를 찾습니다. 과도한 객체 생성, 비효율 루프, 동기화 대기가 흔한 원인입니다.
주의할 점은 표본의 대표성입니다. 가장 극단적인 트랜잭션 하나만 보면 특이 사례에 끌려갈 수 있으므로, 느린 트랜잭션 여러 건을 열어 공통 패턴을 확인합니다. 여러 건에서 같은 쿼리, 같은 외부 호출, 같은 메서드가 반복해서 최장 구간으로 나오면 그것이 원인 후보입니다.
3단계 — 자원 상관 분석으로 어떻게 확정하나?
3단계의 목표는 트랜잭션에서 찾은 후보를 자원 지표와 시간대 대조로 검증하는 일입니다. JVM 힙·GC·스레드·커넥션 풀 그래프를 같은 시간축에 놓고 인과를 확정합니다.
2단계에서 찾은 것은 “증상이 나타난 위치”입니다. 그런데 위치가 곧 원인은 아닙니다. SQL 구간이 길었던 이유가 쿼리 자체가 아니라 커넥션 풀 대기였을 수 있고, 애플리케이션 구간이 길었던 이유가 코드가 아니라 GC 중지였을 수 있습니다. 그래서 마지막으로 자원 지표와의 시간대 대조가 필요합니다.
대조 요령은 가설별로 짝이 되는 그래프를 보는 것입니다. GC 가설이라면 응답시간 스파이크 시각과 GC 발생·중지 시간이 겹치는지, 힙 그래프의 톱니 골이 높아지고 있었는지 봅니다. 커넥션 가설이라면 풀 사용률과 대기 스레드 수가 장애 시각에 차올랐는지, 그 직전에 슬로우 쿼리가 늘었는지 봅니다. 스레드 가설이라면 액티브 스레드의 계단식 증가와 스레드 덤프의 대기 지점을 봅니다. WAS 내부 자원 각각의 정상·이상 패턴은 WAS 모니터링 가이드에서 자세히 다뤘습니다. 대조에는 “이 값이 정상인가”를 판단할 기준선이 필요한데, 힙·GC·스레드 풀·커넥션 풀의 권장 기준값과 설정 근거는 WAS 성능 튜닝 가이드에 정리돼 있습니다.
대조에 쓰는 근거는 그래프만이 아닙니다. 스레드 덤프에서 잠금을 소유한 스레드를 찾거나, 메모리 점유 상위 객체를 클래스 단위로 확인하거나, 커넥션 풀 수치의 과거 추세를 되짚는 일까지가 3단계에 포함됩니다.
그림 3. 3단계에서 쓰는 원인 분석 도구들. 스레드 가설에는 덤프 분석기(Lock 추적·URL 표시)를, 메모리 가설에는 객체 분석기(classname·bytes%·instances)를, 커넥션 가설에는 데이터 추세 분석(Datasource Pool Count)을 씁니다. 가설마다 대조할 화면이 정해져 있다는 점이 요령입니다. (OPENMARU APM 제품 소개 발표 자료)
이 단계까지 오면 인과 사슬이 완성됩니다. 예를 들면 이렇습니다. “통계 배치가 시작되며(변경 이벤트) 특정 쿼리의 실행계획이 풀스캔으로 바뀌었고(2단계 SQL 구간), 그 쿼리가 커넥션을 오래 붙잡아 풀이 고갈됐으며(3단계 자원 대조), 커넥션 대기에 스레드가 묶여 무관한 화면까지 전부 느려졌다(1단계 전면 악화 패턴).” 증상에서 출발해 데이터로 이어진 이 사슬이 곧 근본 원인 보고서의 뼈대가 됩니다.
재발 방지 — 포스트모템과 경보 보정은 무엇을 남겨야 하나?
원인 규명의 마지막 단계는 문서화와 경보 보정입니다. 비난 없는 포스트모템으로 인과 사슬을 기록하고, 이번 장애를 다음에는 더 일찍 알 수 있도록 임계값을 고칩니다.
Google SRE 북은 포스트모템(postmortem, 장애 회고)의 원칙으로 비난 없는(blameless) 문화를 강조합니다. 사람의 실수를 추궁하기 시작하면 정보가 숨고, 같은 장애가 조용히 반복되기 때문입니다. 좋은 포스트모템은 개인이 아니라 시스템과 절차의 빈틈에 초점을 맞춥니다(Google SRE Book — Postmortem Culture).
경보 보정에는 방향이 있습니다. 임계값을 무작정 낮추면 거짓 경보가 늘어 경보 자체가 무시되기 시작하므로, 이번 장애에서 실제로 먼저 움직였던 지표 — 이를테면 커넥션 풀 대기 수, 힙 톱니의 골, p99 응답시간 — 를 골라 그 지표에만 새 경보를 거는 편이 정확합니다. 장애마다 이 보정을 반복하면 경보 체계가 우리 시스템의 실제 장애 패턴에 맞춰 다듬어집니다.
보정의 다음 단계는 임계값을 넘은 뒤가 아니라 넘기 전에 알리는 것입니다. 힙 사용률이나 커넥션 풀처럼 추세가 있는 지표는 증가 기울기로 도달 시점을 추정할 수 있어, “지금 70%인데 16시 5분쯤 81%로 임계값 80%를 넘을 것”과 같은 예고가 가능합니다. 이런 선행 경보가 붙으면 3단계 분석은 장애 후 회고가 아니라 장애 전 점검이 됩니다.
그림 4. 임계값 도달 전에 시점과 예상값을 알리는 예측 경보. 추세 분석으로 도달 시점을 추정해 통보하므로, 포스트모템의 “더 일찍 알 수 있는 신호는 무엇이었나”라는 질문이 그대로 설정으로 옮겨집니다. (OPENMARU APM 제품 소개 발표 자료)
경보 보정이 반복되다 보면 “지표를 더 넓게 모아야 하나”라는 질문으로 이어집니다. 관측 범위를 어디까지 넓히는 것이 적정한지는 APM과 옵저버빌리티의 차이에서 정리했습니다.
APM 기반 분석의 장점은 포스트모템의 근거가 스크린샷과 데이터로 남는다는 점입니다. 기록할 항목은 다섯 가지면 충분합니다. 타임라인(감지→대응→복구 시각), 사용자 영향 범위, 3단계로 확정한 인과 사슬, 잘된 점과 아쉬운 점, 그리고 재발 방지 액션입니다. 액션에는 코드·쿼리 수정 같은 직접 조치와 함께 관측 개선을 반드시 포함합니다. “이번 장애를 우리는 몇 분 만에 알았나, 더 일찍 알 수 있는 신호는 무엇이었나”를 되짚어, 힙 추세·풀 대기·p99 같은 선행 지표에 경보를 새로 걸거나 임계값을 보정합니다. 장애 한 건이 경보 체계를 한 단계 성숙시키는 재료가 되는 셈입니다.
OPENMARU APM 기반 장애 분석 시나리오 — 세 가지 흔한 사례
슬로우 쿼리·커넥션 고갈·GC 폭주는 서로 다른 화면 동선으로 잡힙니다. OPENMARU APM에서 3단계 절차가 실제로 어떻게 흘러가는지 사례로 정리합니다.
OPENMARU APM은 모든 트랜잭션의 응답시간·호출 횟수를 실시간 수집하고 개별 트랜잭션을 코드 레벨까지 프로파일링하므로(OPENMARU APM 제품 페이지), 위 3단계를 화면 이동 몇 번으로 수행할 수 있습니다.
그림 5. 증상 인지에서 조치까지의 연결. 3단계 절차가 특정 환경 전용이 아니라는 점이 중요합니다. 전통 WAS 스택이든 컨테이너 환경이든 같은 순서로 좁혀 들어갑니다. (OPENMARU APM 제품 소개 발표 자료)
사례 1 — 슬로우 쿼리. 특정 화면만 느리다는 신고. 대시보드에서 해당 URL의 응답시간 급증을 확인하고(1단계), 트랜잭션 산점도에서 느린 무리를 골라 호출 트리를 엽니다. 같은 조회 쿼리가 최장 구간으로 반복 확인됩니다(2단계). 같은 시간대 커넥션 풀·GC는 평온해, 쿼리 자체의 문제로 확정합니다(3단계). 처방은 실행계획 점검과 인덱스 보강입니다.
사례 2 — 커넥션 고갈. 전 화면이 서서히 느려지는 계단식 악화. 액티브 서비스가 차오르는 것을 확인하고(1단계), 느린 트랜잭션들에서 SQL 구간 중 커넥션 획득 대기가 길다는 공통점을 찾습니다(2단계). 풀 사용률 100%와 대기 스레드 증가, 그 시작점에 배치성 슬로우 쿼리가 겹칩니다(3단계). 처방은 원인 쿼리 개선이 먼저이고, 풀 크기 조정은 그다음입니다. 조정 폭의 기준은 WAS 성능 튜닝 가이드의 커넥션 풀 항목을 참고하시면 됩니다.
사례 3 — GC 폭주. 주기적인 응답시간 스파이크. 스파이크 시각이 특정 인스턴스에 몰리는 것을 확인하고(1단계), 그 시간대 트랜잭션은 특정 구간 없이 전체가 고르게 늘어져 있습니다(2단계). 힙 그래프의 골이 며칠째 높아지고 Full GC가 반복되고 있었음이 드러납니다(3단계). 처방은 힙 덤프로 누수 객체를 특정하는 후속 분석과, 힙 추세 경보 신설입니다.
이 사례는 실제 분석 기록으로도 남아 있습니다. 15일간의 힙 사용률 추세를 보면 사용량 자체는 46.6%인데 추세선은 77.3%까지 올라가 있습니다. 회수되지 않는 힙이 쌓이는 중이라는 뜻이고, 같은 기간 Full GC 소요 시간도 함께 늘고 있었습니다.
그림 6. 3단계 자원 대조의 실제 화면. 순간값(46.6%)만 보면 정상으로 읽히지만, 추세선(77.3%)이 우상향한다는 사실이 누수를 가리킵니다. 절대값이 아니라 기울기를 보라는 원칙이 그대로 적용된 사례입니다. (OPENMARU APM 제품 소개 발표 자료)
후속 분석에서 힙 덤프를 뜨자 원인이 확정됐습니다. 287만 개의 String 객체가 힙의 46%를 점유하고 있었고, 누수 경로는 Tomcat의 TagHandlerPool에서 로거로 이어지는 참조 사슬이었습니다. “GC가 자주 돌더라”에서 멈추지 않고 어떤 객체가 왜 남았는지까지 내려가야 재발을 막을 수 있습니다.
그림 7. 인과 사슬의 마지막 칸. 지표(힙 추세) → 증상(Full GC 반복) → 객체(String 287만 개) → 경로(TagHandlerPool → Logger)까지 이어져야 포스트모템의 재발 방지 액션이 구체화됩니다. (OPENMARU APM 제품 소개 발표 자료)
화면을 직접 옮겨 다니는 대신 프롬프트로 같은 3단계를 밟는 방법도 있습니다. APM 데이터를 AI Agent에 연결해 자연어로 원인을 좁혀 가는 과정은 프롬프트로 WAS 장애 분석 — OPENMARU APM AI Agent 데모에서 영상으로 확인하실 수 있습니다.
세 사례의 공통점은 순서입니다. 지표 → 트랜잭션 → 자원의 동선을 지키면, 어느 유형이든 추측 없이 데이터의 사슬로 원인에 도달합니다. 골든타임을 지키는 것은 결국 도구가 아니라 절차이고, APM은 그 절차가 실제로 돌아가게 하는 데이터 기반입니다.
성능 최적화 가이드
느려진 서비스 원인, APM으로 한눈에 잡는 법
실시간 트랜잭션 추적부터 서비스 병목 구간 감지까지 — APM(Application Performance Monitoring)의 핵심 개념과 적용 방안을 직접 확인해 보세요.
자주 묻는 질문 (FAQ)
장애 원인 분석은 어떤 순서로 진행하나요?
지표로 범위 좁히기(언제·어디·패턴) → 트랜잭션 추적으로 구간 확정 → 자원 상관 분석으로 검증의 3단계입니다. 순서를 지키면 추측이 줄고, 원인 후보가 코드·쿼리 위치까지 좁혀집니다.
MTTR 단축과 원인 규명은 왜 분리해야 하나요?
복구는 서비스를 되살리는 일, 규명은 재발을 막는 일로 목표가 다르기 때문입니다. 재기동 같은 복구 조치는 휘발성 증거를 지우므로, APM처럼 장애 시점 데이터가 외부에 기록되는 체계를 갖춰 두면 복구를 서두르면서도 규명을 포기하지 않을 수 있습니다.
근본 원인은 무엇으로 확정되나요?
변경 이벤트 → 증상 구간 → 자원 상태로 이어지는 인과 사슬이 데이터로 연결될 때입니다. 트랜잭션에서 찾은 최장 구간(위치)을 자원 지표와의 시간대 대조로 검증해야, 위치와 원인을 혼동하지 않습니다.
재기동하면 증거가 사라지지 않나요?
프로세스 안의 순간 증거(힙·스레드 상태)는 사라집니다. 그래서 스레드 덤프처럼 지금이 아니면 못 뜨는 증거는 복구 전에 확보하고, 트랜잭션·지표 이력은 APM 수집 서버의 기록을 활용합니다.
포스트모템에는 무엇을 담아야 하나요?
타임라인, 사용자 영향, 인과 사슬, 잘된 점과 아쉬운 점, 재발 방지 액션 다섯 가지입니다. 비난 없는(blameless) 원칙으로 시스템의 빈틈에 초점을 맞추고, 액션에는 경보 임계값 보정 같은 관측 개선을 반드시 포함합니다.
참고 리소스
자사 콘텐츠 (OPENMARU)
- APM이란? 서버 지표로 못 잡는 장애, 개념부터 도입까지 — OPENMARU
- APM 핵심 지표 읽는 법 — 응답시간·TPS·에러율, 숫자 너머의 의미
- 트랜잭션 추적이란 — 느린 요청 하나를 코드 레벨까지 따라가는 기술
- WAS 모니터링 가이드 — JVM 힙·스레드·커넥션 풀까지 봐야 하는 이유
- WAS 성능 튜닝 — JVM 힙·GC·스레드 풀·커넥션 풀 기준값 가이드
- APM 옵저버빌리티 차이 — 무엇이 다르고, 무엇부터 갖춰야 하나
- 프롬프트로 WAS 장애 분석 — OPENMARU APM AI Agent 데모
- WAS 장애·세션 유실·APM 선택 기준 정리 — OPENMARU iAP 제품 소개 자료 다운로드
- OPENMARU APM 제품 소개
표준·공식 문서 (외부)
문의
OPENMARU APM 도입을 검토 중이라면 아래 경로로 확인하실 수 있습니다.
- OPENMARU APM 무료 체험: https://www.openmaru.io/product/openmaru-cloud-apm/
- 도입 레퍼런스 확인: https://www.openmaru.io/clients/
- 레드햇 제품·기술 문의: https://www.openmaru.io/request-for-quote/
클라우드 네이티브 워크숍 후기 — 참석자들이 실제로 궁금해한 것들
/카테고리: Cloud, Technical/작성자: OM marketing줌(Zoom), 구글밋(Google Meet), 유튜브 라이브(Yotube Live)를 이용한 클라우드 네이티브 비대면 워크샵 – 혁신적인 기술을 비대면으로 확인하세요
클라우드 네이티브 세미나 후기 — 담당자들이 가장 많이 물은 질문 3가지
/카테고리: Cloud, Technical/작성자: OM marketing클라우드 네이티브 데모와 발료자료를 — 실무자를 위한 핵심 요약, 무료로 받아보세요
/카테고리: OPENMARU/작성자: OM marketing