3편. MSA에 사용되는 여러가지 패턴(Service Discovery, BFF, CQRS)

CI/CD 패턴

CI(Continuos Integration) / CD(Continuous Delivery/Deloyment)

MSA 환경에서 비지니스 민첩성을 키우기 위해서는 배포 자동화를 구축할 필요가 있다.
이때, 자동화된 빌드나 배포 작업을 보통 CI/CD라고 부른다.

 

일반적인 플로우는 아래와 같다.

1. 새로운 버전의 코드와 테스트 코드를 함께 Github와 같은 형상 관리 시스템에 Push 한다.
2. 빌드 도구에서 특정 시간에 형상 관리 시스템으로부터 코드를 Pull해서 통합한 후에, 자동으로 빌드하고 테스트 코드를 실행하여 테스트를 수행한다.
3. 테스트 수행 결과를 따로 로그 파일에 리포팅하고, 빌드된 소스코드를 스테이징 환경에 자동으로 배포한다.
4. QA 테스터가 스테이징 환경에서 테스트를 수행하고, 문제가 없으면 운영 환경에 배포한다.

 

Netflix의 경험이 마이크로 서비스 생태계로

Micro Service를 구축하면서 발생하는 문제를 넷플릭스가 해결하는 데 많은 기여를 했다고 한다.

Netflix OSS는 Netflix가 Micro Service를 개발하고 운영하면서 생긴 노하우를 오픈소스로 공개한 것이다.
이로 인해, 마이크로서비스 애플리케이션을 구성하는 전형적인 패턴으로 자리 잡았다.

 

예를 들어, API G/W, Service Discovery, Monitoring, Tracing 등 마이크로서비스를 관리 및 운영하기 위한 플랫폼 패턴으로 추후에 이러한 패턴을 적용한 다른 여러 오픈 소스가 생겨나게 되었다.

 

Spring Cloud (Spring Boot + Netflix OSS)

Netflix OSS를 더 쉽게 쓸 수 있도록 Spring 진영에서는 기존 Spring Boot에서 잘 돌아갈 수 있도록 Netflix OSS 모듈들을 Spring Framework로 감싸서 Spring Cloud라는 명칭으로 발표했다.

https://spring.io/cloud

https://spring.io/cloud

 

 

Service Discovery 패턴

MSA와 Cloud를 함께 사용한 환경에서 Auto Scaling등에 의해서 서비스가 동적으로 생성되거나 컨테이너 기반의 배포로 인해,
서비스의 IP가 Dynamic하게 변경되는 일이 많아지게 됐다.

 

따라서, 서비스 클라이언트가 서비스를 호출할 때 서비스의 위치 즉, IP주소와 Port를 알아낼 수 있도록 도와주는 것을 Service Discovery 패턴이라고 한다.

 

Client Side Discovery

https://www.nginx.com/blog/service-discovery-in-a-microservices-architecture/

Client Side Discovery는 위 그림과 같이 Service Client가 Service Registry에서 서비스의 위치를 알아내고 호출 하는 방식이다.

 

 

Server Side Discovery

Server Side Discovery는 호출 되는 서비스 앞에 일종의 Proxy 서버(로드밸런서)를 배치하고, Service Client는 Proxy인 로드밸런서를 호출하면 로드밸런서가 Service Registry로부터 등록된 서비스의 위치를 알아내어, 이를 기반으로 라우팅 하는 방식이다.

 

AWS의 ELB가 대표적인 Server Side Discovery이다!

 

 

Service Registry

이제, Service Discovery 패턴에 사용되는 Service Registry는 Netfilx OSS의 Eureka가 대표적인 서비스이다.

각 서비스 Instance가 로딩될 때 자신의 서비스 이름과 할당된 IP 주소를 Service Registry에 등록하고, 클라이언트가 해당 서비스명을 호출할 때 라우터가 Service Registry를 검색하여 해당 서비스의 이름과 매핑된 IP 정보를 확인한 후 호출한다.

 

이렇게, 마이크로서비스가 처음 실행될 때 자신의 위치 정보를 Service Registry에 저장하고, 서비스가 종료될 때 위치 정보를 삭제한다.

 

MSA와 Spring Cloud의 연계 흐름

