실제 현업에서 개발하는 API는 단순히 GET요청도 있지만 인증 등이 들어가고 복잡한 데이터를 POST로 요청하는 경우가 많은데

과연 LLM을 이용해서 대화형으로 사용자가 부하테스트를 할 수 있게 구현이 가능한지 궁금증이 들어 시작을 했다.

문제는 크게 3가지같다.

1. 다양한 데이터를 어떻게 활용하게 할지 ( 예를들어 로그인 api테스트면 여러 ID를 만드는 가입절차까지 스스로 만들게 하는건 어려워보이기 때문에 이미 만들어진 계정을 넘겨줘야 하는데, 어떻게 넘겨줄지)

2. 스크립트를 어떻게 전달할 것인가

    - 스크립트 생성까지 llm이 한다면 검증이 필요한데, 검증은 무조건 스모크테스트처럼 부하를 조금이라도 쏴봐야 한다.

    - 기본적인 스크립트를 줄것인가 ( 그럼 왜 이 llm을 이용하는지에 대한 강점을 확실하게 줘야함 )

3. API을 알려주면 어떻게 llm이 이해를 하고 스크립트를 짤것인가, 또는 만들어진 스크립트를 활용할 것인가

    - 스웨거 json을 이용해야하나?

--개인 메모 -----------

FLOW:  사용자 요청 → LLM 스크립트 생성 → 검증 단계 → 실행 → 결과 보고

검증 단계에서는:

• 문법 검사: k6 스크립트의 문법적 오류 확인
• 안전성 검사: 위험한 코드나 무한 루프 등 확인
• 테스트 실행 가능성 검사: 필수 파라미터 누락 여부 확인

점진적 실행 접근법

• 스모크 테스트 먼저 실행: 생성된 스크립트를 먼저 최소한의 VU(1~2개)로 짧은 시간(5-10초) 실행
• 결과 확인 후 전체 테스트: 스모크 테스트가 성공하면 전체 테스트 실행

템플릿 기반 접근법

• 완전히 자유로운 스크립트 생성 대신, 검증된 템플릿을 사용하고 LLM은 파라미터만 채우는 방식

피드백 루프 구현 ( 이건 랭그래프로 복잡한 구조가 될 듯 )

• 사용자 피드백을 통해 스크립트를 개선하는 메커니즘

실용적인 구현 방안

위 접근법들을 종합하여 다음과 같은 실용적인 구현을 제안합니다:

1. 단계적 접근:
   • 1단계: 템플릿 기반 + 파라미터 추출 (안전하게 시작)
   • 2단계: 제한된 자유도의 스크립트 생성 + 검증
   • 3단계: 완전 자유도의 스크립트 생성 + 강력한 검증
2. 하이브리드 접근법:
   • 핵심 구조는 템플릿 기반으로 유지
   • 동적 부분(페이로드, 검증 로직 등)은 LLM이 생성
   • 생성된 코드는 샌드박스에서 검증 후 통합
3. 사용자 지식 활용:
   • "이 API는 JWT 인증이 필요해" 같은 사용자 힌트 활용
   • 이전에 성공한 테스트 패턴 재활용
4. 점진적 학습:
   • 성공한 스크립트를 데이터베이스에 저장
   • 새로운 스크립트 생성 시 유사한 성공 사례 참조

이 내용은 저의 경험을 통해 개인적으로 정리한 부분입니다. 

다른 사람의 의견과는 다를 수 있습니다.

회사마다 또는 서비스의 규모마다 다를 수 있지만 대고객 서비스를 운영할때 가장 유용하게 본 지표는 서비스의 응답속도입니다.

이러한 응답속도는 tempo를 이용해서 구축할 수 있고, 또는 와탭과 같은 상용 APM을 이용해도 됩니다.

아래와 같은 형태로 제공됩니다.

서비스 운용시 마이크로 서비스가 너무 많으면 데브옵스 엔지니어는 서비스 지연 또는 장애를 어떤 기준으로 딱 봐야할지 기준을 잡기 힘듭니다. 그래서 대고객 서비스라면 우리 서비스를 이루는 모든 마이크로서비스들의 응답속도를 시각화한 대시보드를 보는게 가장 좋습니다.

운영을 하다보면 장애는 항상 패턴을 보입니다. 가장 많이 겪었던 장애포인트는 DB지연 또는 장애, 네트워크 지연, pod 이상, 배포로 인한 장애 정도의 순서였습니다. 

히트맵의 패턴을 몇개 말씀드리면 세로줄, 가로줄 , 무분별한 지연 정도로 볼 수 있었습니다.

장애를 재연할 수 없으니 와탭 홈페이지 도큐먼트의 사진을 예로 설명하겠습니다.

