4.3. 예측 분석
이대로 가면 언제 한계에 닿는가 — 6종
"언제 늘려야 하나" 를 물을 때 쓰는 갈래입니다. 지금까지의 추세를 이어 그려 앞으로 어떻게 될지를 보여 줍니다.
용량 계획을 세우거나, 자원을 늘릴 시점을 잡을 때 씁니다.
무엇을 답해 주나
- 앞으로의 값 — 추세를 이은 선
- 얼마나 확신하는가 — 선 위아래로 퍼진 신뢰구간 띠
- 지금 추세라면 언제 한계에 닿는가
세 계열이 한 차트에 함께 그려집니다. 왼쪽이 지금까지의 실제값, 오른쪽 끝이 예측값이고 그 둘레를 감싼 것이 신뢰구간 띠입니다. 어느 선이 무엇인지는 아래 범례로 구분합니다.
띠가 넓으면 확신이 낮다는 뜻입니다. 좁은 띠일수록 믿을 만합니다. 읽는 법은 부록: 결과를 읽는 법에서 다룹니다.
근거 구간은 길어야 3일입니다
예측은 고른 시간 범위의 데이터만 보고 그립니다. 고를 수 있는 것은 넷입니다.
1시간 · 6시간 · 1일 · 3일
3일보다 긴 근거는 쓸 수 없습니다. 이것이 예측 결과를 읽을 때 가장 먼저 알아야 할 제약입니다.
| 알고 싶은 것 | 이 기능이 맞나 |
|---|---|
| 오늘 밤 힙이 찰까 | 맞습니다 |
| 이번 주말 트래픽을 견딜까 | 맞습니다 |
| 다음 분기 서버를 몇 대 더 살까 | 맞지 않습니다 — 근거가 짧습니다 |
3일치 추세로 한 달 뒤를 말하면 숫자는 나오지만 근거가 없습니다. 장기 용량 계획은 이 기능이 아니라 보관된 지표를 따로 봐야 합니다.
또 하나. 추세가 이어진다고 가정합니다. 배포·이벤트·트래픽 급변처럼 추세를 끊는 일이 예정돼 있다면 예측은 빗나갑니다.
observ 데이터소스 — 4종
| 시나리오 | 대상 | 보는 지표 |
|---|---|---|
| 리소스 사용량 예측 (컨테이너) | 애플리케이션 | 컨테이너 CPU · 메모리 |
| 리소스 사용량 예측 (Web 서버) | 애플리케이션 | Web 서버 CPU · 메모리 |
| 노드 상태 예측 | 노드 | 노드 CPU · 메모리 · 로드 평균 |
| 디스크 고갈 예측 | 노드 | 디스크 사용률 |
이름이 같은 리소스 사용량 예측 두 개는 설명 문구로 가립니다. "컨테이너" 가
나오면 앞쪽, "Web 서버" 가 나오면 뒤쪽입니다 (401 장 참고).
노드 상태 예측 을 고른 화면입니다. 대상이 노드라 앱이 아니라 노드를 고릅니다.
디스크 고갈 예측이 특별한 이유
넷 중 이것만 결과가 곧바로 위험으로 이어집니다. 쿠버네티스는 노드 디스크가 차면 Pod 를 내보냅니다(Eviction). 자원이 모자라 느려지는 것과 달리 서비스가 멈춥니다.
디스크는 CPU 나 메모리와 달리 저절로 내려가지 않으므로, 추세선이 위를 향하면 대개 그대로 갑니다. 예측이 맞을 확률이 가장 높은 시나리오입니다.
apm 데이터소스 — 2종
apm 쪽 둘은 고른 뒤 무엇을 예측할지 한 번 더 묻습니다.
| 시나리오 | 대상 | 되묻는 것 |
|---|---|---|
| 호스트 자원 예측 | 노드 | CPU 예측 · 메모리 예측 |
| 앱 자원 사용량 예측 | 애플리케이션 | JVM 힙 사용률 예측 · 프로세스 CPU 예측 |
observ 쪽은 CPU 와 메모리를 함께 보고, apm 쪽은 하나씩 봅니다.
둘 다 보고 싶으면 두 번 물어야 합니다.
어느 쪽을 고르나
- 호스트 자원 예측 — 서버 장비가 모자란지. 그 위에 무엇이 실행 중이든 합산입니다
- 앱 자원 사용량 예측 — WAS 인스턴스 하나가 모자란지
같은 서버에 WAS 가 여럿이면 앱 쪽은 여유가 있는데 호스트는 여유가 없는 상황이 나옵니다. 그럴 때는 호스트를 봅니다.
예측 갈래가 아닌 시나리오에도 예측이 들어 있습니다
시나리오 갈래가 예측 인 것만 예측을 하는 것은 아닙니다.
apm 의 JVM 메모리 분석 은 갈래가 상관 인데, 되묻는 항목에
힙 예측 과 힙 추세 분석 이 들어 있습니다. 힙은 세 관점을 같이 봐야
판단이 서기 때문입니다.
힙이 걱정이라면 예측 갈래의 앱 자원 사용량 예측 대신 JVM 메모리 분석 을 고르는
편이 낫습니다. 예측·추세·상관을 한 번에 봅니다.
언제 무엇을 고르나
| 겪는 일 | 고를 것 |
|---|---|
| 디스크가 차 간다 | 디스크 고갈 예측 (observ) |
| 노드를 더 늘려야 하나 | 노드 상태 예측 (observ) |
| 컨테이너 자원 요청량을 조정하려 한다 | 리소스 사용량 예측 (컨테이너) |
| 서버 장비가 버틸까 | 호스트 자원 예측 (apm) |
| 힙이 계속 찬다 | JVM 메모리 분석 (apm) — 예측·추세·상관을 함께 |
| WAS 하나의 CPU 가 걱정이다 | 앱 자원 사용량 예측 → 프로세스 CPU |
결과를 받은 뒤
예측은 언제 를 알려 주지 그 원인을 알려 주지는 않습니다.
힙이 6시간 뒤 90% 에 닿는다 → 왜 차고 있는지는 따로 봐야 합니다
원인을 찾으려면 상관 분석으로 넘어갑니다. 예측으로 시점을 잡고, 상관으로 무엇이 그 지표에 영향을 주는지 좁히는 순서가 편합니다.
다음으로
- 띠와 숫자 읽는 법 — 부록: 결과를 읽는 법
- 어떻게 계산하나 — 부록: 예측은 이렇게 계산한다
- 원인 찾기 — 상관 분석
- 다른 갈래 — 이상 탐지