1. Why MSA in 11st?
초대형 거대 Monolithic System(Click)
8년 넘게 사용해 온 낙후된 S/W Stack
200만 라인의 공통 모듈
폭증하는 트래픽으로 수년 내에 감당하기 힘들 것으로 예상되는 부하
2. Project Vine(11번가 팀에서 만듦)
2-1) Project Vine
Strangler Application Pattern
Legacy System(Click) 교살 전략
→ 새로운 Application은 도립된 API 서버로 개발
→ Legacy와 함께 운영
2-2) Project Vine Image
→ 업무 도메인 별로 서버 분리
→ Legacy 코드에서는 새로운 API 서버들을 호출
→ 기존 코드와 새로운 API 호출은 DB Flag를 통해서 Switchable하게
3. MSA 플랫폼 Solution
3-1) NETFLIX | OSS(Click)
→ 개발자들이 가장 친숙해 하는 환경
4. Java Library Hystrix(Click)
4-1) Hystrix
Netflix가 만든 Fault Tolerance Library
장애 전파 방지 & Resilience
4-2) Hystrix Java Library
4-3) Hystrix의 주요 4가지 기능
4-4) Hystrix Command를 호출할 때 벌어지는 일
4-4)-1. Isolation
→ 두 가지 Isolation 방식을 Circuit Breaker 별로 지정 가능함.
Semaphore Isolation(Optional)
→ 연동 System의 호출될 수 있는 갯수를 지정할 수 있음.
→ Circuit Breaker 1개 당 1개의 Semaphore 생성
→ 최대 개수 초과시 Semaphore Rejection 발생(Fall-back 실행)
→ Command를 호출한 Caller Thread에서 메소드 실행
⇒ 특정 시스템의 지연이 일어나서 전체 시스템이 망가지는 걸 대비해서
⇒ 각각의 뒷단 시스템의 용량을 조정함으로써 이 이상의 Request가 들어갈 때 자동으로
⇒ Rejection이라는 Error가 남.
Thread Isolation(Default)
→ Intercept하여 대신 실행함.
→ API Caller(콜러)와 Callee(콜린)(Click)이 다른 쓰레드에서 실행됨.
→ 이 말은 누군가가 가로채서 대신 실행준다는 말임.
→ 이게 Thread Isolation 개념임.
⇒ Circuit Breaker 별로 사용할 Thread Pool을 지정(ThreadPoolKey)
⇒ Circuit Breaker : Thread Pool = N : 1 관계 가능
⇒ 최대 개수 초과시 Thread Pool(Click) Rejection 발생 (Fall-back 실행)
⇒ Command를 호출한 Thread가 아닌 Thread Pool에서 메소드 실행.
4-4)-2. Circuit breaker(Click)
메소드의 실행 결과 성공 혹은 실패(Exception) 발생 여부를 기록하고 통계 냄.
통계에 따라 Circuit Open 여부를 결정함.
(1) 일정 시간 동안 (2) 일정 개수이상의 호출이 발생한 경우,
(3) 일정 비율 이상의 에러가 발생하면 —> Circuit Open(호출 차단)
⇒ Open, 누전 차단기와 같다. 누군가 가로채서 인셉션을 바로 튀어나감.
(4) 일정 시간 경과 후에 단 한 개의 요청에 대해 호출을 허용하며(Half Open),
이 오출이 성공하면 —> Circuit Close(호출 허용)
→ 외부에서 장애가 생기면 같이 장애가 날 확률이 높을 수 있기 때문에
→ 인위적으로 Circuit Breaker Key에 해당하는 값을 같게 해주면
⇒ 두 개의 메소드는 통계를 공유하게 되고, 하나가 차단될 때 나머지도 함께 차단이 됨.
4-4)-3. Fall-back(Click)
실패한 경우 (Exception) 사용자가 제공한 메소드를 대신 실행함.
ex) 상품 추천 서버를 호출했는데 추천 서버가 반응이 없거나 Exception이 난다면
고정된 상품 목록을 대신 보여줌으로써 사용자 불편사항을 최소화 할 수 있음.
⇒ Fall-back 잘못 사용하면 비즈니스 로직의 에러나 장애 상황을 감추게 될 수 있음.
4-4)-4. Time out
특정시간 동안 메소드가 종료되지 않는 경우 Exception을 발생시킴.
Q : 사용하는 대부분 Library에는 Time out이 존재하는데
별도의 인터셉터하는 Time out을 줄 필요가 있을까?
→ 어느 시간 안에 Timeout을 결정하지 못하는 경우가 있어 대부분적으로 걸어주기에 적당함.
⇒ Timeout이 1초라는 작은 값이 지정되어 있지만 대부분의 API는 1초 이하인 경우 많음.
⇒ UI 로직이나 좀 더 복잡한 로직의 경우 충분히 1초를 넘길 수도 있음. 적절히 조절해 사용해야함.
5. Netflix OSS의 Eureka(Click)
5-1) Netflix가 만든 Dynamic Service Discovery
등록 : 서버가 자신의 서비스 이름(종류)와 IP 주소, 포트를 등록.
조회 : 서비스 이름(종류)을 갖고 서버 목록을 조회.
⇒ Ribbon이 서버 목록을 가져올 때 사용 됨.
5-2) Eureka가 Enable된 Spring Cloud Application
Server가 시작시 Eureka Server에 자동으로 자신의 상태 등록 (UP)
주기적 HeartBeat으로 Eureka Server에 자신이 살아 있음을 알림.
Server 종료시 Eureka Server에 자신의 상태 변경(DOWN) 혹은 자신의 목록 삭제.
Eureka 상에 등록된 이름은 'spring.application.name'
5-3) Eureka + Ribbon in Spring Cloud
하나의 서버에 Eureka Client와 Ribbon Client가 함께 설정되면 Spring Cloud는
다음의 Ribbon Bean을 대체
5-3)-1. ServerList<Server>
기본 : ConfiurationBasedServerList
변경 : DiscoveryEnabledNIWSServerList
5-3)-2. IPing
기본 : DummyPing
변경 : NIWSDiscoveryPing
⇒ 서버의 목록을 설정으로 명시하는 대신 Eureka를 통해서 Look up 해오는 구현
6. Netflix OSS의 Ribbon(Click)
6-1) Netflix가 만든 Software Load Balancer를 내장한 RPC(REST) Library
