사례20건

20건 중 11~15번째

1. IL-0556 수동 데이터베이스 유지 보수 중 열어 둔 트랜잭션이 잠금을 쥐어 Storj US1 satellite 의 업로드와 다운로드가 실패했다

   Storj2024

   증상

   2024년 5월 20일 14시 56분 UTC쯤 Storj US1 satellite 에서 쓰기 작업이 실패하기 시작했다. 14시 59분에 당번 팀이 호출을 받고 조사를 시작했다.

   잠금 경합과 교착서비스 중단

   촉발

   14시 55분에 US1 satellite 에서 정기 수동 데이터베이스 유지 보수를 시작했고, 다른 작업을 하는 사이 트랜잭션 하나가 실수로 열린 채 남았다.

   원인

   운영 실수

   구성 요소

   데이터베이스

   기여 요인

   –

   감지

   14시 59분에 당번 팀이 호출을 받고 조사를 시작했다.

   조치

   • 15시 22분에 열려 있던 트랜잭션을 찾아 닫고 복구를 시작했다. 15시 23분에 서비스가 돌아왔다.

   후속 조치

   • 다른 작업으로 넘어가기 전에 모든 트랜잭션을 제대로 닫도록 데이터베이스 유지 보수 절차와 교육을 다시 살펴 고친다.
   • 정해 둔 시간보다 오래 열려 있는 트랜잭션을 찾아 팀에 알리는 모니터링과 알림을 더한다.
   • 사고 분석으로 절차와 시스템에서 더 고칠 점을 찾고, 수동 유지 보수를 줄이거나 없애는 도구를 만든다.

   사례 보기
2. IL-0217 스키마 캐시가 데워지지 않아 주 MySQL 데이터베이스가 내부 교착에 빠지고 Honeycomb 전체가 68분 동안 멈췄다

   Honeycomb2023

   증상

   2023년 7월 24일 밤 저장소와 쿼리 엔진인 Retriever 의 클러스터를 바꾼 지 몇 시간 뒤 수집 서비스 Shepherd 의 내부 SLO 에러 버짓이 천천히 소진되기 시작했다. 엔지니어들은 소진이 느리고 들쭉날쭉하며 뚜렷한 설명이 없어서 아침에 조사해도 되는 작은 문제라고 판단했다.

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

   촉발

   7월 24일 밤 미묘한 버그를 피하려고 Retriever 클러스터 두 개 사이를 전환했다. 전환 뒤 Retriever 가 마지막 쓰기 시각 기록을 데이터베이스에 쓰지 않았고, 그 뒤 쓰기만 되돌리려고 기능 플래그를 바꾸자 남은 쓰기마저 완전히 멈췄다.

   원인

   소프트웨어 결함

   구성 요소

   데이터베이스인메모리 캐시

   기여 요인

   데워진 캐시에 기댄 구조초기 신호 무시수동 조치 악화미검증 가정

   감지

   Shepherd 의 내부 SLO 에러 버짓이 천천히 소진되는 것을 엔지니어들이 봤지만 작은 문제로 판단해 아침으로 미뤘다. 아침에 Retriever 의 데이터베이스 호출이 끊긴 차트를 찾아 성능 문제의 원인을 알았다.

   조치

   • 클러스터의 쓰기에 문제가 있다고 보고 자주 쓰던 기능 플래그를 바꿔 쓰기만 다른 클러스터로 되돌렸지만 고쳐지지 않았다.
   • 데이터베이스를 보호하려고 서킷 브레이커를 걸어 모든 Shepherd 트래픽을 5xx 오류로 거부했다.
   • 데이터베이스 호스트가 완전히 잠겨 살릴 수 없자 복제본으로 페일오버했고, 데이터베이스와 그에 기대는 서비스들이 돌아왔다.
   • 데이터베이스가 살아난 뒤 캐시에 데이터를 채우려고 Retriever 호스트를 모두 재시작했다.
   • 지난 하루 동안 트래픽이 있던 모든 스키마의 마지막 쓰기 시각을 지금으로 손으로 바꿔 스키마 저장소가 캐시를 모두 다시 읽게 했다.
   • 서킷 브레이커를 풀어 수집을 완전히 되살렸고, 데이터베이스 오류로 내부 점검에 실패한 호스트를 다시 재시작해 쿼리 용량을 되찾았다.

   후속 조치

   • 클러스터 이전을 마쳤고, 캐시 뒤의 쓰기를 끌 수 있는 코드를 모두 지웠다.
   • 캐시를 더 튼튼하게 하는 방법을 찾는다.
   • 새 스키마로 갱신이 몰릴 때 데이터베이스에 거는 경합을 줄이는 방법을 찾는다.
   • 시스템 안 일부 작업의 성능 비용이 들쭉날쭉하지 않게 한다.
   • 이런 드문 경우를 더 잘 찾고 다루기 위한 계측과 실험 방법을 검토한다.

   교훈

   Honeycomb 은 기능 플래그, 잦은 배포, 장애 중 배포 중단, 지난 아차 사고에서 배운 것처럼 시스템을 안전하게 만드는 가장 믿는 관행들이 함께 이번 장애의 원인이 됐다고 봤다. 저마다 합리적인 결정들이 간접 의존 관계를 따라 예상하지 못하게 얽혔고, 환경 한쪽의 문제가 다른 쪽 서비스를 망가뜨렸다. 최근 여러 장애와 아차 사고에서 미묘한 버그를 피하려던 조치가 더 큰 예상 밖 장애로 이어진 일이 자주 있었다. 이런 드문 데이터베이스 잠김에는 페일오버가 가장 빠른 복구 방법이라는 것도 배웠다.

   사례 보기
