사례8건

8건 중 5~8번째

1. IL-0308 RevenueCat 이 Aurora PostgreSQL 10 에서 14 새 클러스터로 넘어간 직후 쿼리가 극도로 느려져 대시보드와 SDK 엔드포인트가 세 시간 넘게 실패했다

   RevenueCat2022

   증상

   2022년 11월 23일 9:39 UTC 에 트래픽 전부가 새 Aurora PostgreSQL 14.x 클러스터로 넘어갔고, 지연이 나빠져 인프라 팀이 조사를 시작했다. 9:54 UTC 에는 쿼리가 평소보다 훨씬 오래 걸리면서 데이터베이스 연결을 모두 차지하고 있었다.

   데이터베이스 과부하지연 시간 증가서비스 중단커넥션 풀 고갈

   촉발

   복제를 이용해 Aurora PostgreSQL 10.x 클러스터에서 새 14.x 클러스터로 트래픽을 넘겼다. 그런데 가장 큰 테이블 하나의 vacuum 이 전환 전에 끝나지 않아, 새 클러스터의 가장 큰 테이블들에 ANALYZE 가 돌지 않은 상태였다.

   원인

   업그레이드로 깨진 호환성

   구성 요소

   데이터베이스PostgreSQL vacuum데이터베이스 복제데이터베이스 프록시와 커넥션 풀러쿼리 플래너와 테이블 통계

   기여 요인

   스테이징 불일치미검증 가정자동화 증폭모니터링 사각지대

   감지

   9:39 UTC 에 트래픽 전부가 새 클러스터로 넘어갔을 때 지연이 나빠 보였고, 인프라 팀이 바로 조사를 시작했다.

   조치

   • 9:54 UTC 에 쿼리가 데이터베이스 연결을 너무 오래 잡지 않도록 데이터베이스 사용자에 statement timeout 을 걸었다.
   • 9:58 UTC 에 로드 밸런서에서 트래픽의 90% 에 503 을 보내 부하를 덜고 시스템이 회복할 여유를 만들었다.
   • 10:00 UTC 무렵부터 오래 걸리는 쿼리에 EXPLAIN 을 돌려 보고, 해만 끼치고 필요 없는 인덱스를 지우기 시작했다.
   • 트래픽을 100% 로 되돌리는 동안 Apple 웹훅을 잠시 받지 않았다.
   • New Relic 이 느린 쿼리마다 돌리는 EXPLAIN 쿼리를 없애려고 New Relic 을 끈 새 릴리스를 냈다.
   • 12:00 UTC 무렵부터 가장 큰 테이블들에 손으로 ANALYZE 를 돌렸다.
   • 미리 준비해 둔 스크립트로 영향받은 시퀀스 값을 자동으로 올려 기본 키 중복을 풀었다.
   • 전환 몇 분 뒤 통합 이벤트 발송 작업이 이벤트 테이블을 갱신하지 못하는 것을 잡고 발송 작업을 손으로 멈췄다.
   • 발송되었지만 데이터베이스에 기록되지 않은 웹훅을 만일에 대비해 다시 보냈다.
   • 13:33 UTC 에 통합 이벤트 발송, ETL, 웹 서버 밖의 작업을 모두 되살렸다.

   후속 조치

   • 사업에 중요한 시기에는 변경 동결을 두는 것을 검토한다.
   • 백엔드 장애 때 SDK 가 얼마나 믿을 만하게 동작하는지 더 잘 알린다.
   • 개발자 대시보드와 기술 담당자에게 보내는 직접 이메일을 써서 유지보수와 장애를 고객에게 더 잘 알린다.
   • 사전 연습에서 트래픽 일부를 재생해 전환 당일과 더 비슷한 조건을 만든다. 이번 연습은 쓰기 트래픽을 재생하지 않았다.
   • API 를 빠르고 안정적으로 유지하려고 비용이 큰 작업을 최대한 비동기로 옮기는 데 더 투자한다.
   • 테이블 인덱스를 다시 검토한다. 쓰이지 않는 인덱스가 있고, 데이터베이스가 쿼리에 그 인덱스를 고르면 성능이 떨어질 수 있다.
   • 데이터베이스 대시보드에서 엔드포인트와 시스템별 부하를 더 잘 보여 줘 부하가 어디서 오는지 빨리 찾게 한다. 이번에는 Apple 웹훅 부하가 복구를 막는다는 것을 아는 데 너무 오래 걸렸다.
   • 장애 중에 고객 지원과 고객 커뮤니케이션 담당을 불러 소통을 맡긴다.

   교훈

   RevenueCat 은 처음부터 롤백했으면 더 나았다고 돌아봤다. 사전 연습에서는 데이터 일관성과 쿼리 성능만 보고 쓰기 트래픽을 재생하지 않았다. 쓰기는 인덱스가 얽히지 않아 읽기보다 단순하다고 여겼기 때문이다. 복제를 멈추고 평소처럼 쓰기를 해 봤다면 문제를 찾을 수 있었다. 시퀀스 상태가 복제되지 않는다는 한계를 놓치고 상태도 함께 복제된다고 가정했다. 사전 연습 때는 새 클러스터가 오래 떠 있어 vacuum 과 통계가 이미 끝나 있었기 때문에 ANALYZE 가 없는 문제를 보지 못했다. 시기로는 추수감사절과 블랙 프라이데이 전에 끝내려 했지만, 미국 지원팀 일부가 이미 휴가 중인 민감한 때였으므로 그다음 주로 미뤘어야 했다고 밝혔다.

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

   사례 보기
