MSA(Microservice Architecture)
MSA는 소프트웨어 아키텍처의 패턴 중 하나로 독립적으로 개발 및 실행되는 소프트웨어 컴포넌트(서비스)를 여러 개 조합해서 하나의 애플리케이션을 구축하는 소프트웨어 구조를 의미한다.
서비스를 여러 개로 분할하지 않고 하나의 통합된 서비스 아키텍처를 모놀리스라고 하는데 MSA 패턴은 이러한 모놀리스의 문제점을 개선하기 위해 나온 아키텍처 패턴이다.
그렇다면 모놀리스에는 어떤 문제점이 있을까?
모놀리스의 문제점은 바로 통합된 서비스라는 것에 있다.
위의 그림을 보면 온라인 쇼핑몰에는 여러 가지 기능들이 존재하는데 기존의 모놀리스 아키텍처라면 특정 한 가지 기능에서 장애가 발생할 시 서비스 전체로 장애가 전파되어 결국에는 서비스가 다운되는 상황이 발생할 수 있다.
또 다른 문제점으로는 종속되는 부분이 많아진다는 것이다.
모놀리스는 통합된 서비스이기 때문에 정해진 설정으로 따라갈 수 밖에 없다. 쉽게 생각해 보면 서비스를 개발하는 데 프로그래밍 언어를 자바로 선택했다면 모든 서비스를 자바 언어로 개발해야 한다. 또한 현재 온라인 쇼핑몰에서 사용할 DB로 MySQL을 선택했다면 서비스들은 해당 DB 서버에 맞춰서 개발해야 한다.
이러한 모놀리스 아키텍처의 문제점으로 인해 서비스를 확장하기 어렵고 그에 따라서 유연성이 떨어지게 되어 요구사항을 빠르게 반영하기 어려워진다.
MSA 특징
앞서 언급했던 모놀리스 아키텍처의 문제점들을 해결한 것이 MSA이다.
MSA의 뜻을 살펴보면 큰 특징을 알 수 있는데 말 그대로 Micro(작은) 단위로 service(서비스)를 나누는 Architecture(구조)이다.
위의 그림과 같이 MSA는 통합된 서비스를 하나씩 분리하여 독립적인 컴포넌트(서비스)로 개발을 진행하게 된다.
독립적인 컴포넌트로 분리하여 얻을 수 있는 장점으로는 각각의 서비스 크기가 작아지고 하나의 개발 팀이 아닌 서비스마다 개발팀이 따로 맡아서 개발 및 실행을 할 수 있게 된다.
전통적인 모놀리스 아키텍처는 의사결정에서 많은 시간이 소요되는데 큰 개발 조직이라고 한다면 어느 한 가지를 바꾸기 위해서 개발하는 시간보다 개발팀 간의 소통하고 의사결정하는 시간이 더 오래 소요된다.
반대로 MSA는 서비스가 여러 개로 나뉘어져 있기 때문에 큰 개발 팀에서 소규모 개발 팀으로 나뉘어 각각의 서비스를 도맡아 개발할 수 있게 된다. 그로 인해서 개별 서비스마다 의사결정을 하는 시간이 적어지고 그 만큼 요구사항을 더 많이 적용시킬 수 있다.
MSA를 통해서 서비스를 분리하게 되면 얻을 수 있는 장점이 더 있는데 특정 언어나 DB에 종속되지 않아서 유연하게 개발이 가능하다는 것이다.
분리된 서비스는 하나의 또 다른 프로젝트가 되기 때문에 특정 언어나 DB에 구애받지 않고 기능에 맞춰서 선택하여 개발할 수 있게 된다.
마지막으로 MSA를 적용함에 따라 얻을 수 있는 가장 큰 장점은 바로 모놀리스 아키텍처와는 다르게 특정 서비스의 장애가 서비스 전체에 영향을 주지 않는다는 것이다.
서비스가 분리되어 있기 때문에 특정 서비스에서 장애가 발생하여 다운되었더라도 전체 서비스에 영향을 미치지 않는다.
MSA 장단점
MSA의 개념을 설명하면서 많은 장점을 언급했지만 정리해 보자면
- 유연한 개발이 가능하여 더 많은 요구사항을 적용할 수 있다.
- 여러 개의 독립적인 서비스로 나뉘어져 있어 의사결정 시간이 줄어든다.
- 분리된 각각의 서비스는 특정 프로그래밍 언어나 DB에 종속되지 않기 때문에 확장이 용이하다.
- 특정 서비스에서 문제가 발생하여 다운되더라도 다른 서비스가 다운되지 않는다.
그러면 MSA의 단점은 뭐가 있을까?
- 시스템 복잡도가 증가한다.
- 사용자 요청이 발생할 때마다 서비스 간 통신이 발생할 가능성이 있어 성능에 영향을 준다.
- DB 간 일관성이나 동기화 기법, 운영 및 감시 구조를 정비해야 한다.
MSA를 적용하여 서비스를 독립적인 컴포넌트로 나누기 위해서 고려할 사항도 많아지고 시스템 복잡도가 증가하기 때문에 대용량 트래픽이 있는 큰 규모의 서비스에서 적용하면 좋은 방법이 될 수 있지만, 소규모 서비스에서는 MSA 적용하는 것이 나쁜 영향을 초래할 수도 있다.
서비스 규모가 작을 때는 전통적인 모놀리스 아키텍처로 구성하여 개발을 진행하고 서비스 규모가 점점 커질수록 하나씩 분리하여 MSA 구조를 만드는 것이 가장 이상적인 것 같다.
헥사고널 아키텍처
헥사고널 아키텍처는 MSA 패턴 중 하나로 불특정한 데이터 입출력에 대응할 수 있도록 확장성을 가진 것이 특징이다.
애플리케이션의 도메인을 중심으로 하며 주변에는 그 도메인을 호출하는 입력 측과 도메인에 의해 실행되는 출력 측이 존재한다.
헥사고널 아키텍처를 다른 표현으로 포트 & 어댑터 패턴이라고도 하는데 그림에서 보이는 것과 같이 입력 측과 출력 측이 어댑터로 존재하고 해당 어댑터와 통신을 하기 위해 입/출력 포트가 존재하기 때문에 포트 & 어댑터 패턴이라고도 부른다.
헥사고널 아키텍처의 장점 중 하나는 인터페이스로 되어 있는 포트를 통해 외부 기능에 접근하는 코드를 도메인 내에 구현해 두면 외부 기능을 변경해도 도메인은 영향을 받지 않게 된다.
외부 영향을 받지 않는다는 것은 외부 기능에 의존하지 않는 것으로 어댑터의 종류가 변경되어도 도메인에 영향이 없기 때문에 유연한 변경이 가능하다.
헥사고널 아키텍처와 레이어드 아키텍처 비교
간단한 회원 기능을 구현한다고 했을 경우에 레이어드 아키텍처와 헥사고널 아키텍처를 비교해 보자.
먼저 레이어드 아키텍처로 구현한다고 가정했을 때 그림을 살펴보면 아래와 같다.
레이어드 아키텍처를 적용했을 때 발생할 수 있는 문제점으로는 컨트롤러가 서비스를 호출하고 서비스가 레포지터리를 호출하는 흐름으로 의존성을 가지게 되는 문제가 있다.
만약 요구사항이 추가되어 MemberService의 코드가 변경되면 서비스를 의존하고 있는 컨트롤러도 변경되어야 한다.
레이어드에서 구현한 회원 기능을 헥사고널 아키텍처로 변경한 그림이다.
기존의 레이어드 아키텍처에서는 의존성을 주입하여 컨트롤러, 서비스, 레포지터리 간에 의존 관계를 맺어줘서 특정 부분의 코드를 변경할 시 의존하고 있는 부분도 변경해야 되는 문제점이 발생했다.
이러한 문제점을 해결하기 위해 나온 것이 헥사고널 아키텍처이다.
헥사고널 아키텍처에서는 의존성 역전 법칙을 적용하여 기존의 의존 관계에서 발생하는 문제를 해결하였다.
이제 헥사고널에 있는 웹 어댑터, 유스케이스, 퍼시스턴스 어댑터, 도메인 등의 역할에 대해서 살펴보자.
웹 어댑터(Web Adapter)의 책임
웹 어댑터에서는 DTO를 하나 생성하여 HTTP 요청을 자바 객체로 매핑한다. 그런 다음 클라이언트에 대한 권한을 검사하고 입력 값에 대한 유효성을 검증하게 된다.
검증이 완료된 값을 유스케이스의 입력 모델(Command)로 매핑하고 유스케이스를 호출한다.
호출했던 유스케이스가 반환한 값을 HTTP로 매핑하여 응답을 클라이언트에게 반환해 준다.
유스케이스(UseCase)의 책임
앞서 살펴본 웹 어댑터에서 전달해 준 유스케이스의 입력 모델(Command)을 받아서 비즈니스 규칙을 검증하게 된다.
검증이 완료된 후 도메인 상태를 조작하고 출력을 반환해 준다.
UseCase는 인터페이스로 존재하게 되고 Service가 해당 유스케이스를 구현하게 되며 출력 포트로 값을 넘겨주게 된다.
영속성 어댑터(Persistence Adapter)의 책임
Service에서 값을 전달받고 엔티티로 매핑하여 데이터베이스로 보낸다. 그런 다음 데이터베이스 출력 값을 애플리케이션 포맷으로 매핑하여 서비스로 반환해 준다.
간단한 회원 기능을 가지고 레이어드 아키텍처와 헥사고널 아키텍처를 비교해 봤다.
인터페이스를 통한 의존성 역전으로 헥사고널 아키텍처가 유연한 변경이 가능한 것은 맞지만 간단한 회원 기능도 꽤 여러 가지 작업들이 필요하게 되고 복잡도가 증가하는 문제가 있다.
확실히 소규모 서비스에서는 전통적인 모놀리스 아키텍처가 유리해 보이지만 서비스가 커지고, 요구사항이 많아질수록 MSA를 적용하는 것이 더 좋아 보인다.
참고 자료
헥사고날 아키텍처(Hexagonal Architecture) 코드로 이해 해보기
EventsJdbcEntityRecordPublishedEventService 이 부분은 '만들면서 배우는 클린 아키텍쳐' 의 책을 보고 배운점과 느낌점을 설명합니다. 헥사고날 아키텍쳐란 무엇인까요? 헥사고날 아키텍쳐는 레이어드 아
happy-coding-day.tistory.com
Microservices Pattern: Microservice Architecture pattern
The microservice architecture structures an application as a set of loosely coupled, deployable/executable components organized around business capabilities
microservices.io
그림으로 공부하는 마이크로서비스 구조 | 다루사와 히로유키 - 교보문고
그림으로 공부하는 마이크로서비스 구조 | 디지털 전환(DX) 실현을 위한 기초 기술 ‘마이크로서비스’의 핵심을 쉽고 빠르게 습득하자!이제는 마이크로서비스 방식으로 애플리케이션을 개발하
product.kyobobook.co.kr
