APM AI Insight 사례, 장애 알람에서 근본 원인까지 30초

이 영상이 답하는 7가지 질문 정리

영상의 내용을 질문으로 바꾸면 일곱 가지이고, 아래 일곱 개 절이 이 순서대로 답합니다.

1. 장애는 운영자의 화면에 어떤 모습으로 처음 나타나는가?
2. 알람은 무엇을 알려 주고 무엇을 알려 주지 않는가?
3. APM AI Insight에는 어떻게 질문하는가?
4. 진단 보고서는 어떤 수치를 한데 모으는가?
5. 근본 원인을 JDBC 커넥션 풀 고갈로 판단한 근거는 무엇인가?
6. 그 진단이 맞는지는 무엇으로 확인하는가?
7. 원인을 찾은 다음에는 무엇부터 고쳐야 하는가?

대시보드 색이 바뀌는 순간이 장애 대응의 시작인 이유

장애는 숫자보다 색으로 먼저 드러납니다. 영상의 첫 제품 화면에서 주문(order) 서비스를 나타내는 막대가 초록에서 주황으로, 이어서 빨강으로 바뀝니다.

화면은 OPENMARU APM의 실시간 WAS 대시보드입니다. WAS(Web Application Server, 웹 애플리케이션 서버)는 업무 프로그램이 실제로 실행되는 서버를 말합니다. 대시보드는 shoppingmall이라는 애플리케이션 그룹에 속한 인스턴스들을 한 화면에 놓고, 인스턴스마다 처리 중인 트랜잭션의 상태를 색 막대로 그립니다. 나레이션은 이 장면을 두고 “장애는 예고 없이 옵니다”라고 말합니다.

▲ order 서비스가 주황으로 바뀌는 실시간 WAS 대시보드 (영상 0:07)

캡처에서 왼쪽 큰 막대가 주문 서비스 인스턴스이고, 오른쪽 두 막대는 같은 그룹의 다른 인스턴스입니다. 다른 인스턴스는 초록인데 주문 서비스만 주황으로 변했습니다. 아래쪽 분포도와 응답 시간 그래프는 아직 평소 모양을 유지합니다. 이 시점의 운영자는 어느 서비스가 이상한지는 알지만 이유는 알지 못합니다. 영상이 첫 문장 뒤에 “원인은, 누가 찾습니까?”라고 묻는 까닭입니다.

알람이 증상까지만 알려 주는 구조

알람은 임계값을 넘은 지표 하나를 알려 줍니다. 영상에서 주문 서비스의 보류 트랜잭션 평균이 24.6개로 심각 임계값 10을 넘었고, 화면 왼쪽 아래에 붉은 경고가 나타납니다.

보류 트랜잭션은 요청을 받았지만 아직 응답하지 못하고 처리 중에 머물러 있는 요청을 뜻합니다. 이 값이 늘어난다는 것은 요청이 들어오는 속도를 처리 속도가 따라가지 못한다는 뜻입니다. 나레이션은 “주문 서비스가 붉게 변하고, 보류 트랜잭션이 임계값을 넘었습니다”라고 설명합니다.

운영 지표로 보면 알람은 장애를 알아채는 시간(MTTD, Mean Time to Detect)을 줄이는 장치입니다. 복구까지 걸리는 시간(MTTR, Mean Time to Repair)은 알아챈 뒤 원인을 찾는 데 쓰는 시간에 크게 좌우되는데, 알람은 이 구간을 줄여 주지 않습니다. APM과 옵저버빌리티가 각각 어느 구간을 맡는지는 APM 옵저버빌리티 차이 글에서 함께 읽을 수 있습니다.

▲ 붉게 변한 order 서비스와 보류 트랜잭션 경고 (영상 0:13)

경고 문구에는 지표 이름과 평균값, 임계값, 대상 인스턴스가 들어 있습니다. 여기에 원인은 없습니다. 보류 트랜잭션이 쌓이는 이유는 느린 쿼리일 수도, 외부 호출 지연일 수도, 메모리 부족일 수도 있습니다. 지금까지는 운영자가 트랜잭션 목록, JVM(Java Virtual Machine, 자바 가상 머신) 지표, 데이터소스 화면을 차례로 열어 값을 대조해야 했습니다. APM AI Insight가 맡는 일이 이 대조입니다.

화면째 문장으로 묻는 APM AI Insight의 질의 방식

APM AI Insight에는 평소 쓰는 문장으로 묻습니다. 영상은 대시보드 오른쪽에 AI 패널을 열고, 지금 보고 있는 화면을 붙인 뒤 shoppingmall 애플리케이션에 문제가 없는지 현재 상황을 분석해 달라고 입력합니다.

