APM 핵심 지표 읽는 법 — 응답시간·TPS·에러율, 숫자 너머의 의미

TPS — 처리량 숫자는 응답시간과 함께 봐야 하는 이유는?

TPS는 단독으로는 부하의 크기만 알려 줍니다. 응답시간과 함께 봐야 시스템이 부하를 견디는지, 무너지기 시작했는지 판단할 수 있습니다.

TPS(Transactions Per Second)는 시스템이 초당 처리한 요청 건수, 즉 처리량(throughput) 지표입니다. TPS가 높다는 것 자체는 좋은 일도 나쁜 일도 아닙니다. 트래픽이 몰려서 높을 수도 있고, 성능이 좋아 많이 처리하는 것일 수도 있습니다. 판단은 항상 응답시간과의 조합에서 나옵니다.

두 지표의 관계를 설명하는 고전적 원리가 리틀의 법칙(Little’s Law)입니다. 시스템 안에 머무는 요청 수(L)는 도착률(λ)과 체류 시간(W)의 곱과 같다는 대기행렬 이론의 결과입니다. APM 지표로 옮기면 “동시 처리 중인 요청 수 = TPS × 평균 응답시간”이 됩니다. 이 관계에서 실무적으로 중요한 패턴이 나옵니다.

• TPS 상승 + 응답시간 유지: 시스템이 부하를 잘 소화하고 있습니다. 정상적인 성장 곡선입니다.
• TPS 상승 + 응답시간 상승: 포화가 시작됐다는 신호입니다. 스레드·커넥션 같은 내부 자원이 대기열을 만들고 있을 가능성이 높습니다.
• TPS 하락 + 응답시간 급상승: 위험 신호입니다. 요청은 계속 들어오는데 처리가 막혀, 동시 체류 요청이 쌓이는 상태입니다. 이 패턴이 보이면 장애가 이미 진행 중이라고 봐야 합니다.
• TPS 급락 + 응답시간 정상: 앞단(로드밸런서·웹 서버·네트워크)에서 요청 자체가 줄었을 가능성을 먼저 의심합니다.

그림 2. TPS 는 혼자 읽지 않는다 — 응답시간과의 네 가지 조합

기준선 없이 TPS 절대값만 보는 실수도 흔합니다. 서비스마다, 시간대마다 정상 TPS는 다르므로, 요일·시간대별 평소 곡선을 만들어 두고 그 곡선에서 벗어나는 폭을 보는 편이 정확합니다.

에러율 — 5xx·예외·타임아웃을 왜 구분해서 세야 하나?

에러율은 무엇을 에러로 세는지 집계 기준부터 정해야 하는 지표입니다. HTTP 5xx, 애플리케이션 예외, 타임아웃은 원인도 대응도 다릅니다.

에러율(error rate)은 전체 요청 중 실패한 요청의 비율입니다. 간단해 보이지만, “무엇을 실패로 볼 것인가”에서 세 갈래가 나뉩니다.

첫째, HTTP 5xx 응답입니다. 서버가 명시적으로 실패를 알린 경우로, 집계가 가장 쉽습니다. 다만 4xx(클라이언트 오류)를 섞어 세면 착시가 생깁니다. 크롤러가 만드는 404 급증은 서비스 장애가 아니기 때문입니다. 5xx와 4xx는 반드시 분리해서 봅니다.

둘째, 애플리케이션 예외(exception)입니다. 코드 안에서 발생했지만 HTTP 응답으로는 200이 나가는 경우가 있습니다. 예외를 잡아 빈 화면이나 기본값을 돌려주는 방어 코드가 있으면, 사용자는 잘못된 결과를 받는데 상태 코드는 정상입니다. APM이 트랜잭션 안의 예외를 별도로 집계해 주는 이유가 여기에 있습니다. 상태 코드 기준 에러율과 예외 발생률을 나란히 두고, 두 곡선이 벌어지는 지점을 찾아야 숨은 실패가 보입니다.

셋째, 타임아웃(timeout)입니다. 외부 API나 DB 호출이 제한 시간을 넘겨 끊긴 경우입니다. 타임아웃은 실패이면서 동시에 “느림의 끝”이므로, 에러율과 응답시간 양쪽에 걸쳐 있습니다. 타임아웃이 늘기 시작하면 그 직전 구간의 응답시간 분포가 이미 나빠져 있었는지 되짚어 봐야 합니다.

그림 3. 에러율은 무엇을 세는가 — 세 갈래를 나눠 센다

