Handling Partial Failure
(부분적인 실패 처리)
API Gateway에 대해 이전 article에서 논의한 것처럼, 분산 시스템에서는 부분적인 실패에 대한 리스크가 항상 존재한다. Client와 service가 분리되어 있는 프로세스이기 때문에, service는 client의 요청에 대해 적기에 응답할 수 없을지도 모른다. Service는 실패나 유지보수 때문에 다운될지도 모른다. 혹은 service가 과부하로 인해 요청에 대해 극도로 느리게 응답할지도 모른다.
예를 들면, Product details scenario(상품 상세 정보 시나리오) article을 생각해 보라. Recommendation Service(추천 서비스)가 응답하지 못하는 상황을 상상해 보라. Client가 본래 실행할 기능은 응답을 무기한 기다리면서 중단될지도 모른다. 사용자 경험 측면에서 좋지 못한 결과일 뿐만 아니라 많은 어플리케이션에서 thread와 같은 값비싼 리소스를 사용하게 된다. 결국 실행환경에서 thread를 모두 사용하고, 다음 그림에서 보여주는 것처럼 응답할 수 없는 상황이 된다.
이 문제를 예방하기 위해서는 부분적인 실패를 처리할 수 있도록 서비스를 디자인하는 것이 필수적이다.
Netflix에서 설명하고 있는 한가지 방법을 따라가는 것도 좋은 접근 방법이다.
부분적인 실패를 다루기 위한 전략에는 다음 내용들이 포함되어 있다.
- 네트워크 타임아웃(Network timeouts) : 응답을 기다리고 있는 동안 결코 무한 대기하지 말고, 항상 타임아웃을 사용하라. 타임아웃을 사용하는 것은 리소스가 무한히 묶여 있지 않도록 해준다.
- 대기 요청 숫자의 제한(Limiting the number of outstanding requests) : Client가 특정 서비스에 가질 수 있는 대기 요청 숫자의 상한선을 정하라. 만약 제한된 숫자에 도달하게 되면, 추가적인 요청을 만드는 것은 무의미할 것이다. 그리고 그러한 시도들은 즉시 실패처리할 필요가 있다.
- 자동 차단 패턴(Circuit breaker pattern) : 성공적으로 수행된 요청과 실패한 요청의 숫자를 추적하라. 만약 오류 비율(error rate)이 설정된 한계값을 넘어간다면, 자동 차단기를 작동시키고 추가적인 시도들은 즉시 실패하게 된다. 만약 많은 요청들이 실패하게 된다면, 서비스 이용불가로 추측되기 때문에 요청을 보내는 것은 무의미하다. 타임아웃 기간이 지나고 나서 Client는 다시 시도하게 되고, 만약 성공한다면 자동 차단기를 닫는다.
- 대비책을 제공하라(Provide fallback) : 요청이 실패했을 경우에는 대비하는 로직을 수행하라. 예를 들면, 추천 정보들이 비어있을 경우에는 캐시된 데이터나 기본 값을 리턴하라.
Netflix Hystrix는 이러한 circuit breaker 패턴과 다른 패턴들을 구현한 오픈소스 라이브러리이다. 만약 JVM을 사용한다면, Hystrix를 사용하는 것을 분명히 고려해야 한다. 그리고 non-JVM환경에서 구동하고 있다면, 동등한 라이브러리를 사용해야 한다.
댓글을 달아 주세요
댓글 RSS 주소 : http://www.yongbi.net/rss/comment/762