Incident Library

IL-0314 Daily · 2023-02-07databaseaws

주말에 업그레이드한 Aurora MySQL 데이터베이스에서 교착이 쌓여 통화 서버가 재시작되고 통화가 다른 서버로 옮겨졌다

Daily 는 주말에 데이터베이스 서버를 업그레이드했고, 데이터베이스는 월요일까지 정상으로 돌았다. 2023-02-07 9:47 AM 동부 시간, 14:47 UTC 에 평소 부하에서 데이터베이스 성능 문제 알림이 울렸고, 알림은 높은 락 경합을 가리켰다. 9:51 에 엔지니어들은 meeting events 쿼리가 대량으로 교착에 걸린 것을 찾았다. SFU 가 참가자의 입장과 퇴장을 기록하는 쿼리였다. 이 교착으로 webapp API 요청이 타임아웃되며 5xx 를 냈고, SFU 는 데이터베이스에 연결하지 못하자 스스로 종료했다. 오토스케일링이 새 SFU 를 띄우는 동안 meeting move 가 평소보다 많아져 데이터베이스에 부하를 더했다.

10:13 에 팀은 마이그레이션 뒤에도 옛 데이터베이스를 최신으로 맞추려고 켜 둔 MySQL binlog 복제를 끄고 데이터베이스를 재시작했다. 나아지긴 했지만 SFU 가 교착을 일으키던 쿼리를 재시도해 문제가 이어졌다. 팀은 AWS 지원에도 연락했다. 10:47 에 엔지니어들이 멈춘 쿼리를 끊는 스크립트를 만들던 중 데이터베이스가 갑자기 스스로 재시작했다. 이번 재시작은 10:13 의 재시작보다 조금 길었다. 그 덕분에 SFU 는 재시작할 만큼 오래 끊기지 않으면서 오래된 meeting 업데이트를 버릴 수 있었다. 이때 SFU 와 플랫폼이 정상으로 돌아왔고, 11:01 에 모니터링 상태로 넘어갔다. 영향은 14:47 에서 15:47 UTC 까지 거의 정확히 한 시간이었다.

Daily 는 교착이 주말 점검으로 올라간 MySQL 포인트 릴리스의 저수준 동작 변경 때문이라는 것을 증명했다. 그래서 이 동작 변경을 피하려고 영향받은 테이블 하나의 인덱스를 고치기로 했다. 그 주 내내 운영 데이터베이스를 바꿀 계획을 만들어 시험했고, 토요일 저녁에 사용자 영향 없이 작업을 끝냈다. 그 사이 예방 조치로 방을 만드는 REST API 엔드포인트에 요청 제한을 걸었다. MySQL 5.7 에서 교착을 더 보수적으로 다루도록 바뀐 것은 알려진 변경이었다. Aurora MySQL 2 는 MySQL 5.7 을 바탕으로 한다. 그러나 Aurora MySQL 2.11.0 에서 겪은 교착의 심각도는 Daily 에게도 AWS Aurora 팀에게도 뜻밖이었다.

심각도
–
영향 범위
API, Dashboard and Core Call Experience: some users in calls had meeting moves with video and audio dropping for a few seconds, a small number may have failed to join a room during a move, and some REST API requests returned 5xx errors
영향 사용자
Some users in Daily calls and some REST API clients
지역
–
감지까지
0m
복구까지
1h

증상

2023-02-07 9:47 AM 동부 시간에 평소 부하에서 데이터베이스 성능 문제 알림이 울렸다. 알림 내용은 주말에 업그레이드한 데이터베이스의 락 경합이 높다는 것이었고, 이 때문에 통화 서버인 SFU 가 문제를 겪었다.

상태 페이지의 첫 공지는 플랫폼 오류율이 높고, 사용자가 통화에 들어갈 때 websocket 연결 오류가 날 수 있다고 알렸다. meeting move 는 진행 중인 통화 세션이 한 통화 서버에서 다른 통화 서버로 옮겨 가는 일이고, 이때 통화 중인 사용자는 다른 사람의 영상과 음성이 몇 초 끊겼다 돌아오는 것을 겪는다. 이번에는 meeting move 가 평소보다 자주 일어났다. meeting move 가 일어나면 녹화나 라이브 스트리밍을 다시 시작해야 할 수도 있었다. REST API 요청은 타임아웃되거나 5xx 오류를 받을 수 있었다.

9:51 에 엔지니어들은 교착에 걸린 대량의 쿼리를 찾았다. SFU 가 참가자의 입장과 퇴장을 기록하는 meeting events 쿼리였다. 이 교착 때문에 webapp API 요청이 타임아웃되며 5xx 를 냈고, 결국 SFU 가 연결을 끊고 재시작했다.

SFU 는 데이터베이스에 연결하지 못하면 스스로 종료하고, 오토스케일링이 새 SFU 를 띄운다. 여러 SFU 가 동시에 내려가고 올라오면서 meeting move 가 평소보다 많아졌고, 이것이 이미 부하가 높던 데이터베이스를 더 압박했다.

10:13 에 팀은 교착의 원인 후보 하나를 찾았다. 지난 주말 마이그레이션 뒤에도 옛 데이터베이스를 최신으로 맞추려고 켜 둔 MySQL binlog 복제였다. 복제를 끄고 데이터베이스를 재시작하자 나아졌지만, 많은 SFU 가 교착을 일으키던 쿼리를 재시도해 문제가 이어졌다. 팀은 조사를 계속하며 AWS 지원에도 연락했다.

증상 잠금 경합과 교착오류율 상승간헐적 타임아웃

원인

원인 업그레이드로 깨진 호환성

구성 요소 데이터베이스
기여 요인 스테이징 불일치자동화 증폭재시도 폭주늦게 드러난 변경
촉발
Daily 는 주말에 데이터베이스 서버를 업그레이드했고, 이 작업으로 데이터베이스가 MySQL 포인트 릴리스의 저수준 동작 변경이 들어간 버전으로 올라갔다. 월요일까지 정상이던 데이터베이스가 2월 7일 평소 부하에서 대량의 교착을 일으켰다.

감지

9:47 AM 동부 시간에 평소 부하에서 데이터베이스 성능 문제 알림이 울렸고, 알림은 새로 업그레이드한 데이터베이스의 높은 락 경합을 가리켰다.

조치

후속 조치

교훈

Daily 는 모든 인프라 변경을 운영과 비슷한 부하로 시험하려 하지만, 이번에는 이 교착을 일으킬 만한 형태의 합성 부하로 시험하지 못했다. MySQL 5.7 에서 교착 처리가 더 보수적으로 바뀐 것은 알려진 변경이었어도, 실제로 겪은 교착의 심각도는 Daily 와 AWS Aurora 팀 모두에게 뜻밖이었다.

출처

관련 사례

내 클러스터에도 있는지 확인하기

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: 데이터베이스. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

kubegap 열기

AI 도구와 스크립트용

API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.