docs: 회차 10 — 매칭 상한 29 RPS 의 진범은 RDS CPU (스레드 덤프·동시성 실측)

[popeye0618]

요약

OSIV off(#92) 재측정에서도 상한이 ~29 RPS 그대로였다. 두 처방(#91 트랜잭션, #92 OSIV off)이 연속 기각된 뒤 배제 실험으로 진범을 확정했다.

실험	결과
계정 10개 동시 요청	전부 0.13~0.18s — 전역 락 아님
표본 쿼리 단독 실측 (RDS)	10ms — SQL 자체는 빠름
스레드 덤프 (50 RPS 부하 중)	요청 스레드 78/106 이 Hikari 풀 대기, 커넥션 보유자는 전원 쿼리 실행 중
표본 쿼리 10개 동시	단독 129ms → 1,084ms — 동시성 아래 ~10배 붕괴

결론: RDS(db.t3.micro, 2 vCPU 버스터블, 버퍼풀 128MB)가 상한이다. 매칭 1건 = 표본 5,000행 temp table/filesort + 제외 목록 + INSERT + 티켓 UPDATE + 프로필 2회, 6개 서비스가 이 한 대를 공유 — 건당 RDS CPU 60~70ms × 29/s ≈ 2코어 포화. 앱을 뭘 고치든 꿈쩍 안 한 이유.

EC2 호스트도 25 RPS 에서 컨테이너 합 176%/200% — RDS 다음 벽.

OSIV off 는 유지(부작용 0 확인, 커넥션 수명 위생). Kafka 체인은 3회차 누적 36,878/36,878 손실 0.

다음 지렛대

1. 표본 5,000→2,000 (80점 이상 확보 99.9%→94.2%, 회차 3 분포표) — RDS CPU 60% 절감, 코드 상수 하나
2. RDS 스케일업 — 런칭 규모 산정과 함께
3. EC2 분리/스케일업

docs 만 변경 — 머지해도 배포 없음.

🤖 Generated with Claude Code