MSA(Microservice Architecture) 요약 - 1

1. MSA ( Microservice Architecture ) : 하나의 애플리케이션을 여러 개의 독립적인 서비스로 분리하여 개발, 배포, 유지보수를 용이하게 하는 소프트웨어 아키텍처 스타일

- 확장성, 독립적인 배포, 유연성, 작은 팀 구성

ex) 기능 추가 시 추가된 애플리케이션만 배포하면 되기 때문에 기존 애플리케이션에 영향을 주지않음

- 복잡성 및 운영비용이 증가함, 데이터 관리 및 네트워크 지연

ex) 기능 추가 시 특정 기능 관련 팀과 해야하는 일이 늘어남 하나의 서비스가 다른 서비스를 호출하기 때문에 복잡성이 증가함 각 서비스가 정보를 별도 DB에 보관할 경우 정보의 변경이 생기면 데이터 불일치 문제 발생 가능

 

2. 모놀리틱 아키텍처 : 하나의 큰 코드베이스로 구성된 애플리케이션, 모든 기능이 하나의 애플리케이션 내에 포함

- 배포가 간단하고 하나의 데이터베이스를 사용

- 확장성과 유연성이 부족하며 개발주기가 김 

ex) 기능 한가지 수정 시 다른 기능에 영향을 줄 수도 있으며 기능 추가 후 배포 시 알지 못하는 이슈로 큰 문제가 생길 수 있음

 

-> 신규 서비스를 작성할 때에는 초반에는 모놀리틱으로 개발하다가 서비스 사이즈가 커지면 MSA로 전환

: 신규 프로젝트 초기부터 MSA로 설계 및 개발하게되면 리소스와 설계 시간이 많이 필요함

 

3. Spring Cloud : 마이크로서비스 개발을 위해 다양한 도구와 서비스를 제공하는 스프링 프레임워크의 확장

- 현업에서는 Hystrix, Zuul로 개발된 상태가 많음 

 

3.1 Spring Cloud 주요 모듈

- 서비스 등록 및 디스커버리 : Eureka ( 호스트 app을 알기 위해 생성, 모든 서비스(app)이 Eureka 클라이언트 )

- 로드 밸런싱 : Ribbon ( 한 app에서 다른 app을 호출할 때 어떤 app을 호출하는지 컨트롤을 관리)

- 서킷 브레이커 : Hystrix, Resilience4j ( 에러 상황을 뒷 서비스로 요청하지 않고 리턴)

 

3.2 Spring Cloud 구성 요소의 활용

- API 게이트 웨이 : Zuul, Cloud gateway ( 모두 다른 호스트로 호출하는 것을 번거롭기 때문에 API 게이트웨이를 통해 요청 처리, 필터 기능을 통해 불필요한 요청 처리)

- 구성 관리 : Spring Cloud Config ( 각 모든 서비스의 yml 파일 관리 )

 

3.3 Spring Cloud의 적용 사례 : Netflix

- 초반은 DVD 비디오 대여점으로 시작 ( 우편으로 하는 대여 서비스 )

- 2000년대 후반 OTT 서비스를 시작하면서 사용자가 급격히 증가 함에 따라 기존 모놀리틱 아키텍처로는 빠르게 증가하는 트래픽과 사용자 요구 증가

- 폭발적인 사용자 증가, 빈번한 서비스 장애, 인프라 확장의 어려움, 빠른 기능 배포의 필요성, 클라우드 전환 등의 계기로 인해 MSA 전환

- 서비스를 분리하며 CI/CD를 통해 코드가 배포하는 과정을 자동화하며, 자체 도구( Hystrix, Eureka, Ribbon )를 개발하며 AWS 클라우드 서비스를 사용하여 인프라 사용

 

4. 서비스 디스커버리 : 마이크로서비스 아키텍처에서 각 서비스의 위치를 동적으로 관리하고 찾아주는 기능

 

4.1 Eureka : 마이크로서비스 아키텍처에서 각 서비스의 위치를 동적으로 관리하며 모든 서비스 인스턴스의 위치를 저장하는 중앙 저장소 역할을 하며, 서비스 인스턴스의 상태를 주기적으로 확인

4.1.1 Eureka 서버 설정 

4.1.2 Eureka 클라이언트 설정

- 각 서비스 앱은 Eureka 서버에 등록, spring-cloud-starter-netflix-eureka-client 의존성을 사용

- spring : apllication : name 에 이름 지정해야함

4.2 서비스 등록 및 디스커버리

4.2.1 서비스 등록 : 각 서비스 앱은 Eureka 서버에 등록, spring-cloud-starter-netflix-eureka-client 의존성을 사용

4.2.2 서비스 디스커버리 : 클라이언트 애플리케이션은 Eureka 서버에서 필요한 서비스의 위치를 조회

- FeignClient 사용 

4.2.3 헬스 체크 및 장애 처리 

- 헬스 체크 : Eureka 서버가 주기적으로 서비스 인스턴스의 상태를 확인하여 가용성을 유지

- 장애 처리 : 서비스 장애 시 Eureka 서버는 해당 인스턴스를 레지스트리에서 제거하여 다른 서비스의 접근을 차단

 

4.3 Eureka 고가용성 구성