24.08.12 TIL - MSA 구성 요소들

오늘 배운 것

• MSA 구성 요소들
• 서비스 디스커버리 = Eureka Server, Client
• HTTP 클라이언트 및 로드밸런서 = FeignClient & Ribbon
• 서킷 브레이커 = Resilience4j
• API gateway = Spring Cloud Gateway
• Config Server = Spring Cloud Config
• 분산 추적 및 로깅 = Zipkin

 

개요

MSA를 학습하며 많은 것들을 배웠다. 

 

그중 정리해 볼 만한 것들을 가져와 봤다. 

 

간단하고 큰 그림을 그릴 수 있도록 작성할 예정이다. 

 

서비스 디스커버리 (Eureka Server, Client)

서비스 디스커버리는 MSA에서 각 서비스의 위치를 동적으로 관리하고 찾아주는 기능이다.

 

이 중 Eureka라는 것이 있고 이것을 사용해봤다. 

 

 

MSA이기 때문에 각 어플리케이션(=서비스)마다 host가 다르다. 

 

monolithic architecture에서는 localhost:8080으로만 요청 보내면 되었다.

 

하지만 MSA에서는 localhost:19091, localhost:19092.. 등등 각 어플리케이션마다 요청 보낼 호스트가 다르다. 

 

이런 host 정보를 Eureka Server에서 조회해서 사용하는 것이다. 

 

이외의 각 서비스의 다른 정보들도 Eureka Server에서 조회해 사용한다. 

 

Eureka Sever를 관제소이라고 생각하면 될 것 같다. 

 

 

그리고 MSA의 구성 요소들 예를 들어 Gateway, Config 서버 등이 Eureka Client이다. 

 

이런 Eureka Client들을 Eureka Server에 등록해서 각 정보를 가져와서 사용하는 것이다.

 

Eureka Client는 비행기라고 생각하면 될 것 같다. 

 

또한 Eureka Server는 헬스 체크 및 장애 처리 기능도 담당한다. 

 

주기적으로 서비스의 상태를 확인해 가용성을 유지한다. 

 

그리고 서비스에서 장애 발생하면 Eureka Server는 인스턴스를 레지스트리에서 제거해 다른 서비스의 접근을 차단한다. 

 

 

HTTP 클라이언트 및 로드밸런서 (FeignClient & Ribbon)

Feignclient

FeignClient는 Http 클라이언트로 백엔드 코드 내에서 API를 호출할 수 있는 것이다. 

 

RestTemplate과 비슷하다고 생각하면 될 것 같다. 

 

MSA에 여러 서비스가 있고 각각 API를 호출해야 하는데 이때 FeignClient 사용하는 것이다. 

 

Eureka와 연동해 서비스를 지정하고 간단하게 그 서비스의 API를 Monolithic architecture에서 하던 것처럼 호출할 수 있다. 

 

FeignClient는 Ribbon과 통합되어 있어 자동으로 로드 밸런싱을 수행할 수 있다. 

 

Ribbon

Ribbon은 클라이언트 사이드 로드밸런서다. 

 

MSA에서 서비스간의 부하를 분산하는데 사용을 한다. 

 

Ribbon은 Eureka Server로부터 서비스 리스트를 제공 받아 로드 밸런싱에 사용한다. 

 

또한 Ribbon은 요청 실패 시 다른 인스턴스로 자동 전환하는 기능도 있다고 한다. 

 

 

FeignClient와 Ribbon은 전화 교환원이라고 생각하면 될 것 같다. 

 

FeignClient와 Ribbon의 사용 예시를 보자. 

1. Order 서비스 1개와 Product 서비스 3개가 있는데 Order 서비스가 Product 서비스에 API를 호출한다.
2. Order 서비스는 Eureka 서버에서 Product 서비스의 목록을 가져온다. 
3. Order 서비스에서 Product 서비스로 FeignClient를 사용하여 Product 서비스의 API를 호출한다. 
4. 이때 FeignClient는 Ribbon을 통해 3개의 Product 서비스 중 하나 선택해 호출한다. 

 

