GET 502 (avg 50660ms, max 50815ms)

What Happened#

2026-06-17 04:42 KST 무렵 production-us-west-2 의 cupixworks-api 에서 인증 미들웨어가 모든 요청마다 발급하는 UPDATE users SET first_sign_in_at = ? 쿼리가 동일한 user row 에 대한 row lock 대기로 50초간 hang 되어 InnoDB lock wait timeout (~50s) 에 걸렸다. Puma 가 응답을 만들지 못한 사이 Elastic Beanstalk/ALB 가 idle/upstream timeout 으로 502 를 반환했고, APM 은 이 요청들을 resource_name: GET 502 로 묶었다. 같은 사용자 세션에서 병렬로 떠난 두 건의 GET /api/v1/sessions?fields= 가 서로 같은 row 를 잠그며 동시에 timeout 됐다.

Quick Facts#

Affected Teams#

Timeline#

1. 2026-06-17 04:42:29 KST — host i-0a026d499fb305739 에서 GET /api/v1/sessions?fields= 시작 (trace 1083198673863158736).
2. 2026-06-17 04:42:37 KST — host i-09eb846280d67ac02 에서 두 번째 GET /api/v1/sessions?fields= 시작 (trace 3060560276632410961). 동일 user row 에 BEGIN + UPDATE 진입.
3. 2026-06-17 04:42:37 KST (+0ms) — 두 트랜잭션 모두 같은 row 의 X-lock 을 요청. 첫 트랜잭션이 잡고 두 번째가 대기 시작.
4. 2026-06-17 04:43:28 KST (~50.5s 뒤) — 두 UPDATE 모두 InnoDB innodb_lock_wait_timeout (50s) 으로 종료, ROLLBACK. Puma 는 5xx 응답 직전이지만 이미 ALB 가 502 로 응답을 끊어 resource_name: GET 502 로 분류됨.
5. 2026-06-17 04:43:28 KST 직후 — 후속 요청은 정상 (/api/v1/sessions 200 로그가 04:42:39 KST 부터 다수 관찰).

Scoring#

Confidence 85% · Actionability 32%

Confidence#

Actionability#