MSA

MSA

2024. 11. 27. 23:58ㆍ카테고리 없음

MSA : 마이크로서비스아키텍쳐 ( 작고 독립적인 서비스들의 집합으로 구성된 애플리케이션 구조 )

모놀리식 아키텍처

모놀리식 아키텍처는 전통적 개발방식으로써, 하나의 프로젝트에 모든 기능을 함께 포함합니다. -> 코드 베이스가 커질수록 개발 및 배포에 복잡성이 증가하게 됩니다.

모놀리식 아키텍쳐는 위와같이 모듈단위로 쪼개는 것이 아닌 하나의 프로젝트로 전체 애플리케이션을 묶어서 개발하는 방식입니다.

이렇게 개발하게 된다면 회원, 상품, 주문뿐만 아니라 여러개의 비즈니스 로직이 추가된다면 코드 베이스가 커지게됩니다.

모놀리식 아키텍쳐의 장단점 정리

장점 : 초기 개발에 유리하며 빠르게 프로토타입을 개발할 수 있으며, 필요한 모든 기능을 한 번만 호출하기에 복잡한 통신 없이 직접 사용할 수 있습니다.

단점 : 코드 베이스가 커질수록 복잡해지고, 유지관리 및 확장이 어려워집니다. 또한 일부 기능을 수정 혹은 업데이트하려면 전체 애플리케이션을 재배포해야합니다.

따라서 모놀리식 아키텍쳐는 간단한 소규모 프로젝트(사이드 프로젝트)나 프로토타입 제작 및 단기 프로젝트를 할때 유용합니다.

MSA

마이크로 서비스 아키텍쳐(MSA)는 여러개의 작은 서비스로 구성되어 서비스가 독립적으로 개발되고 배포되는 구조입니다.

MSA로 구성되어있는 애플리케이션의 경우 전체 시스템이 분산되어있어서 개발 배포가 독립적으로 가능하며 확장성과 유지관리가 용이해집니다.

그림과 같이 MSA는 애플리케이션을 작은 독립적인 서비스로 분리하고, 각 서비스는 모듈 또는 프로젝트로 나눠서 개발 및 관리를 진행합니다. 이렇게 개발을 진행할 경우 독립적으로 개발 및 배포가 가능하여 개별적인 배포 주기를 가질 수 있습니다.

MSA의 장단점

장점: 서비스간 독립성으로 인해 확장성과 유연성이 높아지며, 기능 고립성이라는 특징때문에 일부 서비스가 실패하더라도 전체 시스템에 큰 영향을 미치지 않는다.

단점: 서비스간 통신이 필요하며, 서로 간 연결 구축 및 관리의 복잡성이 증가한다.

따라서 이런 MSA는 대규모 및 복잡한 프로젝트나 시스템을 독립적으로 개발하고 확장해야하는 경우에 적합합니다.

MSA 구현 프레임워크

spring cloud는 spring boot 기반으로 제작되었으며, 클라우드 환경을 보다 편리하게 구축하기 위해 설계된 라이브러리 입니다.

이런 spring cloud에서는 MSA구축에 널리 쓰인 Netflix OSS 프레임워크의 핵심적인 라이브러리를 포함하고 있습니다.

netfilx oss의 핵심 라이브러리인 Eureka, Ribbon, Hystrix, Zuul과 Config를 통해 진행하겠습니다.

MSA는 최소한의 작게 쪼개진 서비스들이 서로 통신하며 연계되는데, 밑에 쇼핑몰 그림을 보게되면

MSA 환경에서는 이와같이 다양한 서비스들이 존재하며 각 서비스들은 고유한 IP와 PORT, 그리고 기본정보를 가지고 있습니다. 또한 서로 통신을 하기 위해서는 위 IP와 PORT와 같은 정보들을 서로 알고 있어야 합니다.

