이 문서는 아래 네 가지 질문만 수치로 답하기 위한 실행 계획이다. RPS 산정 근거와 전체 병목 목록은 402 설계, 공통 토폴로지·관측·중단 조건은 402 실행을 그대로 따르고, 여기서는 402의 부분집합에 새 비교 축과 판정 산식만 추가한다.

측정 대상은 loadtest-target/compose.yaml의 합성 픽스처(perf/ws-lab/demo 빌드 이미지)이며, 부하 발생기는 loadtest-scenarios/의 k6 스크립트를 loadtest-target/k6.sh로 실행한다. 절대값은 실제 moyeota/be가 아니므로 곡선의 모양과 최초 포화 자원을 결론으로 사용하고, 절대 RPS를 V1 용량 보증값으로 쓰지 않는다.

t3.medium은 2 vCPU · 4 GiB다. 컨테이너 예산은 docs/103-V1-IaC-Input-Spec.md 4.1을 따르며 합계가 호스트 CPU를 100% 소진하도록 배분되어 있다.

이 배분에서 나오는 구조적 사실을 판정의 기준선으로 삼는다.

• REST와 WebSocket은 같은 backend 컨테이너의 0.75 CPU · 512 MB heap · Hikari 10 커넥션을 공유한다. 따라서 "WS가 API 서비스에 장애를 준다"는 1차적으로 컨테이너 내부 경합으로 나타난다.
• frontend·mysql·nginx는 별도 quota이므로 backend 포화만으로는 직접 빼앗기지 않는다. 이들까지 동시에 악화되면 원인은 호스트 CPU·네트워크· CPU credit 또는 디스크다. F1-c에서 이 구분을 판정에 쓴다.
• backend mem_limit 768m과 -Xmx512m 사이 여유는 약 256 MB다. Metaspace, 스레드 스택, Tomcat NIO의 direct ByteBuffer가 이 안에서 늘어나므로 heap OOM보다 컨테이너 OOM-kill이 먼저 올 수 있다. F1-a에서 NMT로 확인한다.

t3.medium의 baseline은 20%(= 2 vCPU 중 0.4 vCPU, 24 credits/h)다. backend 하나만 0.75 CPU를 지속 사용해도 baseline을 넘으므로, 10분 이상 측정은 항상 credit을 소모한다.

• 매 단계 전후로 CPUCreditBalance, CPUSurplusCreditBalance, credit specification(standard/unlimited)을 기록한다.
• credit balance가 0에 닿은 구간의 성능 저하는 용량 한계가 아니라 credit 고갈이다. 해당 구간은 C_knee 산정에서 제외하고 재측정한다.
• 비교 실험(F2 셀 간, F1-c control 대비)은 credit 상태가 유사한 구간끼리만 비교한다. 가능하면 unlimited로 고정하고 그 사실을 결과에 남긴다.

loadtest-target/.local/target.env 전체 값을 단계별로 고정하고, 변경 시 RUN_ID와 함께 기록한다. 기본값은 다음과 같다.

BACKEND_CPUS=0.75  BACKEND_MEMORY=768m  JVM_XMX=512m
HIKARI_MAX_POOL_SIZE=10  HIKARI_CONNECTION_TIMEOUT_MS=1000
WS_PER_CONNECTION_BYTES=0
MYSQL_BUFFER_POOL=384M  MYSQL_MAX_CONNECTIONS=151
FRONTEND_RESERVE_MB=384  FRONTEND_SSR_WORK_MS=5

추가로 BACKEND_IMAGE digest, 픽스처 lab_run 설정(chat_hold_ms, lock_hold_ms, parties, seats), 로컬 발생기 사양·ulimit -n·업로드 대역폭, 시간대, credit 상태를 매 실행에 남긴다.

402와 동일하게 C_knee(SLO·정합성이 처음 깨지는 지속 부하), C_safe = C_knee × 0.7을 사용한다. 각 단계는 5분 warm-up → 10분 measure, 한 번에 한 축만 변경하고, 임계 근처 단계만 3회 반복해 중앙값과 변동폭을 남긴다. 로컬 발생기 지표(CPU 60% 미만, swap 0, 업로드 70% 미만, dropped iterations 0, 목표 전달률 95% 이상)를 만족하지 못한 실행은 서버 한계로 해석하지 않는다.

REST 배경 부하는 모든 블록에 계속 깔지 않는다. 테스트 목적에 따라 다음처럼 분리한다.

http-mixed.js를 모든 블록의 공통 배경으로 사용하면 관측값은 순수한 WebSocket 비용이 아니라 다음의 합이 된다.

관측 자원 = REST 기본 비용 + WebSocket 비용 + 두 부하 사이의 경합 비용

