1. MSA 는 뭘까?
MSA란 무엇이고 언제 사용해야하고 왜 사용해야 할까요?
MSA는 Microservices Architecture 의 약자입니다.
이걸 우리 서비스의 관점에서 해석하자면,
하나의 어플리케이션을 여러개의 독립적인 서비스로
분리하여 개발, 배포, 유지보수를 용이하게 하는 아키텍처라고 볼 수 있습니다.
각 서비스는 독립적으로 운영되기 때문에
다른 서비스에 영향을 미치지도 않고,
기능을 팀별로 독립적으로 관리할 수 있으며,
각 서비스마다 기술스택도 자유롭게 설정할 수 있습니다.
2. 모놀리식 아키텍처 vs MSA
보통 MSA와의 비교는 모놀리식 아키텍처와 비교가 많이 되는데,
그 이유는 서로가 극명하게 차이를 보이고 있기 때문입니다.
모놀리식 아키텍처는 모든 기능이 하나의 어플리케이션에 포함되어 있는 점이
기능들이 각각 독립적으로 분리된 MSA와는 차이가 있다고 볼 수 있습니다.
두가지 아키텍처를 비교해보겠습니다.
| 항목 | 모놀리식 아키텍처 | MSA(Microservice Architecture) |
| 정의 | 하나의 큰 코드베이스로 구성된 애플리케이션 | 여러 개의 독립적인 서비스로 구성된 애플리케이션 |
| 구성 방식 | 모든 기능이 하나의 애플리케이션 내에 포함됨 | 각 서비스가 특정 비즈니스 기능을 수행 |
| 장점 | - 간단한 배포: 모든 코드가 하나의 코드베이스에 있어 배포가 단순함 - 단일 데이터베이스: 데이터 일관성을 쉽게 유지할 수 있음 |
- 확장성: 특정 서비스만 확장하여 성능을 최적화 가능 - 독립적 배포: 개별 서비스 변경 시 독립적으로 배포 가능 - 유연성: 서비스별로 적합한 기술 스택 선택 가능 |
| 단점 | - 확장성 부족: 특정 기능 확장을 위해 전체 애플리케이션을 확장해야 함 - 긴 개발 주기: 작은 변경도 전체 애플리케이션을 다시 배포해야 함 - 유연성 부족: 새로운 기술 도입이 어렵고, 특정 모듈에 종속적임 |
- 복잡성 증가: 서비스 간 통신, 데이터 일관성 유지, 트랜잭션 관리 등의 복잡성이 증가함 - 운영비용 증가: 개별 서비스의 모니터링, 로깅 등의 관리 필요 |
결론은,
모놀리틱 아키텍처는 작은 규모의 애플리케이션이나 빠른 개발이 필요한 경우 적합
MSA는 확장성과 독립성이 중요한 대규모 애플리케이션에 적합
3. Spring Cloud 가 필요합니다...!!!
이 시점에서 spring cloud 가 왜 나오냐
제가 현재 진행하고있는 프로젝트가 spring 환경이기 때문입니다 하하
Spring Cloud는 마이크로서비스 개발을 위해
다양한 도구와 서비스를 제공하는 스프링 프레임워크의 확장 서비스입니다.
MSA를 spring환경에서 쉽게 구축하도록 도와주는 서비라고 보시면 됩니다!
spring cloud가 지원하는 주요 기능들은 아래와 같이 정리해볼 수 있습니다!
- 서비스 등록 및 디스커버리: Eureka, Consul, Zookeeper
- 로드 밸런싱: Ribbon, Spring Cloud LoadBalancer
- 서킷 브레이커: Hystrix, Resilience4j
- API 게이트웨이: Zuul, Spring Cloud Gateway
- 구성 관리: Spring Cloud Config
- 분산 추적: Spring Cloud Sleuth, Zipkin
- 메시징: Spring Cloud Stream
4. Eureka 는 무엇인가? 유레카!
넷플릭스가 개발한 서비스 디스커버리 서버로,
마이크로서비스 아키텍처에서 각 서비스의 위치를 동적으로 관리해주는 서비스입니다
모든 서비스 인스턴스의 위치를 저장하는 중앙 저장소 역할을 하며,
서비스 인스턴스의 상태를 주기적으로 확인하여 가용성을 보장해줍니다.
말이 너무 어렵죠? 그림으로 확인해봅시다
서비스를 각각 독립적으로 운영하기 때문에,
서비스 간의 통신이 필요할때, eureka server를 추가하면 됩니다.
eureka server와의 통신이 필요할때, 인스턴스 객체들도
eureka discovery client 설정을 해주어야 하는데,
아래에서 확인하시죠
5. 클라이언트 사이드 로드 밸런싱 (FeignClient, Ribbon)
로드 밸런싱은 네트워크 트래픽을 여러 서버로 분산시켜 서버의 부하를 줄이고,
시스템의 성능과 가용성을 높이는 기술입니다.
서버 간 트래픽을 고르게 분배하여 특정 서버에 부하가 집중되는 것을 방지해 줍니다!
클라이언트 사이드 로드 밸런싱, 서버 사이드 로드 밸런싱이 존재하는데,
클라이언트 사이드 로드 밸런싱에 대해서 이야기 해보려고 합니다
클라이언트 사이드 로드 밸런싱은 클라이언트가 직접 여러 서버 중 하나를 선택하여 요청을 보내는 방식이며,
클라이언트는 서버의 목록을 가지고 있으며, 이를 바탕으로 로드 밸런싱을 수행합니다
1) 여기서 등장하는 것이 FeignClient입니다!
FeignClient는 spring cloud에서 제공하는 HTTP 클라이언트로,
선언적으로 RESTful 서비스 호출이 가능합니다
유레카와 같은 서비스 디스커버리와 연동하여 동적으로
서비스 인스턴스를 조회하고 로드 밸런싱을 수행할 수 있습니다
로드 밸런싱을 직접하는 것이 아니라 Ribbon이 통합되어 있어 자동으로 로드밸런싱이 됩니다
2) Ribbon이란?
넷플릭스가 개발한 클라이언트 사이드 로드 밸런서로,
많은 요청들이 인스턴스들로 몰리는 것에 대비하여 부하를 분산시켜 줍니다.
다양한 로드 밸런싱 알고리즘을 지원하며,
유레카와 같은 서비스 디스커버리와 연동하여 사용합니다
주요 특징
서버 리스트 제공자 - Eureka 등으로부터 서비스 인스턴스 리스트를 제공받아 로드 밸런싱에 사용
로드 밸런싱 알고리즘 - 라운드 로빈, 가중치 기반 등 다양한 로드 밸런싱 알고리즘 지원
Failover - 요청 실패 시 다른 인스턴스로 자동 전환
아래와 같은 로드밸런싱 알고리즘이 있다~ 라고 보시면 됩니닷
라운드 로빈
각 서버에 순차적으로 요청을 분배하는 방식
간단하고 공평하게 트래픽을 분산
가중치 기반 로드 밸런싱
각 서버에 가중치를 부여하고, 가중치에 비례하여 요청을 분배하는 방식
서버의 성능이나 네트워크 상태에 따라 가중치를 조절
기타 알고리즘
최소 연결: 현재 연결된 클라이언트 수가 가장 적은 서버로 요청을 보내는 방식
응답 시간 기반: 서버의 응답 시간을 기준으로 가장 빠른 서버로 요청을 보내는 방식
유레카 서버 하나에 주문 인스턴스 1개와 같은 기능의 포트만 다른 상품 인스턴스 3개를 연결하고,
상품을 요청(http://localhost:19091/order/1) 하면 응답하는 인스턴스의 포트를 받아서 노출하는데
라운드 로빈 방식이라면, 19092 -> 19093 -> 19094 -> 19092 -> 19093 -> ... (예시)
식으로 반복하면서 각 요청마다 따라 서버가 번갈아 가면서 응답합니다.
6. Resilience4j
Resilience4j는 서킷 브레이커 라이브러리로, 서비스 간의 호출 실패를 감지하고 시스템의 안정성을 유지합니다.
다양한 서킷 브레이커 기능을 제공하며, 장애 격리 및 빠른 실패를 통해 복원력을 높입니다.
서킷 브레이커 상태: 클로즈드, 오픈, 하프-오픈 상태를 통해 호출 실패를 관리
Resilience4j 주요 특징
- 클로즈드(Closed):
- 기본 상태로, 모든 요청을 통과시킵니다.
- 이 상태에서 호출이 실패하면 실패 카운터가 증가합니다.
- 실패율이 설정된 임계값(예: 50%)을 초과하면 서킷 브레이커가 오픈 상태로 전환됩니다.
- 예시: 최근 5번의 호출 중 3번이 실패하여 실패율이 60%에 도달하면 오픈 상태로 전환됩니다.
- 오픈(Open):
- 서킷 브레이커가 오픈 상태로 전환되면 모든 요청을 즉시 실패로 처리합니다.
- 이 상태에서 요청이 실패하지 않고 바로 에러 응답을 반환합니다.
- 설정된 대기 시간이 지난 후, 서킷 브레이커는 하프-오픈 상태로 전환됩니다.
- 예시: 서킷 브레이커가 오픈 상태로 전환되고 20초 동안 모든 요청이 차단됩니다.
- 하프-오픈(Half-Open):
- 오픈 상태에서 대기 시간이 지나면 서킷 브레이커는 하프-오픈 상태로 전환됩니다.
- 하프-오픈 상태에서는 제한된 수의 요청을 허용하여 시스템이 정상 상태로 복구되었는지 확인합니다.
- 요청이 성공하면 서킷 브레이커는 클로즈드 상태로 전환됩니다.
- 요청이 다시 실패하면 서킷 브레이커는 다시 오픈 상태로 전환됩니다.
- 예시: 하프-오픈 상태에서 3개의 요청을 허용하고, 모두 성공하면 클로즈드 상태로 전환됩니다. 만약 하나라도 실패하면 다시 오픈 상태로 전환됩니다.
- Fallback: 호출 실패 시 대체 로직을 제공하여 시스템 안정성 확보
- 모니터링: 서킷 브레이커 상태를 모니터링하고 관리할 수 있는 다양한 도구 제공
- Spring Cloud 와의 통합
- Resilience4j는 Spring Cloud Netflix 패키지의 일부로, Eureka와 Ribbon 등 다른 Spring Cloud 구성 요소와 쉽게 통합할 수 있습니다.
- Spring Cloud의 서비스 디스커버리와 로드 밸런싱을 활용하여 더욱 안정적인 마이크로서비스 아키텍처를 구축할 수 있습니다.