서킷 브레이커 (Resilience4j)

• 마이크로서비스 간의 호출 실패를 감지하고 시스템의 전체적인 안정성을 유지하는 패턴이다. 
• 외부 서비스 호출 실패 시 빠른 실패를 통해 장애를 격리한다.

 

서킷 브레이커는 간단하게 검문소라고 생각하면 된다. 

 

Resilience4j는 서킷 브레이커 라이브러리다.

 

서킷 브레이커 관련해 작성한 글이 있어 그 글을 보면 될 것 같다. 

 

https://dev-gongmyoung.tistory.com/11

24.08.09 TIL - 서킷 브레이커 & Resilience4j

 

API Gateway (Spring Cloud Gateway)

• 클라이언트의 요청을 받아 백엔드 서비스로 라우팅한다. 
• 다양한 부가 기능을 제공하는 중간 서버다.
• 클라이언트와 서비스 간의 단일 진입점 역할을 한다.
• 보안, 로깅, 모니터링, 요청 필터링 등을 처리한다. 
• Spring Cloud Gateway는 Eureka Server를 통해 서비스 조회해 로드 밸런싱, 라우팅 할 수 있다. 

 

위에서 말했듯이 MSA이기 때문에 여러 서비스가 있고 여러 서비스마다 호스트가 다 다르다. (localhost:19091, localhost:19092...)

 

그렇다면 각 서비스에 요청할 때마다 호스트를 신경써야 하는 번거로움이 생긴다. 

 

이런 번거로움을 해결하기 위한 것이 API Gateway이다. 

 

각 서비스들 앞에 API Gateway를 두고 사용자는 API Gateway의 호스트로 요청을 하면 된다. 

 

그러면 API Gateway가 요청을 보고 각 서비스로 요청을 보내준다. (라우팅)

 

그리고 각 서비스로부터 응답을 받아 사용자에게 응답 제공하는 것이다. 

 

또한 API Gateway는 가장 앞에서 요청을 받는 것이기 때문에 할 수 있는 일들이 많다. 

• 요청의 인증 및 권한 검증
• 로드밸런싱
• 라우팅
• 모니터링 및 로깅
• 요청 및 응답 필터링 및 변환

 

API Gateway는 우체국이라고 생각하면 될 것 같다. 

 

우리가 모든 택배 다 우체국으로 보내면 우체국이 알아서 주소지로 보내준다. 

 

그리고 상대방이 보낸 택배도 우리에게 보내주기 때문이다. 

 

Config Server (Spring Cloud Config)

• 분산 시스템 환경에서 중앙 집중식 구성 관리를 제공하는 프레임워크다.
• 모든 애플리케이션의 설정을 중앙에서 관리하는 것이다.
• 설정 변경해도 다른 어플리케이션을 재시작하지 않고도 변경 사항을 실시간으로 반영할 수 있다.
• 환경별로 (개발, 테스트, 배포) 다른 설정 파일을 제공할 수 있다. 

 

Monolithic Architecture에서는 application.properties나 application.yml을 수정하고 적용하려면 프로젝트를 다시 빌드하고 배포해야 한다. 

 

그렇다면 서비스를 내렸다가 다시 올려야 하는데 그때 사람들이 서비스를 사용할 수 없다. 

 

그러면 MSA에서 각 서비스가 설정 파일 가지고 있으면 역시 위와 같은 문제 겪을 수 있다. 

 

그래서 모든 서비스의 설정 파일들을 Config Server에 모아 놓고 각 서비스들에게 설정 파일을 Config Server에서 전달하는 것이다. 

 

그리고 만약에 Config Server에서 설정 파일의 설정이 바뀌면 실시간으로 각 서비스에 설정 변경 사항을 반영할 수도 있다. 

 

정리

MSA를 학습하며 배운 많은 것들을 정리해 봤다. 

 

비유가 적절한지 모르겠다.

 

조금 더 적절한 비유가 있다면 수정해보겠다.