서버 성능 병목 구간 탐지를 위한 CI/CD 파이프라인 설계: 코드 배포 전 API 성능 및 부하 테스트를 통한 사전 문제 탐지 및 방지 방안

[trueS2]

1. 문제 정의 및 목적 설정

먼저 성능 병목 현상이 발생하는 이유와 이를 CI/CD 파이프라인에서 미리 탐지하는 것의 중요성을 이해하는 것이 핵심이다.

• 성능 병목이란? 서버나 시스템에서 특정 자원(CPU, 메모리, I/O 등)이 과도하게 사용되거나, 잘못 설계된 코드나 데이터 흐름으로 인해 성능이 저하되는 현상이다.
• 이 딥다이브의 목적: 서버가 성능 문제로 인해 장애가 발생하기 전에, CI/CD 파이프라인에서 이를 사전에 탐지하고 해결책을 제시하는 프로세스 설계.

2. 성능 병목에 대한 심층 이해

병목 현상이 발생할 수 있는 여러 시나리오와 원인에 대해 학습해야 한다.

• 서버 병목의 주요 원인:

  • 과부하로 인한 CPU 사용률 증가
  • 메모리 누수나 과도한 메모리 사용
  • 디스크 I/O 지연
  • 네트워크 대역폭 문제
  • 동시성 문제로 인한 레이스 컨디션

• 일반적인 성능 문제 탐지 방법:

  • API 응답 시간이 느려지는 시점
  • 고부하 시 처리량 감소
  • 타임아웃, HTTP 5xx 에러 발생 빈도 증가

3. CI/CD 파이프라인 개요

CI/CD 파이프라인 내에서 성능 및 부하 테스트를 위한 핵심 단계와 전략을 설계한다.

• CI/CD 기본 단계:

  1. 코드 푸시 → 자동화된 빌드 및 유닛 테스트
  2. 통합 테스트 → API 성능 및 부하 테스트
  3. 성능 지표 분석 → 결과에 따른 배포 결정

• 테스트 위치:

  • 통합 테스트 이후: 기본 테스트 통과 후 성능 및 부하 테스트가 진행되도록 설정.
  • 스테이징 환경에서 테스트: 실제 프로덕션과 유사한 환경에서 성능 테스트를 실행해야 한다.

4. 도구 선택 및 분석

성능 테스트와 부하 테스트를 효과적으로 수행할 수 있는 도구를 선택한다. 선택한 도구들의 장단점, 사용법 등을 심층적으로 분석해 파이프라인에 맞게 설정하는 과정을 딥다이브한다.

• 성능 테스트 도구:

  • k6: 성능 테스트와 부하 테스트를 함께 지원하는 경량화된 도구. 자바스크립트 기반 시나리오 작성 가능.
  • Gatling: 고성능 부하 테스트 도구로, 성능 테스트 자동화 및 상세한 리포트 제공.
  • Apache JMeter: 대규모 부하 시뮬레이션을 위해 많이 사용하는 도구. HTTP, FTP, JDBC 등을 지원.

• 모니터링 및 로그 도구:

  • Prometheus & Grafana: 실시간 모니터링과 성능 시각화 도구. CI/CD와 연동해 API 성능 지표를 지속적으로 관찰 가능.
  • ELK 스택: Elasticsearch, Logstash, Kibana를 사용해 성능 데이터를 수집하고, 이를 기반으로 분석.

5. API 성능 및 부하 테스트 자동화

성능 테스트와 부하 테스트를 자동화하는 구체적인 방법을 연구하고, 이를 CI/CD 파이프라인에 통합하는 방법을 깊이 있게 탐구한다.

• 성능 테스트 자동화:

  • k6나 Gatling 같은 도구를 사용해 API의 응답 시간, 처리량, 에러율 등을 테스트하는 스크립트를 작성한다.
  • 다양한 시나리오를 설계해 API가 다양한 부하 조건에서 어떻게 동작하는지 분석한다.
  • API 경로별로 성능을 측정해 병목이 발생할 수 있는 경로를 탐지한다.

