[단잠] MSA로 마이그레이션 하다 - 2편

1편이 궁금하시다면?
https://agongstory.tistory.com/29

[단잠] MSA로 마이그레이션 하다 - 1

 

📜서론

이전글에 이어 SpringCloud를 통해 아키텍처를 구성하는 과정에 대한 글입니다. Spring Cloud를 선택한 이유와 그 주요 특징 및 구성요소에 대해 살펴보겠습니다.

 

Spring Cloud를 선택한 이유

1. 기존에 SpringBoot로 개발했기 때문에

단잠은 기존에 Spring Boot로 개발된 서비스를 운영하고 있었습니다. Spring Cloud는 Spring Boot와 자연스럽게 통합되어 개발 환경에 큰 변화를 주지 않고도 MSA 전환이 가능했습니다. 그렇기 때문에 가장 먼저 1순위로 생각하였습니다.

 

2. 다양한 기능을 지원하기 때문에

Spring Cloud는 MSA 개발에 필수적인 서비스 디스커버리, 분산 설정 관리, 로드 밸런싱, 장애 복구, 모니터링 등 다양한 기능을 제공합니다. 이를 통해 단잠은 서비스 간 통신 최적화, 분산 환경 설정 관리, 안정적인 서비스 운영 등 MSA 전환에 필요한 기술적 과제를 효율적으로 해결할 수 있었습니다.

 

그러면 다른 대안은 없었을까요?
SpringCloud이외에도 쿠버네티스를 통해 MSA를 구현하는 방법이 존재하였습니다. 
SpringCloud와 쿠버네티스는 다음과 같은 차이점이 있었습니다.

 

Spring Cloud

 

• Java 라이브러리 다수 존재: Spring Cloud는 다양한 Java 라이브러리를 제공하여 마이크로서비스 개발 및 운영을 지원합니다.
• JVM 환경에 적합한 기능 제공: JVM 기반 애플리케이션에서 네이티브처럼 작동하며, 높은 호환성과 유연성을 보장합니다.
• Runtime 기능 제공: Spring Cloud는 애플리케이션이 실행되는 동안 서비스 디스커버리, 로드 밸런싱, 설정 동기화, 장애 복구 등의 기능을 실시간으로 수행하며, 애플리케이션의 운영과 동작에 직접적인 영향을 미칩니다.
• Application stack의 일부로써 기능: 애플리케이션 코드에 추가되어 스택의 핵심 구성 요소로 작동하며, 마이크로서비스 환경의 인프라 역할을 수행합니다.

Kubernetes

 

• Java 한정 X, 모든 언어 적용 가능: Kubernetes는 언어에 종속되지 않으며, 다양한 프로그래밍 언어와 런타임 환경에서 애플리케이션을 실행하고 관리할 수 있습니다.
• 분산 컴퓨팅 문제 해결을 위한 전반적인 기능 제공: Kubernetes는 컨테이너 오케스트레이션 도구로, 스케일링, 로드 밸런싱, 자원 할당, 장애 복구 등 분산 시스템에서 발생하는 다양한 문제를 해결합니다.
• Platform 수준에서 동작: Kubernetes는 애플리케이션이 실행되는 플랫폼으로 작동하며, 컨테이너 기반 애플리케이션을 배포, 관리, 확장할 수 있는 환경을 제공합니다.
• Application 외부에서 기능 수행: Kubernetes는 애플리케이션 자체에 포함되지 않고 외부에서 애플리케이션의 상태를 모니터링하고 제어하며, 애플리케이션과는 독립적으로 동작합니다.

 

이렇게 살펴보았을 때 장단점이 존재하였습니다.

Spring Cloud는 Java 개발자에게 친화적이며, 마이크로서비스 개발과 런타임 환경에서 생산성이 뛰어납니다. 그러나 플랫폼 수준의 기능( 자동 배포, 스케쥴링, 리소스 관리, 프로세스 분리, 자가복구, 빌드 파이프라인)이 부족하여 다른 추가 도구가 필요합니다.

Kubernetes는 컨테이너 오케스트레이션과 분산 환경 관리에 강력하지만, 설정 관리 및 개발자 친화성 측면에서 부족함이 있습니다. 그렇기 때문에 새롭게 개념을 배우고 문제를 해결하기 위한 방법을 배우는 데 SpringCloud에 비해 다소 시간이 걸릴 것입니다.

 

