사례21건

21건 중 14~18번째

1. IL-0524 인덱스를 다시 만드는 마이그레이션이 운영에서 Transactions 테이블을 잠가 Open Collective 서비스가 느려짐

   Open Collective2023

   증상

   2023년 4월 4일 09:13 UTC 에 배포를 시작하고 7분 뒤인 09:20 UTC 에 서비스 성능 저하가 보였다. 운영에서 실행한 마이그레이션이 Transactions 테이블 전체를 잠근 상태였다.

   잠금 경합과 교착데이터베이스 과부하

   촉발

   2023년 4월 4일 09:13 UTC 에 성능을 높이려고, 소프트 삭제된 행을 빼고 Transactions 테이블의 인덱스를 다시 만드는 마이그레이션을 배포했다.

   원인

   배포 결함

   구성 요소

   데이터베이스스키마 마이그레이션

   기여 요인

   리뷰 누락스테이징 불일치

   감지

   배포를 시작하고 7분 뒤인 09:20 UTC 에 서비스 성능 저하를 알아챘다.

   조치

   • 마이그레이션을 죽였지만 Transactions 테이블은 잠긴 채로 남았다.
   • 쿼리를 줄이려고 프런트엔드를 점검 모드로 돌렸다. 사용자에게는 분명한 안내 문구가 보였다.
   • 데이터베이스에 붙어 있던 다른 연결을 닫았다.
   • 새 인덱스 생성을 취소하고 10:00 UTC 부터 옛 인덱스를 되살렸으며, 10:05 UTC 에 복원이 끝나 성능이 정상으로 돌아왔다.
   • 10:08 UTC 에 프런트엔드를 되살리고 문제가 해결됐다고 공식으로 확인했다.

   후속 조치

   • vegeta 같은 도구로 로컬에서 운영 부하를 흉내 내는 스크립트를 더한다.
   • 이런 마이그레이션은 정해진 점검 시간대에 돌린다.
   • 앞으로 마이그레이션은 새 인덱스를 먼저 만들고 옛 인덱스를 나중에 지운다.
   • PR 을 머지하기 전에 다른 엔지니어의 리뷰를 꼭 받는다. 이번 PR 은 팀에 공유됐지만 리뷰되지 않았다.

   교훈

   옛 인덱스를 지우고 새 인덱스를 만드는 방식은 쿼리가 끊임없이 들어오는 테이블에서 너무 낙관적이었다. 로컬과 staging 에서 시험해도 부하가 걸린 환경에서 마이그레이션을 돌려 볼 도구가 없으면 이런 문제를 미리 잡지 못한다. 문제를 빨리 알아채고 엔지니어 두 명이 함께 조사한 것과, 사용자에게 분명한 안내를 보이면서 영향을 줄인 프런트엔드 점검 모드는 도움이 됐다.

   사례 보기
2. IL-0314 주말에 업그레이드한 Aurora MySQL 데이터베이스에서 교착이 쌓여 통화 서버가 재시작되고 통화가 다른 서버로 옮겨졌다

   Daily2023

   증상

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

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

   촉발

   Daily 는 주말에 데이터베이스 서버를 업그레이드했고, 이 작업으로 데이터베이스가 MySQL 포인트 릴리스의 저수준 동작 변경이 들어간 버전으로 올라갔다. 월요일까지 정상이던 데이터베이스가 2월 7일 평소 부하에서 대량의 교착을 일으켰다.

   원인

   업그레이드로 깨진 호환성

   구성 요소

   데이터베이스

   기여 요인

   스테이징 불일치자동화 증폭재시도 폭주늦게 드러난 변경

   감지

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

   조치

   • 10:13 에 옛 데이터베이스를 최신으로 맞추던 MySQL binlog 복제를 끄고 데이터베이스를 재시작해 부하를 줄였다. 나아졌지만 SFU 가 교착을 일으키던 쿼리를 재시도해 문제가 이어졌다.
   • 10:47 에 데이터베이스가 갑자기 스스로 재시작했다. 이 재시작 덕분에 SFU 는 재시작하지 않고 오래된 meeting 업데이트를 버릴 수 있었고, 플랫폼이 정상으로 돌아왔다.
   • 예방 조치로 방을 만드는 REST API 엔드포인트에 요청 제한을 걸었다. POST /rooms 의 한도를 DELETE /rooms/:name 과 같은 초당 약 2회, 30초에 50회로 맞췄다.
   • MySQL 동작 변경을 피하려고 영향받은 테이블 하나의 인덱스를 고쳤다. 그 주 동안 계획을 만들어 시험했고 토요일 저녁에 사용자 영향 없이 운영 데이터베이스에 적용했다.

   후속 조치

   • 운영 환경의 Aurora MySQL 2.11.0 에서 본 교착 문제를 문서로 남기고 원인을 밝혀 다음 릴리스에서 고치도록 AWS 와 계속 협력한다.
   • 시험 부하에 API 요청 패턴을 더했다.
   • 더 세밀한 데이터베이스 지표를 보는 운영 모니터링 알람을 더했다.

   교훈

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

   사례 보기