3. IL-0456 100% 할인 이벤트 기간에 인프런 서비스가 Aurora PostgreSQL 병목으로 여섯 번 멈췄다

   Inflab2022

   증상

   2022년 1월 3일부터 17일까지 이어진 100% 할인 이벤트 기간에, 인프런은 1월 3일, 4일, 7일, 17일 오전 9시와 오후 10시 무렵마다 쓸 수 없을 만큼 느려졌다. 트래픽은 평소의 5~20배였고, 매번 데이터베이스의 슬로우 쿼리와 부하가 함께 나타났다.

   서비스 중단데이터베이스 과부하지연 시간 증가

   촉발

   2022년 1월 강의 125개를 0원에 등록할 수 있는 100% 할인 이벤트가 크게 퍼지면서 평소 대비 5~20배의 트래픽이 들어왔다.

   원인

   용량 한계

   구성 요소

   데이터베이스PostgreSQL vacuum

   기여 요인

   비효율적인 쿼리모니터링 사각지대과도한 영향 범위

   감지

   모니터링과 슬로우 쿼리 알람으로 문제를 알아챘고, 문제가 되는 쿼리를 30분 안에 찾았다. 1월 17일에는 오후 10시부터 RDS 의 여러 수치가 요동치는 것을 보았다.

   조치

   • 관심회사 조회 API 의 쿼리 일부가 인덱스를 쓰지 않는 것을 로그와 실행계획으로 확인하고 바로 인덱스를 추가했다.
   • 용량이 큰 캐시 행의 캐시 초기화와 재생성 주기를 바꿨다.
   • 쓰기 DB 에 부하를 준 조회용 쿼리부터 읽기 DB 로 옮겼다.
   • 시간을 벌려고 데이터베이스를 r5.8xlarge 8대로 늘렸다.
   • 느린 강의 조회 쿼리에 인덱스를 추가하거나 쿼리를 바꿔 인덱스를 쓰게 했고, 개선할 수 없는 쿼리를 쓰는 기능은 껐다.
   • select * 로 읽던 강의 조회 쿼리에서 실제로 쓰지 않는 고용량 강의 소개 컬럼을 모두 뺐다.
   • IN 절에 담는 강의 ID 를 20개씩 나눠 Promise.all 로 처리하게 바꿔, 쿼리가 다시 인덱스를 쓰게 했다.
   • PostgreSQL 을 10.16 에서 11.13 으로 올렸다.
   • 5초 넘게 도는 쿼리를 강제로 끝내도록 쿼리 타임아웃을 5초로 걸었다.
   • Max Connection 을 늘렸다.
   • 강의 테이블에 수동으로 vacuum 을 돌려 Dead Tuple 을 정리했다.
   • 용량이 큰 강의 소개 컬럼을 강의 테이블에서 떼어 별도 테이블로 옮겼다.

   후속 조치

   • 한 테이블의 장애가 전체 서비스의 장애로 번지는 구조를 개선한다.
   • 성능 개선이 쉽지 않은 테이블과 캐시 구조를 개선한다.
   • 직관적이지 않은 SQL 코드를 개선한다.
   • 타입과 테스트 코드가 없어 안심하고 고치기 어려운 코드를 개선한다.
   • 배치 작업을 안정적으로 돌릴 환경을 갖춘다.
   • 모놀리식 구조는 알맞은 선에서 유지하고, 장애가 잘 번지는 일부 도메인만 따로 분리한다.

   교훈

   그동안 데이터베이스 병목이 모두 읽기 DB 의 슬로우 쿼리로 보여 팀은 읽기 DB 만 모니터링했다. 이 때문에 근본 원인인 쓰기 DB 강의 테이블의 Dead Tuple 을 늦게 찾았다. 원인 쿼리는 빨리 찾았지만, 무분별한 쿼리 추상화와 타입과 테스트 코드가 없는 코드 때문에 수정과 배포가 늦어졌다. 그만큼 장애 시간도 길어졌다. 첫 주 장애를 돌아보면 어느 페이지가 문제가 될지 예상할 수 없었고, 대부분의 페이지가 트래픽이 몰리면 언제든 장애가 날 수 있는 상태였다. 팀은 조직의 구조와 성숙도가 갖춰지지 않은 상태에서 마이크로서비스 아키텍처인 MSA 로 바로 옮기면 더 큰 문제가 생긴다고 보았다. 그래서 모놀리식 구조를 알맞은 선에서 유지하면서 일부 도메인만 분리하기로 했다.

   사례 보기
