타임아웃과 재시도, 서킷 브레이커

느린 호출이 스레드나 커넥션을 붙잡고 있어 다른 요청이 쓸 자원이 사라지기 때문입니다.

4번이 핵심입니다. 문제는 외부 API 하나인데 증상은 전체 장애로 나타납니다. 그래서 원인을 찾기 어렵습니다.

두 번째가 근본입니다. 자원을 나눠 두면 그 부분만 고장 나고 나머지는 계속 돕니다.

흔한 실수: 타임아웃만 줄여 해결하려는 것. 짧게 해도 그 시간 동안 자원을 점유하는 것은 같아서, 호출량이 많으면 여전히 전체가 막힙니다.

열림 상태의 의미가 중요합니다. 실패할 것이 뻔한 호출을 하지 않는 것입니다. 그러면 우리 자원을 점유하지 않고, 상대에게 부하를 더 얹지도 않습니다.

반열림이 필요한 이유는 회복을 감지하기 위해서입니다. 열림을 영구히 유지하면 상대가 복구돼도 모릅니다. 소수만 보내 확인하고, 괜찮으면 전체를 재개합니다.

설정에서 정할 것들입니다.

흔한 실수: 마지막 항목을 구분하지 않는 것. 잘못된 요청(4xx)을 실패로 세면, 우리 버그 때문에 정상인 상대를 차단하게 됩니다.

자원을 칸으로 나눠 한 칸이 마르더라도 다른 칸은 계속 돌게 하는 것입니다. 배의 격벽에서 온 이름입니다.

없을 때와 있을 때가 이렇게 갈립니다.

차단기와 함께 쓰면 더 낫습니다. 격리가 피해 범위를 가두고, 차단기가 그 안에서도 빨리 포기하게 만듭니다.

대가는 자원 효율입니다. 나눠 두면 한쪽이 남고 다른 쪽이 부족한 상황이 생깁니다. 전체 활용도를 조금 내주고 장애 격리를 얻는 거래입니다.

흔한 실수: 격리를 인스턴스 분리로만 생각하는 것. 한 프로세스 안에서 스레드풀을 나누는 것만으로도 큰 효과가 있고, 훨씬 값쌉니다.

받을 수 없는 요청을 받으면 아무도 응답받지 못합니다. 일부를 거절하는 것이 전체를 지키는 방법입니다.

핵심은 이미 포기한 요청을 처리하는 낭비입니다. 클라이언트가 3초에 타임아웃하는데 큐 대기가 10초면, 처리한 결과를 받을 사람이 없습니다. 그런데도 자원은 씁니다.

빨리 실패하는 것이 사용자에게도 낫습니다. 10초 기다려 실패하는 것보다 즉시 실패해 재시도 안내를 받는 편이 낫습니다.

흔한 실수: 큐를 무한으로 두는 것. 요청을 잃지 않으려는 의도지만, 결과적으로 모든 요청을 잃습니다.