Repository navigation
Observability
xowns_j edited this page Sep 30, 2026
·
1 revision
- E2E / 부하테스트 진행 전 Observability 환경 구성 필요
- 테스트 결과만으로는 장애 및 성능 저하의 원인 확인이 어려움
- E2E
- 요청 실패 시 어느 구간에서 실패했는지 확인 필요
- 부하테스트
- P95 증가, Error 증가 시 어떤 자원의 병목으로 발생했는지 확인 필요
- E2E
- Metric / Log를 수집하여 서비스 내부 상태 확인
- E2E와 부하테스트에서 공통으로 사용
### **진행 순서**
1. Observability 구성
2. E2E 테스트
3. Fake LLM 구성
4. 부하테스트
5. 병목 분석
6. 개선
7. 재테스트
- Metric
- 시스템의 상태 및 변화 확인
- CPU / Memory
- JVM
- HTTP
- DB Connection
- AI 처리시간 등
- Log
- 실제 오류 내용 확인
- Exception
- Timeout
- Connection Error 등
- AWS Resource Metric
- AWS Resource 자체의 상태 확인
| 대상 | 도구 | 역할 |
|---|---|---|
| Application / System Metric | Prometheus | Backend / AI / DB 상태 확인 |
| Application Log | CloudWatch Logs | Backend / AI Error 확인 |
| AWS Resource Metric | CloudWatch Metrics | EC2 / CloudFront 상태 확인 |
- Prometheus
- Application / System Metric 수집 및 조회
- CloudWatch Logs
- Application Log 수집 및 조회
- CloudWatch Metrics
- AWS Resource Metric 확인
- 현재 목적은 지속적인 Dashboard 운영보다 테스트 중 특정 시간대의 Metric 확인 및 병목 분석
- V1에서는 빠른 구축 및 운영 단순화 우선
- Backend / AI Server / DB의 Metric을 한 곳에서 수집 가능
- 한 요청이 여러 시스템을 거치는 우리 서비스에 어느 구간이 병목인지 비교하기 쉬워짐
- 자체 Web UI 제공
- 따라서 V1에서는 별도의 Grafana 환경을 구성하지 않고 Prometheus를 사용
- 추후 지속적인 Metric 모니터링 및 통합 Dashboard 필요성이 커질 경우 Grafana 도입 고려
- 현재 AWS 환경에서 서비스 운영
- 별도의 Logging Stack 구축 시 추가적인 구축 및 운영 필요
- CloudWatch Logs를 이용하여 Backend / AI Server의 Log 확인 가능
⇒ 기존의 환경 활용하며 구축 범위를 줄일 수 있기에 현 상황과 잘 맞는다 판단
- V1에서는 별도의 PLG Stack을 구성하지 않고 CloudWatch Logs 사용
PLG Stack ?
- Promtail
- Log 수집
- Loki
- Log 저장 및 조회
- Grafana
- 시각화
⇒ 현재 V1에서는 해당 환경을 별도로 운영할 필요성이 낮다고 판단
⇒ 상시 모니터링 플랫폼이 목표가 아니라 문제 발생 지점과 원인을 찾는것이 목표이기에
- EC2 / CloudFront 등 AWS Resource 자체의 상태 확인
- AWS에서 기본 제공되는 CloudWatch Metrics 활용
- 별도의 Metric 수집 환경을 추가하지 않고 기존 AWS 환경 활용
- Application / System Metric 확인 ⇒ 어느 시스템에서 이상이 발생했는지 확인
- Prometheus ⇒ BE, AI server, MySQL
- 실제 Exception / Timeout 등의 오류 확인 ⇒ Metric 이상 발생 시 동일 시간대의 Log 확인
- CloudWatch Logs ⇒ BE, AI Server
- AWS Resource 상태 확인
- CloudWatch Metrics ⇒ EC2, CloudFront
-
Backend는 모든 일반 API 요청을 처리하고, 가이드북 생성에서도 AI Server와 DB 사이의 중심 역할을 함.
⇒ 따라서 Backend의 상태가 나빠지면 네 가지 SLI 모두에 영향을 줄 수 있음.
-
Spring Boot의 JVM, HTTP, HikariCP 등의 Application Metric을 Micrometer로 수집하고, Actuator의
/actuator/prometheusEndpoint를 통해 Prometheus가 수집할 수 있도록 제공
- System
- ⇒ CPU, Memory, Thread
- EC2/Backend 자체의 처리 자원이 한계에 도달했는지 확인
-
JVM
- ⇒ Heap, Non-Heap 메모리 사용량, GC 횟수, Thread(JVM 내부 스레드)
-
HTTP
- Request Count, Request Duration, Status Code, Error
-
HikariCP(히카리 커넥션풀)
-
백엔드에서 mySQL에 접근할때 커넥션풀을 사용함
-
부하가 증가하면 동시에 DB커넥션 요구하는 요청도 증가
-
부하 증가 시 API Latency와 함께 HikariCP / JVM / System Metric 확인
- API P95 증가
- Hikari Active가 Max에 근접
- Hikari Pending 증가
- 동일 시간대 DB Connection 증가
⇒ Connection Pool 또는 DB 처리 성능을 병목 후보로 확인
(DB연결을 만들고 끊는 비용 발생 줄이기 위해 커넥션을 만들어놓고 필요할때 쓰는게 CP)
-
- AI Server는 일반 API보다 특히 가이드북 생성 성공률과 생성시간에 직접적으로 연결됨.
- 가이드북 생성이 느려졌다고 해서 무조건 LLM이 느린 것은 아님 (BE가 문제일 수도)
-
System
- ⇒ CPU, Memory, Thread
- EC2/Backend 자체의 처리 자원이 한계에 도달했는지 확인
-
HTTP
- Request Count, Request Duration, Active Request(동시활성), Error
- duration : 생성시간 / Error : 생성 성공률과 연관
- duration은 전체 생성시간을 체크하므로 세분화 해야함( Req, llm call, post process)
-
Backend Metric과 함께 확인
- API P95 증가
- Hikari Active Max 도달
- Hikari Pending 증가
- DB Connection 증가
- Query 처리 지연
- latency가 DB때문인지 확인할 수 있어야 함
- Connection / Active Connection
- Query처리량, 처리 상태
- DB컨테이너 리소스
-
Prometheus가 어디가 이상한가 를 찾는 역할
⇒ CloudWatch Logs는 그래서 실제로 무슨 오류가 발생했는가 를 확인하는 역할
ex)
- 가이드북 생성 성공률 감소
- AI Error Count 증가 (prometheus)
- LLM Timeout(CloudWatch Logs)