서킷 브레이커(Circuit breakers)와 재시도 패턴(retry patterns): 탄력적인 분산 시스템 구축하기

분산 시스템(distributed system)에서는 모든 원격 호출(remote call)이 실패할 수 있습니다. 네트워크가 분할(partition)되고, 서비스가 충돌(crash)하며, 의존성(dependencies)이 저하됩니다. 재시도(Retries)와 서킷 브레이커(circuit breakers)는 이러한 장애에 맞서는 첫 번째 방어선입니다. 올바르게 사용하면 시스템을 탄력적(resilient)으로 만들지만, 잘못 사용하면 상황을 악화시킵니다.

재시도는 네트워크 타임아웃(network timeouts), 연결 재설정(connection resets), 일시적인 사용 불가능 상태와 같은 일시적인 장애(transient failures)를 처리합니다. 지터(jitter)를 포함한 지수 백오프(Exponential backoff)가 표준적인 접근 방식입니다. 각 재시도 사이의 대기 시간을 최대치까지 두 배씩 늘리고, 재시도 트래픽을 분산시키기 위해 무작위 지터(random jitter)를 추가합니다. 전형적인 패턴은 다음과 같습니다: 100ms, 200ms, 400ms, 800ms, 1.6s, 3.2s, 최대 10s까지 증가합니다.

모든 오류를 재시도해서는 안 됩니다. HTTP 4xx 오류(429 및 408 제외)는 클라이언트 오류(client errors)를 나타내므로 즉시 실패(fail fast)해야 합니다. HTTP 5xx 오류와 네트워크 타임아웃은 재시도해야 합니다. 이 차이를 알고 그에 따라 재시도 정책(retry policy)을 구성하십시오. 400 Bad Request를 재시도하는 것은 결코 성공할 수 없으며 리소스만 낭비할 뿐입니다.

최대 재시도 횟수(maximum retry count)와 마감 시간(deadline)을 설정하십시오. 30초 동안 5번 재시도된 요청은 추가 재시도를 통해 성공할 가능성이 낮습니다. 즉시 실패(Fail fast)하고 상위 클라이언트(upstream client)가 장애를 처리하도록 하십시오. 시스템 부하를 증가시키는 재시도를 쌓아두는 것보다 빠르게 실패하는 것이 더 낫습니다.

서킷 브레이커 패턴(circuit breaker pattern)은 재시도가 실패 중인 서비스를 압도하는 것을 방지합니다. 장애율(failure rate)이 임계값(threshold)을 초과하면 서킷이 열리고(opens), 이후의 호출은 원격 호출을 시도하지 않고 즉시 실패합니다. 타임아웃 이후, 서킷은 반개방(half-open) 상태로 전환되어 몇 개의 테스트 요청을 허용합니다.

서킷 브레이커에 적절한 임계값을 선택하십시오. 배포 중에 가끔 503을 반환하는 서비스는 장애(outage)로 인해 실패하는 서비스와는 다른 임계값이 필요합니다. 서킷 브레이커의 상태를 모니터링하고 서킷이 열릴 때 알림을 받도록 설정하십시오.

모든 계층에서 재시도(retries)와 서킷 브레이커(circuit breakers)를 구현하십시오. 호출하는 서비스, API 게이트웨이(API gateway), 그리고 클라이언트 모두 재시도를 수행합니다. 하지만 재시도가 중첩되지 않도록 각 계층마다 서로 다른 타임아웃(timeouts)을 사용해야 합니다. 클라이언트는 내부 서비스들보다 더 거친 입도(coarser granularity)로 타임아웃을 설정하고 재시도해야 합니다.

Rizwan Saleem | https://rizwansaleem.co