• 부하 테스트 자동화:

  • JMeter나 Locust 같은 도구를 사용해 대규모 사용자를 시뮬레이션하고, 부하 테스트를 자동화한다.
  • 동시에 많은 요청을 처리할 때 API 서버의 CPU, 메모리, 네트워크 사용률을 모니터링하고, 병목 현상을 감지한다.

6. 병목 현상 탐지 및 경고 시스템

CI/CD 파이프라인 내에서 병목을 탐지한 후 개발자나 운영자가 빠르게 대응할 수 있도록 자동화된 경고 시스템을 설정한다.

• 알림 시스템 설정:

  • 슬랙, 이메일, 혹은 다른 알림 도구와 연동해 성능 테스트에서 실패하거나 특정 임계치를 초과하면 자동으로 알림이 발생하도록 설정한다.
  • 성능 지표와 함께 문제가 발생한 API 경로, 테스트 실패 원인 등을 포함한 자동 보고서를 생성한다.

• 모니터링과 데이터 분석:

  • 테스트 결과를 Grafana 대시보드를 통해 시각화하고, 병목이 발생하는 구간을 실시간으로 모니터링한다.
  • 이상 징후가 발생했을 때 이를 분석하고, 성능이 떨어지는 시점을 정밀하게 파악하는 메커니즘을 설계한다.

7. 실제 프로젝트 적용 및 실험

이론적 딥다이브만으로는 실제 문제를 해결하기 어렵기 때문에, 실제 CI/CD 파이프라인에 성능 테스트를 적용하고 실험하는 과정이 필요하다.

• 스테이징 환경에서 시뮬레이션:

  • 성능 테스트와 부하 테스트를 실제 프로젝트의 스테이징 환경에 적용하고, 그 결과를 분석한다.
  • 성능 저하가 발생했을 때 이를 어떻게 해결할 수 있을지 구체적으로 실험하고, 성능 개선을 위한 피드백 루프를 설계한다.

• 실제 병목 사례 분석:

  • 실제로 성능 병목 현상이 발생했던 사례를 바탕으로 병목 탐지 시스템이 이를 어떻게 탐지하고 해결할 수 있었는지 사례 연구를 진행한다.

8. 최적화 및 개선 방안

딥다이브의 마지막 단계는 탐구한 내용을 기반으로 CI/CD 파이프라인을 최적화하고, 지속적인 성능 개선 전략을 제시하는 것이다.

• 성능 테스트 최적화:

  • 성능 테스트 시나리오를 반복적으로 개선해 실제 사용 사례에 더욱 가까운 테스트를 만들고, 테스트 속도 및 효율성을 개선한다.

• 성능 병목 대응 전략:

  • 병목 구간을 탐지한 후 이를 해결하기 위한 최적화 전략을 설계한다. 예를 들어, 데이터베이스 쿼리 최적화, 캐싱 전략, 코드 최적화 등을 통해 병목을 해결할 수 있다.

---

2024.09.05

성능 병목에 대한 심층 이해

병목 현상이란?

병목 현상은 시스템의 성능이 특정한 부분이나 자원에 의해 제한을 받는 상황을 의미한다.
서버나 네트워크, 데이터베이스, 애플리케이션 가은 시스템에서 병목이 발생하면 해당 시스템의 전반적인 성능이 저하된다.

병목 현상이 발생하는 주요 원인

CPU 사용률 증가

CPU가 처리해야 할 작업이 너무 많아 처리 속도가 저하될 때 병목 현상이 발생한다.
이는 주로 애플리케이션에서 다량의 연산이 필요한 작업이 쌓일 때 발생한다.
비효율적인 알고리즘, 병렬 처리 부족, 불필요한 반복 작업 등이 CPU의 과부화를 유발할 수 있다.

메모리 누수 및 과도한 메모리 사용

