사례4건

4건 중 1~4번째

1. 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 는 이 시스템을 잘 알면서도 결정적인 단서가 없고 데이터베이스 내부를 깊이 들여다볼 수단이 없어 확신을 갖고 대응하지 못했다고 썼다. 그래서 문제 하나를 고치는 대신 위험을 줄이고 확신을 쌓아 가는 길을 택했다.

   사례 보기
2. IL-0256 하드웨어 로드 밸런서가 거듭 죽고 대기 장비로 넘어간 뒤 라우터가 동기화하지 못해 Basecamp 전체가 이틀 연속 열리지 않았다

   37signals2020

   증상

   2020년 9월 1일 화요일 Central Time 9:51am 부터 10:08am 까지, UTC 로는 14:51–15:08 의 17분 동안 Basecamp 가 아예 열리지 않았다. 아무것도 동작하지 않는 것처럼 보였고, 다시 열린 뒤에는 모든 것이 정상으로 보였다.

   서비스 중단링크 플래핑지연 시간 증가

   촉발

   2020년 9월 1일 데이터센터 사이 네트워크 회선이 끊긴 것을 복구하는 도중 하드웨어 로드 밸런서 하나가 죽었다. 9월 2일에는 Virginia 데이터센터의 주 로드 밸런서와 보조 로드 밸런서가 차례로 죽었다.

   원인

   소프트웨어 결함

   구성 요소

   온프레미스 로드 밸런서백본망

   기여 요인

   장애 중첩여유 용량 부재

   조치

   • 9월 1일 라우터가 새 로드 밸런서와 자동으로 동기화하지 못하자 손으로 개입해 바로잡았다.
   • 9월 2일 라우터가 동기화하지 못하는 같은 문제가 다시 나자 이번에도 손으로 개입해 고쳤다.

   후속 조치

   • 로드 밸런서 공급사와 함께 장애 원인을 끝까지 밝히고, 1차 평가에서 나온 버그 수정을 적용한다.
   • 하드웨어 로드 밸런서를 교체한다.
   • 데이터센터 사이 이중 네트워크 경로를 다시 깔아 회선이 실제로 다른 경로를 지나게 하고, 네트워크 공급사 사이의 숨은 의존을 없앤다.
   • 비상 대책으로 하드웨어 로드 밸런서에서 소프트웨어 로드 밸런서로 옮기는 것을 검토한다. 하드웨어는 교체에 며칠이 걸리지만 소프트웨어는 몇 분이면 배포할 수 있다.
   • 비상 대책으로 로드 밸런서 구성을 분산해 장애 하나의 영향을 줄이는 것을 검토한다.
   • 시스템의 복원력, 취약함, 위험을 평가하고 평가 과정 자체도 검토한다.

   교훈

   Basecamp 는 여러 겹의 이중화와 복원력을 갖추고 운영 시스템에서 큰 장애 대응을 연습해 왔지만 이번 사고들은 잡지 못했다. 모든 사고를 잡을 수는 없지만, 연쇄 장애가 예상하지 못한 취약함과 어려운 복구 경로를 드러내는 일에는 대비할 수 있다.

   사례 보기
3. IL-0255 데이터센터 사이 메트로 회선이 잠깐 끊긴 뒤 Redis 레플리카가 재동기화 루프에 빠져 BC3 가 느려지고 채팅이 멈췄다

   37signals2020

   증상

   2020년 8월 28일 금요일 11:59AM CDT 에 PagerDuty, Nagios, Prometheus 에서 알림이 쏟아졌다. 모니터링에는 새 메트로 회선이 20~30초쯤 끊긴 것이 보였고, 네트워크가 돌아온 뒤에도 BC3 응답이 계속 느렸다.

   링크 플래핑지연 시간 증가복제 지연

   촉발

   2020년 8월 28일 11:59AM CDT 에 Ashburn 의 주 데이터센터와 Chicago 데이터센터를 잇는 이중 메트로 회선이 짧게 끊겼다. 모니터링에는 새 회선이 20~30초 끊긴 것만 보였지만, 로그에서는 두 회선이 모두 잠깐씩 끊긴 것이 드러났다.

   원인

   의존성 장애

   구성 요소

   백본망BGP 라우팅인메모리 캐시데이터베이스 복제

   기여 요인

   단일 장애점재시도 폭주잡음에 묻힌 신호

   감지

   PagerDuty, Nagios, Prometheus 에서 알림이 쏟아졌다. Redis 문제는 상황이 진정된 뒤 Redis DB 인스턴스 하나에 계속 떠 있던 알림을 보고 찾았다.

   조치

   • 로드 밸런서 계층에서 채팅을 꺼 나머지 BC3 를 안정시켰다.
   • 레플리카의 Redis 를 재시작했다.

   후속 조치

   • 알려진 Redis 문제의 문서화된 우회 방법대로 Redis 서버의 설정을 바꾼다.
   • 두 메트로 회선이 펜실베이니아에서 같은 물리 경로를 지나는 문제를 없앨 구체적인 계획을 세운다.
   • 장애 조치 시스템을 최대 부하 때 운영 환경에서 직접 검증한다.
   • 사고 후속 조치를 할 시간을 명시적으로 비우고, 우선순위를 밝혀 다른 일을 뒤로 미룬다.

   교훈

   이중화를 계획하고 실제 시험을 늘려 왔지만 충분하지 않았고, 특히 최대 부하에서는 안전하다는 착각을 하고 있었다. 데이터센터 사이로 부하를 옮기거나 이중 회선 사이를 오가는 일은 문제없이 돼야 한다. 그렇지 않다면 팀 전체가 준비된 통제된 상황에서 그 사실을 알아야 한다. 장애에서 나온 후속 조치는 목록에 더하는 데서 그치지 말고 더 급하게 처리해야 한다.

   사례 보기
4. IL-0300 Basecamp 3 의 events 테이블이 데이터베이스 한도에 닿아 서비스가 다섯 시간 가까이 읽기 전용이 되었다

   37signals2018

   증상

   Basecamp 3 가 읽기 전용 상태가 되었다. 사용자는 기존 메시지, 할 일 목록, 파일을 볼 수 있었지만 새 내용을 넣을 수 없었고 기존 내용도 고칠 수 없었다.

   쓰기 거부

   촉발

   사용량이 아주 많은 events 테이블이 데이터베이스의 한도인 2,147,483,647 에 닿아, 이 테이블에 새 이벤트를 쓸 수 없게 되었다.

   원인

   용량 한계

   구성 요소

   데이터베이스

   기여 요인

   용량 계획 부재

   조치

   • Rails 5.1 이 모든 테이블의 새 기본값으로 바꾼 것과 같은 변경을 Basecamp 의 테이블에 적용해 레코드 한도를 9,223,372,036,854,775,807 로 올렸다.

   교훈

   37signals 는 이 장애를 피할 수 있었다고 밝혔다. 장애 전 며칠 동안 events 테이블의 용량을 늘리는 작업을 하면서도 여유가 줄어드는 속도를 제대로 따지지 않았다. 37signals 의 CTO 는 Rails 5.1 이 새 기본값을 발표했을 때 회사의 데이터베이스 스키마를 더 주의 깊게 살폈어야 했다고 썼다. 해결 작업을 시작한 뒤에도 끝까지 챙기며 꼭 필요한 질문을 했어야 했다고 덧붙였다.

   사례 보기

원인별3