따라서 F1-a·F1-b·F2의 회귀에는 REST를 넣지 않는다. F1-c·F3·F4에서는 control(REST만)과 treatment(REST + WS 또는 hot-row)를 같은 조건으로 비교한다. CPU·thread 경합은 REQUEST_GROUP=light, Hikari·DB 경합은 REQUEST_GROUP=detail, 실제 사용자 패턴은 http-mixed.js로 별도 측정한다. 배경 REST를 고정한 결과는 순수 단가가 아니라 REST 50 RPS가 실행 중일 때의 조건부 추가 비용으로만 해석한다.

management.server.port=8081(호스트 8080) → /actuator/prometheus.

컨테이너·호스트 지표는 cAdvisor·Node Exporter를 쓴다. 컨테이너 이름은 compose project가 moyeota-loadtest-target이므로 moyeota-loadtest-target-backend-1 형태다.

rate(container_cpu_usage_seconds_total{name="moyeota-loadtest-target-backend-1"}[1m])
rate(container_cpu_cfs_throttled_seconds_total{name="moyeota-loadtest-target-backend-1"}[1m])
container_memory_working_set_bytes{name=~"moyeota-loadtest-target-.*"}

단계별로 아래 값을 계산해 표로 남긴다. 원시 지표가 아니라 이 값들이 V2 결정의 근거다.

연결당 heap bytes   = Δ(full GC 직후 heap used) ÷ Δ(연결 수)
연결당 direct bytes = Δ(direct buffer used) ÷ Δ(연결 수)
수용 가능 연결 상한 = (Xmx 512MB × 안전율 0.7 − 기저 heap) ÷ 연결당 heap bytes
메시지당 CPU ms     = Δ(backend CPU core-seconds/s) × 1000 ÷ Δ(msg/s)
KB당 CPU ms         = Δ(backend CPU core-seconds/s) × 1000 ÷ Δ(msg/s × payload KB)
요청당 CPU ms       = (backend CPU core-seconds/s) × 1000 ÷ 실제 RPS
quota 이론 상한 RPS = 750 ÷ 요청당 CPU ms        (0.75 CPU = 750 CPU-ms/s)
스레드 기준 상한 RPS = Tomcat max threads(200) ÷ 평균 응답시간(s)
풀 기준 상한 TPS    = HIKARI_MAX_POOL_SIZE(10) ÷ 커넥션 점유시간(s)

1. 픽스처 배포와 상태 확인: loadtest-target/deploy.sh up 후 /api/probe, /api/lab/db-probe, up{...} exporter 상태, Grafana 대시보드.
2. 단계별 픽스처 run 생성. chat_hold_ms·lock_hold_ms는 run 단위 설정이라 축마다 별도 run이 필요하다.

# F2·F3용 (채팅 저장 트랜잭션 점유시간 0/50/200ms)
for h in 0 50 200; do
  curl -sk -X POST https://PUBLIC_DOMAIN/api/lab/runs \
    -H 'Content-Type: application/json' \
    -d "{\"id\":\"f3-h$h\",\"parties\":10,\"seats\":1000,\"chatHoldMs\":$h,\"lockHoldMs\":0}"
done

# F4용 (lock 점유 0/100/500ms, 좌석 충분 → 409 full로 lock 비용이 가려지지 않게)
for h in 0 100 500; do
  curl -sk -X POST https://PUBLIC_DOMAIN/api/lab/runs \
    -H 'Content-Type: application/json' \
    -d "{\"id\":\"f4-L$h\",\"parties\":10,\"seats\":1000,\"chatHoldMs\":0,\"lockHoldMs\":$h}"
done

# F4 정합성 전용 (정원 4석, 초과 승인·음수 좌석 검증)
curl -sk -X POST https://PUBLIC_DOMAIN/api/lab/runs \
  -H 'Content-Type: application/json' \
  -d '{"id":"f4-cap4","parties":2,"seats":4,"chatHoldMs":0,"lockHoldMs":100}'

3. DATA_FILE 세트를 만든다. WS payload 크기와 runId 쿼리는 데이터 파일에 있으므로 셀마다 파일을 분리한다. ws 배열에는 항목을 하나만 두어 크기가 섞이지 않게 한다(select(data.ws)가 무작위로 고른다).

