매칭 테스트 중 매칭 로직 자체에서 구조적인 문제를 발견하여, 조건을 바꿔가며 재현 테스트를 수행했습니다. 본 테스트는 모든 부르미와 드리미가 동시에 콜을 등록하는 최악의 상황을 가정합니다.
| 항목 | 정의 |
|---|---|
| 오더 요청 수 | 부르미 수와 동일 (부르미 1명당 주문 1건) |
| 매칭 락 수 | 하나의 offer 요청이 한 번에 호출하는 드리미 수 (기본값 3) |
| 동시 요청 | k6 VU 기준 동시 API 요청 수 |
| 주문등록 → 첫 Offer 제출 p99 | 부르미가 주문을 등록한 시점부터, 임의의 드리미 한 명에게 첫 offer가 도달하기까지의 지연 (클라이언트 관측 기준) |
이 지표는 "매칭이 성사되기까지"가 아니라 "매칭 시도가 시작되기까지"의 시간이다. 즉 이 값이 크다는 것은 호출할 드리미가 없어 매칭 시도 자체가 시작되지 못했다는 의미다.
| case | 부르미 | 드리미 | 동시요청 | 매칭 락 수 | 첫 Offer 제출 p99 |
|---|---|---|---|---|---|
| 1 | 1000 | 1000 | 100 | 3 | 96,896 ms |
| 2 | 500 | 500 | 100 | 3 | 64,236 ms |
| 3 | 250 | 250 | 20 | 3 | 43,600 ms |
| 4 | 250 | 250 | 10 | 3 | 40,000 ms |
| 5 | 250 | 250 | 10 | 15 | 148,523 ms |
| 6 | 250 | 250 | 10 | 1 | 2,132 ms |
| 7 | 250 | 750 | 10 | 3 | 2,045 ms |
테스트 서버의 Tomcat thread 수와 DB 커넥션 수를 파악하지 않은 상태에서 동시 요청 수를 과도하게(100) 설정했습니다. 그 결과 매칭 지연이 아니라 API 요청 처리 단계에서 대기와 timeout이 발생했습니다.
본 테스트 결과는 매칭 알고리즘의 특성이 아니라 인프라 한계를 측정한 값이므로, 지표로 사용하지 않습니다.
동시 요청 수를 10~20으로 낮춰 인프라 병목을 제거하고, 순수 매칭 지연만 관측했습니다.