조용한 개발 노트

안정성을 높이기 위한 장치가 왜 장애를 키우는가Timeout, Retry, Backoff는 분산 시스템에서 가장 흔히 사용하는 안정성 장치다.문제는 이 세 가지가 결합되는 순간, 시스템이 장애를 완화하는 방향이 아니라 증폭하는 방향으로 동작할 수 있다는 점이다.이 글에서는 각 기법의 사용법이 아니라, 왜 이 조합이 구조적으로 위험해지는지를 살펴본다.Timeout은 실패 감지 장치가 아니다Timeout은 흔히 “요청이 실패했음을 감지하는 수단”으로 오해된다.하지만 실제로 Timeout이 의미하는 것은 이것이다.이 시간 안에는 응답을 기다리지 않겠다즉, Timeout은 실패 판별이 아니라 기다림을 포기하는 시점이다.이 차이를 이해하지 못하면, Timeout 설정은 곧잘 잘못된 선택으로 이어진다.Timeout..

지연이 발생하면 가장 먼저 손대는 설정은 보통 타임아웃과 재시도입니다.값을 조금 줄이거나, 재시도를 한 번 더 추가합니다.하지만 이 선택은 문제를 해결하기도 하고, 반대로 장애를 더 빠르게 키우기도 합니다.이 편에서는 타임아웃과 재시도가 언제 도움이 되고, 언제 위험해지는지를 요청 흐름 기준으로 정리합니다.1. 타임아웃은 실패를 만들기 위한 장치다타임아웃의 목적은 요청을 성공시키는 것이 아닙니다.더 이상 기다리지 않겠다는 선언에 가깝습니다.즉, 타임아웃은 시스템을 빠르게 만들기 위한 장치가 아니라, 실패를 언제 인정할지 결정하는 기준입니다.이 전제를 놓치면, 타임아웃 값은 항상 “짧을수록 좋다”는 방향으로 흐릅니다.2. 타임아웃은 요청 경로 전체를 포함해야 한다요청 하나가 끝나기까지의 시간은 단일 지점에..