분류
개발 · 7쪽
DB·백엔드에서 실제로 터지는 문제와 USB·CD 굽기 교과서를 모았다. 느린 쿼리, 락과 트랜잭션, 장애와 확장, 배포와 관측은 태그로 나눠 찾는다.
96편 · 글 80 · 강 16 · 마지막 글 2026.09.28
교과서굽기 16강
개발 글
96편 중 73–84
DB 엔 있는 주문이 검색엔 없다, 아웃박스 패턴
DB 에는 있는 주문이 검색에는 안 나오는데 에러 로그는 깨끗했다. 두 곳에 따로 쓰면 언젠가 어긋난다. 그리고 그 어긋남은 아무 신호 없이 쌓인다.
정규식 한 줄에 CPU 가 100% 로 붙었다
이메일 형식을 확인하는 평범한 정규식 하나에 서버 CPU 가 100% 로 붙었다. 문자열 하나 검사하는 데 몇 분이 걸렸다. 정규식이 느린 게 아니라 패턴과 입력이 잘못 만난 거였다.
AWS 2017년 스토리지 장애, 명령 하나가 4시간이 됐다
2017년 AWS 스토리지 서비스가 약 4시간 멈추자 인터넷의 상당 부분이 함께 멈췄다. 시작은 잘못 입력한 명령 하나였다. 그런데 진짜 문제는 사람보다 구조 쪽에 있었다.
GitHub 의 43초 네트워크 단절은 왜 24시간 장애가 됐나
2018년 GitHub 은 데이터센터 사이 네트워크가 43초 끊긴 일로 24시간 넘게 정상이 아니었다. 원인은 1분도 안 돼 사라졌다. 나머지 시간은 판단과 검증에 들어갔다.
타임아웃을 걸었는데도 서비스 전체가 느려진다면
타임아웃을 걸어 뒀는데도 의존 서비스 하나가 느려지자 서비스 전체가 느려졌다. 실패할 걸 알면서 계속 기다리고 있었으니까. 그 고리를 끊는 게 서킷 브레이커다.
평균 응답 시간은 120ms 인데 왜 느리다고 할까
대시보드 평균 응답 시간은 120ms 인데 느리다는 문의가 계속 온다. 로그를 뒤지면 5초, 10초짜리 요청이 하루 수만 건 숨어 있다. 평균은 그 꼬리를 뭉개 버린다.
CDN 을 붙였더니 남의 이름이 보인다
CDN 을 붙였더니 내 계정에 다른 사람 이름이 보인다는 문의가 들어왔다. 에러는 한 줄도 없고 지표는 오히려 좋아졌다. 캐시는 주소만 보고 사람은 안 본다.
카프카 컨슈머가 리밸런싱만 반복한다, max.poll.interval.ms
카프카 컨슈머가 일하는 시간보다 파티션을 다시 나누는 시간이 더 길어질 때가 있다. 컨슈머를 늘려도 그대로다. 살아 있는 컨슈머가 처리 시간 때문에 죽은 걸로 판정받고 있어서다.
PostgreSQL 이 쓰기를 거부할 때, XID wraparound
어느 날 PostgreSQL 이 모든 쓰기를 거부했다. 디스크도 CPU 도 멀쩡한데 DB 가 스스로 문을 닫았다. 그런데 이 일은 몇 주 전부터 지표에 다 보이고 있었다.
1초짜리 ALTER TABLE 이 서비스를 몇 분 세웠다
1초면 끝나는 컬럼 추가 마이그레이션을 돌렸는데 서비스 전체가 몇 분간 멈췄다. 마이그레이션은 시작도 못 한 상태였다. 락을 기다리는 줄 뒤에 평범한 조회까지 서 있었다.
타임아웃을 안 걸었다면 무한대로 건 것이다
외부 API 가 에러도 없이 응답만 안 주자, 우리 서버 스레드가 하나씩 묶이더니 몇 분 만에 서비스가 멈췄다. CPU 는 한가했다. 스레드는 전부 잠들어 있었다.
조건에 맞는 글이 없다. 브루니가 숨었나 보다.