4. IL-0282 US-East 리전의 DynamoDB 스토리지 서버들이 멤버십 정보를 받지 못해 스스로 요청 처리에서 빠지면서 고객 요청의 약 55% 가 실패했다

   Amazon Web Services2015

   증상

   2:19am PDT 에 짧은 네트워크 장애가 있은 뒤 DynamoDB 고객 요청의 오류율이 치솟았다. 2:37am PDT 에는 오류율이 지난 3년 동안 겪은 어떤 수준보다 훨씬 높아졌고, 약 55% 에서 머물렀다.

   오류율 상승데이터베이스 과부하

   촉발

   2:19am PDT 의 짧은 네트워크 장애가 DynamoDB 스토리지 서버 일부에 영향을 줬고, 이 서버들이 한꺼번에 메타데이터 서비스에 멤버십 정보를 요청했다.

   원인

   용량 한계

   구성 요소

   데이터베이스

   기여 요인

   용량 계획 부재모니터링 사각지대재시도 폭주순환 의존과도한 영향 범위

   감지

   주 문제를 해결한 뒤 남은 낮은 오류율은 월요일에 고객들이 테이블이 updating 이나 deleting 단계에 멈췄다거나 오류율이 높다는 지원 케이스를 열면서 드러났다.

   조치

   • 용량 추가가 여러 번 실패한 뒤 5:06am PDT 에 메타데이터 서비스로 가는 요청을 멈췄다. 재시도가 줄어 메타데이터 서비스의 부하가 크게 덜어졌다.
   • 메타데이터 서비스가 관리 요청에 다시 응답하자 용량을 크게 늘렸다.
   • 메타데이터 서비스로 가는 요청을 다시 열고 스토리지 서버를 고객 요청 경로에 되돌렸다. 7:10am PDT 에 대부분의 고객과 AWS 서비스가 정상 운영을 이어 갈 만큼 오류율이 내려갔다.
   • 받아야 할 만큼 트래픽을 받지 못하던 메타데이터 파티션 하나를 전체 트래픽으로 되돌려 남은 오류를 월요일에 정리했다.

   후속 조치

   • 메타데이터 서비스의 용량을 이미 크게 늘렸다.
   • 멤버십 크기 같은 성능 지표를 더 엄격하게 모니터링해 상태를 파악하고 알맞은 용량을 미리 계획한다.
   • 스토리지 노드가 멤버십 정보를 요청하는 빈도를 줄인다.
   • 메타데이터 서비스가 요청을 처리하는 데 쓸 수 있는 시간을 늘린다.
   • DynamoDB 서비스를 나눠 메타데이터 서비스 인스턴스를 여럿 두고, 각 인스턴스가 스토리지 서버의 일부만 맡게 한다.
   • SQS 의 메타데이터 캐싱을 고쳐 메타데이터 테이블에 오래 접근하지 못해도 메시지 보내기와 받기가 계속되게 한다.
   • Auto Scaling 서버들에 작업을 나누는 방식을 바꿔 쌓인 스케일링 작업을 더 병렬로 처리한다.
   • 더 새로운 작업으로 대체된 오래된 스케일링 작업을 걸러 내는 장치를 넣는다.
   • 스케일링 작업을 처리하는 용량을 늘린다.
   • CloudWatch 가 DynamoDB 의 그룹 멤버십 데이터를 캐싱하는 방식을 바꿔, 갱신이 필요한 지표를 가능한 한 적게 줄인다.
   • write-through 캐싱으로 지표를 더 빨리 전달하는 기능을 개발한다. 이 캐시는 지표를 저장하기 전에 바로 보여 준다.
   • 타임아웃을 줄인 콘솔 로그인 코드를 며칠 안에 배포한다. 이 코드는 이미 테스트 과정에 들어가 있다.

   교훈

   AWS 는 멤버십 크기처럼 성능에 영향을 주는 값을 자세히 보지 않아 메타데이터 서비스에 필요한 용량을 미리 잡지 못했다. 전체 오류율이 낮아도 일부 고객에게는 오류가 몰릴 수 있다. AWS 는 이를 늦게 알아채 월요일에 상태 대시보드 게시가 늦었다. 콘솔 로그인은 성공하지 않아도 되는 API 호출에 아주 긴 타임아웃이 걸려 수십 초씩 막혔다. 이런 호출은 빨리 실패하고 로그인을 이어 가게 했어야 했다.

   사례 보기

원인별4