나레이션의 표현은 “이제 AI 인사이트에게, 그대로 물어보세요”입니다. ‘그대로’에는 두 가지 뜻이 있습니다. 하나는 보고 있는 화면 그대로 넘긴다는 뜻이고, 다른 하나는 쿼리 언어나 지표 이름을 몰라도 된다는 뜻입니다.

▲ 대시보드 옆 AI 패널에 화면째 묻는다 (영상 0:17)

캡처 오른쪽의 파란 상자가 질문입니다. 상자 안에는 방금 본 대시보드 화면이 그대로 들어 있고, 그 아래에 질문 문장이 적혀 있습니다. 패널은 대시보드를 가리지 않고 옆에 열리므로 운영자는 알람이 뜬 화면을 떠나지 않습니다. 질문을 보내면 패널에 분석 중이라는 표시가 나타나고, 잠시 뒤 보고서 형태의 답이 같은 패널에 채워집니다.

제품 사용 안내서에 따르면 질문을 직접 입력하지 않아도 됩니다. 화면 위쪽의 AI 진단 버튼을 누르면 지금 선택된 애플리케이션 그룹 전체에 문제가 없는지 묻는 질문이 자동으로 들어갑니다. 안내서가 권하는 순서는 넓게 본 뒤 좁히는 것입니다. 그룹 전체를 먼저 진단하고, 답이 지목한 영역은 그 차트에 붙은 AI 버튼으로 다시 묻습니다.

흩어진 지표를 표 한 장으로 모으는 진단 보고서의 구조

AI Insight의 답은 대화가 아니라 보고서입니다. 첫 부분인 ‘주요 현황’ 표가 에러율, 보류 트랜잭션, 평균 지연을 임계값과 함께 한 장에 모읍니다. 나레이션은 “에러율 30%, 평균 지연 30초. 흩어진 지표를 한 번에 읽어 냅니다”라고 말합니다.

보고서 머리에는 분석 대상이 적혀 있습니다. 애플리케이션은 shoppingmall, 인스턴스는 order이고 데이터 수집 기간은 5분입니다. AI Insight는 이 5분 동안의 지표를 읽어 표를 채웠습니다.

▲ 진단 보고서 「주요 현황」 표 (영상 0:26)

표에 담긴 값을 옮기면 다음과 같습니다.

위 세 줄은 대시보드와 알람에서 볼 수 있던 증상이고, 아래 세 줄은 트랜잭션과 데이터소스 화면을 열어야 보이던 단서입니다. 서로 다른 화면에 있던 값이 한 표에 놓이면 관계가 드러납니다. 평균 지연 30,000ms와 원인 메서드의 지속 시간 30,000ms가 같은 숫자라는 점이 그렇습니다.

에러율과 응답 시간처럼 표의 위쪽에 놓인 지표를 평소에 어떻게 읽는지는 APM 핵심 지표 읽는 법에 정리되어 있습니다. 임계값은 지표마다 따로 정하므로, 한 지표가 넘었을 때 다른 지표도 함께 넘었는지를 한 표에서 확인할 수 있다는 점이 진단 보고서의 쓸모입니다.

근본 원인을 JDBC 커넥션 풀 고갈로 판단한 기준

보고서가 내린 결론은 JDBC 커넥션 풀 고갈입니다. 나레이션도 “근본 원인은, JDBC 커넥션 풀 고갈”이라고 한 문장으로 말합니다. JDBC(Java Database Connectivity)는 자바 프로그램이 데이터베이스에 접속하는 표준 방식이고, 커넥션 풀은 접속을 미리 만들어 두고 빌려 쓰는 저장소입니다.

보고서의 ‘원인 분석’은 네 항목으로 이 결론을 받칩니다.

▲ 원인 분석: JDBC 커넥션 풀 고갈 (영상 0:31)

첫째, 풀에서 “커넥션을 쓸 수 없고 요청이 30,000ms 뒤에 시간 초과됐다”는 오류가 반복됐습니다. 풀 크기가 20개인데 모두 사용 중이라 새 요청이 30초를 기다리다 500 오류로 끝났습니다. 둘째, 느린 트랜잭션의 지연이 모두 커넥션을 얻는 호출에 몰려 있습니다. 셋째, 5분 동안 500 오류가 이어져 에러율이 30%로 올랐고 보류 트랜잭션이 10개를 넘었습니다.

넷째 항목은 원인이 아닌 것을 지웁니다. GC(Garbage Collection, 쓰지 않는 메모리를 정리하는 작업) 시간이 256ms까지 올랐지만 빈도가 0이고, 힙 사용률이 5% 수준이라 메모리 부족은 원인이 아니라고 적었습니다. 운영자가 장애 때 가장 먼저 의심하는 후보 하나를 근거와 함께 제외한 것입니다. 원인을 하나로 좁히려면 맞는 가설을 세우는 일만큼 틀린 가설을 지우는 일이 필요합니다.