( 각 서비스들은 고유한 IP와 PORT를 가지고 있으며, 서로 통신하기 위해선 서로 이 정보를 알아야함 )

이러한 MSA 클라우드 환경에서는 지속적으로 서비스들이 늘어나거나 변경될 수 있으며, 서비스의 부하에 따라 인스턴스가 늘어날수도 있고 줄어들 수도 있습니다.

근데 만약 그렇다면 서비스가 수십~ 수백개가되고, 이 정보들을 매번 직접 공유해야한다면... 매우 힘들겠죠?

이 걱정은 Spring cloud를 통해 해소할 수 있습니다.

위 그림과 같이 상품에 대한 부하가 증가하여 상품 인스턴스가 추가될 수 있으며, 수시로 신규 서비스가 개발되어 추가 되어질수도 있습니다.

특히 MSA 클라우드 환경에서는 지속적으로 서비스들이 늘어나거나 정보가 변경될 수 있으며, 서비스의 부하에 따라 인스턴스가 늘어날 수도 다시 줄어들수도 (Auto scaling)있습니다.

이때 누군가 자동으로 정보를 등록하고 갱신 및 관리해줄수있는것이 서비스 디스커버리 패턴입니다.

서비스 디스커버리

앞서 말했듯이 서비스의 인스턴스가 생성 혹은 소멸되거나 신규 서비스들이 지속적으로 증가하는 등 서비스의 정보가 지속적으로 바뀔 수 있습니다. 디스커버리 서버는 이런 가변적인 모든 서비스의 정보들은 각 서비스의 고유ID에 매핑하여 관리하게 됩니다.

그리고 각 서비스들은 지속적으로 자신의 정보를 디스커버리 서버에 등록하며, 다른 서비스들의 정보를 조회합니다. 그럼 각 서비스들은 다른 서비스의 IP와 PORT번호를 몰라도 서비스의 고유 ID만 가지고 연계가 가능해집니다.

이런 서비스 디스커버리의 구현을 쉽게 도와주는 것이 Spring cloud의 Eureka입니다.

Eureka는 아래 2가지로 구성됩니다.

1. Eureka server ( 서버 라이브러리 ): 서비스들의 정보를 관리, 제공

2. Eureka Client ( 클라이언트 라이브러리 ): 서버에 자신의 정보를 제공, 다른 서비스들의 정보를 조회

-> Eureka server는 디스커버리 서버에 탑재되며, Eureka Client는 각 서비스들에 탑재됩니다.

이 그림과 같이 각 서비스들이 가동될때 혹은 가동중에도 지속적으로 자신의 정보를 디스커버리 서버에 등록(갱신) 하며, 서버는 이 정보들을 캐싱하여 관리합니다.

이와 동시에 각 서비스들은 디스커버리 서버로부터 다른 서비스들의 정보를 지속적으로 조회합니다. 이 정보들도 기본적으로 서비스들이 캐싱하여 관리합니다.

그리고 각 서비스들은 서로의 고유 ID만 가지고 연계가 가능합니다.

ex) 상품 서비스가 주문 서비스로 rest api요청을 할때 IP와 PORT대신 고유 ID로 통신이 가능해집니다.

클라이언트 측 부하 분산 (소프트웨어 로드벨런싱)

일반적으로는 서비스간 HTTP통신을 할때 RestTemplate, WebCilent를 많이 사용합니다.

예시로

1. 클라이언트 요청 : 사용자가 주문을 요청합니다. 클라이언트는 주문서비스의 rest api를 호출합니다.

2. 서비스간 통신 : 주문 서비스는 사용자의 정보를 확인하기 위해 유저 서비스와 HTTP로 통신합니다. ( 이과정에서 RestTemplate 또는 WebClient를 사용하여 요청을 보냅니다. )

3. 응답처리 : 유저 서비스는 사용자 정보를 반환하고, 주문 서비스는 이 정보를 처리하여 주문을 완료합니다.

