부하 rig의 액세스 토큰이 30분에 만료된다 — 3시간 soak가 30분 뒤 조용히 무부하가 된다

[Khyojae]

무엇

measure_ai_worker_load_soak.sh 는 준비 단계에서 로그인 1회로 받은 accessToken 을 워커가 전체 실행 시간 내내 재사용한다. 재발급 경로가 없다.

• 토큰 획득: loadtest/measure_ai_worker_load_soak.sh:42 → tokens.txt 에 적재(:33)
• 워커가 그 파일을 그대로 읽어 씀: :105, :107 — 루프 안에서 다시 로그인하지 않는다
• access token TTL: backend/src/main/resources/application.yml:338 — JWT_EXPIRATION_TIME:1800 (30분)
• 단위 확인: JwtUtil.java:77 now.plusSeconds(expireTime) — 초가 맞다

왜 문제인가

설계 기본값이 DURATION_SEC=10800(3시간)이다. 즉 부하 시작 30분 뒤 203개 워커의 토큰이 전부 동시에 만료된다.

만료 후 워커 루프의 동작(:80~85):

resp=$(curl ... POST /exercises/sessions ...)      # 401
sid=$(... grep -oE '"sessionId":[0-9]+' ...)       # 빈 값
if [ -z "$sid" ]; then failed++; START_FAIL; sleep 5; continue; fi

→ 남은 2.5시간 동안 5초마다 401 을 받는 루프가 되고, 동접은 목표 203이 아니라 사실상 0이 된다. 그 상태로 판정 채널(RestartCount·OOMKilled)은 얌전히 "장애 0회"를 찍는다. 부하가 없어서 안 죽은 것을 "이 강도에서 안전하다"로 읽게 된다.

왜 지금까지 안 드러났나

2026-08-28 라운드 두 번이 각각 90초·10분 만에 박스 정지로 끝나서, 이 rig 이 30분을 넘겨 돌아본 적이 한 번도 없다. (결과)

재현

DURATION_SEC 을 1800 이상으로 두고 돌린 뒤 workers/w*.log 에서 30분 지점 이후 START_FAIL 이 연속으로 찍히는지 본다. 30분 미만 판에서는 재현되지 않는다.

🔴 미검증

• 실제로 401 을 받아본 적이 없다. 코드 경로로만 확인했다 — rig 이 응답 코드를 안 찍고 sessionId 유무만 보기 때문에, 만료 시 어떤 상태코드·본문이 오는지는 이 이슈가 확인하지 않았다. START_FAIL resp= 에 본문이 남으므로 실측 시 거기서 확인 가능
• 만료 시각이 203개 계정에 정확히 동시에 오는지는 준비 단계가 PREP_SLEEP=2.5 로 약 8분에 걸쳐 로그인하므로 그만큼 번진다 — "동시"가 아니라 "8분에 걸쳐 순차 만료"가 맞다

고칠 방향 (미결정)

두 갈래이고 무대 조건이 달라져서 결정이 필요하다:

1. rig 에 재발급/재로그인 — 401 이면 재로그인 후 재시도. 부하 모양이 실제 클라이언트에 가까워지지만 rig 변경이다
2. 라운드 한정으로 JWT_EXPIRATION_TIME 상향 — 손잡이가 이미 있어 코드 변경 0. 대신 측정 조건에 "토큰 수명을 바꿨다"가 붙는다

관련: loadtest/aws/ROUND-2026-09-08-ebs-causality.md — 이 라운드의 Q2 본판(3시간)이 정확히 이 결함에 걸린다

[Khyojae]

처방 ㉡ 확정 (2026-09-08 사용자 결정) — rig 에 재로그인을 넣는 ㉠ 대신, 이미 있는 손잡이(JWT_EXPIRATION_TIME)를 라운드 한정으로 상향한다. 코드 변경 0이다.

값은 임의로 고르지 않고 제약에서 유도한다:

JWT_EXPIRATION_TIME  ≥  계정 준비 시간 + DURATION_SEC + TAIL_SEC

Q2 본판 기준 하한이 11,400초 + 준비 시간이다. 실제로 넣은 값과 그때의 준비 소요는 MANIFEST.txt 에 같이 적어 **「얼마를 줬나」가 아니라 「왜 그 값인가」**가 남게 한다. 네 팔 전부 같은 값을 써서 토큰 수명이 새 교락 변수가 되지 않게 한다.

이 이슈는 닫지 않는다. ㉡ 은 측정 라운드가 결함을 우회하는 방법이지 rig 을 고친 게 아니다 — 부하 rig 이 3시간짜리 판에서 토큰을 재발급하지 않는다는 사실 자체는 그대로 남는다. 다음에 이 rig 으로 30분 넘는 판을 돌리는 사람은 같은 자리를 다시 만난다.

대가는 결과 조건 칸에 **「토큰 수명을 바꿔서 쟀다」**가 영구히 붙는 것이고, 매니페스트 §9 에 박아뒀다.

절차: loadtest/aws/ROUND-2026-09-08-ebs-causality.md §4-ㅁ

[Khyojae]

라운드에서 결함 하나가 더 드러났다 — 실패 경로가 레이트리밋 보호를 건너뛴다. 로그인 실패 시 continue 가 sleep "$PREP_SLEEP" 를 지나쳐서, 첫 실패가 나면 203건이 1초 만에 소진된다(2026-09-08 판 2 에서 실제로 그렇게 됐다 — emails.txt 203개가 전부 같은 date +%s). 원인 진단을 어렵게 만드는 자리라 이 이슈에 같이 적어둔다. 상세: 결과 §5-3