5. Circuit breaker의 필요성
내부
Service A
내부
Service B
내부
Service C
CACHE A CACHE B
QUEUE
내부API
외부
API
DB A
DB B
DB C
외부
ServiceB
외부
ServiceA
외부
ServiceC
외부
ServiceC
외부
API
내부
Service A
내부
Service C
외부
API
내부
Service B
내부
Service C
9. Thread VS Semaphore
• Thread
• 별도 Thread pool의 thread로 HystrixCommand 수행
• 수행중인 thread의 수행시간 오버시 취소 가능
• semaphore에 비해 상대적으로 성능 오버헤드가 큼
• peak rps * 응답시간(sec) + 여유공간으로 thread pool core size 지정 필요
• Semaphore
• 어플리케이션 워킹 thread가 HystrixCommand 수행
• 인스턴스당 초당 수백건 이상의 요청을 처리해야 하는 경우 선택
10. 11번가는 어떻게?
• 11번가에도 주요 연동 프로세스엔 스위치 기능 구현
• 자동 ON/OFF, 수동 ON/OFF 개별 구현
• Hystrix의 장점
• instance별 제어
• 스위치 반영 즉시성
• 요청 횟수와 수행시간등 부가적인 정보 제공
• Dashboard 제공
14. Hystrix metrics 수집
Hystrix Dashboard
(Proxy)
Application
(HystrixEventStrea
m)
Application
(HystrixEventStrea
m)
Application
(HystrixEventStrea
m)
Application
(HystrixEventStrea
m)
Turbine Stream
Aggregator
text/event-stream
text/event-stream
text/event-stream
15. Hystrix plugin
• Dashboard의 아쉬운 점
• 현재 데이터만 모니터링 가능
• 문제 발생 인스턴스를 확인하기 힘듦
• 스위치 수동 제어기능이 없음
• 문제 발생시 자동 알림 기능 부재
• Plugin을 이용 입맛대로 수정 가능
• Event notifier
• Metric Publisher
• Properties Strategy
• Concurrency Strategy
16. 마치며
• 11번가 Hystrix 적용 현황
• 커스텀 Dashboard로 문제 발생 instance와
command만 별도 확인 및 과거 이력 조회 기능 제
공
• Client APP(Android)로 쉽게 스위치 컨트롤 기능
제공
• 실시간 Hystrix properties 변경 기능 제공
• 비동기 Queue에 적용. Cache등 적용 확대 중