4 posts
타임아웃이나 크래시가 API 요청이 사라졌다는 뜻은 아닙니다. idempotency key가 재시도를 안전하게 만드는 방식, 그리고 실제로 중복을 방지하는 저장소 패턴을 소개합니다.
요청을 처리하던 중 서비스가 크래시됩니다. 클라이언트는 타임아웃을 보고 재시도합니다. 이제 두 건의 결제가 생겼습니다. 고객은 화가 났습니다. 데이터베이스는 일관적입니다. 비즈니스 로직은 그렇지 않습니다. 이건 엣지 케이스가 아닙니다. 분산 시스템의 기본 동작입니다. 네트워크는 패킷을…
서버를 재시작하면 인메모리 뮤텍스는 사라진다. 펜싱 토큰과 TTL을 갖춘 분산 리스가 크래시 이후 중복 작업을 어떻게 막는지, 그리고 여전히 물러서는 지점은 어디인지 설명한다.
는 를 견디지 못한다. OOM, 배포 롤아웃, 노드 재부팅에서도 살아남지 못한다. 프로세스가 종료되는 순간 락은 사라진다. 그 락이 예약된 잡, 데이터 마이그레이션, 리더 선출을 보호하고 있었다면, 이제 두 프로세스가 각자가 유일하게 실행 중이라고 믿게 된다. 이건 뮤텍스의 버그가…
대부분의 circuit breaker 라이브러리는 복구를 probe하기 위해 background thread를 생성한다. 그럴 필요 없다. 이 글에서는 correctness를 희생하지 않으면서 모든 background overhead를 제거하는 request-driven 설계를 소개한다.
내가 리뷰한 모든 프로덕션 circuit breaker는 결국 background thread를 생성한다. Go의 goroutine일 수도, Java의 일 수도, Rust의 tokio task일 수도 있다. 하는 일은 항상 같다: 몇 초마다 깨어나 downstream service가…
크래시 온리 소프트웨어는 모든 실패를 크래시로, 모든 시작을 복구로 취급한다. 웹 서비스에 적용하면, 셧다운 로직을 삭제하고 kill -9를 견디는 상태를 설계하는 것을 의미한다.
웹 서비스에는 셧다운 핸들러가 있다. 버퍼를 플러시하고, 연결을 닫고, 체크포인트를 기록한다. 한 번쯤 테스트했을지도 모른다. 프로덕션에서는 계획된 배포 중 1년에 한 번 정도 실행될 것이다. 나머지 시간에는 서비스가 OOM 킬, 노드 축출, 정전, 또는 타임아웃으로 SIGKILL을…