MSA(Microservices Architecture)란?

MSA(Microservices Architecture)

MSA는 소프트웨어 개발 방법론 중 하나로, 하나의 큰 애플리케이션을 여러 개의 작은, 독립적인 서비스로 분리하여 개발하는 것을 의미한다. 이 작은 서비스들은 각각 별도로 배포되고, 독립적인 데이터 저장소를 가질 수 있으며, 각 서비스 간에는 API를 통해 상호 작용한다.

MSA 구축 예시

• 인증 서비스 (Authentication Service):
  사용자의 회원 가입, 로그인, 비밀번호 재설정, 인증 토큰 발급 및 관리 등과 같은 인증 관련 기능.
• 사용자 서비스 (User Service):
  사용자 정보의 생성, 조회, 수정, 삭제와 같은 사용자 관리 기능.
• 상품 서비스 (Product Service):
  상품의 생성, 조회, 수정, 삭제, 카테고리 관리 등과 같은 상품 관련 기능.
• 주문 서비스 (Order Service):
  주문 생성, 조회, 수정, 삭제, 결제 처리 등과 같은 주문 관련 기능.
• 알림 서비스 (Notification Service):
  이메일, SMS, 푸시 알림 등과 같은 알림 기능.

MSA 장점

• 각 서비스가 독립적으로 개발되고 운영될 수 있기 때문에, 전체 시스템의 확장성이 높다.
• 서비스 별로 개발 및 배포를 수행하므로, 개발 및 유지보수가 용이하다.
• 서비스 간의 결합도가 낮아지므로, 하나의 서비스가 변경되어도 다른 서비스에 미치는 영향이 적다.

MSA 단점

• 여러 개의 작은 서비스를 관리해야 하므로, 시스템 복잡성이 증가.
• 서비스 간의 상호 작용이 필요한 경우, 네트워크 지연이 발생할 수 있다.
• 데이터 일관성을 유지하기 위한 추가적인 노력이 필요할 수 있다.
• MSA는 대규모 시스템을 구축하고 유지보수하는데 적합한 방법론이지만, 프로젝트의 규모와 특성에 따라 적절한 아키텍처를 선택하는 것이 중요하다.

*회사프로젝트에서 AWS ecs를 이용해 인스턴스가 분리되어 있지만 완벽한 MSA라고 부르기는 어렵다. 그 이유로는 각각의 기능이 완전하게 독립적이지 않다는 문제를 들 수 있다. 예를 들어 JWT토큰을 활용해 인증 상태를 검사하는데 인증서비스가 아닌 다른 서비스 서버에서 이 토큰을 해석하기 위한 로직이 각각 구현되어 있다. 이렇게 되면 추후에 다음과 같은 문제가 발생할 수 있다고 한다.

1. 보안: 인증서버가 아닌 서버에 토큰 해석 로직이 포함되면, 보안상의 문제가 발생할 수 있다. 토큰 검증 및 발급은 보통 인증 서버에서만 수행되어야 하는 작업인데 인증서버가 아닌 서버 서버에 토큰을 해석하는 로직이 있다면, 인증 서버 외부에서도 비밀 키에 접근할 가능성이 있어 보안에 취약해질 수 있다.

2. 유지보수: 각 마이크로서비스가 독립적으로 작동해야 하는 MSA 아키텍처의 원칙에 어긋난다. 인증서버가 아닌 서버에 토큰을 해석하는 로직을 추가하면, 인증 로직이 여러 서비스에 중복되어 유지보수가 어려워질 수 있다. 인증 로직의 변경이 필요할 때마다 모든 서비스를 수정해야 할 수도 있다.

3. 확장성: 인증 서버를 중심으로 하는 구조가 아닌 경우, 서비스가 확장될 때마다 각 서비스에 토큰 해석 로직을 추가해야 한다. 이는 시스템의 확장성을 저해하며, 새로운 서비스를 추가할 때마다 추가 작업이 필요하게 된다.

새로 들어가는 서비스에서는 MSA 원칙을 최대한 지키고 ECS말고 EKS를 활용하여 도커 컨테이너를 최대한 활용한 서버 환경을 구축해볼까 한다.