Server Side LoadBanlancer
- 일반적인 L4 Switch 기반의 Load Balancing
- client는 L4 주소만 알고 있음
- L4 Switch 는 Server의 목록을 알고 있음 (Server Side Load Balancing)
- H/W Server Side Load Balancer 단점
- H/W가 필요 (비용 up 유연성 down)
- 서버 목록의 추가를 위해서는 설정 필요 (자동화 어려움)
- Load Balancing Schema가 한정적 (Round Robbin, Sticky)
- 12 Factors의 dev/prod를 만족하기 어려움
Client LoadBalancer - Ribbon
- client (API Caller)에 탑재되는 S/W 모듈
- 주어진 서버 목록에 대해서 Load Balancing을 수행
- Rebbon의 장점
- H/W가 필요없이 S/W로만 가능 ( 비용 down, 유연성 up )
- 서버 목록의 동적 변경이 자유로움 (단. 코딩 필요)
- Load Balancing Schema를 마음대로 구성 가능 (단. 코딩 필요)
[실습 Step-3] RestTemplate에 Ribbon 적용하기
- [product] ProductController 정상 코드로 복원
- 준비작업 (Application 정상화)
- Sleep 제거 / Throw Exception 제거
- [display] build.gradle에 dependency 추가
- compile('org.springframework.cloud:spring-cloud-starter-netflix-ribbon')
- [display] DisplayApplication의 RestTemplate 빈에 @LoadBalanced 추가
- [display] ProductRemoteServiceImple에서 주소를 제거한 뒤, 'product'로 변경
- [display] application.yml에 ribbon 설정 넣기
실습 정리 - Ribbon
- Ribbon 디펜던시 추가 후 RestTemplate에 @LoadBalanced
- 설정에 특정 서비스 (Product)의 주소 설정
- RestTemplate 사용 시 주소를 넣지 않고 서비스 이름 (Product) 사용
- 로드 발란스?
[실습 Step-3] Ribbon의 Retry 기능
- [display] application.yml에 서버 주소 추가 및 Retry 관련 속성 조정
- [display] build.gradle에 retry dependency 추가
- compile('org-springframework.retry:spring-retry:1.2.2.RELEASE')
- 확인
- localhost:7777은 없는 주소이므로 Exception이 발생
그러나, Ribbon Retry로 항상 성공
- Round Robin client Load Balancing & Retry
주의 사항 - Ribbon Retry
- Retry를 시도하다가도 Hystrix Timeout이 발생하면 즉시 에러 반환 리턴
(Hystrix로 Ribbon을 감싸서 호출한 상태기 때문)
- Retry를 끄거나, 재시도 횟수를 0으로 하여도 해당 서버로의 호출이 항상 동일한 비율로 실패하지 않는다.
(실패한 서버로의 호출은 특정 시간 Skip 되고 그 간격은 조정된다 - BackOff)
- Classpath에 retry가 존재해야 한다는 점 주의
실습 정리 - Ribbon Retry
- Ribbon은 여러 Component에 내장되어 있으며,
이를 통해 Client Load Balancing이 수행 가능하다.
- Ribbon에는 매우 다양한 설정이 가능하다. (서버 선택, 실패 시 Skip 시간, Ping 체크)
- Ribbon에는 Retry 기능이 내장되어 있다.
- Eureka 와 함께 사용될 때 강력하다.