SI Supply Depot

Hystrix가 무엇인가? 에 대한 내용은 지난 시간에 다루었다. 열심히 이 method, 저 method에 @HystirxCommand를 달아 놓고 이게 잘 동작하고 있는지 직접 확인을 하는건 작은 프로젝트에서는 가능할지 몰라도 서비스의 개수가 늘어나면 늘어날수록 어려움에 처하게 된다. 이럴때 유용하게 사용하라고 Hystrix에서는 모니터링을 할 수 있는 Dashboard를 제공을 한다. Hystrix Dashboard는 single instance에 대해 @HystirxCommand가 정의된 method에 대한 모니터링을 수행할수도 있게 해주고 Turbine을 이용해 multi instance에 대해 @HystirxCommand가 정의된 method에 대한 모니터링을 수행할수도 있게도 해준다. 즉 실..

MSA를 하면 당연히 어플리케이션 개수가 많아지고 그에 따라 어플리케이션마다 있는 설정 파일도 많아진다. 이렇게 되면 관리의 어려움이 생기고 이번에도 이런 관리의 어려움을 해결해주기 위해 Spring Cloud 형님들이 힘을 써주셨다. 사방에 나뉘어 있는 설정파일들을 모두 모아서 외부에서 한번에 관리할 수 있게 해주는, 또 변경이 되면 서버의 중단 없이 바로 반영까지 하게 해주는 Spring Cloud Config 라는 것을 통해서 말이다. 지금껏 구성했던 환경에 추가적으로 Config Server를 추가하였다. 모든 설정파일을 가지고 있는 Git에서 변경사항이 발생하면 이 변경된 Configuration properties가 Config Server를 거쳐 각각의 API Server에서 사용할 수 있도..

Eureka를 사용하면서 application.properties (application.yml) 에서 설정값에 대한 공부를 자세히 하고싶은데 자료를 찾는것이 쉽지 않다. 대부분의 포스팅은 매번 사용하는 비슷한 설정만 사용하고 그 외의 자료는 spring 공홈밖에 나타나있지 않다. 다들 영어를 잘해서 spring 공홈으로 들어가서 직접 설정값들을 보고 적용을 하는걸까? 내가 직접 번역은 못하고.. 번역기 돌려서 번역해 놓고 나중에 두고두고 써먹어야겠다.. NameDefaultDesceureka.client.allow-redirectsfalse서버가 클라이언트 요청을 백업 서버 / 클러스터로 리디렉션 할 수 있는지 여부를 나타냅니다. false로 설정하면 서버가 요청을 직접 처리하고 true로 설정하면 H..

지난 시간에 Eureka Server와 Eureka Client를 구성해 봄으로써 Service Registry, Discovery에 대해서 알아보았다. MSA처럼 여러개의 API Service 들을 생성하고 그것을 Eureka에 regist까지 해봤다. 이제 이 Eureka에 등록된 서비스들에 대해서 어떻게 접근하고 사용하는지 그 방법인 Spring Cloud Netflix Zuul을 이용해 API Gateway 구성을 해보려고 한다. API Gateway는 Service Routing 기능과 고가용성을 적용할 수 있으며 가볍게 설계된 디자인 패턴이다. 일단 설명에 앞서 지난번에 구성해봤던 Eureka와 API 서버에 API Gateway를 붙인 구성도이다. 요청이 들어오면 API Gateway가 Eu..

Monolitic 어플리케이션을 여러개의 서비스로 나누다 보니 서비스도 많아지고 그에 따라 인스턴스의 개수도 엄청나게 늘어난다. 또한 오토스케일링 기술을 사용하며 동적으로 ip가 바뀌기도 한다. 그래서 기존과 같은 방법으로 이를 관리하기는 힘들다. 그래서 Cloud를 활용해서 이런 이슈를 해결하려고 나온 기술이 바로 Service Discovery를 해주는 Spring Cloud Netflix Eureka 라는 것이다. Eureka는 기존에 물리적인 서버에 직접 설정을 했던 부분들을 대신해 Service Registry를 해주는 역할을 한다. 이것은 서비스 간에 물리적인 주소로 호출을 하는게 아닌 인스턴스 정보를 중앙 시스템에 등록을 하고 이 중앙 시스템을 통해서 호출을 하는 구조이다. 위 그림이 가장 ..

MSA (Micro Service Architecture) 가 이쪽 업계에서는 아주 뜨겁다. JD를 봐도 MSA 경험자 찾는 회사들이 엄청나게 많아진걸 보면 대세가 되어가고 있는듯 하다. 조금 공부를 해보니 그렇게 될 수밖에 없는듯 하다. MSA는 기존의 하나의 application 형태(Monolithic Architecture)가 아닌 application을 서비스별로 나누어 독립적으로 개발하는 아키텍처를 말한다. 각 서비스들은 API 호출을 하는 형식으로 통신을 한다. 아주 간단한 정의이다. MSA의 목적 (장점)그럼 왜 멀쩡히 잘 돌아가는 서비스를 골치 아프게 나눌까? 여러가지 이유가 있다. 빠르고 간단한 배포시스템의 선택적 확장Polyglot 아키텍처 지원 제목의 간단히 라는 컨셉에 맞게 MSA..

우리가 보통 사용하던 Spring MVC + RDBMS 패턴은 Blocking IO 방식이다. Blocking IO 방식이라는 것은 요청을 처리하기 전까지는 다른 작업을 수행할 수 없는 상태라는 것을 말한다. 동시에 여러 요청을 처리하기 위해서는 Thread 수를 늘려서 하는 방법이 존재하기는 하지만 이도 오버헤드가 발생한다. 이를 개선하기 위해 나온 기술이 Non-Blocking IO 방식인 Spring WebFlux 이다. Spring WebFlux 는 동시에 처리되어야 할 많은 요청에 대해 효율적으로 처리해줄 수 있다. The other is a fully reactive stack that takes advantage of Spring WebFlux and Spring Data’s reactive..