본문으로 건너뛰기
버전: 4.5.2.5-onprem

k6로 NetFUNNEL 큐 시뮬레이션

이 가이드는 k6를 사용하여 NetFUNNEL에 직접 부하를 생성하여 순차 진입, 큐잉, TTL 주기 및 완료를 재현하고 측정하는 방법을 설명합니다. 스크립트가 실제 클라이언트 호출을 모방하므로 구성 효과와 사용자 경험을 안전하게 검증할 수 있습니다.

테스트 시나리오:

  • 기본 제어: nfStart → (작업 시뮬레이션) → nfStop
  • 구간 제어: nfStartSection → (Alive Notice 5003 루프) → nfStopSection

사용하는 이유

  • 순차 진입 및 큐 검증: 의도적으로 대기 조건을 생성하여 사용자가 순서대로 진입하고 TTL 주기가 구성된 대로 동작하는지 확인합니다.
  • 대기실 UX 관찰: k6가 부하를 생성하는 동안 브라우저를 열고 동일한 세그먼트로 보호된 페이지로 이동하여 대기실 및 후속 진입을 시각적으로 확인합니다.
  • 세그먼트 구성 드라이런: 백엔드를 건드리지 않고 실제 효과를 확인하기 위해 다양한 유입 속도, 진입 상태 및 타이밍을 시도합니다.
  • 용량 및 SLO 확인: opcode 지연 시간(5101, 5002, 5003, 5004)을 측정하고 예상 VU 수준에서 목표를 충족하는지 확인합니다.
  • 위험 없는 통합 테스트: 백엔드 부하를 도입할 준비가 될 때까지 NetFUNNEL만 테스트합니다.
  • 사고 리허설: 스파이크 및 큐 구축을 시뮬레이션하여 알림 및 대시보드를 확인합니다.

대기실을 관찰하는 빠른 방법:

  1. NetFUNNEL 콘솔에서 유입(예: TPS)을 낮추거나 진입 상태를 설정하여 세그먼트에 대한 큐잉을 강제합니다.
  2. 해당 세그먼트(기본 또는 구간 제어)에 대한 k6 스크립트를 실행하여 압력을 생성합니다.
  3. 브라우저에서 동일한 세그먼트로 보호된 페이지에 액세스합니다. 대기실이 표시되고 허용되면 진입이 표시됩니다.

이 스크립트가 하는 것(그리고 하지 않는 것)

  • NetFUNNEL에만 부하를 생성합니다. 서비스 로직(Web/WAS/DB)을 호출하지 않습니다. 필요하면 사용자 정의 호출을 추가할 수 있습니다.
  • 라이브 구성을 가져오고, 진입 키를 요청하고, 선택적으로 대기 및 재시도한 다음 완료(키 반환)합니다.
  • 빠른 분석을 위해 k6 Trends로 opcode별 타이밍을 측정합니다.

다운스트림 서비스에도 스트레스를 주려면 성공적인 진입(200)과 키 반환(5004) 사이에 서비스 호출을 삽입하세요. 아래 샘플의 주석을 참조하세요.

이 시뮬레이션이 실제 사용자와 동일한 이유(opcode 설명)

k6 가상 사용자는 실제 클라이언트(에이전트/SDK)가 보낼 것과 동일한 NetFUNNEL opcode를 보냅니다. 그래서 보이는 동작(큐, 속도 조절, 허용, 완료)이 최종 사용자 경험과 일치합니다.

  • 5101 — 진입 요청(키 발급)

    • 최종 사용자 관점: "들어가게 해주세요." 용량이 있으면 사용자가 허용되고, 그렇지 않으면 큐에 배치됩니다.
    • 스크립트 동작: GET 5101; 응답을 상태(200/201) 및 key/sticky/ttl로 파싱합니다.
  • 5002 — 큐 폴링(대기/재시도)

    • 최종 사용자 관점: "대기 중입니다. 나중에 다시 확인하세요." 클라이언트는 ttl 초를 대기한 후 다시 요청합니다.
    • 스크립트 동작: sleep(ttl), GET 5002; 200이 될 때까지 루프합니다.
  • 5003 — Alive Notice(구간 제어만)

    • 최종 사용자 관점: "보호된 구간을 여전히 사용 중입니다." 구간 내에서 세션을 활성 상태로 유지합니다.
    • 스크립트 동작: section_count 횟수만큼 (sleep ttl → GET 5003)을 반복합니다.
  • 5004 — 완료(키 반환)

    • 최종 사용자 관점: "완료했습니다." 다음 사용자를 위한 용량을 해제합니다.
    • 스크립트 동작: 시뮬레이션된 서비스 지속 시간(btn_click_delay) 후 GET 5004를 실행합니다.

최종 사용자 관점에서의 시퀀스(기본 vs 구간):

전제 조건

  • 접근 가능한 NetFUNNEL 엔드포인트(클라우드 또는 온프레미스)
  • 프로젝트 ID(sid) 및 세그먼트 ID(aid)
    • 기본 제어 세그먼트 및/또는
    • 구간 제어 세그먼트
  • k6가 설치된 Linux/macOS/WSL 환경

k6 설치

sudo gpg -k || true
sudo gpg --no-default-keyring --keyring /usr/share/keyrings/k6-archive-keyring.gpg --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys C5AD17C747E3415A3642D57D77C6C491D6AC1D69
echo "deb [signed-by=/usr/share/keyrings/k6-archive-keyring.gpg] https://dl.k6.io/deb stable main" | sudo tee /etc/apt/sources.list.d/k6.list
sudo apt-get update && sudo apt-get install -y k6

제공되는 스크립트