cd loadtest-scenarios/data
python3 - <<'PY'
import json, copy
base = json.load(open('test-data.json'))
for size in (256, 8000):
    for run in ('f3-h0', 'f3-h50', 'f3-h200'):
        d = copy.deepcopy(base)
        body = 'x' * size
        d['ws'] = [{
            "name": f"chat-{size}b",
            "path": f"/ws?runId={run}",
            "headers": {}, "onOpenMessages": [],
            "heartbeatMessage": None, "heartbeatIntervalMs": None,
            "messages": [{"id": "m-{{runId}}-{{vu}}-{{iteration}}-{{timestamp}}", "body": body}],
        }]
        json.dump(d, open(f'ws-{size}b-{run}.json', 'w'))
    # 저장 없는 echo 경로: runId 쿼리를 제거하면 픽스처가 DB를 쓰지 않고 에코만 한다
    d = copy.deepcopy(base)
    d['ws'] = [{
        "name": f"echo-{size}b", "path": "/ws",
        "headers": {}, "onOpenMessages": [],
        "heartbeatMessage": None, "heartbeatIntervalMs": None,
        "messages": [{"id": "m-{{vu}}-{{iteration}}", "body": 'x' * size}],
    }]
    json.dump(d, open(f'ws-{size}b-echo.json', 'w'))
PY

F4용 데이터 파일도 run id를 바꿔 함께 만든다.

python3 - <<'PY2'
import json, copy
base = json.load(open('test-data.json'))
def retarget(d, run):
    for group in ('hotRowSame', 'hotRowDistributed', 'hotRowVerify'):
        for spec in d['requests'][group]:
            spec['path'] = spec['path'].replace('/runs/hot-01/', f'/runs/{run}/')
    return d
for run in ('f4-L0', 'f4-L100', 'f4-L500', 'f4-cap4'):
    json.dump(retarget(copy.deepcopy(base), run), open(f'test-data-{run}.json', 'w'))
PY2

f4-L* run은 좌석 1,000석이므로 hotRowVerify의 approved <= capacity 비교값을 4에서 1000으로 고쳐야 한다. 정합성 검증용 f4-cap4만 4로 둔다.

• 픽스처 제약: body는 8,192자 이하여야 저장 경로가 성공한다. 따라서 payload 큰 쪽은 8,000 B를 상한으로 쓴다.
• 저장 경로(?runId= 있음)는 커밋 후 {"id","ok"} ACK만 회신하고, echo 경로(?runId= 없음)는 받은 payload를 그대로 반송한다. 두 조건을 비교할 때 outbound 바이트 차이를 감안한다.

4. 발생기 headroom 검증(T0). F2의 최대 셀(연결 1,800 · 8,000 B · 120 msg/s ≈ 960 KB/s ≈ 7.7 Mbps upload)과 F1-a의 최대 연결(5,000 VU)을 로컬에서 1분 예행하고 ulimit -n, 로컬 CPU, 업로드 대역폭, dropped iterations를 확인한다. k6/ws는 VU 1개가 연결 1개이므로 연결 수가 곧 VU 수다.

연결만 유지해 연결 자체의 자원 단가를 구한다.

• 연결 수: control 0 → 500 → 1,000 → 1,575 → 1,800 → 2,100 → 3,000 → 5,000
• CONNECT_RATE=6 고정, HOLD_DURATION=30m, ramp-down 1분
• WS_PER_CONNECTION_BYTES: 0(연결 순수 비용)으로 전 단계 → 32768(세션이 사용자·방·최근 메시지 상태를 들고 있는 실제 앱 근사)으로 1,800 / 3,000 / 5,000 재측정

RUN_ID=f1a-c1800-b0 TARGET_CONNECTIONS=1800 CONNECT_RATE=6 HOLD_DURATION=30m \
  DATA_FILE=./data/ws-256b-echo.json \
  loadtest-target/k6.sh ws-connect.js \
  --summary-export=results/f1a-c1800-b0.json

측정: hold 구간에서 jcmd <pid> GC.run 후 heap used, jcmd <pid> VM.native_memory summary(Thread/Internal/Other 증가분), direct buffer, lab_ws_connections, backend·nginx FD와 ESTABLISHED/TIME_WAIT, GC pause, backend·nginx CPU와 throttling, container_memory_working_set_bytes.

판정:

• 연결당 heap·direct bytes를 계산해 수용 가능 연결 상한을 산출한다. 이 값이 예측 피크 2,100을 밑돌면 연결 수 자체가 V1 한계다.
• working set이 768 MB에 접근하며 OOM-kill이 heap OOM보다 먼저 오면 원인은 heap이 아니라 direct/native 영역이다. -Xmx 축소 또는 컨테이너 메모리 증설·WS 분리로 방향이 갈린다.
• Tomcat max-connections 8192, backend nofile 16384, nginx nofile 32768(연결당 client+upstream 2 FD)이 구조적 상한이다. 그 전에 CPU·메모리가 포화되는지 확인한다.

연결 수를 고정하고 초당 신규 연결만 늘려 연결 수립 비용을 분리한다.

