모놀리식 아키텍처
모놀리식 아키텍처는 전통적인 개발 방식으로 하나의 프로젝트에 모든 기능을 포함한다. 이렇게 하면 코드 베이스가 커질수록 개발 및 배포의 복잡성이 증가한다.
모놀리식 아키텍처는 모듈 단위로 나누지 않고 하나의 프로젝트로 전체 애플리케이션을 묶어서 개발하는 방식이다. 이러한 경우 회원, 상품, 주문뿐만 아니라 여러 개의 비즈니스 로직이 추가 되면 코드 베이스가 커지게 되는 구조이다.
모놀리식 아키텍처의 장점
1) 초기 개발에 유리하며 빠르게 프로토타입을 개발할 수 있다.
2) 필요한 모든 기능을 한 번만 호출하기 때문에 복잡한 통신 없이 직접 사용할 수 있다.
모놀리식 아키텍처의 단점
1) 코드 베이스가 커질수록 복잡해지고 유지관리 및 확장이 어려워진다.
2) 일부 기능을 수정하거나 업데이트를 하려면 전체 애플리케이션을 재배포 해야된다.
모놀리식 아키텍처를 사용하기에 적합한 상황
1) 간단한 소규모 프로젝트 (사이드 프로젝트)
2) 프로토타입 제작 및 단기 프로젝트
MSA 마이크로서비스 아키텍처
MSA는 여러 개의 작은 서비스로 구성되어 각 서비스가 독립적으로 개발되고 배포되는 구조이다.
MSA로 구성되어 있는 애플리케이션의 경우 전체 시스템이 분산되어 있어 개발, 배포가 독립적으로 가능하며 확장성과 유지관리가 용이해진다.
MSA의 경우 애플리케이션을 작은 독립적인 서비스로 분리하고, 각 서비스는 모듈 또는 서비스를 기준으로 나눠서 개발 및 관리를 진행한다. 이렇게 진행할 경우 독립적으로 개발 및 배포가 가능하여 개별적인 배포 주기를 가질 수 있다.
MSA의 장점
1) 서비스 간 독립성으로 인해 확장성과 유연성이 높아진다.
2) 기능 고립성이라는 특징 때문에 일부 서비스가 실패하더라도 전체 시스템에 큰 영향을 미치지 않는다.
- 고립성 - 어떠한 작업을 수행하는 것이 다른 작업에 영향을 주어서는 안된다는 것이다.
3) 독립된 기술 스택과 데이터 스토리지 - 각각의 서비스를 다른 프레임워크를 통해 개발할 수 있고, 이에 따른 데이터 스토리지도 공유하지 않고 각각 운영하여 의존성을 낮추고 낮은 결합도를 가질 수 있다.
4) 서비스의 부하에 따라 개별적으로 확장하거나 축소할 수 있다.
MSA의 단점
1) 서비스 간 통신이 필요하며, 서로 간 연결 구축 및 관리의 복잡성이 증가한다.
2) 초기 개발 및 통신 등에 시간이 많이 소요된다.
MSA를 사용하기에 적합한 상황
1) 대규모 및 복잡한 프로젝트
2) 시스템을 독립적으로 개발하고 확장해야 하는 경우
Eureka Server
Eureka 라이브러리를 사용하면 Service Discovery를 구현할 수 있다.
Service Discovery 패턴은 MSA를 도입하면서 불편한 점을 해결 해주는 패턴이다.
Service Discovery가 필요한 이유
MSA에서는 외부에서 들어오는 요청은 API Gateway를 통해서 전달되고, 서비스 간 통신도 이루어진다.
이때 API Gateway는 어떻게 모든 서비스의 정보를 알아서 요청을 전달하고, 각각의 서비스들은 어떻게 다른 서비스의 정보를 알고 통신을 하는가?
수동으로 각 서비스들의 정보를 등록해주는 방식을 생각할 수 있을 것이다. 그럼 서비스가 확장/축소 될 떄마다 이렇게 수동으로 Gateway에 등록을 한다면 각각의 마이크로 서비스가 확장/축소 될 때마다 해당 마이크로 서비스의 정보(IP, Port)를 수동으로 업데이트 해야 하는 불편함이 있다.
이러한 불편한 점을 해결하는 것이 바로 Service Discovery 패턴이다.
Service Discovery는 서비스의 위치(IP, Port)를 저장 및 관리하는 서비스의 주소록 역할을 한다.
여기에서 Service Registry가 서비스의 위치를 저장 및 관리하는 서비스의 주소록이다.
이렇게 Service Discovery 패턴을 구현함으로써 특정 서비스에 요청을 보내고자 하는 서비스(클라이언트)에서는 Service Discovery를 구현한 구현체에게 서비스의 위치를 질의(쿼리)함으로써 요청을 전달할 수 있다.
Service Discovery 패턴 종류
이러한 Service Discovery 패턴에는 2가지 종류가 있다.
Server-Side Discovery
Server-Side Discovery는 클라이언트가 다른 서비스를 호출할 때 Service Registry에 직접 요청을 보내지 않고, 앞단의 Gateway로 요청을 전달한다. Gateway는 Service Registry를 조회해 적절한 서비스 인스턴스를 선택하고, 로드밸런싱을 통해 요청을 분배한다.
장점
1) 각 서비스들이 다른 서비스를 호출할 때 Gateway에만 요청을 보내기 때문에 Service Registry의 구체적인 구현은 몰라도 된다. Gateway가 Service Registry와의 통신을 처리한다. 즉, 캡슐화 되어있다.
2) Gateway를 통해 라우팅이 자동으로 이루어지기 때문에, 각 서비스에서 직접 다른 서비스를 검색하거나 연결 로직을 구현할 필요가 없다.
단점
1) 배포 환경에서 Gateway를 사용해야 하며, Gateway에 내장된 로드 밸런서 또는 별도의 로드 밸런서를 반드시 구성해야 한다.
2) 요청이 Gateway를 통해 전달되기 때문에 네트워크 홉이 추가로 발생하여 처리 지연이 상대적으로 증가할 수 있다.
Client-Side Discovery
Client-Side Discovery는 Gateway로 요청을 보내지 않고 각 서비스들이 직접 Service Registry에게 질의하여 요청을 보내려는 서비스의 정보를 받아와서 직접 요청을 보낸다.
Spring Cloud Netflix Eureka - Service Registry의 서버 역할, 서비스들의 정보를 등록하는 역할
장점
1) 각 서비스들이 호출하려는 서비스를 알기 때문에 서비스의 특성에 맞게 로드밸런싱 방식을 구현할 수 있다.
단점
1) 각 서비스별로 다른 서비스를 검색하는 로직을 언어 및 프레임워크 별로 구현해야된다.
2) 따라서 각 서비스가 Service Registry에 의존적이다.
Gateway
Gateway 패턴은 MSA 관리/운영을 위한 플랫폼 패턴이며 해당 패턴에 필요한 기능들을 제공하는 서버를 말한다.
API Gateway는 개별 서비스의 앞 단에서 모든 서비스들의 엔드포인트를 단일화하고 다음과 같은 필수 기능 요소를 제공한다.
1) 인증과 인가 - 모든 서비스들에 대한 접근에 있어서 단일 집임점에서 인증과 인가 처리를 진행
2) API 요청 로드밸런싱 및 라우팅 - API 요청을 식별하여 적절한 마이크로서비스로 전달
3) QoS - 안정적인 서비스 제공 및 네트워크 품질을 관리하며 사용자, 클라이언트, API 단위로 접속 제어
4) 로깅 및 모니터링 - API 요청에 대한 로깅/모니터링 기능 지원
5) 입력 유효성 검사 - API 요청의 적절한 형식과 필수 데이터 포함 여부를 식별 및 관리
Gateway의 장점
1) 애플리케이션의 내부 구조를 캡슐화 - 클라이언트는 특정 마이크로 서비스를 호출하지 않고 단순히 게이트웨이와 통신하며, API 게이트웨이는 각 종류의 클라이언트에 특정 API를 제공
2) 클라이언트와 애플리케이션 간의 왕복 횟수가 감소하며, 클라이언트 코드 단순화
Gateway 단점
1) 개발, 배포 및 관리해야 하는 지점이 증가
2) 각 마이크로 서비스의 EndPoint를 노출하기 위해 API게이트웨이를 업데이트해야 하는데 이로 인해 개발 병목 현상이 발생할 수 있음
- 병목 현상 - 프로젝트의 실현을 지연시키는 기술적 문제로 인해 발생하는 모든 상황
Spring Cloud Gateway
Spring Cloud gateway는 Spring Framework에서 제공하는 오픈 소스 기반의 Gateway 서비스이다.
Spring Cloud gateway는 클라이언트의 단일 진입점 역할을 하는 서버이다.
Spring Cloud Zuul이 있었으나 패치가 중단됨에 따라 Spring Cloud Gateway로의 이전이 이루어졌다.
가장 큰 차이점은
Zuul은 Tomcat이였지만, Spring Cloud Gateway는 Netty로 비동기 방식이며, Spring WebFlux 기반이다.
WebFlux란?
반응형 및 비동기적인 웹 애플리케이션 개발을 지원하는 모듈이다. 이 모듈은 Reactive Streams 사양을 기반으로 하여, 비동기적인 이벤트 지향 프로그래밍을 통해 높은 확장성과 성능을 제공한다.
Spring과 완벽한 통합을 이루고 netty를 지원하며, 비동기 논 블로킹 메시지 처리를 도와준다.
Spring Cloud Gateway는 비동기 방식을 통해 수많은 요청을 빠르게 처리할 수 있으며 다른 Spring Cloud 기반 기술과 통합이 잘 되어 있어 다양한 기술적 연계가 가능하다.
아키텍처와 특징
Spring Cloud Gateway를 구성하는 주요 3요소는 Route, Predicate, Filters가 있다.
Route
Route는 고유 ID + 목적지 URI + Predicate + Filter로 구성되며, Predicate + Filter의 묶음이자 라우팅이 될 규칙이라고 할 수 있다.
Route를 통해 Spring Cloud Gateway로 요청된 URI의 조건이 Predicate를 통과하여 참인 경우 매핑된 해당 경로로 매칭된다.
Predicate
Predicate는 요청이 주어진 조건을 충족하는지 테스트하는 구성요소이며, 하나 이상의 조건자를 정할 수 있습니다.
만약 Predicate에 매칭되지 않을 경우 Spring Cloud Gateway에서 자체적으로 404 NotFound로 응답한다.
여기에서 말하는 매칭은 Spring Cloud Gateway의 라우팅 규칙. 즉, 이 요청을 처리할 서비스가 없다.
시간, URI 패턴, 요청, 네트워크 관련으로 분류할 수 있다.
Filter, Filter Chain
Filter, Filter Chain은 Spring Cloud Gateway를 통해 들어오는 요청이나 반환되는 응답에 대해 전처리/후처리를 담당한다.
Proxy Filter는 프록시 요청이 처리될 때 수행되는 필터이다.
Load Balancer
로드밸런서는 각 마이크로 서비스가 N개의 인스턴스로 돌아가고 있다면, 서버의 부하를 줄여주기 위해 사용자 접근을 여러 서버로 고르게 분산시켜주는 역할을 한다.
Eureka Server와 Gateway
클라이언트에서 특정 MicroService로 요청시에 API Gateway Server와 Eureka Server 그리고 MicroService의 동작 순서는 다음과 같다.
1) Client에서 Service A로 요청을 보낸다.
2) Gateway에서 Eureka Server에 등록된 Service A에 대한 정보(IP, Port)를 요청한다.
3) Eureka Server는 Service A의 위치를 검색 후 Gateway에게 전달해준다.
4) Gateway는 Eureka Server에게 응답 받은 Service A의 정보를 통해 Service A로 포워딩 후 응답한다.
