[Project] MSA 란? 그리고 적용가능성

Updated: 2024.09.25

Categories: Project

Tags: practice, project3

📌 개인적인 공간으로 공부를 기록하고 복습하기 위해 사용하는 블로그입니다.
정확하지 않은 정보가 있을 수 있으니 참고바랍니다 :😸
[틀린 내용은 댓글로 남겨주시면 복받으실거에요]

그룹웨어 프로젝트

이번 세 번째 프로젝트 주제로 그룹웨어가 나왔다.. 사실 다른 좀 참신한 주제를 하고 싶어서 ~~웨딩플래너를 주제로 제안했는데 역시 남자들은 이런 것에 관심이없다… 아직 결혼이 가깝지 않기 때문이 더 크려나~~

무튼 그룹웨어에 MSA를 하고 싶다는 분들이 있었다. MSA를 채용공고 우대사항에서 많이 보긴 했지만 크게 관심가지지 않았는데,, 이번에 MSA를 공부하는 좋은 기회가 된 것 같다.

근데 MSA가 무엇인지 그리고 이걸 어떻게 적용 해야 하고 정확히 어떤 어려움이 있는지 찾아봤다.

MSA란 무엇인가?

마이크로서비스 아키텍처(MSA)의 정의:

MSA는 하나의 큰 애플리케이션을 여러 개의 독립적인 작은 서비스로 분리하여 개발하는 아키텍처 패턴이다. 각각의 마이크로서비스는 자체적으로 배포, 확장, 관리가 가능하며, 각 서비스는 REST API 또는 메시지 큐와 같은 방식으로 통신한다.
- 독립 배포: 각 서비스는 독립적으로 배포 가능하며, 전체 시스템에 영향을 주지 않고 개별 서비스를 업데이트할 수 있다.
- 개별 확장성: 트래픽이 많은 서비스만 선택적으로 확장하여 자원을 효율적으로 사용 가능하다.
- 작은 단위의 관리: 작은 팀이 각각의 서비스 개발과 유지 보수를 맡을 수 있어 생산성을 높일 수 있다.
MSA의 장점과 단점
- 장점
  1. 확장성(Scalability): 시스템의 특정 부분에만 트래픽이 몰리더라도 해당 마이크로서비스만 확장하면 되므로 자원을 효율적으로 사용할 수 있다.
  2. 유연성(Flexibility): 각 서비스는 독립적으로 관리되므로 서비스별로 다른 기술 스택을 사용할 수 있다. 예를 들어, 하나의 서비스는 Spring Boot로, 다른 서비스는 Node.js로 개발할 수 있다.
  3. 빠른 배포(CI/CD 연계): 애플리케이션을 작은 단위로 분리해 더 빠르게 기능을 배포할 수 있고, 버그 수정도 신속하게 이루어질 수 있다.
  4. 고가용성(Availability): 특정 서비스가 장애를 일으키더라도 다른 서비스는 정상적으로 동작할 수 있어 시스템 전체의 가용성을 높인다.
- 단점:
  1. 복잡성 증가: 여러 서비스 간의 통신 관리가 복잡해진다. 데이터베이스 분리 및 데이터 일관성 유지가 어렵다.
  2. 서비스 간 통신 비용: 네트워크를 통해 서비스들이 서로 통신하기 때문에 레이턴시 문제가 발생할 수 있다.
  3. 배포 및 모니터링의 어려움: 마이크로서비스 개별적으로 배포되기 때문에 각각의 상태를 모니터링하고 관리하는 데 추가적인 도구가 필요하다.
  4. 데이터 일관성 문제: 각 서비스마다 데이터베이스가 따로 존재할 경우, 데이터 일관성을 보장하는 것이 어려워질 수 있다.

그룹웨어에 MSA 적용

그룹웨어 시스템의 주요 기능은 메일, 캘린더, 게시판, 결재 시스템, 메신저, 근태 관리 등이 있는데

이 기능들은 서로 연관되어 있지만 각 기능이 독립적으로 관리될 수 있게 된다.

따라서 MSA를 도입하면 다음과 같은 방식으로 기능을 나눌 수 있다.