Google SRE의 골든 시그널 정의도 명시적 실패뿐 아니라 “잘못된 내용을 담은 200 응답” 같은 암묵적 실패를 에러로 다루라고 안내합니다(Google SRE Book — The Four Golden Signals). 집계 기준을 문서로 정해 두면, 장애 회고 때 “에러율 몇 %였나”를 두고 팀마다 다른 숫자를 말하는 혼선을 막을 수 있습니다.

액티브 서비스와 동시 사용자 — 순간 부하는 무엇으로 읽나?

액티브 서비스는 지금 이 순간 처리 중인 요청 수로, 장애가 번지는 순간을 실시간으로 포착하는 지표입니다. 집계 지표보다 반 박자 빠른 조기 경보 역할을 합니다.

응답시간·TPS·에러율은 모두 일정 구간을 집계한 결과라서, 상황이 나빠지는 “지금”보다 한 박자 늦게 움직입니다. 이 틈을 메우는 것이 액티브 서비스(active service) 지표입니다. 현재 처리 중이어서 아직 응답을 돌려주지 못한 요청의 수를 실시간으로 보여 줍니다.

정상 상태에서 액티브 서비스 수는 리틀의 법칙대로 TPS와 응답시간의 곱 근처에서 출렁입니다. 그런데 어딘가 막히기 시작하면 — 느린 SQL 하나가 커넥션을 오래 붙잡거나, 외부 API가 응답을 멈추면 — 처리 중 요청이 빠져나가지 못하고 쌓입니다. 액티브 서비스 급증은 그래서 “무언가 막혔다”는 가장 빠른 신호입니다. 함께 표시되는 동시 사용자 수는 부하의 원천이 실제 사용자 증가인지, 내부 적체인지 가르는 보조 정보가 됩니다.

그림 4. 액티브 서비스 — 집계 지표보다 반 박자 빠른 신호

이 지표가 특히 유용한 순간은 행(hang) 장애입니다. 프로세스는 살아 있는데 응답이 없는 상태에서는 에러율도 오르지 않고 TPS만 서서히 줄어들어, 집계 지표만 보면 원인이 잡히지 않습니다. 액티브 서비스가 천장까지 차오른 그래프는 이 상황을 한눈에 드러냅니다. 이때 쌓여 있는 트랜잭션들을 열어 어느 구간에서 멈췄는지 확인하는 것이 다음 단계이며, 그 방법은 APM 트랜잭션 분석 차트 활용하기(T-MAP) 글에서 자세히 다룹니다.

골든 시그널과 APM 지표는 어떻게 대응되나?

APM 핵심 지표는 Google SRE의 네 가지 골든 시그널과 일대일로 대응됩니다. 표준 프레임에 지표를 얹으면 무엇이 빠져 있는지 점검하기 쉽습니다.

Google SRE 북은 서비스 상태를 판단하는 최소 지표로 지연시간(latency)·트래픽(traffic)·에러(errors)·포화도(saturation) 네 가지를 제시합니다(Google SRE Book — The Four Golden Signals). APM 지표와의 대응은 다음과 같습니다.

이 대응표에서 눈에 띄는 점은 포화도입니다. 응답시간·TPS·에러율은 대시보드 첫 화면에 있지만, 포화도는 JVM(Java Virtual Machine) 힙 사용량, 스레드 풀 활성 개수, DB 커넥션 풀 사용률처럼 한 겹 안쪽의 자원 지표로 측정됩니다. 사용자 체감 지표(앞의 셋)가 증상을 알려 준다면, 포화도는 원인 쪽에 가까운 지표입니다. 증상 지표에 경보를 걸고, 원인 지표로 내려가 확인하는 순서가 표준 동선입니다. WAS 내부 자원 지표를 읽는 법은 WEB/WAS 모니터링 페이지에서 확인하실 수 있습니다.

한편 OpenTelemetry는 이런 수치 지표를 카운터·게이지·히스토그램 같은 계기(instrument) 유형으로 표준화해 수집하도록 정의합니다(OpenTelemetry — Metrics). 응답시간처럼 분포가 중요한 지표는 히스토그램으로 수집해야 백분위수 계산이 가능하다는 점도 도구 평가 시 확인할 항목입니다.

임계값과 경보는 어떻게 설계하나 — OPENMARU APM에서의 확인 경로

경보 임계값은 절대값 하나가 아니라 기준선 대비 편차와 지속 시간으로 설계해야 합니다. 그래야 새벽의 거짓 경보와 낮의 놓친 장애를 함께 줄일 수 있습니다.

