• E2E / 부하테스트 진행 전 Observability 환경 구성 필요
• 테스트 결과만으로는 장애 및 성능 저하의 원인 확인이 어려움
  • E2E
    • 요청 실패 시 어느 구간에서 실패했는지 확인 필요
  • 부하테스트
    • P95 증가, Error 증가 시 어떤 자원의 병목으로 발생했는지 확인 필요
• 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 자체의 상태 확인

• 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/prometheus Endpoint를 통해 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 : 생성 성공률과 연관

  7.2.1. 주의할점

  • 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)

  1. 가이드북 생성 성공률 감소
  2. AI Error Count 증가 (prometheus)
  3. LLM Timeout(CloudWatch Logs)