test(S15P11A705-283): 로컬 천만 건 규모 벤치 환경 구축

[minyongP]

요약

현재 시드(record 117k)에서는 플래너가 Seq Scan을 골라도 손해가 없어 인덱스 설계가 판별되지 않는다. record 1,000만 · 회원 10만 규모를 296초에 적재하는 순수 SQL 생성기와, 캐시 적중률 99.99%의 비현실을 걷어내는 자원 한도 override를 추가한다.

Jira (필수)

• 키 또는 URL: S15P11A705-283

변경 사항

• loadtest/tools/seed-massive.sql — generate_series 기반 생성기. 기존 데이터를 지우지 않고 새 id를 최대값 뒤에 이어 붙여 골든 셋·기존 시드·하네스 참조를 보존. 분포는 5구간표(monster 50명×2만 ~ tiny 5만명×8)로 회원당 record가 실측 형태(p50 19 · p90 103)를 유지. 비유니크 인덱스만 내렸다 되돌리고(pg_get_indexdef 왕복) 유니크는 남겨 생성기 결함이 그 자리에서 터지게 함. identity 시퀀스 재정렬 + ANALYZE 포함
• loadtest/tools/verify-massive.sql — 완료 조건 10종(행 수·분포·골든 보존·통계 갱신·BD-11/20/33 값 정합)을 PASS/FAIL 판정, FAIL 시 0이 아닌 종료 코드. 정합 검사는 벤치 생성분 한정 — 기존 시드의 알려진 기준선(빈 Collection 137건, BI-33)과 생성기 결함을 구분하기 위함
• loadtest/tools/teardown-massive.sql — BENCH- 표식으로 벤치 행만 걷어내는 되돌리기(FK 역순 삭제 + VACUUM)
• loadtest/tools/run-massive.sh — 적재+검증 오케스트레이션. 자원 한도가 걸린 컨테이너를 감지하면 적재를 중단(한도 안에서 인덱스 재생성이 기어가는 사고 방지)
• compose.bench.yaml — 측정용 자원 한도 override(운영 StatefulSet과 같은 1Gi·1cpu). 기본 compose.yaml 무변경, override 없이 띄우면 기존과 동일(합성 확인)
• loadtest/README.md — 「대량 벤치」 절과 적재 실측 수치
• docs/backend/worklog/2026-08-03-S15P11A705-283-massive-bench.md

테스트 / 검증

• ./gradlew clean check --no-daemon — BUILD SUCCESSFUL in 1m 55s (Java 변경 없음)

RED — 검증 게이트가 실제로 실패를 잡는지:

docker exec -i back-postgres-1 psql -U pinlog -d pinlog -v ON_ERROR_STOP=1 < verify-massive.sql
=== FAIL 1 건 — 위 표를 볼 것 ===  (첫 전체 실행: 기존 시드의 빈 Collection 137건을 전역으로 세어 FAIL)
종료코드=3

정합 검사를 벤치 생성분으로 한정해 해소(137건은 BI-33에서 시드 생성기 산물로 삼분류된 기준선).

GREEN — 본 적재(회원 10만 → record 1,000만) 후 검증 전부 통과:

bash loadtest/tools/run-massive.sh
적재 소요: 296초, DB 707MB → 5,906MB
PASS 10/10 — record=10,117,022 · member=103,007 · p50=19 p90=103 max=20,000 ·
             골든 6/6·25/25·25/25 · BD-11/20/33 정합 · BENCH 계정 100,000건
종료코드=0

한도 동작 실측 — override를 얹은 콜드 스캔에서 캐시 적중률 0%, 디스크 읽기 369,185블록(약 2.9GB):

docker compose -p back -f compose.yaml -f compose.bench.yaml up -d postgres
SELECT pg_stat_reset(); (대량 스캔 3종 실행)
heap 적중률 0.00% | 디스크 읽기 369,185블록

override 제거 후 mem_limit=0 복귀·앱 health 200 확인.

리뷰 포인트

1. seed-massive.sql의 place 회전식 (idx * 7919 + k) % :places — 회원당 record ≤ 20,000 ≤ places 전제에서 uq_record_active 충돌이 없는지
2. 정합 검사를 벤치 생성분으로 한정한 판단 — 전역 기준선은 verify-invariants.sql 소관으로 남김

미결 / 후속

• 이 볼륨 위 실행 계획 관측은 S15P11A705-284가 이어받는다
• 소프트 삭제 프로파일(부분 인덱스 판별)은 범위 밖 — 후속 티켓 후보
• ai 스키마·feed_event는 만들지 않으므로 Keyword 집계·노출 패널티 쿼리는 이 볼륨으로 검증 불가

🤖 Generated with Claude Code