• TARGET_CONNECTIONS=1000 고정, CONNECT_RATE = 6 → 10 → 20 → 50 → 100 → 200
• 측정 창은 ramp 구간이다. ws-connect.js는 연결 수명을 ramp + hold + rampDown + 60s로 잡아 한 번 맺은 연결을 테스트 끝까지 유지하므로, hold 구간에서는 신규 handshake가 발생하지 않는다. 따라서 HOLD_DURATION=2m로 짧게 두고 같은 단계를 5회 반복해 ramp 구간의 handshake 지표를 모은다(ramp 길이 = 연결수 ÷ 연결률초).
• 지속적인 handshake 부하가 필요하면 ws-connect.js에 연결 수명 (CONNECTION_TTL) 축을 추가해 연결이 주기적으로 끊기고 다시 맺도록 바꿔야 한다. 현재 RECONNECT_DELAY는 테스트 종료 후 iteration 간격이라 이 목적에 쓰이지 않는다.

for i in 1 2 3 4 5; do
  RUN_ID=f1b-rate50-r$i TARGET_CONNECTIONS=1000 CONNECT_RATE=50 HOLD_DURATION=2m \
    DATA_FILE=./data/ws-256b-echo.json \
    loadtest-target/k6.sh ws-connect.js --summary-export=results/f1b-rate50-r$i.json
done

측정: handshake p95/p99, 101 성공률, ws_errors, nginx active/reading/writing/ waiting과 accept 실패, listen queue overflow(node_netstat_TcpExt_ListenOverflows), nginx·backend CPU와 throttling, TLS handshake 비용.

판정: TLS와 accept는 **nginx 0.25 CPU · worker_processes 1**에서 처리된다. backend가 여유로운데 nginx CPU가 quota를 채우고 handshake p95만 악화되면 한계는 Spring이 아니라 진입 계층이므로, Spring 분리보다 nginx CPU·worker 조정 또는 TLS 종료 위치 변경이 먼저다.

WS 연결을 단계별로 고정한 상태에서 동일한 REST 부하를 반복해 control과 비교한다.

1. control: WS 0에서 http-operation.js REQUEST_GROUP=light, TARGET_RPS=50
2. 터미널 1에서 ws-connect.js를 hold에 진입시키고, 터미널 2에서 같은 REST 부하를 실행
3. WS 연결 = 1,000 · 1,800 · 2,100 · 3,000 · 5,000
4. 필요 시 F2의 36 msg/s를 추가해 "연결만의 간섭"과 "메시지까지의 간섭"을 분리

# 터미널 1
RUN_ID=f1c-ws2100 TARGET_CONNECTIONS=2100 CONNECT_RATE=6 HOLD_DURATION=30m \
  DATA_FILE=./data/ws-256b-echo.json loadtest-target/k6.sh ws-connect.js
# 터미널 2 (control과 동일 조건)
RUN_ID=f1c-rest-ws2100 REQUEST_GROUP=light TARGET_RPS=50 WARMUP=5m DURATION=10m \
  loadtest-target/k6.sh http-operation.js \
  --summary-export=results/f1c-rest-ws2100.json

기록 표는 다음 형태로 만든다.

판정:

• REST p95가 control 대비 20% 이상 악화되고 backend CPU·GC·Tomcat busy와 상관되면 같은 컨테이너 자원 공유가 원인이다 → WS 분리(별도 프로세스 또는 게이트웨이)를 V2 후보로 올린다.
• frontend·mysql까지 동시에 악화되면 컨테이너 quota가 아니라 호스트 CPU· 네트워크·credit이 원인이다. credit balance를 먼저 확인하고 재측정한다.
• REST는 light(DB 미사용)와 detail(DB 사용) 두 계열로 각각 본다. light만 악화되면 CPU·스레드, detail도 악화되면 풀·DB 경로까지 번진 것이다.

"메시지 컨텍스트가 크고 연결이 적은 경우"와 "메시지가 짧고 연결이 많은 경우"를 그냥 두 번 재면 원인을 분리할 수 없다. 연결 수·payload·메시지율을 2×2×2 요인 설계로 돌려 건수 비용과 바이트 비용을 분리한다.

• 8개 셀 모두 REST 배경 없이 echo 경로(저장 없음)로 먼저 돌려 Spring· 네트워크 비용만 본다. DB 축은 F3에서 다룬다. 저장 경로와 병행 REST는 F3에서 별도의 control/treatment로 측정한다.
• ws-message.js는 messageIntervalMs = (TARGET_CONNECTIONS ÷ MESSAGE_RATE) × 1000으로 연결당 간격을 계산하므로, aggregate msg/s가 고정되고 연결 수는 독립 축이 된다.

