MSA
시스템이 낙후되었다?
개발자 관점에서 나쁜 시스템이 나쁜 개발 문화를 만들게 된다
MSA를 만드는 기준은 개발 문화가 좋은 것인가? 라는 부분을 고려해야 한다
과감하게 리팩토링 하면 전사 장애가 난다는 확실한 부분이 있다면 분명히 이것을 처리해야 한다.
안 쓰이는 코드를 정적 분석으로 파악도 되지 않았다.
대규모 시스템을 직접 들어가서 수정하기 자체가 힘들었음
점진적 MSA 전환
Vine 이라는 프로젝트 명
기존 코드를 놔둔 채로 새롭게 하나하나 다 쪼개가는 REST API 설계부터 시작했음
Legacy Code에서는 새로운 api서버를 호출하는 방식으로 처리했지만, DB flag를 통해서 바로 스위칭 가능하도록 세팅해뒀음
솔루션
netflix oss 가 가장 관심이 갔었음 netflix 의 경우는 자기만의 로직이기에 production 단계에서 검증된 로직이었음. spring boot 환경이었음
netflix oss, spring cloud spring cloud netflix 라고 하는 요소가 있었음
솔루션을 하나하나 찾아서 구축한다
Hystrix, Ribbon, Eureka 라는 3가지 단어
Hystrix
서킷 브레이커?
총 4가지 기능이 있어야 함
1. circuit breaker
2. Fallback
3. Thread Isolation
4. Timeout
Hystricx는 jvm만 있어도 됨
Aop를 지원하는 anotrix도 정말 간단하게 도입할 수 있음 개발자 개개인이 직접 진행할 수 있었던 부분이 있었음
api caller와 api callee 가 서로 다른 thread에서 일어남
Exception이 났던 모든 부분을 다 통계를 내고, 모든 exception 개수를 circuit open 여부를 결정
실패했을 경우 Fallback 이라고 지정된 다른 메서드를 호출해줌
Timeout 은 일정 시간만에 도달하지 않으면 무조건 리턴해버림. socket conn timeout 같은 부분은 우리가 준 부분이 아니라 다른 타임아웃에 영향을 받는 다는 것같은 것들을 계산하기도 정말 힘들고, 이런 부분을 무조건 intercept 하는 부분이 있어서 됨
일정 시간동안 일정 개수 이상 호출시 일정 비율이상의 에러가 circuit open. 서킷 open 이라는 것은 무조건 차단시키는 것
일정 시간 경과 후 단 한개의 요청에 대해서 호출이 허용하면, circuit close를 해버림. 그래서 사용이 가능하도록 할 수 있어야 했음
무조건 circuit breaker 를 구축해두어야 사실 모든 것들을 제대로 작동시키는 핵심 키워드가 됨. a가 b,c,d 모두를 호출해서 결과를 얻어야 하는 상황이 있었을 때, b가 지연되었을 경우 c,d까지 다 못 쓰게 막는 것이 아니라 b만 차단하는 것이 효율적임
대략 10초간 20번 이상의 호출이 있었을 경우, 50% 이상의 에러가 발생했을 경우 5초간 circuit open같은 부분이 default 라고 생각해도 괜찮음
circuit breaker를 시도했을 경우 무조건 circuit breaker를 사용할 때 단위를 정해야 함. command key가 같은 경우 같은 통계로 처리해버림. 너무 작은 단위, 너무 큰 단위로 했을 경우, 작은 경우 모두 문제가 쉽게, 많이 발생할 수 있음
fallback도 정말 중요함. circuit open이 발생하거나, 모든 익셉션이 발생하면 전부 다 fallback이 호출했기에 안정적으로 작용시킬 수 있음
fallback을 너무 막 정해두게 된다면 심각한 문제가 생겨나는데, fallback이 exception같은 것들을 전부 다 감추어버리는 현상이 생기는데, 이것은 정말 심각함
HystrixBadRequestException 이라는 부분이 있는데, 이 부분은 badrequest 에 해당하는 부분인데, 이 부분은 분명한 사용자의 잘못인데, exception이 던져지면 이것은 커다란 문제가 될 수 있음. 그렇기에 이런 exception 은 우리 로직상 문제가 아니기 때문에, circuit breaker같은 부분에서 통계에서 빼버림
timeout 같은 것들은 circuit break 같은 것들이 default 같은 부분이 1초이기에 잘 조절할 필요가 있었음
Isolation Semaphore, Thread 같은 부분이 있었음
Semaphore를 지정할 필요가 있었음
시스템이 3개가 있고, semaphore isolation 이라고 정했다면, 최대 동시 호출 지정을 해서 간단하게 처리가 가능함.
단점은 caller thread가 실제 실행하는 스레드가 같다는 것이 있음. timeout 이 제대로 발생하지 않음. java에서 고질적인 문제가 있는데, thread.interrupt만 처리를 할 수가 없기에 계속 루프가 돎
thread Isolation은 어느 thread pool 에서 n:1의 관계로 맵핑이 가능하고, 실제 thread가 다르기에 바로 return을 처리할 수 있다는 장점이 있음
caller thread가 바로 return을 하는 부분이 있음
많은 library 가 threadlocal 에서 발생한다는 부분이 많다는 점이 있음.
Ribbon 이 client load balancer라는 부분이라는 것이 중요함. api 의 caller 쪽에 load balancing 이 처리가 할 수 있다는 개념임
api Caller 에서 ribbon이 있기에, 하드웨어 단위로 처리하는 elb같은 것을 거치지 않고도 해결할 수 있다는 해결책이 있음
줄 api gateway 자체에 rebone 이 있고, rest template 를 써도 가능함.. java 부럽다..
서버 군 명만 집어넣으면 알아서 처리를 해주는 부분이 있음.
근데 왜 ribbon인가? 라는 부분에 있어서 완벽한 programmable 한 코드라는 부분이 있다는 장점이 있음
IRule 은 어떤 서버를 선택할 것인지. 기본적으로는 1/n이다
Eureka 실제로 dns 기반이 아니라, eureka server에 등록함으로써 다른 애들이 가져갈 수 있도록 하는 서버. euraka server를 그냥 따로 두고, 시작시 자동으로 등록하는 방식이 있어야 함
주기적으로 health check도 해야하고, 정보같은 것들도 해야하고, 서버 이름도 해야함
이게 RIBBON 과 함께 엮이면 훨씬 더 강력해짐. 서버 목록을 직접 지정하는 것들이, eureka 를 위해서 lookup해보는 것으로 바뀜, eureka 가 없다면 설정 기반으로 loadbalancing을 하게 되고, 이런 부분들에 대해서 훨씬 인프라에 대한 dependency 가 적어지게 됨
eureka 를 주기적으로 lookup하는 모델을 참조하는 방식이 진짜 좋아짐
API GATEWAY
api gateway 는 도입시 장점이 많음
Single Endpoint 를 제공해줌.
- Api를 사용할 클라이언트들은 API Gateway의 주소만 인지
API의 공통 로직 구현 - Logging, authentication, Authorization
Traffic Control - Api Quota, Throttling
약간 Proxy 서버를 하는 느낌으로 받아들이면 될듯?
자체 개발? vs Zuul 사용? 벤치마크를 통해서 Zuul로 이전했음. Hystrix, Ribbon, Eureka 가 정말 잘 녹아들어가 있음.
https://youtu.be/J-VP0WFEQsY?t=1890
정적 분석
