485
12
장
회복 탄력성
더 심각한 문제는 우리가 이야기하고 있는 그 다운스트림 서비스 (순무 )는
5
% 미만의 고객이
사용하는 기능으로 실제 수익은 그보다 훨씬 적었다는 점이다. 요점을 말하자면, 느리게 작동
하는 시스템이 빠르게 실패하는 시스템보다 다루기
훨씬훨씬
어렵다는 것을 알게 됐다. 분산 시스
템에서 지연 시간은 치명적이다.
풀에서 타임아웃을 올바르게 설정했더라도 모든 아웃바운드 요청에 대해 하나의
HTTP
커넥
션 풀을 공유하고 있었다. 이는 하나의 느린 다운스트림 서비스가 다른 모든 것이 정상인 경우
에도 자체적으로 사용 가능한 워커 수를 소진할 수 있다는 것을 의미했다. 마지막으로 잦은 타
임아웃과 실패로 인해 문제의 다운스트림 서비스가 정상적이지 않다는 것이 분명했지만, 그럼
에도 계속해서 트래픽을 그곳으로 전송했다. 하지만 이 상황에서는 다운스트림 서비스가 복구
할 기회를 놓치기 때문에 실제로 상황은 악화됐다. 필자와 동료들은 이런 일이 재발되지 않도
록 하려고 세 가지 수정 사항을 구현했다. 구체적으로 말하면
타임아웃타임아웃
을 올바르게 설정하고,
서로 다른 커넥션 풀을 구현하기 위해
벌크헤드벌크헤드
를 구현하고, 애초에 비정상 시스템에 호출을 보
내지 않도록
회로 차단기회로 차단기
circuit
breaker
를 구현했다.
12.5.112.5.1
타임아웃 타임아웃
타임아웃
time
-
out
은 간과하기 쉽지만 분산 시스템에서 올바르게 이해하는 것이 중요하다. 다운
스트림 서비스에 대한 호출을 포기하기 전에 얼마나 기다려야 하는가? ...