사용자 관리(User Management)
- 인증 및 인가 서비스: Spring Security와 OAuth2를 기반으로 인증 서비스 구현.
- 회원 정보 관리: 별도의 사용자 정보 관리 서비스 구축.
캘린더 및 일정 관리(Calendar Service)
- 일정 관련 데이터를 관리하는 별도의 서비스로 분리하여 구글 캘린더와의 동기화 기능 추가.
게시판(Board Service)
- 공지사항, Q&A, 자유게시판 등 다양한 게시판 기능을 마이크로서비스로 관리. 각 게시판의 데이터를 독립적으로 관리하고, 게시판 간의 데이터 의존성을 최소화.
메일(Mail Service)
- 메일 송수신 기능을 SMTP/IMAP 기반으로 구현하고, 메일 관리 기능을 별도의 서비스로 분리.
메신저(Chat Service)
- 웹소켓을 활용한 실시간 메시징 기능을 별도의 서비스로 구현. 채팅 기록이나 파일 공유 기능도 분리하여 관리.
전자 결재 시스템(Approval Service)
- 결재 문서 작성, 승인, 결재 흐름 관리 등을 하나의 독립적인 서비스로 관리하여 다른 서비스와의 연계를 API 기반으로만 처리.
근태 관리(Time Management Service)
- 출퇴근 기록, 휴가 관리, 출장 관리 등을 전담하는 서비스로 분리.
통합 알림 서비스(Notification Service)
- 메일, 메시지, 일정 등에서 발생하는 알림을 통합적으로 관리하는 알림 시스템 구축.

서비스 간 통신

각 마이크로서비스는 REST API 통신 방식을 사용하여 상호작용.
비동기 처리가 필요한 경우 Kafka나 RabbitMQ 같은 메시지 큐 시스템을 도입하여 데이터 전달을 처리할 수 있다.

데이터베이스 분리:

각 마이크로서비스는 자체 데이터베이스를 가진다. 예를 들어, 메일 서비스는 메일 관련 데이터베이스를, 사용자 서비스는 사용자 관련 데이터베이스를 갖도록 분리.
이로 인해 데이터 중복이 발생할 수 있으나, 서비스 간 데이터 일관성 유지를 위해 SAGA 패턴이나 이벤트 소싱같은 기법을 도입할 수 있다.

Spring에서 MSA 구현 방법

Spring Boot와 Spring Cloud

Spring Boot는 MSA 환경에서의 마이크로서비스 구축에 적합하다. Spring Cloud는 MSA의 복잡성을 관리할 수 있는 다양한 도구들을 제공한다.
- Spring Cloud Netflix: 서비스 디스커버리와 로드 밸런싱을 위해 Eureka(서비스 등록 및 탐색), Ribbon(클라이언트 측 로드밸런싱) 등을 사용할 수 있다.
- Spring Cloud Gateway: API Gateway로, 마이크로서비스 간의 통신을 중앙에서 관리하고 요청을 라우팅하는 역할을 한다.
- Spring Cloud Config: 중앙 집중형 설정 서버로 각 서비스의 설정을 중앙에서 관리할 수 있다.
- Spring Cloud Sleuth와 Zipkin: 서비스 간의 트랜잭션을 추적하고, 분산 로그를 통해 문제를 모니터링하는 데 유용하다.
API Gateway

MSA에서는 API Gateway가 중요한 역할을 한다. API Gateway는 클라이언트 요청을 각 마이크로서비스로 전달하는 역할을 하며, Spring Cloud Gateway나 Kong 같은 툴을 사용할 수 있다.
- 인증, 인가, 로깅, 모니터링, 요청 제한 등 부가 기능을 제공하며 서비스 간 복잡한 의존 관계를 클라이언트가 직접 처리하지 않도록 돕는다.
Spring Security와 OAuth2

각 마이크로서비스 간의 인증/인가 문제를 해결하기 위해 OAuth2와 JWT(Json Web Token)를 사용하여 토큰 기반 인증 시스템을 구현할 수 있다. Spring Security OAuth2를 사용해 중앙 인증 서버를 구축하고, 각 서비스가 이 인증 서버를 통해 사용자 권한을 확인하도록 한다.
데이터 일관성 관리

MSA에서는 각 서비스가 독립적인 데이터베이스를 사용하므로, 분산 트랜잭션이 어려워진다. 이를 해결하기 위해 SAGA 패턴을 사용하여 각 서비스가 개별적으로 트랜잭션을 처리하되, 전체적인 흐름에서 일관성을 유지할 수 있다.

그룹웨어를 하게된다면 우리 시스템에서 굳이 MSA를 적용해야할지는 아직 의문이지만

점점 많은 IT기업들이 트래픽에 대한 이슈로 MSA 로 많이 전향하는 것 같다.

기술을 목적으로 프로젝트를 시작하면 안되는데 그것도 고민이고

그룹웨어도 다른 그룹웨어와 차별점이 딱히 없어서 이게 굳이 필요한가 의문이 든다….

아무리 2가지의 이유로 다른 주제를 하자고 설득을 해도 설득되지가 않았다..

과연 잘 할 수 있을지 걱정이 된다.

Hezzi