로드 성능 테스팅

Tier: Premium, Ultimate Offering: GitLab.com, Self-Managed, GitLab Dedicated

로드 성능 테스팅을 통해 GitLab CI/CD에서 보류 중인 코드 변경 사항이 애플리케이션의 백엔드에 미치는 영향을 테스트할 수 있습니다.

GitLab은 애플리케이션의 시스템 성능을 메트릭하기 위해 무료 오픈 소스 도구인 k6를 사용합니다.

브라우저 성능 테스팅이 웹 사이트의 클라이언트 브라우저에서 실행되는 사이트 성능을 메트릭하는 것과 달리, 로드 성능 테스팅은 API, 웹 컨트롤러 등의 애플리케이션 엔드포인트에 대한 여러 유형의 로드 테스트를 수행하는 데 사용할 수 있습니다. 이를 통해 백엔드나 서버의 확장성을 테스트할 수 있습니다.

예를 들어, 로드 성능 테스팅을 사용하여 애플리케이션에서 인기 있는 API 엔드포인트에 대해 많은 동시 GET 호출을 수행하여 성능을 확인할 수 있습니다.

로드 성능 테스팅 작동 방식

먼저, .gitlab-ci.yml 파일에서 작업을 정의하여 로드 성능 보고서 아티팩트를 생성합니다. GitLab은 이 보고서를 확인하여 소스 브랜치와 타깃 브랜치 간의 주요 로드 성능 지표를 비교하고, 그 정보를 Merge Request 위젯에 표시합니다.

로드 성능 위젯

다음으로, 테스트 환경을 구성하고 k6 테스트를 작성해야 합니다.

테스트 완료 후 Merge Request 위젯에 표시되는 주요 성능 지표는 다음과 같습니다:

  • Checks: k6 테스트에서 구성된 checks의 통과율.
  • TTFB P90: 응답을 받기 시작하는 데 걸린 시간인 첫 번째 바이트 시간 (TTFB)의 90 백분위.
  • TTFB P95: TTFB의 95 백분위.
  • RPS: 테스트가 달성한 초당 요청(Requsest Per Second, RPS) 평균 속도.

참고: 로드 성능 보고서에 비교할 데이터가 없는 경우, 예를 들어 처음으로 .gitlab-ci.yml에 로드 성능 작업을 추가했을 때 등, 로드 성능 보고서 위젯은 표시되지 않습니다. 이 보고서는 대상 브랜치(main 등)에서 적어도 한 번 실행되어야 해당 브랜치를 대상으로 하는 Merge Request에서 표시될 수 있습니다.

로드 성능 테스팅 작업 구성

로드 성능 테스팅 작업을 구성하는 것은 여러 부분으로 나눌 수 있습니다:

  • 처리량(throughput) 등 테스트 매개변수 결정.
  • 로드 성능 테스팅을 위한 대상 테스트 환경 설정.
  • k6 테스트 디자인 및 작성.

테스트 매개변수 결정

첫 번째로 실행할 로드 테스트 유형 및 실행 방식(예: 사용자 수, 처리량 등)을 결정해야 합니다.

상기 내용 및 기타 사항에 대한 지침은 k6 문서 및 특히 k6 테스트 가이드를 참고하세요.

테스트 환경 설정

로드 성능 테스팅을 위한 대상 테스트 환경을 준비하는 데는 많은 노력이 필요합니다. 테스트하는 처리량이 환경에서 처리 가능한지 확인해야 합니다. 또한 로드 성능 테스트에 사용할 대상 환경에는 일반적으로 대표적인 테스트 데이터가 필요합니다.

프로덕션 환경에서 이러한 테스트를 실행하지 말아야 한다는 것을 강력히 권장합니다.

로드 성능 테스트 작성

환경이 준비되면 k6 테스트 자체를 작성할 수 있습니다. k6는 유연한 도구이며 다양한 유형의 성능 테스트를 실행하는 데 사용할 수 있습니다. 자세한 정보는 k6 문서를 참고하세요.

GitLab CI/CD에서 테스트 구성

k6 테스트가 완료되면 다음 단계는 GitLab CI/CD에서 로드 성능 테스팅 작업을 구성하는 것입니다. 이 작업을 가장 쉽게 하는 방법은 GitLab과 함께 제공되는 Verify/Load-Performance-Testing.gitlab-ci.yml 템플릿을 사용하는 것입니다.

참고: 대규모 k6 테스트를 위해 실제로 테스트를 실행하는 GitLab Runner 인스턴스가 테스트를 실행할 수 있도록해야 합니다. 하드웨어 세부 정보에 대해서는 k6의 지침을 확인하세요. 기본 공유 GitLab.com 러너는 대부분의 대규모 k6 테스트를 처리하기에는 사양이 부족할 수 있습니다.