세로줄은 아래와 같이 지속적이지는 않지만 단발성으로 그어지는 패턴이 있고, 어느정도 그림을 그려나가며 세로줄이 그어지기도 합니다.

저는 보통 두번째의 경우가 많았던것 같지만 첫번째는 주로 특정 시간에 어떠한 병목구간이 해결이 되거나 락이 해소되면서 풀리는 상황이며 두번째는 점점 지연이 발생하다가 장애 서비스의 배포등으로 해결되는 상황 등에서 발생했었습니다.

가로줄은 아래와 같이 나타납니다. 이는 보통 타임아웃처럼 무언가에 걸리는 상황이며 이 상황도 지속되는 상황이기에 해당 서비스의 자원(우리쪽이든 외부 서비스쪽이든)에 대해 살펴봐야 합니다. 또는 타임아웃 시간이 적절히 설정되었는지 확인합니다.

아래와 같은 대환장 케이스는 서비스 전반적으로 장애가 전파된 상황이라고 생각이 됩니다. DB모니터링이나 restart pod나 cpu,mem사용률이나 네트워크 장애, 배포이력을 모두 보면서 해결해야 합니다.

위에서 말한것처럼 외부서비스 연동도 많이 되어있는 서비스라면 장애시 내부서비스의 문제인지 외부서비스의 문제인지 파악해야 하며, 외부 서비스들을 전용 ALB등으로 통신하도록 되어있다면 클라우드와치등을 이용하여 그라파나로 시각화한 대시보드도 모니터링 해야 합니다.

모니터링 및 장애 추적은 위와같이 응답속도로 부터 찾아가는게 가장 빠른 방법이라고 생각합니다.

그래서 루틴을 적어보자면.

1. 히트맵 모니터링

2. 응답지연이 발생하는 서비스 찾기 ( 상용 APM들은 히트맵을 클릭하면 해당 API이력들이 연결되도록 지원할 것이며, TEMPO를 이용한다면 복잡하긴 하지만 Data link등을 이용하여 구축이 가능합니다)

3. 서비스를 파악했으면 POD모니터링, 로그 모니터링, 트레이징 모니터링

4. 클라우드 서비스 모니터링 (ALB, WAF등)

POD를 모니터링 하는 경우 보통 CPU, MEMORY, NETWORK, running pod 추이, restart 수 추적,  HPA작동 여부 정도를 모니터링 할 것이며 개인적으로는 cicd연동도 필요하다고 생각합니다. 깃헙 액션을 이용하여 배포를 하는 시스템이면 실제 배포가 이루어 지는 시점을 그라파나 어노테이션으로 대시보드에 표시를 남기고, argocd를 사용한다면 argocd noti기능을 통해 마찬가지로 그라파나로 어노테이션을 보낼 수 있습니다.

이러한 이유는 장애는 배포시점에 나타날 수도 있기 때문에 배포이력을 파악해야 하며, 이상적인 마이크로 서비스는 서비스간 디펜던시가 없는 것이지만 현실적으로 어려운 부분이 많습니다. 우리 서비스를 호출하거나 우리 서비스에서 호출을 하는 마이크로 서비스가 배포되었는지도 우리 서비스의 장애로 연결 될 수 있기 때문에 이러한 배포이력을 시각화하는것도 매우 중요하다고 생각을 합니다.

또한 배포이력을 마이크로 서비스 POD모니터링 대시보드에 표시하지 않는다면 블루그린을 배포하는 서비스의 경우 배포시 POD의 수가 증가하는데 배포이력이 시각화되어있지 않으면 POD가 왜 수가 증가했는지 추가적인 해석이 필요하기 때문에 마이크로 서비스가 많아질수록 모니터링시 직관적인 해석이 아니라 노력이 들어가는 해석이 필요합니다.

로그모니터링은 에러로그 또는 개발자라면 개발자가 남긴 중요한 로그를 검색하도록 쿼리를 구성하고 이 카운팅을 시각화해놓는 것이 좋습니다. 또한 알람도 설정을 해야 합니다. 트레이싱 또한 매우 중요합니다. 마이크로 서비스간 호출 실패 또는 성공을 시각화 하는것은 장애를 고치는 것에 있어 효과적이며, 더불어 네트워크 장애가 있었는지 시스템을 추적해 나가는것에도 많은 도움이 됩니다.

 tempo를 이용하여 서비스 그래프를 구축하면 아래와 같이 서비스간 호출을 시각화 할 수 있습니다. 이는 상용 APM에서는 더욱 많은 기능을 제공하며 토폴로지 맵 등의 이름으로 불리기도 합니다.

