질문은 하나다. 우리 서비스는 동시 접속 몇 명까지 버티는가.
8/16에 로컬 환경으로 세 번의 런을 돌렸다. 이 보고서는 그중 배달 구간을 포함한 두 런(주문 250건 · 400건)을 대상으로 한다.
결론부터 적는다.
http://localhost:8080 + H2이고, 배포환경은 cpus: 1 · mem_limit: 800m · MySQL이다. 배포환경에서 검증된 최대치는 계정 200명이며(매칭 부하테스트 보고서 (8.13)), 같은 조건에서 무너진 런도 있다(매칭 부하테스트 보고서 (8.13 · 외부 API 트랜잭션)).따라서 지금 시점에 "동시 몇 명까지 버티는가"에 대한 정직한 답은 모른다이다. 이 보고서는 그 대신 무엇이 측정됐고 무엇이 측정되지 않았는지를 분리해 둔다.
용량 논의가 어긋나는 첫 번째 이유는 축이 섞이기 때문이다. 이 보고서는 네 축을 구분한다.
| 축 | 정의 | 부하의 성격 |
|---|---|---|
| 동시 접속 계정 | 로그인 세션을 갖고 SSE 스트림을 유지 중인 계정 수 | 상시 점유 — 커넥션·스레드·메모리를 계속 잡는다 |
| 동시 배달 | IN_PROGRESS 상태의 배달 건수 |
위치 전송의 발생원 |
| 주문 유입률 | 초당 신규 주문 수 | 순간 압력 — 매칭 배치·카카오 API를 때린다 |
| 위치 전송률 | 초당 POST /dreami-location 호출 수 |
상시 쓰기 부하 |
세 축이 서로 독립적이지 않다는 점이 문제의 핵심이다. 하네스에서 DREAMI_COUNT 하나가 동시 접속 계정 수와 동시 배달 상한을 동시에 결정한다(6절).
| 항목 | 2차 런 | 3차 런 |
|---|---|---|
| 규모 | 드리미 250 · 부르미 250 · 주문 250 | 드리미 400 · 부르미 400 · 주문 400 |
| 동시 접속 계정 | 500 | 800 |
| 주입 속도 | 초당 15건 | 초당 15건 |
| 배달 | 포함 (DELIVERY=1) |
포함 (DELIVERY=1) |
| 위치 전송 주기 | LOCATION_INTERVAL_MS=5000 |
LOCATION_INTERVAL_MS=5000 |
| 실클라이언트 | 미실행 (WATCH=0) |
미실행 (WATCH=0) |
| 기간 | 23:41:26 → 23:47:05 (339초) | 23:58:43 → 00:04:29 (346초) |
| 배달 구간 | 284초 | 276초 |
| 동시 배달 피크 | 250 | 400 |
| 판정 | 통과 | 통과 |
두 런에서 달라진 것은 규모뿐이다. 주입 속도가 같으므로 순간 압력은 동일하고, 램프 구간만 16.7초에서 26.7초로 길어졌다.
| 항목 | 8.16 런 (이 문서) | 8.13 런 (배포환경) |
|---|---|---|
| API | http://localhost:8080 |
https://d3cev4xst074qp.cloudfront.net |
| DB | H2 (jdbc:h2:tcp://localhost/~/test;MODE=MySQL) |
MySQL |
| 인스턴스 | 개발용 로컬 머신 | cpus: 1 · mem_limit: 800m |
| 커넥션 풀 | — | maximum-pool-size=10 |
| 로그인 대기열 | 동작 (permits 기본) |
login.queue.permits=2 |