육각형 아키텍처
초보적으로 MSA로 전환하는 과정을 통해 육각형 아키텍처를 이해해보기로 한다.
육각형 아키텍처를 시작하게 된 경험부터 차근 차근 시작해보자.
보통 시작은
레이어드 아키텍처
대부분 Layered Architecture를 바탕으로 스프링 프로젝트를 시작하게 된다.
그런데 개발하다보면 육각형 아키텍처가 등장한다.
해결하고자 하는 도메인 문제를 다루는 비즈니스 로직 계층이 핵심이라고 생각했다.
레이어드 아키텍처는 비즈니스 로직이 영속성 계층 변화에 영향을 받는다.
영속성 계층에 의존하지 않는 육각형 아키텍처 설계를 보고 혹했다.
그렇게 단순하게 도전했다.
'인터페이스를 두고 영속성 계층에 대한 의존성 역전'
이 생각 하나로 프로젝트들을 진행했다.
여러 경험을 돌이켜보니 나만의 표현으로 육각형 아키텍처를 정의했다.
본격 시작 전,
의존성 주입과 모듈
육각형 아키텍처를 설명하기전에
의존성 주입과 모듈 분리를 먼저 살펴보자
Spring의 의존성 주입
-
의존성 주입 프레임워크를 활용한다면?
인터페이스와 구현체를 모듈로 분리한다면 쉽게 구현체를 바꿀 수 있다.
빌드 시스템에서 의존하는 구현체 모듈만 수정하면 되기 때문이다. -
의존성 주입 프레임워크가 없다면?
실제 생성하고 주입하는 코드를 개발자가 작성해야 한다.
구현체를 바꿀 때 이 역시 수정해야 한다는 점이 핵심이다.
모듈 분리
-
인터페이스 모듈과 구현체 모듈 분리
위에서처럼 인터페이스와 구현체를 모듈로 분리한다면
DI 프레임워크를 활용하여 손쉽게 구현체를 바꿀 수 있다. -
작은 규모의 핵심에 집중
여러 계층에 아우르는 의존성을 제거할 수 있다.
필요없는 책임을 다루지 않도록 도와준다.
이제 Spring 의존성 주입과 모듈 분리를 활용하여
유연한 육각형 아키텍처를 설계해보자
본론, 내가 생각하는
육각형 아키텍처는?
- 각 모듈은 인터페이스로 통신한다.
- 개발자는 '요청 접수', '도메인 로직 처리', '요청' 단위로 모듈을 구성한다.
DI 프레임워크를 활용한다면,
- 개발자는 타 모듈에 접근하기 위해 인터페이스 모듈만 활용한다.
DI 프레임워크가 구현체 모듈을 활용하여 생성, 주입한다.
-
요청 접수
다른 도메인에서 보낸 요청을 접수한다.
요청 방식은 HTTP, RSocket, 메서드 호출 등 다양하다. -
도메인 로직 처리
해당 도메인에서 처리할 수 있는 작업을 처리한다. -
요청
다른 도메인에 요청한다.
DB 드라이버나 파일시스템 시스템콜, 네트워크 통신, 메서드 호출 등이 있다.
그리고 이들을 조합하는 과정에서 인터페이스를 사이에 둔다.
조합을 바꾸게 된다면 빌드 시스템에서 의존성을 수정한다.
이제 레이어드 아키텍처부터 MSA 전환까지 다루어보자.
레이어드 아키텍처에서 MSA 까지
- 인터페이스는 -><-로 표현
- Spring의 DI 컨테이너 활용
- 각자 판단에 따라 모듈로 판단
- 육각형 아키텍처 용어 대신 가급적 이전 설계 용어 활용
- service는 다른 서버, 마이크로서비스 등을 의미
레이어드 아키텍처1
Spring MVC와 JPA를 활용한 초기 설계
Browser -><- controller -> business 로직 -> JPA repository -><- MySQL
어떤 인터페이스에 주목할까?
네트워크, 운영체제 수준의 인터페이스도 있지만, 아래의 두 인터페이스에 주목할 수 있다.
- REST API : Browser와 controller 사이
- JDBC : repository 구현체와 MySQL 사이
레이어드 아키텍처2
영속성을 추상화한 설계
Browser -><- controller -> business 로직 -> adpater -> service
MySQL 대신 service?
- MySQL이 아니라 HashMap, 또다른 DB, 마이크로서비스 등이 될 수 있다.
JPA 리포지토리 대신 출력 어댑터?
- MySQL이 아닐 수 있고, MySQL이라도 MyBatis를 활용할 수 있다.
작성된 인터페이스 코드는 없다.
- 다섯 단위 간에 있는 인터페이스는 REST API 하나다.
육각형 아키텍처
모듈 사이에 인터페이스를 둔 설계
Browser -><- controller -><- business 로직 -><- adpater -><- service
보다 유연하게 로직 전환
- 타 모듈에 접근하기 위해 인터페이스를 활용한다.
구현체 모듈 의존성만 수정하면 된다.
MSA
Browser를 추상화한 설계
service -><- controller -><- business 로직 -><- adpater -><- service
Browser 대신 service?
- 브라우저가 아니라 다른 서비스가 요청할 수 있다.
용어 정리
- 요청 -><- 요청 접수 -><- 로직 처리 -><- 요청 -><- 요청 접수
다시 모놀리식 서버
service를 도메인으로
타 domain -><- 요청 접수 -><- 로직 처리 -><- 요청 -><- 타 domain
service 대신 도메인?
- 외부 마이크로서비스 코드를 모놀리식 서버 내의 도메인으로 통합한다.
사실은 ..
MSA 전환은 위의 과정처럼 쉽게 진행되지 않는다.
크게 네가지
- 네트워크
- 네트워크 통신 실패는? '재시도 로직? 서킷 브레이커?'
- 네트워크 통신으로 인한 지연 시간은?
- 데이터베이스
- 테이블 관계를 유연하게 설정 가능한가?
- 테이블을 나누게 되면서 조인에 대한 성능 하락은?
- ACID 트랜잭션은? '분산 트랜잭션? 보상 작업?'
- 특정 인스턴스
- 관찰가능성은?
- 인스턴스 간 관계
- 비동기? 동기? 이벤트 기반?
이러한 일련의 복잡성이 발생하기 때문에
이에 대한 성숙한 시스템과 서비스를 충분히 고려하고 종합하여
시스템을 설계한 후 전환해야 한다.
그렇지만
Layered Architecture 기반 Monolithic Server를
DI 프레임워크와 멀티 모듈, 육각형 아키텍처를 활용하여 전환하는 과정,
더 나아가서 적절하다면 MSA로 전환하고
이러한 복잡성을 다룰 수 있는 데
이 글이 도움이 될 수 있다고 생각한다.
잘못된 내용 알려주시면 감사하겠습니다!
:)