3. IL-0301 Basecamp 3 의 주 데이터베이스가 정시 부하에 락 경합으로 30초 만에 완전히 막혔다

   37signals2022

   증상

   2022년 6월 27일 13:00 UTC 에 Basecamp 3 가 갑자기 아주 느려졌고 곧 오류 페이지를 보였다. 같은 30초 사이에 Basecamp 3 의 주 데이터베이스가 정상에서 완전한 정체 상태로 넘어갔다.

   잠금 경합과 교착데이터베이스 과부하지연 시간 증가오류율 상승서비스 중단

   촉발

   13:00 UTC 에 예약 알림을 대량으로 묶어 보내는 시각에 맞춰 부하가 큰 데이터베이스 쿼리가 한꺼번에 몰려들었고, 이 쿼리들이 주 데이터베이스에서 락 경합을 연쇄로 일으켰다.

   원인

   용량 한계

   구성 요소

   데이터베이스

   기여 요인

   용량 계획 부재수동 조치 악화모니터링 사각지대

   감지

   37signals 는 13:00:00 과 13:00:30 UTC 사이에 Basecamp 3 의 주 데이터베이스가 완전히 정체되는 것을 보고 곧바로 대응을 시작했다.

   조치

   • 주 데이터베이스의 부하를 덜려고 Basecamp 3 의 일부 기능을 멈췄다. 진행 보고 이메일을 그날 늦게 보내도록 미룬 것이 그 예다.
   • 막힌 주 데이터베이스에서, 이런 장애에 대비해 대기 중이던 복제본 데이터베이스로 절차대로 페일오버했다.
   • 페일오버 뒤 데이터베이스가 다시 무너지자 Basecamp 3 를 곧바로 유지보수 모드로 바꿨다.
   • 데이터베이스 쿼리 시간에 강제 상한을 걸었다.
   • 쿼리 시간 상한을 안전장치로 두고 기능을 한 단계씩 다시 켜서 서비스를 모두 되살렸다.

   후속 조치

   • 데이터베이스 쿼리에 강제 시간 상한을 둔다. 평소 빠르던 쿼리가 일정 수준 넘게 느려지면 기다리며 쌓이게 두지 않고 실패하게 한다.
   • 동시 실행 한도를 조정한다. 일정 수준을 넘으면 병렬로 도는 작업이 많을수록 시스템 전체가 느려지기 때문이다.
   • 서비스 수준 기대치를 더 엄격하게 잡고, 예약 알림과 보고서를 몇 분 안에 대량으로 보내며 생기던 정시 데이터베이스 부하 급증을 더는 용인하지 않는다. 제품 설계부터 데이터베이스 내부까지 이 부분을 살핀다.
   • 일부 예약 작업을 돌리는 병렬 워커 수를 줄여 동시 실행과 락 경합을 낮춘다.
   • 일부 예약 작업을 한꺼번에 끝내지 않고 몇 분에 걸쳐 돌려 데이터베이스 부하를 시간에 나눈다.
   • 한꺼번에 몰려드는 쿼리 다수를 주 데이터베이스에서 읽기 전용 복제본 데이터베이스로 옮긴다.
   • 지난 1년의 데이터베이스 지표에서 찾은 성능 저하 여러 건을 하나씩 고친다. 이 저하는 알림을 울리지 않았지만 주 데이터베이스 부하를 서서히 늘렸다.
   • 한꺼번에 몰려드는 다른 작업을 찾아 분산해, 데이터베이스의 특정 지점에 부하가 몰리지 않게 한다.
   • 높은 부하와 높은 동시성에서 더 예측 가능하게 동작하도록 데이터베이스를 조정한다.
   • 데이터베이스 내부의 락과 트랜잭션 상태를 더 잘 볼 수 있도록 관측성을 높인다.
   • 장애 중에 부하가 큰 Basecamp 3 기능을 골라 끌 수 있는 더 쓰기 편한 도구를 만든다.
   • 멈춘 데이터베이스에 대응하는 운영 훈련을 잡아 대응을 연습하고 다듬는다.
   • 앞으로 몇 년의 Basecamp 성장에 맞춰 확장할 수 있도록 데이터베이스 소프트웨어와 하드웨어 업그레이드를 검토한다.
   • Basecamp 3 를 받치는 구성 요소에 서비스 수준 목표, 곧 SLO 를 정해 데이터베이스 성능 변화를 더 일찍, 더 분명하게 알아챈다.
   • 분기마다 성능과 부하를 검토해 눈에 띄지 않게 진행되는 성능 변화를 찾는다.

   교훈

   37signals 는 이번 장애에 원인 하나가 없었다고 밝혔다. 시스템이 한계를 조금만 넘어도 순식간에 안정에서 불안정으로 넘어가는 지점이 있고, 그 지점은 특별한 계기 없이 성장과 함께 서서히 다가온다. 막힌 쿼리를 종료하는 일은 트랜잭션 롤백 때문에 같은 락에서 다시 막혀 정체를 키울 수 있다. 37signals 는 이 시스템을 잘 알면서도 결정적인 단서가 없고 데이터베이스 내부를 깊이 들여다볼 수단이 없어 확신을 갖고 대응하지 못했다고 썼다. 그래서 문제 하나를 고치는 대신 위험을 줄이고 확신을 쌓아 가는 길을 택했다.

   사례 보기
