4.2. 상관 분석
두 지표가 함께 움직이는지 — 11종
"왜 느려졌나" 를 물을 때 쓰는 갈래입니다. 응답시간이 튄 구간에서 함께 움직인 지표를 찾아 줍니다. 상관 분석은 셋 중 가장 종수가 많고(11종), 고를 것도 가장 많습니다.
무엇을 답해 주나
두 지표를 나란히 놓고 같이 움직였는지를 수치로 냅니다.
- 얼마나 같이 움직였나 — 상관계수
- 어느 쪽이 먼저였나 — 선행·후행 관계
- 한쪽이 다른 쪽에 영향을 주었다고 볼 수 있나 — 인과 검정
여러 지표를 한 번에 물으면 이렇게 서로 교차한 표로 옵니다. 칸마다 계수가 적히고
색이 진할수록 함께 움직인 정도가 큽니다. 위 그림에서는 평균 응답시간과
프로세스 CPU 사용률이 0.77 로 가장 높습니다.
"함께 움직였다" 와 "원인이다" 는 다릅니다
상관 분석이 높은 값을 냈다고 한쪽이 다른 쪽의 원인은 아닙니다. 둘 다 세 번째 요인의 영향을 받았을 수도 있습니다.
트래픽이 늘면 CPU 도 오르고 응답시간도 늘어납니다. CPU 와 응답시간의 상관은 높게 나오지만, CPU 를 늘려도 트래픽이 그대로면 응답시간은 안 잡힙니다. 진짜 원인은 트래픽입니다.
그래서 상관 결과는 원인을 확정한 것이 아니라 후보를 좁힌 것으로 읽습니다. 좁힌 다음 그 지표를 다시 자세히 봅니다.
계수를 어떻게 읽는지, 어느 값부터 의미 있는지는 부록: 결과를 읽는 법에서 다룹니다.
고르는 순서 — 상황 먼저, 지표 나중
상관 시나리오는 대부분 두 번 묻습니다.
②를 먼저 묻는 이유는 필요한 대상이 달라지기 때문입니다. 앱 내부면 앱 하나만 고르면 되고, 앱 사이면 둘을 골라야 합니다.
③은 대개 추천 조합이 자동으로 정해집니다. 직접 고르고 싶을 때만 손대면 됩니다.
시나리오에 따라 ②를 건너뛰고 바로 대상을 묻기도 합니다. 아래는 힙 메모리·TPS 상관 분석 을 고른 화면으로, 두 단계 중 첫 단계에서 대상을 먼저 묻습니다.
화살표가 뜻하는 것
지표 조합에 → 와 ↔ 가 섞여 있습니다. 뜻이 다릅니다.
| 표기 | 뜻 | 예 |
|---|---|---|
A → B | 방향을 봅니다. A 가 먼저 움직이고 B 가 따라왔는지 | CPU → 응답시간 |
A ↔ B | 동 조만 봅니다. 어느 쪽이 먼저인지는 묻지 않음 | 스레드 ↔ 트래픽 |
원인을 찾는 중이면 →, 두 지표가 같이 움직이는지 보고 싶으면 ↔ 를 고릅니다.
apm 데이터소스 — 6종
| 시나리오 | 고를 수 있는 상황 |
|---|---|
| 응답 지연 원인 분석 | 앱 내부 원인 분석 → 트래픽·JVM CPU·힙·GC 중 무엇이 응답시간에 영향을 주는가 |
| DB 성능 영향 분석 | 같은 서비스 / 서비스 간 — SQL 응답시간·SQL TPS·커넥션 풀 |
| JVM 메모리 분석 | 힙 예측 · 힙 추세 · 힙 ↔ GC · 인스턴스 간 힙 비교 |
| 트래픽 ↔ 에러율 상관관계 | 동일 앱 내 — 요청 수 → 에러율, 요청 수 → 5xx |
| 힙 메모리·TPS 상관 분석 | 힙·GC·TPS·응답시간 네 가지를 한 번에 |
| MSA 장애 전파 상관 분석 | 동일 앱 장애 전파 — 응답시간 → 에러율 |
짚어 둘 것 둘
JVM 메모리 분석 은 상관만 하지 않습니다. 상황에 힙 예측 과 힙 추세 분석 이
섞여 있습니다. 힙은 세 관점을 같이 봐야 판단이 서기 때문에, 한 시나리오 안에서
예측·추세·상관을 함께 다룹니다.
MSA 장애 전파 상관 분석 은 방법을 다 씁니다. 설명에 이렇게 적혀 있습니다.
"…전체 방법(Pearson·Spearman·CCF·DTW·Granger)으로 분석해 지연→에러 장애 전파 경로를 추적합니다."
다섯 방법이 각각 무엇을 보는지는 부록: 상관은 이렇게 잰다에서 다룹니다. 지금은 여러 각도로 재서 한 방법만 썼을 때 생기는 오판을 줄인다고만 알면 됩니다.
observ 데이터소스 — 5종
| 시나리오 | 고를 수 있는 상황 |
|---|---|
| 응답 지연 원인 분석 (컨테이너) | 앱 내부 / 앱 간 — CPU·메모리·GC → 응답시간, 트래픽 → 리소스 |
| 응답 지연 원인 분석 (Web·WAS) | 같은 호스트 내 — 트래픽·CPU·메모리 → 응답시간, 에러율 ↔ 응답시간 |
| DB 성능 영향 분석 | 같은 서비스 / 서비스 간 — 쿼리 수·레이턴시 → 응답시간, 쿼리 → CPU |
| 쓰레드 풀 부하 분석 | WAS 내부 — 스레드 ↔ 트래픽, 스레드 → 응답시간, 스레드 ↔ 힙 |
| 골든 시그널 종합 분석 | 응답시간·트래픽·에러율·CPU 네 가지를 한 번에 |
응답 지연 원인 분석 이 두 개인 이유는 401 장의
"같은 이름이 두 번 나옵니다" 를 보십시오. 설명 문구에 "컨테이너" 가 있으면 앞쪽,
"Web 서버" 가 있으면 뒤쪽입니다.
언제 무엇을 고르나
| 겪는 일 | 고를 것 |
|---|---|
| 응답이 느린데 어디가 원인인지 모른다 | 응답 지연 원인 분석 — 앱 내부부터 |
| 특정 시간대만 느리다 | 응답 지연 원인 분석 → 트래픽 → 응답시간 |
| DB 를 의심한다 | DB 성능 영향 분석 |
| 메모리가 계속 찬다 | JVM 메모리 분석 (apm) — 예측·추세를 함께 본다 |
| 요청이 몰릴 때만 에러가 난다 | 트래픽 ↔ 에러율 상관관계 (apm) |
| 스레드가 모자란 것 같다 | 쓰레드 풀 부하 분석 (observ) |
| 한 서비스가 멈추니 옆도 느려졌다 | MSA 장애 전파 상관 분석 (apm) |
| 무엇부터 볼지 모르겠다 | 골든 시그널 종합 분석 — 넷을 한 번에 확인한다 |
앱 하나가 아니라 둘을 비교할 때
상황에 "앱 간"·"서비스 간" 이 있는 시나리오는 대상을 둘 고릅니다. 앞 서비스의 지표가 뒤 서비스로 어떻게 전파됐는지 볼 때 씁니다.
호출하는 쪽을 먼저, 호출받는 쪽을 나중에 고르면 → 방향이 자연스럽게 맞습니다.
다음으로
- 결과의 숫자 읽기 — 부록: 결과를 읽는 법
- 다섯 방법의 차이 — 부록: 상관은 이렇게 잰다
- 다른 갈래 — 예측 분석 · 이상 탐지
- 고른 뒤 화면 — 위저드 모드