[Perf] 자동 Worker 수·실행 슬롯별 전체 인덱싱 수평 확장 Benchmark 추가

[Gimini-3]

목적

실제 PostgreSQL 17·pgvector·MinIO·BAAI/bge-m3 환경에서 자동 인덱싱 Worker 수와 Worker별 실행 슬롯 수를 변경하며 전체 문서 인덱싱 처리량, 지연, 가속비와 수평 확장 효율을 측정한다.

기존 단일 Worker·실행 슬롯 2개 처리량 기준선을 확장해 Worker 인스턴스를 늘렸을 때 Job이 실제로 분산되는지, Queue 대기와 전체 처리량이 어떻게 변하는지 수치로 확인한다.

범위

• Benchmark 조정용 API Context와 실제 Job 실행용 Worker Context를 분리한다.
• Worker Context마다 고유 Worker 이름·Instance ID·Executor·Hikari Pool을 사용한다.
• 실제 FOR UPDATE SKIP LOCKED Claim과 Worker 소유권으로 Job을 분산한다.
• 기본 Profile 1×1, 1×2, 2×1, 2×2, 4×2를 제공한다.
• Profile과 문서 수·반복 수를 System Property로 변경할 수 있게 한다.
• 실제 HTTP 업로드→MinIO→Parsing→Chunk→BGE-M3→vector(1024)→INDEXED 전체 경로를 측정한다.
• 문서/초·문서/분·Chunk/초·Embedding/초와 Queue·처리·전체 p50/p95/p99를 기록한다.
• 1×1 대비 Speedup과 전체 슬롯 기준 Scaling Efficiency를 계산한다.
• Profile별 Worker 처리 Job 분포와 다중 Worker 참여 여부를 검증한다.
• Job·Attempt·Event·Chunk·Embedding·Vector·검색 Version 불변식을 검증한다.
• 실행마다 UUID 기반 전용 Schema와 Bucket을 사용하고 Secret을 결과에 기록하지 않는다.
• 일반 회귀와 분리된 전용 Gradle Task 및 Git 제외 JSON Report를 제공한다.
• 실제 측정 결과와 환경·한계를 docs/test-results/에 기록한다.

측정 원칙

• Worker Context 시작·종료 시간은 처리량에 포함하지 않는다.
• 같은 결정적 TXT Corpus와 문서 수를 모든 Profile에 사용한다.
• Profile별 Warm-up은 결과 통계에서 제외한다.
• Worker 수가 2개 이상이면 두 개 이상의 Worker가 실제 성공 Attempt를 처리해야 한다.
• 정합성 검증이 실패한 실행은 성능 결과로 인정하지 않는다.
• Local 동일 Host의 다중 Spring Context 결과임을 명시하고 다중 VM 성능으로 일반화하지 않는다.

제외

• Rocky Linux 공식 OpenSQL 원격 환경 재측정
• 다중 물리 서버·Kubernetes 배포 Benchmark
• Queue 허용 한계와 강제 Backpressure 정책 구현
• PDF·DOCX 형식별 Parser 성능 비교
• GPU BGE-M3 처리량 비교

완료 조건

• 실제 Worker 1·2·4개와 슬롯 조합이 같은 Job Queue를 처리한다.
• Worker별 Job 분포, 처리량, 지연, Speedup과 Scaling Efficiency가 JSON에 기록된다.
• 모든 Profile에서 Chunk·Embedding 수가 일치하고 모든 Vector가 1024차원이다.
• 일반 테스트와 전용 Smoke·정식 Benchmark가 통과한다.
• 측정 결과에서 확장 이점과 병목·한계를 재현 가능한 문서로 설명한다.