그런데 이렇게 만약 상품 서비스에서 주문 서비스로 HTTP 통신을 한다고 하는 경우를 예를 들어보면,

대다수의 서비스들은 단일-인스턴스로 구성되지않고 고가용성을 위해 여러개의 인스턴스로 이중화되어 구성되어집니다.

만약 주문 서비스가 2개 이상의 인스턴스로 구성되어있다면, 상품 서비스는 어떤 인스턴스로 요청할지 어떻게 결정해야할까요?

Spring cloud(netflix oss)가 나오기 전에는 보통 물리적인 L4를 주문 서비스 앞단에 두어 로드밸런싱 하는 방법을 사용하였습니다.

하지만 클라우드 환경에서 물리적인 L4를 둔다는 것은 비용적 측면이나 관리적인 측면 또한 유연성 측면에도 적합하지 않을 수 있습니다.

직접 문제 상황을 제시하여 설명해보자면,

주문 서비스는 고가용성을 위해 여러개의 인스턴스(서버)가 배포되어 있는 상태입니다. ( OrderService-1, OrderService-2 )

클라우드 환경에서는 2개 이상의 서버가 같은 역할을 수행하도록 배포하는 것이 일반적입니다 ( 수평확장이라고 합니다. )

이때 상품 서비스가 주문 서비스를 호출하려면 이 인스턴스들중 하나를 선택해야합니다.

그렇다면 여기서 질문은 어떤 인스턴스로 요청을 보낼지? 입니다.

일반적인 해결방법은 물리적인 L4 로드밸런서를 사용하여 해결하는 방법입니다.

L4 로드밸런서는 네트워크 계층(전송계층)에서 동작하며, TCP/UDP 연결 수준에서 트래픽을 분산합니다. 상품 서비스는 단일 IP주소로 요청을 보내면, L4 로드밸런서가 트래픽을 주문 서비스의 여러 인스턴스에 분산시킵니다.

하지만 Spring cloud 등장 후, 물리적인 L4 로드밸런서를 사용하기보다, 소프트웨어 기반의 클라이언트 측 로드밸런싱을 사용하는 것이 더 유연하다는 것입니다. ( 상품 서비스가 직접 주문 서비스의 여러 인스턴스를 관리하고, 요청을 적절하게 분산하는 역할을 담당 )

> 이를 위한 도구가 spring cloud netflix oss에서 제공하는 ribbon입니다.

spring cloud 환경에선 더이상 물리적인 L4를 사용하지 않아도 됩니다.

> ribbon이라는 라이브러리가 해결책이 됩니다.

앞서서 각 서비스들은 Eureka를 이용하여 다른 서비스들의 정보를 캐싱하여 보관한다고 하였습니다. 여기엔 모든 인스턴스의 IP와 PORT를 포함하고 있습니다.

Ribbon 또한 Eureka client와 마찬가지로 각 서비스들에 탑재되어 집니다.

만약 상품 서비스가 주문 서비스로 고유 ID인 order로 요청을 하면 Ribbon이 Eureka로부터 얻은 정보를 이용하여서 정의된 알고리즘에 따라 자동으로 부하 분산을 시켜줍니다. ( 상품 서비스는 주문 서비스의 인스턴스를 알필요가 없게됩니다. 오직 주문 서비스의 고유 ID만 알면 되게됩니다. )

이를 클라이언트측 부하분산 or 소프트웨어적 로드밸런싱이라고 부릅니다.

작게 분리된 서비스들을 서비스 디스커버리(Eureka)를 이용하여 서로의 정보를 관리하고 클라이언트 부하분산으로 통신한다고 하였습니다.

근데 여기서 내부에서는 디스커버리 서버를 통해 서로의 정보를 공유하고 통신하는데 문제가 없지만, 외부 클라이언트에서는 각 서비스들의 정보를 알아야합니다. 디스커버리 서버에 접근할 수 없는데 모든 서비스의 IP와 PORT를 알고 있어야 할까요?