사실 이정도만 구축이 되었다면 어느정도 모니터링은 다 된다고 생각합니다. 인프라 운영자의 입장에서는 추가적으로 하나 더 좋은 대시보드가 있습니다. AWS를 사용한다면 클라우드 와치를 이용하여 우리 서비스의 진입점부터 각 단계의 ALB등의 호출건수 등도 모니터링하며 우리 서비스가 Top-down으로 통신하는 구간에서 어느 구간이 이상한지 한눈에 파악할 수 있기 때문에 굉장히 효과적으로 서비스 가시성을 확보할 수 있습니다.

그리고 블루그린 배포를 하면 POD가 일시적으로 증가합니다. 이때 장애가 날 수 있는 포인트는 데이터베이스 입니다. 커넥션 관리가 중요하며 커넥션 관련 장애가 날 수 있기 때문에 블루 그린 배포를 하더라고 로직상 데이터베이스 커넥션관리를 잘 해줘야 하며, AWS RDS proxy같은 서비스를 적극 활용해야 합니다. 이러한 커넥션 모니터링도 당연히 운영해야 합니다.

그리고 비용최적화의 한 부분으로 호출구조를 변경하여 네트워크사용으로 인한 비용절감이 있습니다. 또는 API 캐싱전략을 사용하여 DB호출을 줄이는 방법도 있습니다. 이러한 개선을 해나갈때 도움이 되는 부분중 하나는 호출되는 API리스트를 시각화하며, API별 호출건수, 지연시간 등도 시각화를 하여 어떠한 개선을 해나가야 할 지 정하는것이 좋습니다.

이러한 전체적인 흐름을 통해 각자 서비스에 맞게 대시보드를 구축하면 됩니다. 어떻게 시각화를 하고 어떻게 대시보드 티어늘 나누고 등은 노하우의 영역입니다.

마이크로서비스 모니터링 가이드

모니터링 전략 구성 요소

기본 성능 지표 설정

• 각 서비스별 핵심 성능 지표(KPI) 식별 및 추적
• 정상 동작 이해를 위한 기준 데이터 수집
• 비즈니스 요구사항에 맞는 현실적인 성능 목표 설정
• 서비스 응답 시간, 오류율, 처리량 등 핵심 지표 모니터링

알림 및 통지 시스템 구축

• 중요 지표에 대한 임계값 정의
• 단계별 알림 시스템 구현:
  • 잠재적 문제에 대한 경고 알림
  • 즉각적인 조치가 필요한 중요 알림
• PagerDuty 또는 OpsGenie와 같은 도구를 사용한 온콜 관리

분산 추적 구현

• 추적 솔루션 선택 (예: SigNoz, Zipkin, Tempo)
• 서비스 계측을 통한 추적 데이터 생성
• 로그 및 지표와 추적 데이터 연계
• 고유 요청 ID를 사용하여 서비스 간 요청 추적

도구별 활용 방안

Prometheus와 Loki 통합 활용

• Prometheus: 실시간 모니터링, 애플리케이션 계측, 시계열 데이터 분석
• Loki: 비용 효율적인 로그 저장, 텍스트 기반 디버깅 정보, 사고 후 분석
• Grafana: Prometheus 지표와 Loki 로그를 통합 시각화

쿠버네티스 모니터링

• Kubernetes Monitoring Helm 차트 활용
• 클러스터 이름을 정적 레이블로 지정하여 모든 로그에 첨부
• 클러스터 이벤트 및 Pod 로그 수집 활성화
• 서비스 메시(Istio, Linkerd)와 통합하여 서비스 간 통신에 대한 상세 정보 확보

로그 관리

• 서비스 전반에 걸친 로그 형식 표준화
• 중앙 집중식 로깅 시스템 구현 (LGTM 스택, ELK 스택)
• 스토리지 비용 관리를 위한 로그 보존 정책 구현

그라파나를 이용한 쿠버네티스 모니터링 지표

클러스터 수준 지표

• 클러스터 CPU 사용량: 사용 vs 총량
• 클러스터 메모리 사용량: 사용 vs 총량
• 클러스터 파일 시스템 사용량: 사용 vs 총량
• 클러스터 네트워크 I/O 압력
• 클러스터 상태 (파드 상태, 파드 재시작, 파드 스로틀링)
• 노드, 파드, 컨테이너 개요

노드 수준 지표

• 마스터 노드 상태 확인 - API 서버, 스케줄러, 컨트롤러 등
• 마스터 노드 성능 저하
• 파드 서비스를 위한 가용 노드 수
• 노드 CPU 사용률 (node_cpu_usage_seconds_total)
• 노드 메모리 사용량 (node_memory_working_set_bytes)
• 파드 배치를 위한 노드 디스크 공간
• 노드 디스크 I/O 사용량
• 노드 네트워크 트래픽 (송수신)
• 노드 네트워크 트래픽 오류
• 노드 네트워크 트래픽 드롭
• 준비되지 않은 노드 수 (node_collector_unhealthy_nodes_in_zone)

파드/컨테이너 수준 지표

