Incident Library

IL-0456 Inflab · 2022-01-03databaseaws

100% 할인 이벤트 기간에 인프런 서비스가 Aurora PostgreSQL 병목으로 여섯 번 멈췄다

인프랩은 2022년 1월 3일부터 17일까지, 이어서 18일부터 24일까지 강의 125개를 0원에 등록하는 100% 할인 이벤트를 열었다. 이벤트가 트위터와 여러 IT 커뮤니티에 퍼지며 평소 대비 5~20배의 트래픽이 들어왔고, 7일 만에 76,730명이 새로 가입했다. 인프런은 모놀리식 NodeJS 프로젝트 하나를 ECS Fargate 에서 10대에서 30대로 돌린다. 데이터베이스는 쓰기 1대와 읽기 2~7대로 이루어진 Aurora PostgreSQL 10.16 이다. 서비스별로 DB 가 나뉘어 있지 않아, 한 기능의 장애가 전체 서비스 장애로 번지는 구조였다.

1월 3일에는 관심회사 조회 API 의 인덱스 없는 쿼리가 Node 프로세스의 커넥션을 고갈시켜 1시간 30분 동안 서비스가 멈췄다. 팀은 인덱스를 추가해 이 장애를 넘겼다. 같은 날 밤에는 쓰기 DB CPU 가 90% 넘게 올라 서비스가 2시간 동안 멈췄다. 모든 캐시를 담은 용량이 큰 캐시 행 1건의 초기화와 재생성, 그리고 쓰기 DB 에서 돌던 조회 쿼리 때문이었다. 팀은 캐시 주기를 바꾸고 조회 쿼리를 읽기 DB 로 옮겼다. 1월 4일 오전에는 강의 조회 슬로우 쿼리로 서비스가 3시간 동안 멈췄다. DB 를 r5.8xlarge 8대로 늘려도 몇십 분만 버텼다. 팀은 인덱스를 못 타는 쿼리를 고치고, select * 에서 강의 소개 컬럼을 뺐다. 원인 쿼리는 30분 안에 찾았다. 그러나 쿼리가 함수, Hook, 커스텀 이벤트로 감싸여 추상화돼 있었고 코드에 타입과 테스트가 없어 고치는 데 3시간이 걸렸다. 1월 7일에는 ID 가 100개를 넘는 IN 절이 풀 스캔을 했다. 팀은 ID 를 20개씩 나눠 보내게 고쳤다. 두 번째 이벤트 전에는 어느 페이지가 문제가 될지 몰라 성능 테스트를 할 수 없었다. 그래서 PostgreSQL 을 11.13 으로 올리고, 쿼리 타임아웃 5초를 걸고, Max Connection 을 늘리고, 2초 넘는 쿼리를 개선했다.

1월 17일 오후 10시 30분에 여섯 번째 장애가 났다. 행이 1만 건도 안 되는 강의 테이블만 읽는 쿼리도 느렸다. 쓰기 DB 의 Tuple 정보를 보니 강의 테이블의 Dead Tuple 이 99% 였다. 수동 vacuum 뒤에도 Dead Tuple Rate 는 매우 빠르게 다시 올랐다. 강의 테이블에는 수강생 수 컬럼이 있었고, 수강 신청이 들어올 때마다 이 값을 1 올리는 UPDATE 가 실행됐다. PostgreSQL 은 MVCC 때문에 UPDATE 때마다 기존 행을 남겨 두고 새 행을 쓴다. 10KB 짜리 강의 소개 HTML 컬럼을 가진 행이 계속 갱신되면서 용량이 큰 Dead Tuple 이 대량으로 쌓였다. autovacuum 이 이를 따라가지 못해 강의 테이블을 읽는 모든 쿼리가 병목에 걸렸다. 팀은 강의 소개 컬럼을 별도 테이블로 분리했고, 그 뒤로 이벤트로 인한 장애는 더 나지 않았다.

심각도
–
영향 범위
Inflearn was unusable at peak hours on 3, 4, 7 and 17 January 2022, six outages in total, including 1 h 30 min and 2 h on 3 to 4 January and 3 h on the morning of 4 January
영향 사용자
–
지역
–
감지까지
–
복구까지
–

증상

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

1월 3일 오후 8시 30분부터 10시까지는 모든 강의 소개 페이지가 부르는 관심회사 조회 API 에서 슬로우 쿼리가 대량으로 났다. 쿼리가 밀리자 Node 프로세스의 커넥션이 빠르게 고갈됐고, 뒤이은 요청이 모두 대기하다가 Node 프로세스가 강제 종료됐다. ECS 가 프로세스를 다시 채웠지만, 종료된 프로세스가 처리하던 다른 쿼리도 전부 취소돼 서비스 전체가 멈췄다.

1월 3일 오후 11시 30분부터 1월 4일 오전 1시 30분까지는 쓰기 DB 의 CPU 가 90% 이상으로 올라 전체 서비스가 멈췄다. 모든 캐시 데이터를 JSON 하나로 담은 용량이 큰 캐시 행 1건에 캐시 초기화와 재생성 요청이 겹쳐 데드락이 났다. 아직 읽기 DB 로 옮기지 못한 조회 쿼리도 쓰기 DB 의 부하를 키웠다.

1월 4일 오전 9시부터 12시까지는 강의 조회 쿼리가 슬로우 쿼리 상위 9개를 모두 차지했다. lower("컬럼명") = lower(쿼리파라미터) 처럼 컬럼을 변형하거나 !=, NOT IN 같은 부정 조건을 써서 인덱스를 타지 못하는 쿼리가 많았다. 그 결과 테이블 풀 스캔이 동시에 수십에서 수백 개씩 돌았다. 값 하나가 10KB 인 강의 소개 컬럼까지 select * 로 읽는 쿼리는 READ IO 병목을 일으켰다. 데이터베이스를 r5.8xlarge 8대로 늘렸지만 몇십 분을 버텼을 뿐 장애를 해소하지는 못했다.

1월 7일 오후 9시부터는 수강바구니, 구매완료, 결제페이지에서 강의 정보를 가져오는 where id in (ID) 쿼리가 ID 를 100개 넘게 받아 인덱스를 쓰지 못하고 테이블 풀 스캔을 했다. 이벤트 강의 125개를 한 번에 담아 일괄 결제하는 수강생이 급증했기 때문이었다.

1월 17일 오후 10시부터 RDS 의 여러 수치가 요동쳤고, 오후 10시 30분에 1월의 여섯 번째 장애가 시작됐다. 행이 1만 건도 안 되는 강의 테이블만 읽는 쿼리조차 느려졌다. 그때까지 병목은 모두 읽기 DB 의 슬로우 쿼리로 보였고, 팀은 읽기 DB 만 모니터링하고 있었다.

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

원인

원인 용량 한계

구성 요소 데이터베이스PostgreSQL vacuum
기여 요인 비효율적인 쿼리모니터링 사각지대과도한 영향 범위
촉발
2022년 1월 강의 125개를 0원에 등록할 수 있는 100% 할인 이벤트가 크게 퍼지면서 평소 대비 5~20배의 트래픽이 들어왔다.

감지

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

조치

후속 조치

교훈

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

출처

관련 사례

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

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

kubegap 열기

AI 도구와 스크립트용

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