트랜잭션 한 건으로 진단을 검증하는 과정

진단은 증거 트랜잭션으로 확인합니다. 영상은 보고서 다음에 트랜잭션 상세 화면을 열어, 요청 한 건이 커넥션 대기에만 30.00초를 쓴 기록을 보여 줍니다. 나레이션은 “증거가 되는 트랜잭션부터”라고 짚습니다.

화면은 OPENMARU APM의 트랜잭션 조회입니다. 위쪽 목록에는 500으로 끝난 요청들이 응답 시간 3만 밀리초 안팎으로 줄지어 있고, 그중 상품 조회 요청 한 건을 골라 성능 분석 탭을 열었습니다.

▲ 증거 트랜잭션: Connection Pool 대기 30.00초 (영상 0:35)

캡처에서 확인할 수 있는 사실은 세 가지입니다. 예외 메시지에 풀 상태가 전체 20, 사용 중 20, 여유 0, 대기 13으로 적혀 있습니다. ‘문제 감지’ 항목은 이 요청을 Connection Pool 대기로 분류하고 커넥션을 얻는 호출이 30.00초, 전체의 100%를 차지했다고 표시합니다. 아래 ‘시간 분석’에서는 CPU 시간이 10ms인데 SQL 시간이 30.00초입니다.

요청은 계산을 하느라 느린 것이 아니라 기다리느라 느렸습니다. 보고서가 말한 메서드, 시간, 풀 상태가 트랜잭션 기록과 모두 일치합니다. AI가 낸 답을 받아들이기 전에 이렇게 원본 기록과 대조할 수 있다는 점이 운영 도구에서는 중요합니다.

제품 사용 안내서도 같은 순서를 권합니다. AI의 답은 출발점으로 삼고, 답이 제안한 지표를 실제 차트와 트랜잭션 기록으로 교차 확인하라는 것입니다. 추적이 더 필요하면 사람이 직접 읽는 진단 절차로 이어 갑니다. 트랜잭션 분포에서 느린 요청을 골라내는 방법은 APM 에서 트랜잭션 분석 챠트 활용하기 : T-MAP 글이, 여러 서비스를 거치는 요청에서 병목을 좁히는 절차는 분산 추적으로 WAS 병목 찾기 글이 다룹니다.

우선순위로 정리된 개선 제안 다섯 가지의 기준

APM AI Insight는 원인에서 멈추지 않고 조치 순서를 줍니다. 나레이션은 “우선순위별 개선 방안까지”라고 말하고, 영상은 그중 위 세 가지인 풀 크기 조정, 쿼리 최적화, 비동기 처리를 강조합니다.

▲ 우선순위별 개선 제안과 요약 (영상 0:40)

보고서의 ‘개선 제안’ 표는 다섯 줄입니다.

순서의 기준은 지금 장애를 멈추는 조치가 먼저라는 것입니다. 1번은 설정값만 바꾸면 되므로 가장 빠릅니다. 2번과 3번은 커넥션을 오래 쥐는 원인을 없애는 일이라 시간이 더 들지만, 하지 않으면 같은 장애가 다시 옵니다. 4번과 5번은 재발했을 때 더 빨리 알아채기 위한 준비입니다. 표 아래 요약도 가장 시급한 조치로 풀 크기와 관련 설정 조정을 꼽고, 메모리와 GC, CPU는 정상 범위라고 다시 확인합니다.

영상 밖의 보충: 30초라는 두 수치를 읽는 기준

영상에는 30초가 두 번 나오고 둘은 서로 다른 값입니다.

첫째는 평균 지연 30초입니다. 화면의 예외 메시지는 커넥션 풀 라이브러리인 HikariCP가 남긴 것입니다. HikariCP 공식 문서에 따르면 풀에서 커넥션을 기다리는 최대 시간의 기본값이 30,000ms입니다. 따라서 이 30초는 쿼리가 느린 정도를 나타내는 값이 아니라, 요청이 대기 한도까지 기다리다 포기한 시간으로 읽는 편이 맞습니다. 모든 실패 요청의 응답 시간이 3만 밀리초 근처에 몰려 있는 것도 같은 이유입니다.

둘째는 제목의 근본 원인까지 30초입니다. 영상 설명란은 화면의 수치가 데모 환경에서 측정한 값이며 AI 응답 시간이 30.84초였다고 밝힙니다. 측정은 한 번이므로 운영 환경에서 같은 시간이 나온다고 볼 근거는 아닙니다. 다만 사람이 여러 화면을 열어 대조하던 일이 한 번의 질문으로 줄어든다는 점은 측정 조건과 무관합니다.

