Spring Cloud로 구축하는 MSA
Eureka, Ribbon, Resilience4j
1. 서비스 디스커버리: Eureka
수많은 서비스 인스턴스가 동적으로 생성되고 사라지는 MSA 환경에서, 각 서비스의 위치(IP, Port)를 수동으로 관리하는 것은 불가능합니다. 이때 Eureka는 모든 서비스 인스턴스의 위치를 저장하는 중앙 저장소(Service Registry) 역할을 합니다.
- 서비스 레지스트리: 모든 서비스의 위치 정보를 저장합니다.
- 헬스 체크(Health Check): 서비스 상태를 주기적으로 확인하여 가용성을 보장합니다.
2. 클라이언트 사이드 로드 밸런싱: Ribbon
Ribbon은 클라이언트 사이드 로드 밸런서로, 서비스 인스턴스 간의 부하를 분산합니다.
- Eureka로부터 서비스 리스트를 제공받아 최적의 서버로 요청을 보냅니다.
- 현업 레거시에서는 많이 쓰이지만, 최근 스프링 환경에서는 Spring Cloud Load Balancer로 대체되는 추세입니다.
3. 장애 전파 방지: Hystrix에서 Resilience4j로
특정 서비스에 장애가 발생했을 때 그 장애가 전체 시스템으로 번지는 것을 막기 위해 '회로 차단기' 역할을 하는 서킷 브레이커가 필요합니다.
📍 Hystrix (레거시): 넷플릭스에서 개발한 원조 서킷 브레이커입니다. 현재는 유지보수 모드로 전환되었습니다.
📍 Resilience4j (모던): 가볍고 함수형 프로그래밍에 최적화된 차세대 표준 서킷 브레이커입니다.
4. 시스템의 단일 관문: Zuul vs Spring Cloud Gateway
모든 클라이언트의 요청을 한 곳에서 받아 라우팅하고 필터링하는 역할을 합니다. 오래된 프로젝트는 Zuul을 사용하지만, 성능과 비동기 처리가 중요한 신규 프로젝트는 Spring Cloud Gateway를 사용합니다.
5. 중앙 집중식 설정: Spring Cloud Config
분산된 환경에서 각 서비스의 설정 파일을 중앙에서 관리합니다. 설정 변경 시 서비스를 재시작하지 않고도 실시간으로 반영(Refresh)할 수 있다는 점이 큰 장점입니다.
넷플릭스가 왜 MSA를 선택 하였을까 ?
1. 왜 MSA였을까? (배경과 이유)
넷플릭스는 글로벌 서비스로 성장하며 수천만 명의 동시 접속자를 감당해야 했습니다. 기존의 거대한 모놀리틱 시스템으로는 다음의 문제들을 해결할 수 없었습니다.
- 확장성(Scalability): 글로벌 사용자 증가에 유연하게 대응할 수 있는 인프라가 필요했습니다.
- 신뢰성(Reliability): 한 부분의 장애가 전체 시스템을 마비시키는 것을 방지해야 했습니다.
- 개발 속도: 독립적인 팀들이 서로 방해받지 않고 새로운 기능을 빠르게 배포할 수 있는 환경이 필수적이었습니다.
2. 넷플릭스의 MSA 전환 4단계
- 서비스 분리: 거대한 애플리케이션을 독립적인 작은 단위의 마이크로서비스로 쪼갰습니다.
- 자동화 도구 도입: CI/CD 파이프라인을 구축하여 빌드부터 배포까지의 전 과정을 자동화했습니다.
- 자체 도구 개발: Hystrix(장애 복구), Eureka(서비스 디스커버리), Ribbon(로드 밸런싱) 등 오늘날 Spring Cloud의 모태가 된 기술들을 직접 개발했습니다.
- 클라우드 인프라 활용: AWS와 같은 클라우드 시스템으로 이전하여 인프라 확장성을 극대화했습니다.
3. 결과: MSA가 가져다준 가치
전환 이후 넷플릭스는 수천 개의 마이크로서비스를 운영하는 세계적인 플랫폼으로 거듭났습니다.
- 장애가 발생해도 다른 서비스로 번지지 않는 높은 가용성을 확보할 수 있었다.
- 사용자의 요구에 실시간으로 대응할 수 있는 빠른 배포 주기를 갖게 되었습니다.
1.그림으로 이해해보자
1. API Gateway: 모든 요청의 단일 관문
- 인증 및 인가: 유효한 사용자인지 확인하고 접근 권한을 체크합니다 (Check Login).
- 라우팅: 사용자가 원하는 기능에 따라 Order, Product, User 서비스로 길을 안내합니다.
- 공통 처리: 모든 서비스에 공통으로 적용될 필터(Filter) 로직을 실행합니다.
2. Eureka Server: 서비스들의 전화번호부 (Service Discovery)
- 등록(Registration): 각 마이크로서비스(Order, Product 등)는 실행 시 자신의 IP와 포트 정보를 Eureka에 등록합니다.
- 탐색(Discovery): 서비스 간 호출이 필요할 때 Eureka에게 물어봐서 상대방의 주소를 알아냅니다.
3. Config Server: 설정 정보의 중앙 집중화
- 중앙 관리: 모든 서비스의 설정 파일을 한곳(Git 등)에서 관리하고 각 서비스에 배포합니다.
- 유연성: 서비스 재빌드 없이도 설정값을 변경하고 적용할 수 있는 기반을 제공합니다.
4. FeignClient & Ribbon: 서비스 간의 스마트한 통신
- FeignClient: 복잡한 HTTP 호출 코드를 작성할 필요 없이, 인터페이스 선언만으로 다른 서비스를 호출할 수 있게 해줍니다.
- Ribbon (Load Balancer): Product 서비스가 여러 대(App 2-1, App 2-2) 떠 있을 때, 라운드 로빈(Round Robin) 방식으로 번갈아 가며 요청을 보내 부하를 분산합니다.
- 그림에서 Order 서비스가 Product 서비스를 호출하는 과정이 핵심입니다.
- 여러 서비스의 설정값(.yml)을 일일이 관리하는 것은 비효율적입니다.
- MSA 환경에서는 서비스 인스턴스가 동적으로 생성되고 사라집니다. 이때 필요한 것이 Eureka입니다.
- 시스템의 맨 앞단에서 외부 사용자의 요청을 가장 먼저 받는다
스프링 클라우드를 통해 공부 하길 권함 Referend Doc.을 누르면 자세한 정보들이 있음.
