00. Netflix OSS와 spring cloud
00-0. Netflix OSS
- 50개 이상의 사내 프로젝트를 오픈소스로 공개
- 플랫폼(AWS)안의 여러 컴포넌트와 자동화 도구를 사용하면서 파악한 패턴과 해결방법을 블로그, 오픈소스로 공개
00-1. Spring Cloud
- Spring Cloud란: Cloud Native하게 개발할 수 있는 환경을 spring 기반으로 만든 것
00-2. Netflix OSS와 spring cloud 교집합 => spring-cloud-netflix
01. Hystrix – Circuit Breaker
01-0. 모놀리틱에서의 의존성 호출
: 실패가 없는 100퍼센트 신뢰도의 호출
01-1. MSA환경에서의 의존성 호출
- 분산 시스템, 특히 클라우드 환경에선 실패(Failure)는 일반적인 표준이다 (Failure as a First Class Citizen)
- 모놀리틱엔 너어어어무 확률이 적어서 신경 안썼던 장애 유형
- 한 마이크로 서비스의 가동률(uptime) 최대 99.99%이라고 할 때
✔ 30개의 마이크로 서비스가 있다면, 99.99^30 = 99.7% uptime
✔ 10억개의 요청 중 0.3% 실패 -> 300만 요청이 실패
✔ 모든 서비스들이 이상적인 uptime을 가지고 있어도 매 달 2시간 이상의 downtime이 발생한다는 수학적 예측
01-2. Circuit Breaker – Hystrix
: Latency Tolerance and Fault Tolerance for Distributed Systems (지연감내 및 실패감내)
모든 설정이 기본이라고 가정하고 임베디드 톰켓으로 4개의 서버를 배포했다고 생각해보자
- 기본 서블릿 쓰레드 값 = 200
- 기본 Timeout = 무한대 -> 한 번의 요청이 끝나기 전엔 그 쓰레드를 못쓴다는 의미
✔ 만일 마지막 서비스가 down되어 버리면, 무한정 대기, 무한정 대기, 200개가 꽉차면 그 앞에게 무한정 대기 무한정 대기 .... 200개가 전부다 대기하고 있으면 down되어 버리는 거임
✔ 가용성이 좋은 서비스가 아니게 되어버림....ㅠ
01-3. Hystrix 적용하기
Hystrix 커맨드 적용하기 (annotation 붙이면 됨)
- 이 restTemplate을 가로채서 대신 실행시킴
- 결과를 통계를 내서, 조치를 취함
Circuit Breaker!!
- Circuit Open??
: Circuit이 오픈된 Method는 (주어진 시간동안) 호출이 ‘제한’되면, ‘즉시’에러를 반환한다 - Why?
: 특정 메소드에서의 지연이 시스템 전체의 Resource를 모두 소모하여 시스템 전체의 장애를 유발함 - So,
: 장애를 유발하는 (외부) 시스템에 대한 연동을 조기에 차단 (Fail Fast) 시킴으로서 나의 시스템을 보호함 - 기본 설정,
: 10초동안 20개 이상의 호출이 발생했을 때, 50% 이상의 호출에서 에러가 발생하면 Circuit을 open함.
✔ Circuit이 open된 경우의 에러처리? -> Fallback
✔ Fallback method는 Circuit이 오픈된 경우 혹은 Exception이 발생한 경우 대신, 호출될 Method.
✔ 장애 발생시 Exception대신 응답할 Default구현을 넣는다
- 오랫동안 응답이 없는 메소드에 대한 처리 방법은? – Timeout
✔ 설정하지 않으면 default 1000ms
✔ 설정 시간동안 메소드가 긑나지 않으면 Hystrix는 메소드를 실제 실행중인 쓰레드에 interrupt()를 호출하고, 자신은 즉시 HystrixException을 발생시킴
✔ Fallback도 이 때 똑같이 실행될라면 실행 됨
02. 실습
- 배경
✔ Display 서비스는 외부 서버인 Product API와 연동되어 있음
✔ Product API에 장애가 나더라도 Display의 다른 서비스는 이상없이 작동되어야 함
✔ Product API에 응답 오류인 경우, Default값을 넣어주고 싶다 - 결정 내용
✔ Display -> Product 연동 구간에 Circuit Breaker를 적용해보자
02-0. Hystrix Fallback 적용하기
- [display] build.gradle에 hystrix dependency 추가
- [display] DisplayApplication에 @EnableCircuitBreaker추가
- [display] ProductRemoteServiceImp에 @HystrixCommand추가
02-1. Hystrix Fallback 적용하기
- [product] ProdcutController에서 항상 Exception던지게 수정하기 (장애 상황 흉내)
- [display] ProductRemoteServiceImp에 Fallback Method 작성하기
- 확인
: Hystrix가 발생한 Exception을 잡아서 Fallback을 실행. Fallback여부와 상관없이 Circuit 오픈 여부 판단을 위한 ‘에러통계’는 계산하고 있음. 아직 Circuit이 오픈된 상태는 X - Fallback원인 출력하기
: Fallback 메소드의 마지막 파라미터를 ‘Throwable’로 추가하면 Fallback일으킨 Exception을 전달 해줌 - 정리
: Hystrix에서 Fallback의 실행 여부는 Exception이 발생했는가 여부.
Fallback의 정의 여부는 Circuit Breaker Open과 무관.
Throwable 파라미터의 추가로 Fallback원인을 파악할 수 있음
02-2. Hystrix로 Timeout처리하기
부터는 ppt 참고하기 (p.66 - p.79) 
Today, I Shoveled AGAIN....