# C4: 연결 1,800 · 8,000 B · 36 msg/s · echo
RUN_ID=f2-C4-echo TARGET_CONNECTIONS=1800 MESSAGE_RATE=36 \
  CONNECTION_RAMP=5m DURATION=10m \
  DATA_FILE=./data/ws-8000b-echo.json \
  loadtest-target/k6.sh ws-message.js --summary-export=results/f2-C4-echo.json

측정: backend CPU(core-seconds/s)와 throttling, heap used·allocation rate·GC pause, direct buffer, rate(lab_ws_messages_total[1m]), 컨테이너 network rx/tx, k6 ws_messages_sent/received·ws_errors, 응답(ACK/echo) 지연.

판정 산식:

backend CPU(core) ≈ a + b·R + c·(R × S_KB) + d·C
   R = aggregate msg/s, S_KB = payload KB, C = 연결 수(d는 F1-a에서 구한 값)
b = 메시지 건당 비용 (프레임 처리·역직렬화·스레드 전환·트랜잭션 오버헤드)
c = 바이트당 비용 (복사·버퍼·직렬화·네트워크)

• b가 지배(C3·C7이 C2·C6보다 나쁨) → 병목은 건수다. 메시지 배칭, ACK 경량화, 저장 비동기화, 연결·세션 처리 경로 최적화가 우선이다.
• c가 지배(C2·C6이 더 나쁨) → 병목은 바이트다. payload 상한, 압축, 본문 분리 저장(메타만 실시간 전달)이 우선이다.
• 메모리는 heap 증가량과 GC 빈도로 본다. 큰 payload는 allocation rate와 GC 횟수를, 많은 연결은 상주 heap(연결당 상수)을 올린다. 두 축 중 어느 것이 -Xmx512m를 먼저 위협하는지 명시한다.
• 어떤 셀이든 dropped iteration·발생기 포화가 있으면 그 셀은 회귀에서 제외한다.

픽스처의 저장 경로는 커밋 후 ACK를 보내므로 WS 응답 경로가 DB 트랜잭션에 직접 묶인다. 이 결합이 어디서 깨지는지, 풀 10개로 감당 가능한 msg/s가 얼마인지 구한다.

• chat_hold_ms = 0 / 50 / 200 (f3-h0, f3-h50, f3-h200 run)
• aggregate msg/s = 36 → 120 → 300
• 연결 1,800 고정, payload 256 B 고정(바이트 축 제거)

각 조건을 두 번 측정한다.

1. WS 저장만 실행해 DB commit·Hikari의 순수 점유 비용을 측정한다.
2. 같은 WS 부하에 REQUEST_GROUP=detail, TARGET_RPS=50을 병행해 REST 간섭을 측정한다.

두 번째 실행은 첫 번째 실행의 대체가 아니라 별도의 treatment다. 첫 번째 실행이 없으면 Hikari pending 증가가 저장 자체 때문인지 병행 REST와의 경합 때문인지 구분할 수 없다.

# 첫 번째 실행: WS 저장만 측정
RUN_ID=f3-h50-r120 TARGET_CONNECTIONS=1800 MESSAGE_RATE=120 \
  CONNECTION_RAMP=5m DURATION=10m \
  DATA_FILE=./data/ws-256b-f3-h50.json \
  loadtest-target/k6.sh ws-message.js --summary-export=results/f3-h50-r120.json

# 별도 반복: 같은 WS 조건에 REST 조회를 추가한 treatment
# 터미널 1
RUN_ID=f3-ws-h50-r120-rest TARGET_CONNECTIONS=1800 MESSAGE_RATE=120 \
  CONNECTION_RAMP=5m DURATION=10m \
  DATA_FILE=./data/ws-256b-f3-h50.json \
  loadtest-target/k6.sh ws-message.js --summary-export=results/f3-ws-h50-r120-rest.json
# 터미널 2: 위 WS 실행과 동시에
RUN_ID=f3-rest-h50-r120 REQUEST_GROUP=detail TARGET_RPS=50 WARMUP=5m DURATION=10m \
  loadtest-target/k6.sh http-operation.js \
  --summary-export=results/f3-rest-h50-r120.json

예측값을 먼저 적고 실측과 비교한다(풀 기준 상한 TPS = 10 ÷ 점유시간).

측정: lab_chat_commit p95/p99, lab_chat_errors_total(= ACK ok:false), hikaricp_connections_pending·active, 획득 시간 p95(1,000 ms 초과 시 실패), MySQL redo·fsync·dirty page·row lock, EBS await, 그리고 병행 REST의 p95와 503 비율.

판정:

픽스처 주의: saveMessage는 메시지마다 SELECT chat_hold_ms를 한 번 더 수행하므로 실제 앱보다 커넥션 점유가 길다. 절대 msg/s가 아니라 조건 간 비교로 해석한다.

