Monolithic과 MSA
Monolithic은 단일 서비스 개발 방식, 즉 하나의 프로젝트로 구성되어 있으며 단일 패키지로 배포하는 아키텍쳐입니다. 서버 애플리케이션은 단일체로서 작은 수정에도 전체를 다시 빌드해 재배포해야 했고, 확장이 필요한 경우에도 로드밸런서를 두고 큰 앱을 복제해 수평적으로 확장해야 했습니다. 즉, 수평적으로 확장된 여러 대의 모놀리식 서버에 수정사항을 적용하려면 시스템 전부를 다시 빌드하고 배포해야 하는 문제가 발생했습니다.
장점
- 통합 시나리오 테스트가 수월하다.
- 배포가 간단하다.
단점
- 서비스가 커짐에 따라 빌드/테스트의 시간이 오래 걸린다.
- 개발 언어가 종속적이다. Spring을 사용하면 Java, Nodejs를 사용하면 JS로 종속된다.
- 선택적으로 확장이 불가능하다. 서비스마다 관여하는 비중이 크게 달라도 전체를 확장시켜야한다.
- 하나의 서비스가 다른 모든 서비스에 영향을 준다.
MSA(Micro Service Architecture)는 여러 개의 작은 어플리케이션으로 쪼개어서 배포하는 아키텍처로, 독립적인 기능을 수행하는 작은 단위의 서비스로 나누어 개발하는 방식입니다. 서버 어플리케이션은 별개의 인스턴스로 로딩되고, 각기 다른 저장소를 사용해 모듈 경계가 명확하게 구분됩니다.
장점
- 서비스 별 배포가 가능해 배포 시에 전체 서비스 중단이 필요없으며, CI/CD가 수월하다
- 상황에 맞게 기술을 유연하게 적용하는 폴리글랏 아키텍쳐 구성이 가능하다.
- 특정 서비스를 선택적으로 확장이 가능하다
- 서비스가 분리되어 있어 부분적인 장애에 대해서 격리 및 대처가 수월하다
단점
- 서비스간 통신에 API를 이용하기 때문에 통신 비용과, latency(지연 시간)이 증가, 오버헤드 등이 발생할 수 있다.
- 서비스 간에 Global 트랜잭션 관리가 까다롭다.
- 서비스가 많아짐에따라 조회와 관리가 어려워 질 수 있다.
2. MSA와 DDD
MSA 서비스를 구성할때 어떤 기준으로 서비스를 분리를 해야할까요? MSA는 DDD를 기반으로, 좋은 서비스를 개발하기 위한 핵심 기본 요소인 Loose Coupling(느슨한 결합)과 High Cohesion(높은 응집)을 원칙으로 합니다.
1. 서비스 하나에 책임도 하나
마이크로서비스의 가장 큰 장점은 모듈 경계가 명확하다는 것입니다. 즉, 시스템 변경 사항이 발생하면, 변경할 특정 도메인 내 마이크로서비스 단위만 이해하고 처리하면 된다는, 단일 책임 원칙을 지킵니다. 만약 제대로 된 경계를 가지지 못한다면, MSA로 인한 마이크로서비스로의 분리는 장점이 아닌 큰 핸디캡이 될 수 있습니다. 따라서 MSA를 설계할 때 도메인을 잘 나누는 것이 얼마나 중요한지 생각해 보실 수 있습니다.
2. 마이크로서비스는 자율적
MSA의 각각의 마이크로서비스는 하나의 단독 서비스로서, 독립적으로 배포가 가능해야 합니다. 그런 의미에서 가상 인프라 발전은 MSA의 일등 공신이라고 할 수 있습니다. DevOps 환경에서 CI/CD 자동화와 수많은 서비스 배포환경을 관리하기 위한 인프라 구성 도구 개발은 MSA에 필수적인 조건인 동시에 MSA를 성공적으로 자리잡게 해주었습니다.
3. 폴리글랏 프로그래밍
각각의 마이크로서비스의 독립성이 강화되면서, 마이크로서비스 내의 기술 선택이 자유로워졌습니다. Loose Coupling의 원칙에 따라 각 마이크로 서비스팀은 서비스를 빠르고 효율적으로 개발할 수 있는 방법론과 도구, 기술을 적용할 수 있고, 자신의 팀에 맞는 개발 언어와 저장소를 선택할 수 있게 된 것입니다.
3. 개발 명세
개발의 요구사항이 관리자 백오피스, 일반 사용자로 나눠져있어서 유저를 확인하고 토큰을 발급하는 인증(auth)서버, 발급된 토큰을 기반으로 인가를 받는 user서버와 admin서버로 분리했습니다. 이어지는 글에서는 개발에 적용된 주요 스택들에 대해 기술하겠습니다.
기본적인 시스템 아키텍처와 워크 플로우는 다음과 같습니다.
Reference
[Kakao Tech]이모티콘 서비스는 왜 MSA를 선택했나?
[마이크로서비스] 스프링 마이크로서비스 요약 정리 (spring microservice, msa)
DDD와 MSA
