Moduler Monolithic 아키텍처

프로젝트를 준비하면서 아키텍처에 대한 고민이 많다. 마이크로서비스 아키텍처로 프로젝트를 하였지만, 현 상황에서는 마이크로서비스 아키텍처가 어울리지 않을 수 있다는 판단을 했고 이유는 아래와 같다.

또한, 아래 사항들을 고려해야 한다.

모놀리식은 단일 단위의 애플리케이션이다. 즉, 모든 비즈니스 로직이 한 곳에 있고 애플리케이션에 변경 사항이 적용되면 전체 애플리케이션에 영향을 미치기에 전체가 다시 배포되어야 한다.

또한, 모놀리식은 종종 큰 진흙 덩어리처럼 보이기도 한다. 시간이 지남에 따라 애플리케이션이 발전하기에 비대해지기 때문이다.

위 그림은 큰 진흙 덩어리인지 분산된 진흙 덩어리인지에 따라 모듈러 모놀리식과 마이크로서비스 아키텍처를 선택하는 것에 대한 아이디어를 준다. 초반에는 모듈식 모놀리식으로 시작하고 제품이 충분히 성공적이면 마이크로서비스로의 이동을 고려해 볼 수 있다.

모놀리식 아키텍처

기존의 모놀리식 애플리케이션은 빌드할 때 코드 개발 및 유지 관리를 쉽게 하기 위해 로직을 여러 계층으로 나눈다.

위의 구조는 효율적으로 애플리케이션을 구축하기 위한 방법이지만, 코드를 변경하면 전체에 영향을 미치기 때문에 유연하지 않다. 이런 상황으로 인해 순수한 모놀리식은 사용할 수 없다.

모듈식 모놀리식 아키텍처는 먼저 로직을 모듈로 나누는 방식으로 구성되며, 각 모듈은 독립적이고 격리된다. 각 모듈에는 고유한 비즈니스 로직이 있어야 한다. 이렇게 다른 모듈에는 최대한 영향을 주지 않고 레이어를 만들고 수정할 수 있어야 한다.

마이크로서비스 아키텍처가 모든 것을 해결하는 솔루션이 아니다. 더 적합한 다른 접근 방식이 존재할 수 있다. 결국 진화에 의해 향후에는 마이크로서비스 아키텍처로 끝나더라도 거기까지 도달하기 위한 다른 중간 단계가 존재하는 것이다.

모듈식 모놀리식은 아래의 특징을 지니고 있다.

일반적인 Java 패키징 체계는 아래 왼쪽 그림처럼 웹 항목, 비즈니스 로직, 데이터베이스 엑세스을 별도의 레이어 패키지로 그룹화 한다.

문제는 시간이 지나면 위 오른쪽 그림처럼 스파게티 코드가 만들어진다는 것이다. 이런 상황이 발생하는 것은 일반적으로 Java에서 대부분 클래스를 Public으로 선언 하기에 캡슐화하는 것이 아니기에 어디서든 접근 할 수 있게 된다.

결국, Jigsaw(자바 모듈 관리)를 이용해서 패키지를 관리해야 한다. (참고: https://openjdk.org/projects/jigsaw/)

위 그림의 패키징 체계에서는 비즈니스 로직 및 데이터 엑세스를 구현한 클래스는 보호되고, 해당 패키지의 접근은 유일하게 정의된 인터페이스를 통해서만 이루어지기에 된다.

이렇게 하면, 느슨하게 결합된 모듈을 만들 수 있고 인터페이스를 일관되게 유지 할 수 있고 향후 마이크로서비스 아키텍처로 전환 할 경우에도 유리하게 작용될 수 있다고 생각한다.

좋은 아키텍처는 끊임없이 진화하는 작업이며 올바른 솔루션은 운영 규모에 따라 달라진다.

이번 선택이 올바른 선택이길 바란다.