Api::V1::AssetsController#create (avg 125457ms, max 125457ms)

What Happened#

2026-07-10 16:49 KST 경 cupixworks-api (ap-southeast-2)의 Api::V1::AssetsController#create 요청이 125.5초 소요된 뒤 200 으로 완료됨. 같은 시간대에 built (team 16) 테넌트의 여러 write 엔드포인트가 Mysql2::Error::TimeoutError: Lock wait timeout exceeded (50 s) 로 502 를 반환했고, 다른 write 요청들도 60 s 이상 지연됨. RDS MySQL 의 광범위한 InnoDB row-lock contention 이벤트로 판단됨.

Quick Facts#

Affected Teams#

Timeline#

1. 2026-07-10 16:47:25 KST — 초기 정상 상태: 동일 capture(81421) CapturesController#update 요청이 810 ms(db 78 ms)로 완료.
2. 2026-07-10 16:48:47 KST — 첫 이상 조짐: capture 81421 update 가 39.8 s(db 33.4 s)로 지연.
3. 2026-07-10 16:49:21 KST — 대상 클러스터 이벤트 발생 시각 (first_seen). scs-assetfuture 팀에서 POST /api/v1/assets(capture 81477, 3.mp4) 시작 — 이 시점부터 클러스터 카운트가 잡힘.
4. 2026-07-10 16:51:16–16:51:20 KST — built 테넌트의 세 개 요청이 정확히 50 s 만에 Mysql2::Error::TimeoutError: Lock wait timeout exceeded 로 502 반환 (Api::V1::AssetsController#update, Api::V1::PanosController#check_tile_uploading, Api::V1::CapturesController#update).
5. 2026-07-10 16:51:27 KST — 락이 해제되면서 대상 AssetsController#create 요청이 125.5 s 만에 200 으로 완료. 같은 초에 19 건의 60 s 이상 걸린 요청이 일제히 완료됨(파노 stitched/check_tile_uploading, asset update, bim create_resource 등).
6. 2026-07-10 16:51:32 KST — capture 81421 update 가 다시 810 ms 수준으로 회복.

Scoring#

Confidence 85% · Actionability 28%

Confidence#

Actionability#