승인 API는 팟 행을 SELECT ... FOR UPDATE로 잡으므로 동일 팟 요청은 직렬화된다. RPS가 아니라 같은 행에 동시에 도달하는 요청 수를 제어한다.

• 동일 팟: REQUEST_GROUP=hotRowSame, 대조군: hotRowDistributed
• 동시성: 2 · 5 · 10 · 20 · 50 · 100
• lock_hold_ms: 0 · 100 · 500 (f4-L0, f4-L100, f4-L500 run)
• 병행 REST: REQUEST_GROUP=light와 detail 각각 50 RPS

RUN_ID=f4-same-c20-L100 REQUEST_GROUP=hotRowSame VERIFY_GROUP=hotRowVerify \
  CONCURRENCY=20 ROUNDS=3 ROUND_PAUSE=10s \
  DATA_FILE=./data/test-data-f4-L100.json \
  loadtest-target/k6.sh hot-row.js --summary-export=results/f4-same-c20-L100.json

두 실패 모드를 반드시 구분한다. 설정상 임계가 다르다.

풀 timeout : 동시성 > HIKARI_MAX_POOL_SIZE(10) → 대기 1,000ms 초과 → 503 database_error
             증거: hikaricp_connections_pending↑, 획득 시간 p95 ≈ 1s, lab_seat_errors_total↑
lock wait  : 동시성 × lock_hold_ms > innodb_lock_wait_timeout(3,000ms) → 503
             증거: innodb_row_lock_current_waits↑, lab_seat_lock p95 ≈ 3s

예측 임계(실측으로 확인): lock_hold_ms=500은 동시성 6부터, 100은 동시성 30부터 lock wait timeout 영역에 들어간다. 동시성 10을 넘는 순간부터는 풀 timeout이 먼저 나타날 수 있으므로, HIKARI_MAX_POOL_SIZE를 10으로 고정한 결과와 20으로 올린 대조 실행을 한 쌍 남겨 두 원인을 분리한다.

정합성 검증(한 건이라도 위반이면 실패):

• hotRowVerify(/api/lab/runs/{run}/stats)의 parties.N.remaining >= 0, parties.N.approved <= capacity
• k6 assertion으로는 항등식을 표현할 수 없으므로, round 종료 후 stats 응답을 저장해 approved + remaining == capacity 를 별도로 확인한다
• f4-cap4 run(정원 4석)으로 초과 승인·중복 승인을 재현 시도한다. 스키마에 CHECK (remaining >= 0)가 있어 위반이 음수 값이 아니라 503으로 나타날 수 있으니, 503 원인을 풀·lock·CHECK 중 무엇인지 로그로 구분한다

판정: 동일 팟에서만 지연이 급증하고 대조군은 평탄하면 hot-row가 원인이다. 이때 병행 REST(light)까지 악화되면 경합이 컨테이너 스레드·CPU까지 번진 것이고, detail만 악화되면 풀 경합에 국한된다. 전자는 승인 경로 구조 변경(Redis 원자 카운터·멱등키·대기열), 후자는 풀 분리·타임아웃 조정이 우선이다.

두 계열을 같은 단계로 올려 Spring 자체 비용과 DB 경로 비용을 분리한다.

• light = /api/probe (DB·외부 호출 없음)
• detail = /api/lab/posts/{id} (DB 1행 조회, 풀 사용)
• 참고로 list = /api/lab/posts (전체 정렬 + LIMIT 20, 데이터량 민감)
• RPS: 25 → 40 → 46 → 53 → 75 → 100 → 150 → 200 → 300 → 400 → 512
• WS 연결 0, 별도 REST 배경 부하 없음(F1-c와의 control로 재사용할 수 있다)

RUN_ID=f5-light-100 REQUEST_GROUP=light TARGET_RPS=100 WARMUP=5m DURATION=10m \
  loadtest-target/k6.sh http-operation.js \
  --summary-export=results/f5-light-100.json --out json=results/f5-light-100-raw.json

기록 표:

판정:

• 요청당 CPU-ms가 RPS 전 구간에서 일정하면 성능 저하는 CPU 단가가 아니라 큐잉이다. quota 이론 상한 RPS = 750 ÷ 요청당 CPU-ms와 실측 C_knee를 비교해 quota 포화 여부를 확정한다.
• container_cpu_cfs_throttled_seconds_total이 오르기 시작하는 RPS가 0.75 CPU quota의 실질 한계다. 이 지점이 목표 피크(50 RPS)의 몇 배인지가 V1 여유율이다.
• light는 평탄한데 detail만 꺾이면 한계는 Spring이 아니라 DB 경로(풀·쿼리)다.
• 호스트 CPU가 baseline 20%를 넘는 구간에서 credit이 줄어드는지 확인하고, credit 고갈로 인한 저하는 C_knee에서 제외한다. 필요하면 C_safe에서 60분 soak을 돌려 credit 영향까지 포함한 지속 가능 RPS를 따로 남긴다.