임계값(threshold) 설계에서 흔한 실패는 “응답시간 1초 초과 시 경보” 같은 단일 절대값입니다. 트래픽이 적은 새벽에는 배치 작업 하나로도 넘어서 거짓 경보가 울리고, 트래픽이 많은 낮에는 p99가 이미 나빠졌는데 평균이 1초를 안 넘어 경보가 침묵합니다. 개선 방향은 세 가지입니다.

• 백분위수 기준: 평균 대신 p95·p99에 임계값을 겁니다. 꼬리부터 나빠지는 장애를 먼저 잡습니다.
• 지속 시간 조건: “1회 초과”가 아니라 “5분간 지속 초과”처럼 시간 조건을 더해 순간 스파이크의 거짓 경보를 거릅니다.
• 복합 조건: 에러율 상승과 액티브 서비스 급증이 동시에 발생할 때만 최고 등급 경보를 울리는 식으로, 지표 조합에 등급을 매깁니다.

그림 5. 임계값 설계 — 단일 절대값에서 세 요소 조합으로

OPENMARU APM에서는 카드 대시보드에서 TPS·액티브 사용자·지연 트랜잭션 수·평균 응답시간을 한 화면으로 확인하고, 개별 트랜잭션을 코드 레벨까지 프로파일링해 지표 이상의 원인 구간으로 바로 내려갈 수 있습니다(OPENMARU APM 제품 페이지). 실시간 통계 분석으로 임곗값 도달 시점을 예측해 알림을 주는 기능은 “넘은 뒤 통보”가 아니라 “넘기 전 개입”을 가능하게 합니다. 지표를 읽는 기준을 세우고 경보를 그 기준에 맞춰 두면, 다음 단계는 이상 신호에서 원인까지 파고드는 일입니다. 그 절차는 트랜잭션 추적과 장애 원인 분석 글에서 이어집니다.

자주 묻는 질문 (FAQ)

APM에서 가장 먼저 봐야 할 지표는 무엇인가요?

응답시간(p95·p99)·TPS·에러율 세 가지입니다. 이 셋이 사용자 체감을 대표하는 증상 지표이고, JVM 힙·스레드·커넥션 풀 같은 자원 지표는 원인을 좁힐 때 내려가 보는 다음 계층입니다.

응답시간은 평균으로 보면 왜 안 되나요?

응답시간 분포는 비대칭이라 평균이 실제 경험을 가리기 때문입니다. 다수의 빠른 요청과 소수의 매우 느린 요청이 섞이면 평균은 무난한 숫자가 됩니다. 전체 요청의 95%·99%가 끝난 시간을 뜻하는 p95·p99로 느린 꼬리를 직접 봐야 합니다.

TPS와 응답시간은 어떤 관계인가요?

리틀의 법칙에 따라 동시 처리 중 요청 수는 TPS와 평균 응답시간의 곱과 같습니다. TPS가 오르는데 응답시간이 함께 오르면 포화 신호, TPS가 떨어지며 응답시간이 급등하면 처리가 막혀 적체가 진행 중이라는 위험 신호입니다.

에러율 집계에는 무엇을 포함해야 하나요?

HTTP 5xx, 애플리케이션 예외, 타임아웃을 분리해 집계하되 모두 추적해야 합니다. 4xx는 별도로 관리하고, 상태 코드는 200이지만 내용이 잘못된 암묵적 실패는 예외 집계로 잡습니다. 집계 기준을 문서로 정해 팀 공통 기준을 만드는 일이 먼저입니다.

경보 임계값은 어떻게 잡아야 하나요?

평소 지표의 기준선을 만들고, 백분위수 기준 + 지속 시간 조건 + 지표 조합의 세 요소로 설계합니다. 단일 절대값 경보는 거짓 경보와 미탐을 함께 만들기 때문에, 기준선 대비 편차로 판단하는 방식이 안전합니다.

참고 리소스

자사 콘텐츠 (OPENMARU)
– APM이란? 서버 지표로 못 잡는 장애, 개념부터 도입까지 — OPENMARU
– APM vs 옵저버빌리티 — 무엇이 다르고, 무엇부터 갖춰야 하나
– APM 트랜잭션 분석 차트 활용하기 : T-MAP
– WEB/WAS 모니터링 — OPENMARU APM
– APM 을 통한 자동 경고 정책 구축
– APM 에 대한 FAQ 5가지
– 애플리케이션 모니터링 — OPENMARU Cloud APM
– OPENMARU APM 제품 소개

표준·공식 문서 (외부)
– Monitoring Distributed Systems — Google SRE Book
– The Four Golden Signals — Google SRE Book
– Metrics — OpenTelemetry