풀 크기 조정에도 덧붙일 점이 있습니다. HikariCP의 풀 크기 산정 문서는 풀을 크게 잡는다고 처리량이 늘지 않으며 데이터베이스의 코어 수와 디스크 특성에 맞춰 정해야 한다고 설명합니다. 보고서가 풀 크기 조정과 쿼리 최적화를 함께 제안한 것은 이 설명과 맞습니다.

핵심 정리: 한 표로 보는 APM AI Insight의 진단 흐름

APM AI Insight는 알람 한 줄을 원인과 조치 순서가 적힌 보고서로 바꿉니다. 영상의 흐름을 단계로 나누면 다음과 같습니다.

영상의 마지막 문장은 “보는 APM에서, 답하는 APM으로”입니다. 지표를 보여 주는 일과 원인을 답하는 일 사이를 지금까지는 사람이 메웠고, APM AI Insight는 그 구간을 대신합니다.

자주 묻는 질문

APM AI Insight는 무엇을 해 주는 기능인가요?

APM AI Insight는 OPENMARU APM이 모은 지표와 트랜잭션을 한 번에 읽어 장애의 근본 원인과 개선 방안을 보고서로 답하는 기능입니다. 영상에서는 대시보드, 트랜잭션, JVM, 데이터소스 지표를 함께 읽어 주요 현황, 원인 분석, 개선 제안, 요약의 네 부분으로 답했습니다. 운영자가 화면을 옮겨 다니며 값을 맞춰 보던 일을 대신합니다.

AI Insight에는 어떻게 질문하나요?

대시보드 옆 AI 패널에 화면 캡처를 붙이고 평소 쓰는 문장으로 묻습니다. 영상에서는 shoppingmall 애플리케이션 그룹에 문제가 없는지 현재 상황을 분석해 달라고 물었습니다. 쿼리 언어나 지표 이름을 외울 필요가 없고, 알람이 뜬 그 화면에서 바로 질문할 수 있습니다.

영상에서 찾은 근본 원인은 무엇인가요?

근본 원인은 JDBC 커넥션 풀 고갈입니다. 커넥션 20개가 모두 사용 중이어서 새 요청이 30초를 기다리다 500 오류로 끝났습니다. 진단 보고서는 지연이 모두 커넥션을 얻는 구간에 몰려 있다는 점과, 힙 사용률과 GC가 정상이라는 점을 함께 들어 원인을 좁혔습니다. 트랜잭션 상세 화면의 예외 메시지에도 사용 중 20, 여유 0, 대기 13이 찍혀 있습니다.

제목의 30초는 어떻게 측정한 값인가요?

데모 환경에서 AI Insight가 답을 내는 데 걸린 시간 30.84초를 가리킵니다. 영상 설명란은 화면의 수치가 데모 환경에서 측정한 값이라고 밝힙니다. 측정은 한 번이므로 운영 환경의 응답 시간은 데이터 양과 모델 구성에 따라 달라집니다. 평균 지연 30초는 이것과 다른 값으로, 커넥션을 기다린 시간입니다.

AI가 낸 진단을 그대로 믿어도 되나요?

진단은 출발점으로 쓰고, 근거가 되는 트랜잭션을 직접 열어 확인하는 것이 안전합니다. 영상도 진단 보고서 다음에 트랜잭션 상세 화면을 열어 커넥션 대기 30.00초를 보여 줍니다. 보고서가 가리킨 메서드와 예외 메시지가 실제 트랜잭션 기록과 같은지 대조하면 진단을 받아들일지 판단할 수 있습니다.

커넥션 풀 크기만 늘리면 문제가 해결되나요?

풀 크기 조정은 가장 먼저 할 조치이지만 그것만으로 끝나지 않습니다. 보고서는 풀 크기 조정 다음으로 쿼리 최적화와 비동기 처리를 제안했습니다. 커넥션을 오래 쥐고 있는 느린 쿼리가 남아 있으면 풀을 키워도 다시 찹니다. HikariCP 문서도 풀을 무작정 키우는 것을 권하지 않으므로 데이터베이스가 감당할 연결 수를 함께 확인해야 합니다.

기존 APM 대시보드만으로는 왜 부족한가요?

대시보드와 알람은 어디에 증상이 있는지 알려 주지만 왜 그런지는 사람이 여러 화면을 대조해 찾아야 하기 때문입니다. 영상의 알람은 보류 트랜잭션이 임계값 10을 넘었다는 사실까지만 알려 줍니다. 원인을 찾으려면 트랜잭션, JVM, 데이터소스 화면을 차례로 확인해야 하는데, AI Insight는 이 대조를 한 번에 수행해 보고서로 돌려줍니다.