[Architecture] MSA, Spring Cloud

MSA (Microservices Architecture)

• 배포 및 독립적인 개발이 용이하다
• 각 서버가 굳이 같은 언어 및 프레임워크로 개발할 필요는 없다
• 각 서비스가 의존성있게 구성되면 유지보수가 어렵고 그렇기 때문에 각 도메인을 팀의 기준에 맞게 적절히 분리해야한다
• 개발의 설계와 리소스가 많이 들고 이런 아키텍쳐를 선택하는 이유가 필요하다 → MSA 를 할만큼 서버에 부담이 된다거나, 배포의 유연성이 필요하다거나 등
• 데이터 일관성, 원자적 처리에 많은 고려 및 설계가 중요하다
• 한 부분의 장애가 전체 시스템에 영향이 미치지 않도록 설계

모놀리식 아키텍쳐 (Monolithic Acthitecture)

• 독립적으로 개발하는 것이 아닌 하나의 프로젝트로 구성되어 개발하는 형태
• 큰 코드베이스 안에 비즈니스 도메인이 여러개 들어가 있음 → 배포의 유연성이 부족함, 하나의 이슈를 수정해서 전체 배포가 필요
• 각 도메인별로 기술 과 프레임워크를 나눌 수 없음
• PoC, Prototype 등과 같은 형태의 개발에서 빠르게 개발하기 용이하다는 점이 있다

Spring Cloud

• MSA 환경을 쉽게 구성하기 편하게 지원하며 운영할 수 있도록 해주는 기능이 존재한다
  • 서비스 운영 : Eureka
  • 로드 밸런싱 : Ribbon
  • 서킷 브레이커: Resilience4j, Hystrix
  • API 게이트웨이 : Spring Cloud Gateway, Zuul
  • 분산 추적, 구성관리, 메시징 등

서비스 등록 및 디스커버리

• Eureka
• 넷플릭스가 개발한 서비스, MSA 에서 서비스의 위치를 동적으로 관리
• 서비스 인스턴스를 저장할 수 있는 중앙 저장소 → 서비스 레지스트리
• 헬스 체크

서킷 브레이커

• Resilience4j, Hystrix
• 호출 실패를 관리 및 차단
• Fallback → 호출 실패 시 대체 로직 제공

API 게이트웨이

• Spring Cloud Gateway, Zuul
• 모든 서비스 요청을 중앙 관리
• 라우팅, 필터, 모니터링

구성 관리

• Spring Cloud Config

• 분산된 환경에서 설정을 중앙 집중형태로 관리

• Config 서버, Config 클라이언트

  • Config 서버 : 설정 파일을 관리 및 각 서비스에게 제공
  • Config 클라이언트 : Config 서버에서 설정 정보를 받아서 사용 → 우리가 만든 Application
  
  

예시로 알아보기 → 주문 요청

• 주문에 대한 요청시 주문은 상품(Product) 와 유저(User) 를 확인해야 한다

• 이때 요청의 흐름은 주문(Order) → 상품(Product) → 유저(User) 형태이다

• 이를 MSA 로 구성한다고 하면 Order App / Product App / User App 각각 따로 구성되어있다

• 먼저 부하를 분산해야한다는 문제 해결책이 생겼다면 로드밸런서를 붙일 것 이다 (아래 형태와 같다)

  

  이렇게 로드밸런서(LB) 를 통해 부하를 분산한다

• 그러나 여기서 문제는 LB 알고리즘은 LB 알아서 자체적으로 구현하지만 현재 살아있는 서버는 어떻게 알아야 할까?

이를 위해 서비스 디스커버리(Eureka) 가 필요하다

각 App 을 Eureka Client 로 등록하여 현재 살아있는 인스턴스가 누구인지 확인한다

이를 기반으로 부하 분산을 한다

• Eureka : 레지스트리, 메타데이터의 개념 / 지금 살아 있는 인스턴스들의 주소/포트/상태 목록을 가진 전화번호부 같은 개념
• 로드밸런서 : 선택자 / 그 목록을 확인하여 어느 인스턴스에 요청을 보낼지 결정하는 역할
• Eureka 자체는 "선택 이력"을 저장하지 않는다. Eureka 는 "누가 살아있나" 만 알려주고 "이번 요청은 누가 선택되었는가" 는 LB (혹은 앱 추적 도구) 를 봐야한다

또한 클라이언트(요청자) 입장에서 불편한 점이 있다
이는 클라이언트가 모든 App 에 대한 호스트 정보를 알아야 한다

이를 해결하기 위해 API Gateway 를 사용한다

• 모든 App 에 대한 호스트 정보를 아는 것이 아닌 하나의 Gateway 호스트 정보만을 알고 라우팅을 통해 연결
• 클라이언트는 gateway-host/{request-domain} 형태로만 요청
• 더불어 인증/인가 관련된 것들도 Gateway 에서 처리하는 것이 올바르다 → 필터

그리고 설정 파일을 중앙 집중형으로 구성하여 모든 서비스가 바로 업데이트 하도록 구성
Config Server 설정