SpringCloud와 Kubernetes는 서로 다른 방법으로이중 하나를 선택해야한다고 생각하였지만 결국에는 서로의 장단점을 채워줄수 있도록 두개 모두 사용하는 것이 좋은 방법이였습니다. 저희 서비스는 이미 Spring으로 개발된 서비스를 마이그레이션 하기 때문에 SpringCloud를 일단 사용하고 부족한 부분이 존재하게 되면 Kubernetes를 함께 사용하는 것으로 추후에 고려해보아야할것 같습니다. (지금은 SpringCloud만으로 머리 지끈)

 

 

 

이제 SpringCloud를 사용하게 된 이유를 알았으니 본격적으로 SpringCloud가 무엇인지. 어떻게 구성되는지를 알아보겠습니다.

 

SpringCloud?

분산 시스템 개발을 위한 일련의 도구를 제공하는 프레임워크입니다. 이는 SpringBoot를 기반으로 하여 마이크로 서비스 아키텍처 구축을 용이하게 합니다. 

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

SpringCloud

주요 구성 요소와 역할은 다음과 같습니다.

 

1. Microservices

Spring Boot 기반으로 각 도메인별로 독립적으로 동작하는 실제 서비스를 제공하는 서버입니다. 

 

2. API Gateway

Zuul 또는 Spring Cloud Gateway를 사용해 클라이언트 요청을 하나의 진입점에서 관리하며, 인증, 권한, 모니터링, 로깅, 서비스 라우팅을 통해 요청을 알맞은 서비스로 전달합니다.

 

3. Config Server

중앙 집중식 설정 관리 서버로, 분산 시스템에서 애플리케이션의 설정 정보를 외부화하고, 설정 변경을 실시간으로 반영하여유지보수를 효율화합니다.

 

4. Service Discovery

서비스의 위치와 상태를 관리하며, 서비스 간 동적 통신, 부하 분산, 장애 시 대체 경로 제공 등의 기능을 수행합니다.

 

5. Circuit Breaker
Hystrix를 사용해 서비스 간 장애 전파를 방지하며, 장애 발생 시 연결을 차단하고 fallback 로직을 통해 시스템의 안정성을 유지합니다.

 

6. Distributed Tracing
Spring Cloud Sleuth와 Zipkin을 통해 분산 시스템 내에서 요청의 흐름과 트랜잭션을 추적하여 성능 병목점과 장애 원인을 시각적으로 분석할 수 있습니다.

 

7. Event-driven Architecture
Spring Cloud Stream은 Kafka와 RabbitMQ와 같은 메시지 큐와 연동하여 비동기 통신을 지원하며, 이벤트 중심 아키텍처를 통해 서비스 간 결합도를 낮추고 확장성을 높입니다.

 

8. Message Broadcasting
Spring Cloud Bus를 사용해 메시지 브로커와 통합, Config 서버의 설정 변경 사항을 브로드캐스트 방식으로 모든 마이크로서비스에 전달하여 실시간 설정 갱신을 지원합니다.

 

이제 SpringCloud에 대해 알아보았으니 MSA 아키텍처를 설계하고자 합니다.

 

단잠의 MSA 아키텍처 설계

단잠의 도메인을 크게 나누자면 다음과 같습니다. 

user, mate(roomMate,foodMate,studyMate,walkMate,workMate),chat, chatroom, notice, admin, home, common, security

 

아직 팀원들과 각 도메인을 모두 분리할지 일부는 결합할지등 자세한 이야기를 나눠야 하기 때문에 일단 몇개의 주요 도메인만으로 설계를 진행하겠습니다.

 

아직 MSA에 대해 잘 모르기 때문에 수정사항이 많이 생기겠지만 초기 아키텍처 설계는 여기에서 마치겠습니다.

모든 구성요소가 다 필요한지 아니면 선택적으로 필요한것들을 사용하면될지 아직 판단을 못하겠습니다.

해보면서 얼른 두드려 맞고 글 작성하겠습니다.

 

참고 자료

- https://bryceyangs.github.io/study/2021/07/28/MSA-SpringCloud-vs-Kubernetes/

- https://bu119.tistory.com/85

- https://enjoy-dev.tistory.com/10

- https://ryudain.tistory.com/39