총 약 33시간, 하루 8시간 기준 4~5일이다. 순서는 F0 → F5(기준선) → F1-a → F1-b → F1-c → F2 → F3 → F4다. F5를 먼저 하는 이유는 WS 없는 REST 기준선이 F1-c·F3·F4의 control로 쓰이기 때문이다.

측정 창이 2시간뿐인 경우는 §13의 압축 실행안을 쓴다. 이 절의 33시간 계획은 창이 며칠 확보될 때의 기준이다.

402 §4.2를 그대로 적용하고 다음을 추가한다.

• backend 컨테이너 OOM-kill 또는 재시작 (mem_limit 768m 초과)
• CPUCreditBalance가 0에 도달 (해당 단계는 무효 처리하고 회복 후 재측정)
• approved + remaining != capacity 또는 중복 승인 1건
• nginx 502/504가 1분 이상 지속 (upstream 단절 → 상태 보존 후 중단)
• 로컬 발생기 CPU 60% 초과, swap 발생, dropped iterations 발생

RUN_ID = <단계>-<축값>-<반복> (예: f1a-c1800-b0-r2, f2-C6-echo-r1, f4-same-c50-L500-r3). 각 실행은 k6 summary JSON과 raw JSON을 loadtest-scenarios/results/에, Grafana 구간 스크린샷과 jcmd 출력을 같은 RUN_ID 이름으로 남긴다. 실행마다 target.env 값, 이미지 digest, 픽스처 run 설정, credit 상태, 발생기 headroom을 함께 기록한다.

최종 보고서에는 §2.2의 파생값 표와 단계별 C_knee/C_safe, 그리고 아래 결정표를 채운다.

픽스처(perf/ws-lab/demo)의 구조적 한계이므로 결론에 명시한다.

• fan-out이 없다. 핸들러는 발신자에게만 ACK 또는 echo를 보내고 세션 레지스트리·방 개념이 없다. 따라서 "수신자 1·3·9명"과 "한 방 집중 ↔ 여러 방 분산" 축은 측정 불가다. 필요하면 핸들러에 방·세션 레지스트리를 추가하는 별도 작업이 선행되어야 한다(402 T10의 해당 항목도 같은 제약을 받는다).
• 인증·권한 경로가 없다(tokens 비어 있음). 실제 앱의 토큰 검증 CPU는 포함되지 않는다.
• 혼잡도 외부 API(FastAPI·LLM) 호출이 없다. 402 T5는 이 계획 범위 밖이다.
• 쿼리 복잡도·데이터량이 실제 스키마와 다르다. /api/lab/posts는 전체 정렬 이므로 데이터량에 민감하고, /api/lab/posts/{id}는 실제 상세 조회보다 단순하다.
• saveMessage의 추가 SELECT, chat_hold_ms·lock_hold_ms의 Thread.sleep은 합성 지연이다. 절대값이 아니라 조건 간 상대 비교로만 사용한다.

2시간을 그대로 측정에 쓸 수 없다. 줄일 수 없는 오버헤드가 먼저 40분을 가져간다.

전제: 픽스처가 이미 배포되어 있고 exporter·Prometheus·Grafana가 살아 있다. deploy.sh up부터 시작해야 하면 빌드·전송·기동에 20분 이상이 더 들고 이 산정은 성립하지 않는다. 배포는 2시간 창 밖에서 끝내 둔다.

1. 배경 부하를 필요한 블록에만 켠다. F1-a·F1-b·F2 echo·F5는 REST 없이 실행한다. F1-c·F3·F4에서만 REST control/treatment를 실행한다. 배경을 계속 유지하면 순수 연결·메시지 단가와 REST 경합 비용이 섞이므로, 압축 실행의 편의보다 비교 가능성을 우선한다.
2. 램프 자체를 독립변수로 쓴다. 연결 수를 8단계로 나눠 각각 30분 유지하는 대신, 0→3,000을 12.5분에 걸쳐 선형으로 올리고 lab_ws_connections에 대해 heap·direct·CPU를 회귀한다. 5초 scrape이므로 표본 약 150점이 나오고, 연결당 단가(기울기)는 단계별 평균보다 오히려 안정적이다. 이 램프는 REST 없이 F1-a를 측정하고, 같은 연결 수준을 별도 REST treatment에서 재현해 F1-c를 측정한다.
3. 짧은 창에서는 이벤트율을 올린다. 90~120초 측정에서 36 msg/s는 표본이 너무 적다. 메시지 축은 120 msg/s로 고정하고 연결 수·payload만 바꾼다. RPS 계단도 90초(warm-up 15초 + 측정 75초)로 자른다.