3. IL-0483 PostgreSQL 커넥션이 바닥나 Replicate 웹사이트와 API가 두 시간 가까이 느린 응답과 HTTP 500을 냈다

   Replicate2023

   증상

   5월 11일 05:45 UTC쯤 데이터베이스 커넥션 풀이 가득 찼고, 모니터링이 이를 곧바로 감지해 05:46 UTC에 엔지니어를 호출했다. 많은 고객이 replicate.com 웹사이트와 API에서 느린 응답이나 HTTP 500 오류를 받았고, 예측 작업을 제대로 실행하지 못했다.

   오류율 상승지연 시간 증가잠금 경합과 교착

   촉발

   5월 9일과 10일에 기능 플래그로 넓게 켠 비동기 예측 상태 업데이트 기능이 같은 예측 ID로 INSERT 쿼리를 동시에 보내기 시작했다. 5월 11일 05:00 UTC가 조금 지나 평소 수준의 트래픽 변동이 이 불안정한 상태를 무너뜨렸다.

   원인

   배포 결함

   구성 요소

   데이터베이스

   기여 요인

   늦게 드러난 변경

   감지

   05:45 UTC쯤 데이터베이스 커넥션 풀이 가득 차자 모니터링 시스템이 거의 곧바로 이를 감지해 05:46 UTC에 엔지니어를 호출했다.

   조치

   • 07:31 UTC에 기능 플래그로 비동기 예측 업데이트 기능을 모두 껐다. 몇 분 안에 데이터베이스가 회복했고 서비스가 정상으로 돌아왔다.

   후속 조치

   • 비동기 예측 업데이트 기능을 꺼 둔 채로, 같은 예측 ID에 INSERT가 쌓이지 않도록 다시 설계한다.
   • 방치하면 비슷한 문제를 일으킬 수 있는 잠금 경합과 그 밖의 데이터베이스 부하 집중 지점을 점검한다.
   • 큰 장애가 나면 무슨 일이 있었고 무엇을 고치는지 담은 자세한 보고서를 공개한다.

   교훈

   Replicate는 이 장애에 복잡한 시스템 장애의 전형적인 특징이 있다고 보았다. 시스템은 성능이 떨어진 채로도 겉으로는 잘 돌다가 어느 순간 크게 무너졌다. 장애를 촉발한 방어 장치가 같은 장애를 일부 막아 주기도 했다. 변경은 새 위험을 만들지만 위험을 없애는 것도 변경이다. 한 가지를 빠르게 만든 성능 개선이 다른 곳을 훨씬 나쁘게 만들 수 있다.

   사례 보기
4. 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 에서 시험해도 부하가 걸린 환경에서 마이그레이션을 돌려 볼 도구가 없으면 이런 문제를 미리 잡지 못한다. 문제를 빨리 알아채고 엔지니어 두 명이 함께 조사한 것과, 사용자에게 분명한 안내를 보이면서 영향을 줄인 프런트엔드 점검 모드는 도움이 됐다.

   사례 보기
5. 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 팀 모두에게 뜻밖이었다.

   사례 보기

원인별8