1. 마이크로 서비스는 인프라에 종속되지 않도록 DB, 파일 등 여러 설정 정보를 형상 관리 시스템에 연계된 Config Server에서 가져와 설정 정보를 주입한다.
2. 로딩과 동시에 Service Registry에 자신의 서비스명과 클라우드 인프라로부터 할당받은 물리 주소를 매핑하여 등록한다.
3. 클라이언트가 API Gateway를 통해 마이크로서비스에 접근하고, 이때 API 게이트웨이는 적절한 라우팅 및 부하 관리를 위한 로드 밸런싱을 수행한다.
4. 또한, API Gateway에서 클라이언트가 마이크로서비스에 접근하기 위한 주소를 알아내기 위해 Service Registry에게 요청하여 주소를 알아낸다.
5. 동시에 API Gateway는 클라이언트가 각 서비스에 접근할 수 있는 권한이 있는지 권한 서비스와 연계하여 인증/인가 처리를 수행한다.
6. 이러한, 모든 마이크로서비스 간의 호출 흐름은 Monitoring Service와 Tracing(추적) Service에 의해 모니터링된다.

 

이러한 패턴은 Spring Cloud 이외에도 여러 클라우드 제공업체인 AWS, Azure, GCP 등에서도 유사한 형태로 서비스를 제공하고 있다.

 

 

BFF(Backend For Frontend)

최근에는 PC 뿐만 아니라 다양한 장치 및 플랫폼 (Web, Android, iOS)을 지원하면서 다양한 클라이언트를 위해 특화된 처리가 필요한 상황이 생긴다.

원하는 데이터 형태에 도달하기 위해서 여러 API의 Response 값을 조작하는 상황이 발생하며, Frontend에서 복잡한 비지니스 로직을 작성해야 하며, 코드 베이스가 거대해지고 복잡해지면서 자연스럽게 UI 렌더링이 느려지는 문제가 발생한다.

 

이런 문제들은 API를 Direct로 의존할 때 발생하며, Backend For Frontend 프론트엔드를 위한 백엔드 중간 서버를 구현함으로써 해결할 수 있다. 

각 장치들의 Entry Point를 하나로 두지 않고, 클라이언트의 종류에 따라 특화된 처리를 수행하는 BFF를 앞 단에 두고 뒤에 통합적인 API G/W를 두는 방식으로 구성할 수 있다.

 

BFF의 역할은?

1. MSA 환경에서 API Endpoint가 분리될 때 Follow Up
2. 브라우저와 떨어질 수 없는 CORS 처리
3. API가 직접적으로 여러 플랫폼에 맞춰줄 필요 없게 해줌 
4. 플랫폼별로 다른 인증 방식 처리 (iOS는 FaceID라는 Android에는 없는 인증 방식이 있음)
5. 화면에 필요한 데이터만 받을 수 있도록 함

 

GraphQL을 사용한 BFF

BFF를 구현하기 위한 구현체로 GraphQL을 사용할 수 있다.

GraphQL로 처리하게 되면 POST 방식으로 요청이 발생하고 브라우저의 캐시 대신 라이브러리에서 제공해주게 된다.

또한, API 응답값을 BFF에서 받아서 각 플랫폼(FE)에서 원하는 모델 타입으로 Convert 해줘서 Response 해준다.

 

 

CQRS 패턴

쿠팡, 배민 등 여러 서비스를 생각해보면 CUD 작업보다 Read 작업이 훨씬 많다는 것을 알 수 있다.

이러한 비지니스 모델에서 하나의 애플리케이션 내에 CRUD 모든 기능을 하도록 구성하면 조회 요청 빈도가 증가함에 따라 다른 명령 기능도 확장해야 해서 효율적이지 않다.

또한, 쓰기 트랜잭션 작업 시에 테이블에 Lock 매커니즘이 적용된다면 조회 응답 속도가 떨어질 수 밖에 없다.

이러한 문제를 해결하기 위해서 CQRS(Command Query Responsibility Segregation) 패턴을 이용할 수 있다.

 

 

하나의 저장소에 쓰기 모델과 읽기 모델을 분리하는 방식으로 변화시켜 쓰기 서비스와 조회 서비스를 분리할 수 있다.
더 큰 시스템에서는 물리적으로 쓰기 트랜잭션용 저장소와 조회용 저장소를 따로 구성할 수도 있다.

 

DB 단계에서 물리적으로 적용해보지는 못했지만, 이것을 코드단계로 응용해서 Write 작업용 서비스 및 DAO와 Read 작업용 서비스 및 DAO를 분리하는 개념으로 프로그래밍 해본적은 있었고 개인적으로 매우 좋아하는 방식이다.