마이크로서비스 아키텍처(MSA)는 애플리케이션을 작은 서비스들로 나눠서 각각 독립적으로 개발하고 운영할 수 있게 하는 방식이다. 단일 시스템보다 더 쉽게 관리하고 확장성이 보장되어 있다. 각 서비스는 특정한 기능을 담당하고, 따로따로 배포하거나 수정할 수 있다.
MSA 주요 특징
-
마이크로 서비스
단일 서비스를 여러 작은 서비스로 쪼갠다. 예를 들어, 사용자 관리, 주문 처리, 결제 기능을 따로 나눠서 관리할 수 있다. -
독립 배포
서비스마다 따로 개발하고 배포할 수 있다. 예를 들어 결제 기능을 수정해도 다른 서비스에는 영향을 주지 않는다. -
가벼운 통신
서비스 간의 소통은 주로 REST API나 gRPC 같은 네트워크 요청을 통해 이루어진다. 데이터를 주고받을 땐 proto등을 사용한다. -
분산 환경
모든 서비스가 각각의 서버나 컨테이너에서 돌아가면서 서로 연결되어 있다. 네트워크 장애 같은 문제를 관리해야 등의 까다로운 점이 있다.
MSA 구성
-
API Gateway
클라이언트가 각 서비스와 바로 통신하지 않고, 이 게이트웨이를 통해 요청을 보내고 서버는 요청을 적절한 서비스로 보내주고, 인증이나 로드 밸런싱도 처리해준다. -
서비스 디스커버리
각 서비스가 어디 있는지 찾아주는 역할이다. IP 주소나 포트 번호가 바뀌어도 자동으로 알려준다. -
데이터베이스 분리
각 서비스가 자신만의 데이터베이스를 갖고 있다. 예를 들어, 주문 관리 서비스는 주문 데이터만, 사용자 관리 서비스는 사용자 데이터만 저장한다. -
모니터링과 로깅
여러 서비스가 있다 보니 문제가 생기면 원인을 바로 찾기 어려울 수 있다. 그래서 로그를 모으고 성능을 모니터링하는 도구가 필요하다.
장점
-
빠른 배포
수정해야 할 부분만 따로 배포하면 돼서 배포가 빠르고 부담이 적음 -
확장성
필요한 서비스만 따로 확장할 수 있다. 예를 들어, 주문 처리가 많아지면 그 부분만 서버를 늘릴 수 있다. -
기술 선택 자유
각 서비스마다 가장 적합한 프로그래밍 언어나 기술을 선택할 수 있다. 통신 규약만 맞춰져 있으면 된다. -
문제 격리
하나의 서비스가 다운되어도 다른 서비스들은 정상 작동할 수 있다.
단점
-
복잡한 구조
서비스가 많아질수록 관리할 게 늘어나고 특히 서비스 간 통신이나 데이터 일관성을 관리하는 게 어려울 수 있다. -
운영 비용 증가
각각의 서비스를 운영하고 모니터링하려면 많은 도구와 인프라가 필요 -
초기 설정 부담
처음부터 MSA로 시작하려면 많은 시간과 노력이 든다. 팀이 충분히 준비되지 않았다면 더 복잡해질 수 있다.
