회사에서 Circuit Breaker 도입을 하는데, 우선적으로 hystrix가 고려되었습니다.
Spring을 쓰고 있었고 hystrix 관련 레퍼런스도 많았기 때문입니다.
해당 레퍼런스들을 참고해서 진행하고.. 모니터링을 위한 hystrix dashboard, turbine, eureka 까지 보았건만.. 무엇인가 이상하고 잘 안되어 찾아보니..
사용 중인 Spring Boot 2.5.2 버전은 호환되는 Spring Cloud 2020.0.X 버전을 사용해야 하는데 해당 버전이 되면서 openfeign에 hystrix 관련 설정도 사라지고 해당 버전 Circuit Breaker가이드에도 hystrix관련 설명은 없었습니다.
(openfeign의 경우 기존에 hystrix.enabled 키가 circuitbreakcer.enabled 로 변경 됨)
하루 종일 hystrix 파악하고 세팅하기 위해 썻던 시간이.. 아까워지는 순간이었습니다..!!
Spring Cloud 버전이 올라가며 hystrix가 fade out 된 것은 hystrix가 2018년 11월부터 active development -> maintenence로 변경되었기 때문으로 보입니다. hystrix는 더 이상 활발히 개발되지 않기 때문 계속 개발이 진행되는 다른 Circuit Breaker를 선택하게 된 것이죠.
현재 Spring Cloud에서는 hystrix 대신 resilience4j를 권장하고 있고, 제가 사용하는 버전의 Spring Cloud Circuit Breacker 가이드에도 resilience4j 기준으로 설명이 되어 있습니다.
https://docs.spring.io/spring-cloud-circuitbreaker/docs/2.0.2/reference/html/
Spring Cloud Circuit Breaker
Spring Cloud is released under the non-restrictive Apache 2.0 license, and follows a very standard Github development process, using Github tracker for issues and merging pull requests into master. If you want to contribute even something trivial please do
docs.spring.io
https://resilience4j.readme.io/docs
Introduction
Resilience4j is a lightweight, easy-to-use fault tolerance library inspired byNetflix Hystrix, but designed for Java 8 and functional programming. Lightweight, because the library only uses Vavr, which does not have any other external library dependencies.
resilience4j.readme.io
resilience4j는 hystrix에서 영감을 받아 만들어졌지만 더 많은 기능을 제공하는데 관련해서는 위 공식 가이드만 읽어도 이해할 수 있게 가이드에 설명이 잘 되어 있습니다.
제 생각에는 가이드의 Introduction 부터 Bulkhead까지만 잘 읽으면 우선 적용하는데 필요한 주요 내용은 파악할 수 있는 것 같습니다.
Bulkhead
제가 Bulkhead 관련해서 처음에 이해를 잘 못했어서 관련해서만 간단히 설명을 해봅니다.
Bulkhead는 hystrix의 isolation과 대응되는 개념입니다. 특정 API에 대한 요청을 어떻게 다른 요청들과 격리시킬 것인가에 대한 것이라고 생각하시면 됩니다.
Semaphore는 해당 circuit으로 요청되는 최대 요청량을 세어서 최대 요청량을 넘지 못하게 해서 격리 시키는 것이고
Thread는 circuit당 지정된 갯수만큼의 쓰레드를 만들어 격리시키는 방식입니다.
Semaphore 방식이 무슨 격리냐라고 할 수 있지만 내부 서비스에 대한 요청들을 하나의 쓰레드풀을 쓰고 있을 때 한 서비스에 대한 요청이 느려지면서 해당 풀의 모든 쓰레드가 영향을 받는 문제를 해결할 수 있습니다.
hystrix에서는 thread 격리 방식이 권장되었는데, resilience4j 에서는 Semaphore 방식이 기본인 것을 보면 Semaphore 방식이 권장되는 것으로 보입니다. hystrix에서는 thread 방식이 기본 isolation 전략이었고 thread 생성으로 인한 큰 문제가 없다면 thread 방식을 사용하라고 권장하고 있습니다.
resilience4j의 Buldhead 설명 첫부분에서 SemaphoreBuldhead 가 대부분의 IO 모델에 적합하다고 설명을 하고 있는 것을 보면
아마 hystrix의 Semaphore 방식은 문제점이 있었는데 resilience4j에서는 문제가 되지 않거나 해결 했기 때문이지 않을까 싶네요.
'제안&정리' 카테고리의 다른 글
Application Scaling 전략 (0) | 2022.07.03 |
---|---|
React Native - NumberInput (0) | 2022.06.25 |
후이즈 도메인 구매 및 AWS Certificate Manager 연결 (0) | 2022.06.05 |
리팩토링은 점진적으로 그리고 테스트 작성부터 (0) | 2022.05.01 |
테스트 시 API 조회에 목사용? SpringBootTest & MockBean? (0) | 2022.04.10 |