실행 준비가 된 두 개의 스크립트가 제공됩니다. 전체 복사/붙여넣기 코드 및 사용법은 하위 페이지를 참조하세요:

확장된 연습을 위해서는 별도의 방법 가이드를 참조하세요.

구성 및 설정

대부분의 설정은 두 스크립트에 공통입니다. 구간 제어 전용 필드는 표시되어 있습니다.

각 스크립트 상단에서 가상 사용자 및 지속 시간을 조정합니다:

export const options = {
vus: 30,
duration: "600s",
// iterations: 3000, // 선택적 제한
};

setup()에서 환경을 설정합니다(공통):

vars["apiurl"] = "https://your-netfunnel-domain"; // NetFUNNEL 기본 URL
vars["sid"] = "service_1"; // 프로젝트 ID
vars["aid"] = "basic_control"; // 세그먼트 ID
vars["btn_click_delay"] = "2.5"; // 시뮬레이션된 서비스 지속 시간(초)
// 구간 제어만:
// vars["section_count"] = "10"; // Alive notice 주기

k6 옵션 의미(VUs, duration, iterations)

  • vus

    • 의미: 기본 함수를 병렬로 실행하는 동시 가상 사용자(k6 워커) 수입니다.
    • 효과: 더 높은 vus는 동시 요청과 큐 형성(201) 가능성을 증가시켜 5002/5003 루프에 스트레스를 줍니다.
  • duration

    • 의미: VU가 기본 함수 루프를 실행하는 벽시계 시간입니다.
    • 효과: 더 긴 지속 시간은 압력을 유지합니다. VU 전체에서 더 많은 5101/5002/5003/5004 주기가 발생합니다.
  • iterations (선택적)

    • 의미: 모든 VU에 걸친 총 반복 횟수(기본 함수 실행)의 상한선입니다.
    • 효과: 설정하면 반복 상한선에 도달하면 duration 전에 테스트가 종료될 수 있습니다. 설정하지 않으면 VU는 duration이 경과할 때까지 루프합니다.
  • 상호작용

    • vus + duration만 설정된 경우: 주어진 시간 창에 대한 개방형 루핑입니다.
    • iterations도 설정된 경우: 먼저 충족되는 조건(반복 상한선 또는 지속 시간 타임아웃)이 실행을 종료합니다.
    • 반복당 속도 조절은 서버 ttl 대기 및 btn_click_delay에 의해 결정됩니다. 설계하지 않는 한 고정 요청 속도는 없습니다.

구성 → 흐름 매핑

  • apiurl

    • 의미: 모든 요청(설정 자산, 5101/5002/5003/5004)에 대한 기본 URL입니다.
    • 흐름에서의 위치: 두 다이어그램의 모든 요청
  • sid / aid

    • 의미: 제어할 NetFUNNEL 세그먼트를 식별하는 프로젝트 ID 및 세그먼트 ID입니다.
    • 흐름에서의 위치: 5101(초기 진입 요청)에 포함됩니다.
  • btn_click_delay

    • 의미: 진입 키를 보유하는 동안 시뮬레이션된 비즈니스 처리 시간입니다. 키를 반환하기 전의 클라이언트 측 보유 시간입니다.
    • 흐름에서의 위치:
      • 기본 제어: 진입이 허용된 후(200) 및 5004(완료) 직전에만
      • 구간 제어: Alive Notice 루프(5003 주기) 후 및 5004 직전
    • 사용되지 않음: 201 대기 주기; 이러한 대기는 서버의 ttl에 의해 제어됩니다
    • 선택 방법: 요청당 지연이 아닌 실제 사용자/세션이 보호된 리소스(예: 페이지 처리, 짧은 트랜잭션)를 점유하는 평균 시간에 근사하도록 설정합니다
  • section_count (구간 제어만)

    • 의미: 제어된 구간 내에서 세션이 머무르는 것을 시뮬레이션하는 Alive Notice(5003) 주기 수입니다.
    • 흐름에서의 위치: 진입(200)과 완료(5004) 사이의 5003에 대한 루프 반복 횟수
    • ttl과의 관계: 각 Alive Notice 주기는 다음 5003을 보내기 전에 서버가 반환한 ttl을 대기합니다

작동 방식(요청 흐름)

아래 다이어그램은 정확한 요청 시퀀스를 보여줍니다.

기본 제어 흐름

구간 제어 흐름

동시 VU(개념적)

VUs/duration/iterations가 흐름에 미치는 영향:

  • 더 많은 VU → 더 많은 동시 5101 요청 및 잠재적 201 큐.
  • 더 긴 지속 시간 → 전체적으로 더 많은 재시도(5002) 및 Alive(5003) 주기.
  • iterations 상한선(설정된 경우) → 지속 시간과 관계없이 총 흐름 실행을 제한합니다.

테스트 실행

# 예제 파일 이름(저장한 스크립트 이름에 맞게 조정)
k6 run basic-control-script.js
k6 run section-control-script.js

실습 시나리오:

  1. 콘솔 준비: 큐를 강제하기 위해 진입 허용 수를 낮춥니다(세그먼트를 열어두되 제한만 둡니다).
  2. 실행: VU >> 진입 허용 수(예: 진입 허용 수≈2 vs VU=20–30) 및 5–10분 지속 시간을 선택합니다.
  3. 관찰: 모니터링에서 대기 중인 사용자 수 및 관련 지표를 포함한 주요 메트릭을 확인합니다.
  4. UX 확인: 테스트 중에 보호된 페이지/앱을 엽니다. 대기실 → 큐 위치 → 허용을 확인합니다.

이 스크립트를 사용하여 부하 하에서 NetFUNNEL 동작을 빠르고 반복 가능하게 검증하세요.