분류
장애·확장 · 2쪽
타임아웃·재시도·캐시·트래픽 급증처럼 서비스가 커질 때 무너지는 지점과 버티는 법을 모았어요.
23편 · 마지막 글 2026.10.16
장애·확장 글
23편 중 13–23
정규식 한 줄로 CPU 가 100% 가 된다
이메일 형식을 확인하는 평범한 정규식 때문에 서버 CPU 가 100% 에 붙었어요. 문자열 하나 검사에 몇 분이 걸렸고요. 어떤 패턴이 위험한지, 입력 하나로 서버가 멈추지 않게 막는 법을 알 수 있어요.
AWS 2017년 스토리지 장애 — 잘못된 입력 하나가 4시간이 된 구조
2017년 AWS 스토리지 서비스가 약 4시간 멈추자 인터넷의 상당 부분이 함께 멈췄어요. 시작은 잘못 입력한 명령 하나였고요. 사람의 실수를 탓하는 대신 실수가 커지지 않게 막는 설계를 읽어 봤어요.
GitHub 43초 네트워크 단절이 24시간 장애가 된 이유
2018년 GitHub 은 데이터센터 사이 네트워크가 43초 끊긴 일로 24시간 넘게 정상이 아니었어요. 원인은 1분도 안 돼 사라졌는데요. 짧은 단절이 긴 장애로 커지는 구조와 막는 법을 짚었어요.
서킷 브레이커 — 느린 의존성 하나가 서비스 전체를 붙잡을 때 끊는 법
타임아웃을 걸어 뒀는데도 의존 서비스 하나가 느려지자 서비스 전체가 느려져요. 실패할 걸 알면서 계속 기다리기 때문이에요. 서킷 브레이커가 그 고리를 끊는 방식과 설정에서 흔한 실수를 알 수 있어요.
CDN 이 로그인한 사람의 화면을 캐시한다
CDN 을 붙였더니 내 계정에 다른 사람 이름이 보인다는 문의가 들어와요. 에러는 한 줄도 없고 지표는 오히려 좋아졌고요. 로그인한 화면이 남에게 나가는 이유와 안전한 캐시 설정을 알 수 있어요.
카프카 컨슈머가 리밸런싱만 반복할 때 — max.poll.interval.ms
카프카 컨슈머가 일하는 시간보다 파티션을 다시 나누는 시간이 더 길어질 때가 있어요. 컨슈머를 늘려도 나아지지 않고요. 살아 있는 컨슈머가 죽은 것으로 취급되는 이유와 이 고리를 끊는 법을 정리했어요.
타임아웃 기본값이 「무한」인 클라이언트가 많다 — 연결·읽기·전체 타임아웃
외부 API 가 에러도 없이 응답만 안 주자, 우리 서버 스레드가 하나씩 묶여 몇 분 만에 서비스가 멈췄어요. 타임아웃을 안 걸면 무한정 기다리는 클라이언트가 많은 이유와 값 정하는 법을 다뤄요.
재시도 폭주 — 지수 백오프·지터·재시도 예산으로 막기
DB 가 몇 초 느려졌을 뿐인데 서비스가 무너지고, 원인이 사라진 뒤에도 회복이 안 돼요. 「실패하면 세 번 재시도」라는 상식적인 설정이 어떻게 장애를 키우는지 보여 드려요.
멱등성 — 재시도는 반드시 일어난다
사용자는 결제 버튼을 한 번 눌렀는데 두 번 청구됐어요. 응답을 못 받았다고 재시도한 게 원인이었죠. 재시도가 언젠가 꼭 중복을 만드는 이유와 같은 요청을 한 번만 처리하는 법을 다뤄요.
keep-alive 를 안 쓰면 악수만 하다 끝난다
상대 서비스는 5ms 만에 처리하는데 우리 쪽에서 재면 40ms 가 나와요. 사라진 35ms 는 요청마다 연결을 새로 맺는 데 쓰이고 있었어요. 설정은 맞는데 쓰는 법이 틀린 흔한 실수를 짚어요.
캐시 스탬피드 — 만료 순간 DB 가 몰리는 이유와 막는 법
캐시 적중률은 95% 인데 정각마다 DB 부하가 순간적으로 치솟아요. 캐시가 만료되는 그 순간 요청이 한꺼번에 DB 로 몰리는 현상과 이를 막는 네 가지 방법을 정리했어요.
조건에 맞는 글이 없어요. 브루니가 숨었나 봐요.