메모리 누수란 애플리케이션이 필요 이상으로 메모리를 할당한 후, 이를 해제하지 않는 상황을 말한다.
메모리가 점차 고갈되면 시스템은 메모리를 확보하기 위해 많은 시간을 소비하게 되고, 이로 인해 성능이 저하된다.
자바, C/C++ 등에서 메모리 관리가 잘못된 경우 발생하며, 특히 객체나 데이터가 계속해서 생성되지만 제대로 해제되지 않을 때 발생한다.

디스트 I/O 지연

하드 디스크나 SSD와 같은 저장 장치에서 데이터를 읽고 쓰는 속도가 느릴 때 발생하는 병목이다.
디스크 I/O는 데이터베이스 쿼리나 파일 입출력 작업에서 중요한 역할을 한다.
과도한 파일 접근, 디스크의 물리적 결함, 비효율적인 데이터 구조 등이 디스크 I/O 병목의 주요 원인이다.
특히 대용량 데이터베이스의 비효율적인 쿼리가 디스크 I/O 병목을 유발할 수 있다.

네트워크 대역폭 문제

네트워크 트래픽이 많거나 대역폭이 제한적일 때, 데이터 전송이 지연되며 병목이 발생할 수 있다.
특히 클라우드 기반 애플리케이션에서는 네트워크 라우터 문제, 불필요한 네트워크 트래픽 등이 원인이 될 수 있다.

동시성 문제와 레이스 컨디션

동시성 문제가 발생할 때 여러 프로세스나 스레드가 같은 자원에 동시에 접근하려고 할 때 병목이 발생할 수 있다.
이때 레이스 컨디션이 발생하면, 자원에 대한 비정상적인 경쟁으로 인해 시스템이 성능이 저하된다.
적절한 동기화가 이루어지지 않거나, 다중 스레드 프로그램에서 자원 관리가 제대로 되지 않았을 때 발생한다.

병목 현상의 종류

하드웨어 병목

하드웨어 성능이 한계에 도달해 발생하는 병목이다. 대표적인 하드웨어 병목 요소로는 CPU, 메모리, 디스크, 네트워크 카드 등이 있다.

• CPU 병목: CPU 사용률이 100%에 도달했을 때 다른 작업을 처리할 수 없는 상태.
• 메모리 병목: 메모리 부족으로 인해 스왑(swap)이 발생하고, 성능이 급격히 떨어지는 상태.
• 디스크 병목: 디스크 읽기/쓰기 작업이 과도해 디스크 I/O가 매우 느려지는 상태.
• 네트워크 병목: 네트워크 대역폭 부족으로 인해 데이터 전송 속도가 느려지는 상태.

소프트웨어 병목

소프트웨어 설계나 구현에서 발생하는 병목으로, 비효율적인 알고리즘, 코드 최적화 부족, 데이터베이스 쿼리 문제 등이 여기에 포함된다.

• 알고리즘 병목: 비효율적인 알고리즘이 특정 상황에서 과도한 연산을 요구하는 경우.
• 데이터베이스 병목: 비효율적인 쿼리 또는 적절한 인덱스가 없을 때 데이터베이스의 성능이 떨어지며 발생.
• 동시성 병목: 여러 프로세스나 스레드가 동시에 자원에 접근할 때 발생하는 문제.

병목 현상이 일어난다면?

병목 현상이 발생하면 시스템의 처리 속도가 급격하게 떨어지고, 특정 작업이 지연되거나 전체 시스템 성능이 저하될 수 있다. 병목이 지속되면 서버가 응답하지 않거나 애플리케이션의 성능이 크게 떨어져 사용자 경험에 심각한 영향을 미칠 수 있다.

병목 해결 방안