4. IL-0385 큰 MySQL 테이블의 스키마 마이그레이션 마지막 단계에서 읽기 복제본 다수가 semaphore deadlock 에 걸려 GitHub 핵심 서비스가 2시간 50분 저하됐다

   GitHub2021

   증상

   2021년 11월 27일 20:40 UTC 부터 GitHub Actions, API 요청, Codespaces, Git 작업, Issues, GitHub Packages, GitHub Pages, Pull Requests, Webhooks 의 가용성이 떨어졌다. 큰 MySQL 테이블의 스키마 마이그레이션이 마지막 rename 단계를 실행하던 때였다.

   잠금 경합과 교착데이터베이스 과부하

   촉발

   큰 MySQL 테이블의 스키마 마이그레이션이 마지막 단계로 갱신한 테이블을 제자리로 옮기는 rename 을 실행했다. 이때 읽기 복제본 상당수가 semaphore deadlock 에 걸렸다.

   원인

   소프트웨어 결함

   구성 요소

   데이터베이스스키마 마이그레이션

   기여 요인

   여유 용량 부재단계적 배포 부재

   조치

   • 정상 상태인 내부용 복제본을 모두 운영 경로로 올려 용량을 늘렸다. 이것만으로는 완전히 복구되지 않았다.
   • crash-recovery 를 되풀이하는 복제본에서 운영 트래픽을 미리 빼고, 그 복제본이 테이블 rename 을 끝까지 처리할 때까지 기다렸다.
   • 회복한 복제본을 운영에 다시 넣어 정상 운영에 필요한 용량을 되찾았다.

   후속 조치

   • 클러스터를 기능별로 나누는 작업을 계속 우선해서, 마이그레이션을 샤드 하나에서 카나리 모드로 먼저 돌릴 수 있게 한다.
   • 클러스터마다 여유 용량을 더 크게 잡도록 내부 절차를 고친다.
   • 이 문제를 막는 방법을 더 알게 될 때까지 스키마 마이그레이션을 멈춘다.
   • 이번 장애가 일어난 구체적인 조건을 계속 조사한다.
   • 마이그레이션 도구를 시험하면서 이런 상황에서 도구를 고칠 점을 가려낸다.

   사례 보기
5. IL-0441 세일 이벤트 때 SQL Server 의 초당 배치 실행 수가 임계값을 넘으면 쿼리가 밀려 애플리케이션 타임아웃 오류가 쏟아졌다

   ZOZO2021

   증상

   2020년 중반부터 세일 이벤트처럼 트래픽이 몰릴 때, 한 기능을 맡은 SQL Server DB 의 초당 배치 실행 수가 일정 임계값을 넘으면 애플리케이션에서 타임아웃 오류가 많이 났다. 여기서 배치는 SQL Server 에서 하나 이상의 쿼리를 묶은 단위다.

   간헐적 타임아웃데이터베이스 과부하잠금 경합과 교착

   촉발

   세일 이벤트나 럭키백 판매 이벤트로 트래픽이 늘어 초당 배치 실행 수가 일정 임계값을 넘었다.

   원인

   unknown

   구성 요소

   데이터베이스

   기여 요인

   –

   조치

   • 컴파일 대기로 블로킹을 일으킨 스토어드 프로시저 네 개의 실행 계획을 플랜 가이드로 고정했다.
   • 장애 시간대에 통계가 한 번 이상 업데이트된 테이블을 뽑고, 트래픽이 늘 것으로 보이는 시간대에만 UPDATE STATISTICS tablename WITH NORECOMPUTE 로 그 테이블들의 통계 자동 업데이트를 껐다.
   • 트래픽이 가라앉으면 WITH NORECOMPUTE 없이 UPDATE STATISTICS tablename 을 실행해 통계 자동 업데이트를 다시 켰다.
   • 플랜 캐시 축출을 줄이려고 메모리에 올라간 데이터 캐시 가운데 용량이 큰 인덱스를 압축해 메모리를 더 효율적으로 쓰게 했다.

   교훈

   근본 원인을 찾지 못한 장애에서도 장애 중에 관찰된 현상 가운데 없애거나 줄일 수 있는 것을 골라 대책을 세우면 장애가 나지 않는 상태를 만들 수 있었다. 조사는 특이하게 변한 지표를 먼저 보고 가설을 세운 뒤 DMV 와 확장 이벤트로 파고들고, 장애 앞뒤 몇 초의 변화를 자세히 보는 순서로 했다.

   사례 보기

원인별8