MSA 구성을 지원하는 Spring Boot 기반 Framework
Spring Cloud 는 마이크로서비스의 개발/배포/운영에 필요한 여러 구성요소들을 간편하게 구축할 수 있도록 지원하는 Spring Boot 기반의 프레임워크이다.
아래와 같은 핵심 component 들로 이루어져있다.
동그라미로 표시된 component 만 spring cloud 에 해당한다
Spring Cloud 가 나온 이유
기존 MSA 방식의 서비스에는 다음과 같은 단점이 존재하였다
- 서비스의 파편화로 인해, 특정 서비스가 필요한 경우, 해당 서비스의 위치정보를 알기 힘들다.
- 각 서비스에 대한 여러 인스턴스에 대한 로드벨런싱이 힘들다.
- 한 서비스의 장애가 다른 서비스로 전파될 수 있다. (장애의 연쇄)
- 로그의 통합과 모니터링이 어렵다
- 각 서비스의 구성파일(Config) 관리가 어렵다
이러한 각 단점에 대한 해결책으로, 여러 개념들이 나왔으며, Spring Cloud 에서는 이러한 해결책들을 더욱 쉽게 적용할 수 있도록 도와준다.
Service Discovery (Eureka)
IP 와 port 같은 서비스의 정확한 위치정보를 알려주는 기술이다. 클라우드 환경에서 동적으로 IP 가 변경되는 일이 많아 도입되게 되었다.
통상적으로 Netflix 에서 개발하여 Spring Cloud 와 통합된 Eureka 를 주로 사용한다.
Eureka 서버를 가동한 이후, 각 서비스에서 Eureka 클라이언트를 통해 Eureka 서버에 서비스를 등록하는 방식으로 작동된다.
Client side Load Balancing (Ribbon)
MSA 에서 더욱 쉽게 로드밸런싱을 할 수 있는 방법이다.
기본적으로 로드벨런싱은 server side 로드밸런싱과 client side 로드밸런싱이 존재한다.
server side 로드밸런싱은 switch 같은 로드밸런싱 장비 혹은 소프트웨어를 통해 클라이언트의 요청을 서버로 중계해주는 방식이다. 다만 switch 자체가 처리할 수 있는 요청수 한계로 인해 성능이 저하될 수 있으며, Switch 혹은 로드밸런싱 서버(소프트웨어) 를 따로 구축하는 비용이 든다.
또한, 로드벨런서가 다운되면 모든 클라이언트에서 로드밸런싱을 할 수 없게되는데, 이를 해결하기 위한 개념이 바로 client side 로드밸런싱이다.
client side 로드밸런싱은 기존과는 다르게, 클라이언트에서 switch 를 거치지 않고 바로 서버로 요청을 하게 된다. 즉, switch 에서 하던 분산역할을 각 client(MicroService) 가 처리하게 된다.
client side 로드밸런서는 아래의 세가지 기능을 구현해야한다.
- 클라이언트 내에서 알고리즘을 통해 클러스터로 묶여있는 서버중 하나의 서버에 접속하여, 로드밸런싱할 수 있어야 한다.
- 서버 접속시 발생하는 오류에 대한 대응(handling) 이 가능해야한다. 예를들어, 서버에서 일정시간 넘게 응답이 오지 않을 경우, 다른 서버로 다시시도할 수 있어야한다.
- 클러스터로 묶여있는 서버들은 해당 로드밸런서를 사용하는 사용자에게 하나의 서버로 보여야 한다.
Ribbon 은 위의 세가지 기능을 구현한, Spring Cloud 계열의 client side 로드밸런서이다.
클라이언트에서 configuration 을 통해 클러스터로 묶을 서버 목록을 받아서 로드밸런싱을 하는 방식으로 구현되어있다.
Circuit Breaker (Hystrix, Resilience4j)
장애의 연쇄적인 전파를 막기위한 방법이다.
Micro Service 가 호출되었을 경우, 지정된 Policy 에 따라 적절한 응답을 해주지 못하는 경우, 다양한 방법으로 이를 해결하는것을 Circuit Breaker 패턴이라고 한다.
이러한 Circuit Breaker 는 서비스의 정상동작 여부에 따라 3가지 상태로 나뉜다.
CLOSED: 정상적으로 서비스가 작동하는 상태OPEN: 오류가 발생하여, Circuit Breaker 의 대체로직(handler) 이 작동하는 상태HALF_OPEN: 오류 상태에서 정상 상태로 돌아가기 위해, 서비스의 정상 동작 여부를 판단하기위한 상태
기본적으로 CircuitBreaker 는 CLOSED 상태를 띄다가, 서비스의 오류 응답률이 일정 값 이상으로 높아질 경우, OPEN 상태로 변경된다. 이후 일정시간이 지나면 HALF_OPEN 상태로 전환되어, 기존 서비스에 요청을 보내서 서비스의 정상동작여부를 판별하고, CLOSED 나 OPEN 으로 전환된다.
이러한 Circuit Breaker 의 구현체로는 Netflix 의 Hystrix 와 Spring Cloud 의 Resilience4j 가 존재한다.
현재 Hystrix 는 지원종료 상태이며, Resilience4j 가 권장되는 상태이다
Monitoring (Spring Admin)
넷플릭스의 괴랄한 서비스 매쉬
넷플릭스는 현재 수많은 마이크로서비스들로 이루어져있다.
이때 기존 모니터링 방식을 사용한다면, 각 마이크로 서비스별로 모니터링 데이터와 로그가 생성될 것 이고, 이는 전체 서비스의 유기적 연결을 쉽게 파악하지 못할 뿐더러, 개별 서비스의 동작 또한 제대로 파악하기 힘들다(각 서비스간의 수많은 연결로 이루어진 구조이므로)
따라서, MSA 로 서비스를 분산하더라도 통합 가능한 모니터링/로깅 기술이 필요하게 되었고, 모니터링의 경우 현재 Spring Admin이나 Prometheus + Grafana 조합이 주로 사용되고 있다.
Config Management (Cloud Bus)
MSA 의 서비스가 많아질수록 config 의 중앙관리가 필요하게 되었다. config 가 변경될 경우 각 Micro Service 는 최신 config 를 가져오기 위해 actuator 를 사용하는데, 각 서비스별로 refresh 에 관한 POST 요청을 보내주어야 하기 떄문에 비효율적이다.
Spring Cloud Bus 는 이를 해결하기위해 MQ를 통한 config managing 방식을 채택하였다.
github 에 config 를 작성한 이후, config 의 변경을 Git Web Hook 을 통해서 받은 후, 이를 config server 에서 MQ 에 publish 한다.
이때, 이를 구독한 각 마이크로서비스에서 MQ 에 publish 된 변경사항을 감지하고 자신의 서버에 반영한다.