• CPU 병목 해결: 비효율적인 코드나 연산을 최적화하거나, 멀티스레드 프로그래밍을 적용해 병렬 처리를 개선한다. 필요한 경우 더 높은 성능의 CPU로 업그레이드한다.
• 메모리 병목 해결: 메모리 누수를 해결하고, 캐싱 전략을 도입하거나 필요한 경우 더 큰 메모리 용량을 제공한다.
• 디스크 I/O 병목 해결: 데이터베이스 쿼리 최적화, 캐싱을 도입하거나 SSD 등 빠른 저장 장치로 업그레이드한다.
• 네트워크 병목 해결: 네트워크 대역폭을 확장하거나, 트래픽을 최적화하고 불필요한 데이터 전송을 줄인다.

---

2024.09.12

• [https://trues2.tistory.com/24 ]

CI/CD 파이프라인 개요

CI/CD 파이프라인 내에서 성능 및 부하 테스트를 설계하는 것은 애플리케이션이 배포되기 전에 성능 문제를 사전에 탐지하는 중요한 과정이다. 이를 통해 시스템이 과부하 상황에서도 안정적으로 작동할 수 있는지 확인할 수 있으며, 최종 배포 결정에도 큰 영향을 미친다. 이 글에서는 CI/CD 파이프라인 내에서 성능 및 부하 테스트를 위한 핵심 단계와 그에 따른 전략을 살펴보겠다.

CI/CD 기본 단계

성능 및 부하 테스트를 CI/CD 파이프라인에 통합하기 위해, 전체적인 파이프라인 흐름을 먼저 이해해야 한다. CI/CD 파이프라인은 개발자가 코드를 저장소에 푸시하는 순간부터 시작하여, 코드가 프로덕션 환경에 안전하게 배포될 때까지의 모든 과정을 자동화한다. 이를 위한 주요 단계는 다음과 같다:

1. 코드 푸시 → 자동화된 빌드 및 유닛 테스트:

   • 개발자가 코드를 Git 저장소에 푸시하면, CI/CD 파이프라인이 자동으로 트리거된다.
   • 이 단계에서는 코드가 정상적으로 빌드되고, 유닛 테스트가 자동으로 실행되어 코드가 예상대로 작동하는지 확인한다.
   • 빌드와 유닛 테스트가 성공적으로 완료되면 다음 단계로 넘어간다.

2. 통합 테스트 → API 성능 및 부하 테스트:

   • 통합 테스트 단계에서는 애플리케이션의 여러 모듈이 서로 연계되어 제대로 작동하는지 검증한다.
   • 통합 테스트가 통과되면, API 성능 및 부하 테스트가 이어서 실행된다. 이 단계는 CI/CD 파이프라인 내에서 매우 중요한 부분으로, 실제 환경에서 서버가 다양한 부하를 어떻게 처리하는지 시뮬레이션한다.
   • 성능 테스트는 API의 응답 시간, 처리량, 에러율 등을 측정하고, 부하 테스트는 대규모 사용자 요청을 시뮬레이션하여 서버의 CPU, 메모리, 네트워크 대역폭 등을 모니터링한다.

3. 성능 지표 분석 → 결과에 따른 배포 결정:

   • 성능 및 부하 테스트 결과를 기반으로 애플리케이션의 성능 지표를 분석한다. 여기에는 API 응답 시간, 처리량, 오류율, 자원 사용량(CPU, 메모리, 네트워크)이 포함된다.
   • 성능 지표가 설정한 기준을 만족하지 못할 경우, 배포는 중단되고 문제를 해결한 후 파이프라인을 다시 실행한다. 반대로, 성능 지표가 양호할 경우, 배포는 자동으로 진행된다.

테스트 위치

성능 및 부하 테스트를 CI/CD 파이프라인에 통합하기 위한 적절한 위치를 설정하는 것도 매우 중요하다. 성능 및 부하 테스트는 통합 테스트 이후, 그리고 스테이징 환경에서 실행해야 한다.

1. 통합 테스트 이후:

   • 통합 테스트에서 기본적인 기능 테스트가 완료되면, 성능 및 부하 테스트를 진행하도록 설정한다.
   • 이를 통해 기능이 정상 작동하는지 확인한 후, 애플리케이션이 실제로 얼마나 효율적으로 동작하는지, 성능 병목 현상이 어디서 발생할 수 있는지 테스트할 수 있다.
   • 성능 테스트는 API 경로별로 성능을 측정하고, 부하 테스트는 동시 사용자 요청을 시뮬레이션해 애플리케이션의 한계치를 탐지한다.

2. 스테이징 환경에서 테스트:

   • 성능 및 부하 테스트는 스테이징 환경에서 실행해야 한다. 스테이징 환경은 실제 프로덕션 환경과 유사하게 구성되어 있으며, 실제 트래픽 시뮬레이션을 통해 서버 성능을 측정할 수 있다.
   • 이 환경에서 실행된 성능 테스트 결과는 프로덕션 배포 전 성능 문제를 미리 감지하고 해결하는 데 중요한 역할을 한다.
   • 특히 스테이징 환경에서의 부하 테스트는 프로덕션 환경에서 발생할 수 있는 다양한 시나리오를 예측하고 대비하는 중요한 과정이다.

전략 설계

CI/CD 파이프라인 내에서 성능 및 부하 테스트를 성공적으로 수행하기 위한 전략은 다음과 같다:

• 도구 선택: 성능 및 부하 테스트를 위한 도구로는 k6, Gatling, JMeter 등의 성능 테스트 도구를 사용할 수 있다. 이 도구들은 각각의 장점을 활용하여 다양한 부하 조건에서 API 성능을 테스트할 수 있다.
• 성능 기준 설정: 성능 테스트의 목표는 성능 병목을 사전에 감지하는 것이므로, 응답 시간, 처리량, 오류율 등에 대한 기준을 미리 설정하고, 이를 초과할 경우 배포를 중단하는 조건을 설정해야 한다.
• 자동화 및 보고서 생성: 성능 및 부하 테스트 결과는 자동으로 **시각화 도구(Grafana, Kibana)**에 통합되어 실시간으로 모니터링할 수 있어야 하며, 문제가 발생한 경우 자동으로 개발자에게 알림이 가도록 설정한다.

이러한 단계와 전략을 통해 CI/CD 파이프라인 내에서 성능 및 부하 테스트를 효과적으로 수행할 수 있다. 이를 통해 애플리케이션이 실제 운영 환경에서도 안정적으로 동작할 수 있는지 사전에 검증하고, 성능 문제를 빠르게 해결할 수 있는 자동화된 프로세스를 구축할 수 있다.

---

2024.09.19

도구 선택 및 분석

성능 테스트 도구: k6

선택 이유

1. 사용자 친화적인 스크립트 작성 방식

• JavaScript 기반: K6는 JavaScript로 성능 테스트 스크립트를 작성한다. 이는 많은 개발자들에게 익숙한 언어로, 테스트 작성이 상대적으로 쉽고 직관적이다. JavaScript를 사용하면 모듈화 및 재사용 가능한 테스트 코드를 작성하기 용이하다.
• 유연성: 테스트 스크립트에서 HTTP 요청뿐만 아니라, 사용자 정의 로직, 조건부 흐름 제어, 비동기 작업 등을 구현할 수 있다.

2. CLI 기반 실행

• 간단한 실행: K6는 커맨드라인에서 매우 간단하게 실행되며, 추가 설정 없이 로컬 또는 CI/CD 환경에서 쉽게 통합할 수 있다.
• 로컬 또는 클라우드에서 실행 가능: K6는 로컬에서 로드 테스트를 실행할 수 있으며, 더 큰 부하 테스트를 위해 클라우드 환경에서 실행할 수도 있다.

3. 고성능 및 경량화

• 효율적인 자원 사용: K6는 Go 언어로 개발되었으며, 매우 경량화되어 있어 높은 부하를 걸더라도 비교적 적은 시스템 자원을 소비한다.
• 고성능: K6는 대규모 부하 테스트 시에도 높은 성능을 유지하며, 수천에서 수만 명의 가상 사용자를 시뮬레이션할 수 있다.

4. 가상 사용자 시뮬레이션 및 부하 패턴 제어

• 가상 사용자(VU): K6는 동시에 여러 사용자를 시뮬레이션할 수 있는 VU(Virtual Users) 개념을 사용한다. 각 VU는 독립적인 사용자로 행동하며, 다양한 시나리오에서 테스트가 가능하다.
• 부하 단계 설정: 부하를 점진적으로 증가시키거나 감소시키는 등, 복잡한 부하 시나리오를 제어할 수 있다. stages 옵션을 통해 단계별로 사용자를 증가시키거나 감소시키는 부하 패턴을 정의할 수 있다.

5. 통합 및 자동화 용이

• CI/CD 파이프라인 통합: K6는 GitLab CI, Jenkins, CircleCI 등의 CI/CD 도구와 쉽게 통합할 수 있어, 배포 전후 성능 테스트를 자동화할 수 있다. 이를 통해 성능 병목을 사전에 발견할 수 있다.
• 간단한 통합: Docker 기반으로 동작하기 때문에, 다양한 개발 환경이나 파이프라인에서 손쉽게 통합할 수 있다.

6. 다양한 프로토콜 및 메트릭 지원

• HTTP, WebSocket 지원: K6는 HTTP와 WebSocket을 지원하여 다양한 API 성능 테스트에 적합하다. REST API뿐만 아니라 실시간 통신(WebSocket) 환경에서도 사용 가능하다.
• 확장성: K6는 Prometheus, InfluxDB, Grafana와 같은 모니터링 도구와 연동이 가능하여, 실시간으로 메트릭을 시각화하고 성능 데이터를 수집할 수 있다.

7. 강력한 성능 모니터링

• 성능 메트릭 수집: K6는 응답 시간, 오류율, 요청 성공률, 사용자의 지연 시간 등 다양한 성능 메트릭을 제공하여, API나 애플리케이션의 성능을 자세히 분석할 수 있게 한다.
• 체크포인트 기반 검증: 응답 상태 코드나 특정 조건을 체크하는 기능을 제공하여, 성능 테스트 중에 원하는 조건이 충족되었는지 실시간으로 확인할 수 있다.

8. 오픈소스 및 커뮤니티 지원

• 오픈소스: K6는 무료로 사용할 수 있는 오픈소스 도구이다. 엔터프라이즈급 성능 테스트 도구를 대체할 수 있는 비용 효율적인 솔루션이다.
• 풍부한 문서와 커뮤니티: K6는 활발한 개발 커뮤니티를 가지고 있으며, 자세한 문서화와 다양한 예제를 통해 빠르게 테스트 환경을 구축하고 사용할 수 있다.

구현 예시

import http from 'k6/http';
import { check, sleep } from 'k6';

export let options = {
    vus: 10, // 10명의 가상 사용자를 시뮬레이션
    duration: '30s', // 30초 동안 테스트 실행
};

export default function () {
    let chatRoomId = 7;
    let res = http.get(`http://host.docker.internal:8080/api/v1/chatrooms/7/reviews`);

    // 응답 상태 코드가 200인지 확인
    check(res, {
        'status is 200': (r) => r.status === 200,
    });

    sleep(1); // 1초 대기
}

결과

- **✓ status is 200**

- **checks.........................:** 100.00% ✓ 290      ✗ 0   
- **data_received..................:** 478 kB  16 kB/s
- **data_sent......................:** 34 kB   1.1 kB/s
- **http_req_blocked...............:** avg=112.71µs min=750ns   med=5.35µs   max=3.56ms   p(90)=14.38µs  p(95)=24.36µs 
- **http_req_connecting............:** avg=38.75µs  min=0s      med=0s       max=1.25ms   p(90)=0s       p(95)=0s      
- **http_req_duration..............:** avg=37.32ms  min=19.85ms med=36.24ms  max=100.71ms p(90)=45.21ms  p(95)=54.64ms 
  - **{ expected_response:true }...:** avg=37.32ms  min=19.85ms med=36.24ms  max=100.71ms p(90)=45.21ms  p(95)=54.64ms 
- **http_req_failed................:** 0.00%   ✓ 0        ✗ 290 
- **http_req_receiving.............:** avg=201.26µs min=10.37µs med=119.54µs max=3.69ms   p(90)=419.94µs p(95)=769.45µs
- **http_req_sending...............:** avg=37.56µs  min=3.83µs  med=16.33µs  max=606.7µs  p(90)=57.4µs   p(95)=107.5µs 
- **http_req_tls_handshaking.......:** avg=0s       min=0s      med=0s       max=0s       p(90)=0s       p(95)=0s      
- **http_req_waiting...............:** avg=37.08ms  min=19.55ms med=36.05ms  max=99.65ms  p(90)=45.15ms  p(95)=54.35ms 
- **http_reqs......................:** 290     9.615707/s
- **iteration_duration.............:** avg=1.03s    min=1.02s   med=1.03s    max=1.1s     p(90)=1.04s    p(95)=1.05s   
- **iterations.....................:** 290     9.615707/s
- **vus............................:** 10      min=10     max=10
- **vus_max........................:** 10      min=10     max=10

**running (0m30.2s), 00/10 VUs, 290 complete and 0 interrupted iterations**
- **default ✓ [ 100% ] 10 VUs 30s**

K6 성능 테스트 결과 해석

성공적인 응답

• ✓ status is 200: 모든 HTTP 요청이 성공적으로 처리되었다. 290개의 요청 중 오류는 없었으며, 모든 요청이 200 상태 코드를 반환했다.

데이터 전송 및 수신

• data_received: 478 kB의 데이터를 수신했으며, 초당 16 kB의 속도로 데이터를 받았다.
• data_sent: 34 kB의 데이터를 전송했으며, 초당 1.1 kB의 속도로 데이터를 전송했다.

요청 지연 시간

• http_req_blocked: 요청이 차단된 평균 시간은 112.71µs로, 네트워크 및 시스템 지연 시간이 매우 짧았다.
• http_req_connecting: 평균 연결 시간은 38.75µs로, TCP 연결에 소요된 시간이 거의 없었다.

요청 처리 시간

• http_req_duration: 평균 응답 시간은 37.32ms로, 최소 19.85ms에서 최대 100.71ms까지 걸렸다.
  • P90 기준(90번째 백분위 수)으로는 45.21ms, P95 기준으로는 54.64ms가 소요되었다. 대부분의 요청이 50ms 이내에 처리되었다.

요청 실패

• http_req_failed: 요청 실패율은 0%로, 모든 요청이 성공적으로 완료되었다.

처리 속도

• http_reqs: 초당 9.62개의 요청을 처리했다.
• iteration_duration: 한 번의 가상 사용자 반복 실행에 평균 1.03초가 소요되었으며, P95 기준으로는 1.05초가 걸렸다.

가상 사용자(VUs)

• vus: 10명의 가상 사용자가 동시에 동작했으며, 30초 동안 총 290번의 반복 실행을 완료했다.

종합 평가

• 이 테스트 결과는 성공적인 성능을 보여준다. 응답 시간이 평균 37.32ms로 매우 빠르며, 요청 실패가 전혀 발생하지 않았다. 또한, 초당 9.62개의 요청을 처리하면서도 성능 저하가 발생하지 않았다.

---

[startupcodekr]

"서버 성능 병목 구간 탐지를 위한 CI/CD 파이프라인 설계: 코드 배포 전 API 성능 및 부하 테스트를 통한 사전 문제 탐지 및 방지 방안"
주제 제목은 위와 같을 것 같은데, 본인 프로젝트 문제점 시나리오와 관련이 있어야 합니다.