이 해답은 바로 API GATEWAY입니다.

이 API GATEWAY를 쉽게 구현할수 있게 도와주는 도구는 spring cloud의 Zuul1, Zuul2, spring cloud gateway등이 있습니다.

( 여기서의 외부 클라이언트는 네트워크 외부망에서 접속하는 모든 시스템이나 이용자이거나, legacy 시스템 혹은 또다른 네트워크 망의 사내 시스템일수도 있습니다. )

그림과 같이 외부에서는 내부의 서비스들을 몰라도 됩니다. 다만 공개된 url을 이용해서 api gateway 서버로 요청하면 api gateway가 알아서 해당 서비스로 호출하고 응답을 받아서 외부 클라이언트에게 답을 해줍니다.

예를들어 상품 서비스에 /display라는 상품의 정보를 반환해주는 api가 있다고 가정하면 외부 클라이언트는 내부 서비스의 유무를 몰라도 대표도메인과 공개된 url호출로 통신이 가능해집니다 ( https://대표도메인.co.kr + /api/product/display )

또한 api gateway는 많은 역할을 하는데 그중 하나가 내/외부망의 분리로 서비스를 안전하게 보호해줍니다.

이 그림과 같이 망을 분리하고 내부망으로의 통신은 api gateway로 제한하게된다면 외부의 공격으로부터 중요한 서비스들을 안전하게 보호할 수 있습니다.

외부 클라이언트가 유효한 사용자인지 인증을 하거나 해당 사용자가 원하는 자원에 접근할 권한이 있는지 인가하는 등의 작업을 각 서비스가 신경 쓸 필요없이 모두 api gateway가 처리하면 됩니다.

( 주의할점은 api gateway가 모든 서비스의 요청을 받아주는 단일지점이기에 부하에 신경을 많이써야합니다. 그래서 리소스를 많이 쓰는 작업 (DB연동, file IO 작업등)은 피하고 가볍게 유지하는 것이 좋습니다. )

MSA 환경에서는 작은 서비스들이 분리된 자기 자신의 DB를 제어하며 서로 상호 소통하기때문에 모놀리식보다 다양한 통신 오류 및 지연문제가 발생할 수 있습니다.

만약 하나의 서비스에 특정 기능에 문제가 생긴다면, 해당 문제점이 시스템 전체의 장애로 확산되지않도록(thread Isolation) 장애를 자동으로 차단하고(Circuit Breaker), 문제가 된 기능을 대체할 수 있는 기능을 응답(Fallback)할 수 있습니다.

이러한 장애를 적극적으로 대응하는 여러 방안이 있으며, 이러한 구현을 쉽게 도와주는 Hystrix와 Spring Cloud의 Resilient라이브러리가 있습니다.

대표적인 장애 대응 및 복구방안 ( Hystrix )

1. circuit breaker

Hystrix가 관리하는 기능들은 요청처리에 대한 통계가 내부적으로 집계됩니다. 통계를 분석하여 특정 기능이 일정 시간동안 일정 횟수의 요청에 대해 일정 비율로 에러(Exception)가 발생할 경우 Circuit Open합니다.

Circuit Open되면 일정 시간동안 이후 요청(기능)을 차단함으로써 지속적으로 발생하는 에러로 인한 자원고갈 및 반복 장애를 차단하고 복구를 위한 시간을 벌 수 있습니다. 이것은 서비스간의 연계에서 연쇄적인 서비스 장애를 방지할 수 있습니다.

이후 한건의 요청을 허용하며 해당 요청이 성공하면 Circuit Close하며, 실패할 경우 다시 일정 시간 Circuit Open을 유지합니다.

2. Fallback(풀백 패턴)

특정 기능이 실패할 경우 해당 기능을 대체하는 다른 기능을 반환 할 수 있습니다.

예를들자면 쇼핑몰에서 특정 고객에게 맞춤형 상품을 제공하는 기능이 있다고하면, 이 기능이 문제가 발생했을때 에러 화면을 그대로 고객에게 노출하는게 아니라 미리 준비해둔 상품의 정보를 제공할 수 있습니다.

3. Thread Isolation (벌크 헤드 패턴)

각 기능이 사용할 수 있는 자원을 제한함으로써 1개 기능 장애가 전체 시스템에 영향을 미치는것을 차단합니다.

예를들어 상품 서비스의 전체 가용자원이 100이라고하면 상품 서비스의 A,B,C,D,E 기능들이 같은 자원을 공유하며 서비스가 운영됩니다. 근데 갑자기 A기능에 부하가 심해지거나 심각한 지연이 발생하여 자원의 대다수를 점유해버립니다. 그러면 B,C,D,E는 얼마 남지않은 자원으로 운영되다보면 연쇄적인 장애로 이어지게 됩니다.

이럴때 Thread Isolation을 하여 각각의 서비스에 자원을 20씩만 할당해 격리한다면 A서비스가 20개의 자원을 모두 고갈하더라도 B,C,D,E는 영향을 받지 않게 됩니다.

4. Timeout 처리

특정시간동안 해당 기능이 완료되지않으면 예외를 발생합니다. 너무 긴 타임아웃을 가지는것 또한 장애를 유발할 수 있는 요소입니다. 모든 스레드의 요청이 응답을 대기하게되면 더이상 추가 요청을 받지 못하고 해당 요청은 대기 큐에 쌓이며 밀리게 됩니다. 이에 기능별로 적절한 수치의 Timeout의 지정이 필요할 수 있습니다.

Config Server

서비스마다 기본적인 설정 혹은 서비스가 사용하는 정보인 환경설정을 properties(yml)파일에 key:value값으로 관리하고 있습니다. 근데 만약 서비스의 수가 많아지고 각각의 서비스가 자체적으로 환경설정을 가지고있다면 관리가 매우 어려워집니다. 또한 빠르게 변화하는 클라우드 환경에서 매번 yml파일을 변경하고 배포하는것은 쉽지않습니다.

( 컨테이너에 떠있는 프로퍼티를 직접 수정하는것은 x 추후 변경사항이 관리가 되지 않기 때문입니다. )

구현

우선 구현할 msa의 전체적인 구조를 살펴보면

서비스는 service1과 service2 총 2개로 구성되어있고 service discovery, api gateway, config server로 구성되어있습니다.

각 역할들을 살펴보면 api gateway는 단일 지점으로서의 역할을 하게됩니다.

클라이언트에서 GET /api/service1/ribbon{id} 로 api 요청을 하게되면, service1 서비스를 찾아서 GET /ribbon/{id} api를 다시 요청하게 됩니다.

우선 service1의 주요 기능은 고객의 id를 받아서 service2에게 rest api로 통신 요청하여 이름을 받아오는 것입니다.

api gateway로 전달받은 id를 서비스2의 GET /name/{id} api 로 요청을 하고 이름을 받아옵니다.

서비스1은 최종id와 이름을 조합하여 id is name이라는 문장을 만들어 반환하게 해줄것입니다.

service2는 고객의 id를 받으면 해당 id의 이름을 반환합니다.

서비스 디스커버리 구현

service1,2는 기동시 서비스 디스커버리 서버에 서비스 자신을 등록하고 정보를 전달합니다.

(서비스 디스커버리 서버 == eureka server is True)

이후 service1,2는 주기적(기본 30초)으로 서비스 디스커버리 서버로부터 다른 서비스의 정보를 가져갑니다.(fetch)

우선 스프링 프로젝트를 생성해줍니다.

다음으로는 spring cloud netflix eureka server를 설정해줍니다.

다음으로는 EurekaServer를 활성화 시켜주기 위해 ServiceDiscoveryApplication.java에 어노테이션을 적용해줍니다.

마지막으로는 환경 설정을 진행해주었습니다.(저는 yml 파일로 진행하였습니다.)

그 후 기동을 시켜보면 /경로에 유레카 서버 대시보드가 나오게 됩니다.

서비스 1을 구현하기전 eureka 설정의 3가지를 살펴보고 가겠습니다.

eureka 설정 3가지

eureka.server.* ( 디스커버리 서버 자체에 대한 설정 )

eureka.server.*의 접두어로 시작하는 설정입니다. 서버로써 어떻게 구성될지의 설정을 합니다 ( Eureka 서버의 프로퍼티 설정에 들어가는 내용 )

eureka.instance.* ( 클라이언트 자체에 대한 설정 )

eureka.instance.*의 접두어로 시작하는 설정입니다. 클라이언트로써 어떻게 구성될지에 대한 설정입니다.

eureka.client.* ( 클라이언트 행위 설정 )

eureka.client.*의 접두어로 시작하는 설정입니다. 클라이언트가 연계할 유레카 서버설정 (defaultZone, register-with-eureka), 다른 서비스들의 정보를 가져오는 (fetch-registry)등 행위에 대한 설정을 합니다.

service1 구현

다음으로는 서비스1을 구현해보도록 하겠습니다.

서버와는 다르게 client 라이브러리를 설정해줍니다.

추가적으로 제가 지금 사용하고 있는 프레임워크는 스프링 부트 3xx버전이기에

스프링 부트 버전에 따라 spring cloud BOM을 설정해주었습니다 ( 스프링 3버전이기에 2022.0.4 버전 사용)

또한 spring cloud와의 혼용을 위해 스프링 부트 버전을 3.1.5 로 설정해주었습니다 ( 서버 동일 )

다음으로는 application.yml 파일을 설정해주었습니다.

여기서 중요한점은 spring.application.name인데 통신할때 IP:PORT대신 각 서비스의 고유 ID(즉, 어플리케이션 이름)으로 통신을 하기때문입니다.

prefer-ip-address는 유레카 서버에 애플리케이션 이름에 매핑되는 호스트명이 기본적으로 등록되게 됩니다. ( 이 설정으로 호스트명이 아닌 IP주소를 대신 등록 ) 이런 이유는 컨테이너 기반의 MSA 환경에서 보통 DNS 서버가 없기에 임의로 생성된 호스트 네임을 부여받습니다. 이것은 결국 생성된 호스트 네임의 정상적인 위치를 얻지 못할 수 있기에 명확한 IP로 등록해달라고 지정하는 것입니다.

defaultZone은 등록할 유레카 서버의 위치를 지정합니다. (아까 유레카 서버를 구현할때 defalutZone 설정한곳)

다음으로는 유레카 클라이언트라고 어노테이션을 통해 명시하여주어서 유레카 클라이언트로서의 구현을 진행해줍니다.

그 후 DiscoveryClient 객체를 사용하여 유레카 서버에 등록된 서비스 목록을 가져오는 API를 구현해줍니다

controller에서는 DiscoveryService를 호출하여 "/services" api를 구현해줍니다.

service단에서는 유레카 서버에 등록된 서비스 목록을 가져와줍니다.

여기서 DiscoveryClient는 유레카 클라이언트에서 제공하는 객체로써 서비스들의 정보를 찾아서 제공해주는 객체입니다.

(유레카 서버에 등록된 모든 서비스들을 List로 반환해줌)

Service2 구현

스프링 이니셜라이저를 통해 새로운 프로젝트를 생성해주고 service1과 동일하게 yml파일을 설정해주고 EnableDiscoveryClient 어노테이션을 적용해줍니다. (이때 service2의 포트번호와 application.name은 service1과 다르게 지정해주어야합니다.)

service2의 기능은 고객의 id를 받으면 해당 이름을 반환하여주어야합니다.