• 파드 리소스 할당
• 과소 또는 과대 프로비저닝된 파드
• 클러스터 내 실행 중인 파드 수
• 클러스터 내 정상 vs 비정상 파드
• 스로틀된 컨테이너 비율
• 컨테이너 재시작 횟수
• 실패 또는 대기 상태의 영구 볼륨 수
• 컨테이너 CPU 및 메모리 사용률
• 파드 CPU 사용률 (pod_cpu_usage_seconds_total)
• 파드 메모리 사용량 (pod_memory_working_set_bytes)
• 대기 중인 파드 (scheduler_pending_pods)
• 스케줄링 시도 (scheduler_pod_scheduling_attempts)
• 프로브 카운트 (prober_probe_total)

애플리케이션 성능 지표

• 요청 속도: 초당 처리된 요청 수
• 오류 율: 실패한 요청의 비율
• 지연 시간: 요청 처리에 소요된 시간
• API 서버 요청 지연 시간 (apiserver_request_duration_seconds)
• 메트릭 스크래핑 오류 (resource_scrape_error)

모니터링 모범 사례

자동화된 모니터링 솔루션

• 인프라 확장에 맞춰 모니터링 솔루션 자동화
• 명확한 인시던트 대응 프로토콜 수립 및 팀 교육 제공
• 자동 계측 라이브러리 및 에이전트 사용

메트릭, 로그, 트레이스 상관관계 분석

• 시스템 동작에 대한 다양한 관점 제공
• 더 빠른 디버깅 및 근본 원인 분석 가능
• 로그, 트레이스, 메트릭 간 쉬운 상관관계 분석을 위한 컨텍스트 로깅 구현

증상 기반 알림 설정

• 단순 임계값이 아닌 증상에 기반한 알림 설정
• 지연 시간 증가, 오류율 급증, 포화도 등 모니터링

컨테이너 내부 모니터링

• 컨테이너가 실행 중인지 뿐만 아니라 내부 프로세스 상태 확인
• 프로세스 상태, 메모리 누수, 문제를 나타내는 로그 등 고려
• 상태 확인 및 준비 프로브 구현 (/health 및 /ready 엔드포인트)

개발 단계부터 모니터링 통합

• 초기 단계에서 계측 추가
• 개발 중 알림 임계값 정의
• 배포 전 관찰 가능성 테스트
• 서비스 설계에 관찰 가능성 요구사항 포함

최우선 조건 : 사용자의 복잡한 질문,여러 툴을 이용해야해도 완성도 있게 대답해야 한다.

1. 오케스트레이터 노드: 사용자 입력을 최초로 받아 처리 방향을 결정하는 중앙 제어 장치
2. 플래닝 노드: 복잡한 작업을 여러 단계로 분해하여 실행 계획을 수립
3. 전문 에이전트 노드들: 각각 특정 도구나 서비스에 특화된 8개의 에이전트 (그라파나, 로키, 템포, 아르고시디 등)
4. 밸리데이션 노드: 결과의 완성도와 정확성을 검증
5. 응답 노드: 최종 결과를 사용자 친화적으로 요약하여 제공

보완하면 좋을 만한 부분들:

• 컨텍스트 관리: 사용자와의 대화가 이어질 때 이전 대화 컨텍스트를 어떻게 유지할지 고려가 필요함. 예를 들어 "그 중에서 메모리 사용량이 가장 높은 것만 보여줘"와 같은 후속 질문에 대응할 수 있어야 함 -> 메모리세이버 등 이용
• 에이전트 선택 메커니즘: 오케스트레이터가 어떤 에이전트를 호출할지 결정하는 로직이 중요. -> 프롬프트 강화
• 실패 처리 메커니즘: 특정 에이전트가 실패하거나 정보를 가져오지 못할 경우에 대한 대처 방안이 필요.-> 고민 필요
• 사용자 피드백 루프: 사용자가 결과에 만족하지 못할 경우 시스템이 어떻게 개선 방향을 찾을지에 대한 고려가 필요 -> 고민 필요
• 병렬 처리: 여러 에이전트를 동시에 실행하여 응답 시간을 단축하는 방법을 고려해 볼 수 있음 -> 멀티 처리 적용
• 중간 결과 제공: 복잡한 질문의 경우 최종 답변까지 시간이 오래 걸릴 수 있으므로, 중간 진행 상황이나 부분 결과를 제공하는 기능이 유용할 수 있음 -> add 메세지를 구현하고 st.session_state를 이용하여 화면에 실시간 출력
• 에이전트 확장성: 새로운 에이전트를 쉽게 추가할 수 있는 구조인지 확인. 향후 새로운 도구나 서비스를 통합할 필요가 있을 수 있음 -> 고민필요

코드 구현은 차차 할 예정, 랭그래프, 랭체인, 제미나이 예정