이 템플릿은 작업에서 k6 도커 컨테이너를 실행하고 작업을 사용자 정의하는 여러 가지 방법을 제공합니다.

예시 구성 작업 플로우:

  1. Docker-in-Docker 워크플로우와 비슷하게 GitLab Runner를 Docker 컨테이너를 실행할 수 있도록 설정합니다.
  2. 콘피규레이션 파일 .gitlab-ci.yml에서 기본 로드 성능 테스팅 CI/CD 작업을 구성합니다. 템플릿을 포함하고 CI/CD 변수로 구성해야 합니다:

    include:
      template: Verify/Load-Performance-Testing.gitlab-ci.yml
       
    load_performance:
      variables:
        K6_TEST_FILE: <프로젝트 내 K6 테스트 파일 경로>
    

위 예시는 CI/CD 파이프라인에서 load_performance 작업을 생성하여 k6 테스트를 실행합니다.

참고: 쿠버네티스 설정의 경우 다른 템플릿을 사용해야 합니다: Jobs/로드-성능-테스팅.gitlab-ci.yml.

k6는 여러 옵션을 가지고 있어서 테스트를 실행하는 방식을 구성할 수 있으며, 예를 들어 실행할 처리량 (RPS)과 테스트의 지속 시간 등을 설정할 수 있습니다. 대부분의 옵션은 테스트 자체에서 구성할 수 있지만 K6_OPTIONS 변수를 통해 명령줄 옵션도 전달할 수 있습니다.

예를 들어, CLI 옵션을 사용하여 테스트의 지속 시간을 재정의할 수 있습니다:

  include:
    template: Verify/로드-성능-테스팅.gitlab-ci.yml
  
  load_performance:
    variables:
      K6_TEST_FILE: <프로젝트 내 K6 테스트 파일 경로>
      K6_OPTIONS: '--duration 30s'

GitLab은 k6의 결과가 summary export를 통해 저장되어 로드 성능 보고서 아티팩트로 제공될 경우에만 Merge Request 위젯에 주요 성능 지표를 표시합니다. 항상 사용 가능한 최신 로드 성능 아티팩트는 테스트에서의 summary 값을 사용합니다.

만약 GitLab Pages가 활성화된 경우 보고서를 브라우저에서 직접 볼 수 있습니다.

리뷰 앱에서 로드 성능 테스트

상기의 CI/CD YAML 구성 예제는 정적 환경에서의 테스트에 대해 작동하지만 리뷰 앱이나 동적 환경에서도 몇 가지 추가 단계로 확장할 수 있습니다.

가장 좋은 방법은 동적 URL을 .env 파일에 캡처하여 작업 아티팩트로 공유한 다음, k6 도커 컨테이너를 사용하여 파일을 사용하도록 구성하는 우리가 제공한 사용자 정의 CI/CD 변수 K6_DOCKER_OPTIONS를 사용하는 것입니다. 이를 통해 k6는 자체적인 JavaScript 스크립트에서 .env 파일의 환경 변수를 사용할 수 있습니다. 예를 들어: http.get(`${__ENV.ENVIRONMENT_URL}`).

예시:

  1. review 작업에서:
    1. 동적 URL을 캡처하고 .env 파일에 저장합니다. 예: echo "ENVIRONMENT_URL=$CI_ENVIRONMENT_URL" >> review.env.
    2. 환경 파일을 작업 아티팩트(artifact)로 설정합니다.
  2. load_performance 작업에서:
    1. 이를 리뷰 작업에서 상속받도록 설정합니다.
    2. K6_DOCKER_OPTIONS 변수를 환경 파일을 위한 도커 CLI 옵션과 함께 설정합니다. 예: --env-file review.env.
  3. k6 테스트 스크립트를 환경 변수를 사용하도록 구성합니다.

귀하의 .gitlab-ci.yml 파일은 다음과 유사할 수 있습니다:

stages:
  - deploy
  - performance

include:
  template: Verify/로드-성능-테스팅.gitlab-ci.yml

review:
  stage: deploy
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    url: http://$CI_ENVIRONMENT_SLUG.example.com
  script:
    - run_deploy_script
    - echo "ENVIRONMENT_URL=$CI_ENVIRONMENT_URL" >> review.env
  artifacts:
    paths:
      - review.env
  rules:
    - if: $CI_COMMIT_BRANCH  # 파이프라인 규칙과 일치하도록 수정하거나 필요한 경우 `only/except`를 사용하세요.

load_performance:
  dependencies:
    - review
  variables:
    K6_DOCKER_OPTIONS: '--env-file review.env'
  rules:
    - if: $CI_COMMIT_BRANCH  # 파이프라인 규칙과 일치하도록 수정하거나 필요한 경우 `only/except`를 사용하세요.