아래는 REST 배경 부하를 §1.5에 맞게 목적별로 분리한 스케줄이다. loadtest-target/run-2h.sh가 이 순서를 그대로 실행한다(--plan 출력과 동일). 블록 단위 수동 실행은 --block <이름>을 쓴다.

loadtest-target/run-2h.sh --plan       # 스케줄 확인 (부하 없음)
loadtest-target/run-2h.sh --prepare    # T+00~10: 데이터 파일, run seed, smoke
loadtest-target/run-2h.sh --run        # T+10~94: 아래 표 전체를 무인 실행
loadtest-target/run-2h.sh --collect    # T+94~: 구간별 파생값 CSV

loadtest-target/run-2h.sh --block a    # 개별 블록만 (warm a b c d e f1c f g)

C 블록의 4셀은 200conn/256B · 200conn/8000B · 1800conn/256B · 1800conn/8000B다. 2×2가 완성되어야 §5의 회귀로 건수 비용 b와 바이트 비용 c를 분리할 수 있다. 3셀이면 교차항을 검증할 수 없어 "큰 컨텍스트가 더 무겁다" 수준의 인상만 남는다. 90분 창이라면 여기서 한 셀을 잃는다.

F1-c의 REST 간섭 결과는 A·B·C의 순수 비용 결과와 섞지 않는다. 별도의 REST만 control과 REST + WS treatment 구간을 만들고, control 대비 REST p95·오류율·Tomcat·Hikari 변화를 보고한다.

시간이 밀릴 때 버리는 순서: f의 700 RPS → g → b의 200 conn/s → d의 treatment → f1c. 블록 a와 e는 마지막까지 지킨다. a는 V2의 REST·WS 분리 결정에 직접 쓰이고, e는 1분짜리 실행으로 가장 강한 신호를 준다.

결론에 반드시 함께 적는다.

• 반복 3회가 없다. A'와 G가 각각 1회 control/treatment 또는 재측정일 뿐이다. 90120초 단일 측정에서 p95는 ±2030% 흔들리므로, 지연 차이는 30% 이상일 때만 실재로 인정하고, 1차 근거는 변동이 작은 자원 지표(연결당 heap, 메시지당 CPU-ms, CPU quota 사용률)로 삼는다.
• 30분 idle hold가 없다. 연결 누수·heartbeat 누적·완만한 heap 증가는 검출되지 않는다. C_safe soak(60~120분)도 이 창 밖의 과제다.
• 서버 설정 축을 건드릴 수 없다. HIKARI_MAX_POOL_SIZE, WS_PER_CONNECTION_BYTES, JVM_XMX 변경은 재배포와 JVM 냉시동을 부르고 블록 간 비교 가능성을 깨뜨린다. 이 창의 모든 축은 k6·데이터 파일 쪽에만 둔다. 풀 크기 대조(10 ↔ 20)는 별도 창에서 한다.
• CPU credit을 통제할 수 없다. 120분 연속 부하는 baseline 20%를 계속 넘으므로 credit을 소모한다. 시작 전 CPUCreditBalance를 기록하고, standard 모드에서 잔량이 적으면 unlimited로 바꾸거나 블록 A를 먼저 끝낸다 는 전제로 진행한다. balance가 0에 닿은 뒤의 구간은 용량 한계가 아니다.
• lock_hold_ms·chat_hold_ms는 각각 한 값(100ms / 0·50ms)만 본다. §6·§7의 다단계 비교는 이 창에서 성립하지 않는다.
• §12의 픽스처 한계(fan-out·방 개념 없음)는 시간과 무관하게 그대로다.

loadtest-target/collect-window.py가 results/runs.tsv의 실행 구간마다 Prometheus를 조회해 §2.2 파생값을 CSV로 만든다. 램프 런(a-, a2-)은 lab_ws_connections에 대한 최소제곱 회귀로 연결당 heap·direct bytes와 1,000 연결당 CPU 코어까지 함께 출력한다.

loadtest-target/run-2h.sh --collect          # PROM_URL 은 terraform output 에서 자동
PROM_URL=http://<monitoring-ip>:9090 loadtest-target/run-2h.sh --collect

CSV를 받으면 §11의 결정표를 그 자리에서 채운다. 정합성은 hot run stats로 확인한다.

curl -sk https://$(cat loadtest-target/.local/public_host)/api/lab/runs/h-L100/stats \
  | python3 -m json.tool
# parties[i].approved + parties[i].remaining == capacity 인지 확인

--prepare가 .local/fixture-runs.json의 base/hot을 새 run으로 덮어쓰므로, 창이 끝나면 되돌린다.

python3 loadtest-target/make-test-data.py --base-run base-01 --hot-run hot-01