마이크로서비스 : Layer 구조, 설계, 고려사항 : 개념, 정의, 개요

Presentation Layer

Presentation Layer에서 가장 많이 쓰이는 패턴은 Model View Controller로 이루어진 MVC 패턴입니다. MVC 모델은 초기 컨트롤러와 모델이 어떤 기술을 쓰느냐에 따라 발전해왔습니다. 최근에는 JSP가 View의 역할을, POJO가 모델의 역할, 서블릿이 이 두 개의 요소를 연계하는 컨트롤러의 역할을 수행하는 방식으로 발전해왔습니다. 

그렇지만 현재는 JSP 서블릿뿐만 아니라 웹, 모바일, 태블릿, 인터넷, PC, 셋톱박스와 같은 다양한 인터페이스의 등장으로 인해서 이를 지원하기 위한 다양한 화면 플랫폼이 등장했습니다. Spring의 Thymeleaf나 페이스북이 공개한 React, 기존에 유명했던 ANGULARJS, 그리고 Vue.js 등의 아주 많은 UI 플랫폼이 존재합니다.

이러한 기술들은 어떠한 장비의 사용자 인터페이스가 요구되는지, 화면에서 얼마나 파워풀한 기능을 요구하고 있는가에 따라 Presentation Layer의 주 기술로 고려되고 선택되어야 합니다.

 

 

Presentation Layer의 역할

다음은 전형적인 웹 서비스를 제공하는 프로젝트에서 정의한 Layered Architecture의 구조입니다. 마이크로서비스의 성격에 따라 Front-End 마이크로서비스와 Back-End Biz 마이크로서비스로 구분되고, Front-End 마이크로서비스 측에서도 MVC 구조의 Presentation Layer가 존재하고, Back-End Biz 마이크로서비스 측에서도 Business Logic 층의 API를 제공하기 위한 Presentation Layer가 존재하는 것을 볼 수가 있습니다.

이 두 개의 마이크로서비스는 각각 클라우드의 서비스로 배포되어 Rest API를 통해 연계되어 서비스를 제공하게 됩니다.
Front-End 마이크로서비스는 여러 개의 Back-End Biz 마이크로서비스에서 제공한 결과 값을 가지고 화면을 구성하여 사용자에게 보여주게 됩니다. 이러한 방식은 Back-End Biz 마이크로서비스를 개발 운영할 때는 마이크로서비스 단위의 자율적인 배포나 독립성의 장점을 누릴 수 있으나 Front-End 마이크로서비스가 한 덩어리이기 때문에 Front-End 측면에서는 모노리스 시스템의 단점들이 나타나게 됩니다.

따라서 최근의 방향은 Front-End 마이크로서비스도 각 Back-End Biz 마이크로서비스처럼 독립적으로 분해되어 서비스를 제공할 수 있도록 분해되는 방식이 등장하게 됩니다. 이걸 Composite UI라고 합니다. 각 팀은 자신의 서비스를 위해 페이지의 영역을 구현하는 HTML 조각을 생성하는 Front-End 마이크로서비스를 독자적으로 개발하고, 전체 화면은 각 서비스에서 제공받은 조각을 통해 화면을 구성하여 보여줍니다.

 

 

Server-side

이러한 방식을 Server-side Page Fragment Composition 방식이라고 부릅니다. 서버에는 각 조각을 모으기 위한 간단한 웹 프레임의 서비스가 동작하고, 각 조각 영역은 비즈니스를 구성하는 한 쌍 이상의 Front-End 마이크로서비스와 Back-End 마이크로서비스에 의해 제공됩니다.

 

 

Business Logic 층의 역할

다음은 Business Logic층의 구성을 살펴보도록 하겠습니다. Business Logic 층은 특정 업무의 도메인 개념을 표현하는 도메인과 그것을 이용해서 Biz 흐름 처리를 수행하는 서비스로 구성이 됩니다. 개발 운영 시에 기능 추가와 변경은 주로 Business Logic 층의 로직변경을 통해서 이루어지기 때문에 비즈니스 민첩성을 좌우할 핵심 Layer가 됩니다. 따라서 이 Layer를 잘 구조화하고 설계하는 것이 중요합니다. 일반적으로 다음과 같이 두 개의 큰 패턴으로 정의되어 있습니다.

 

마이크로서비스 : Layer 구조, 설계, 고려사항 : 개념, 정의, 개요

 

Transaction Script 패턴과 Domain Model 패턴입니다. Transaction Script 패턴은 Transaction 단위로 모든 처리 흐름을 혼자 처리하는 방식입니다. 따라서 서비스 클래스가 Transaction Script가 되어 모든 비즈니스 처리를 수행하고, 각 도메인 클래스는 행위가 없고 데이터 처리 결과를 담고 있는 데이터 홀더의 역할을 수행하며, 서비스 클래스를 처리하기 위한 데이터나 그 결과를 담는 용도로 활용되며, DTO의 역할을 수행하게 됩니다.

이러한 구조는 초급자도 쉽게 이해할 수 있는 장점이 있으나, Transaction 증가에 따라 비슷한 처리 흐름이 중복되는 한계가 있습니다. Domain Model 패턴은 서비스가 모든 Biz 흐름을 처리하지 않고 도메인 클래스의 Biz 개념에 따라 그 처리를 위임하게 됩니다. 따라서 도메인 클래스는 객체 모델의 형태를 띠게 되며, 자체적으로 Biz 행위를 처리하고 서비스는 여러 개의 Domain Model 결과를 모아서 로직 처리를 하는 경우에만 활용되게 됩니다.

처음에 익숙해지기는 어렵지만 복잡한 로직을 잘 조직된 방법으로 각 객체 모델에 위임하기 때문에 로직 중복들을 제거하고 잘 모듈화시킬 수 있는 장점이 있습니다. 정리하면 Transaction Script 패턴 구조는 단순한 입출력 구조의 쉬운 업무 처리를 위한 마이크로 서비스 내부 구조로 활용하면 유용하며, 복잡한 비즈니스 로직을 잘 정리하여 핵심 서비스로 활용해야 할 경우에는 Domain Model 패턴 구조의 마이크로서비스 내부 구조를 취하면 효율적입니다.

 

 

Business Logic 층의 Architecture 고려 사항

또한 Business Logic 층에서 Transaction 처리를 어떻게 할 것인가도 고려되어야 합니다. Transaction의 시작이 되는 Transaction 경계를 Presentation Layer에 둘 것인지 Business Layer에 둘 것인지를 고민해야 하며, Transaction 처리 로직을 명시적으로 코드에 표현할지 아니면 Spring 등의 프레임워크에서 제공하는 선언적인 Transaction에 맡길 것인지를 고민해야 합니다.

Transaction을 시작, Commit 코드를 명시적으로 기입하는 방식과 어노테이션을 통해 프레임워크의 선언적 Transaction을 활용하는 방법을 도식화하여 그린 것입니다. 선언적 Transaction을 사용하는 경우 특별히 코드에 Transaction 코드를 기입할 필요가 없기 때문에 코드가 간결해지며, Biz 로직에만 집중할 수가 있습니다.

 

 

Data Access 층의 Architecture 고려 사항

Hexagonal Architecture가 적용되었기 때문에 Data Access 층은 어떤 저장소가 오더라도 Business Logic 층에 영향을 적게 받도록 하는 것이 중요합니다. 그리고 데이터를 처리하는 메커니즘을 검토해야 합니다. 두 가지 기술 메커니즘이 고려됩니다.

하나는 OR Mapping이고, 하나는 SQL Mapping 방식입니다. 국내에서는 Mybatis 프레임워크를 활용한 SQL Mapping 방식이 많이 쓰였지만, 해외에서는 Spring이나 Spring JPA, 하이버네이트 기술을 활용한 OR Mapping 방식이 많이 쓰입니다.

SQL Mapping은 데이터 모델링을 통해 관계형 테이블을 먼저 작성한 후 Business Logic을 처리할 때 유용하며, Business Logic 층에 Transaction Script 패턴을 적용했을 경우 적합한 방식입니다. OR Mapping은 데이터 저장소를 먼저 고려하지 않고 Business Logic에 필요한 Object가 무엇인지를 먼저 고려하여 비즈니스를 처리하는 흐름을 구현한 뒤 나중에 저장소를 결정하고 Object에 Mapping하여 데이터를 처리합니다.

따라서 객체지향 중심으로 Domain Model의 Entity를 추출, 그 Entity를 바탕으로 나중에 테이블을 작성하게 됩니다. SQL Mapping 방식은 개발자가 직접 SQL을 작성하기 때문에 Query Tuning 등 세밀한 SQL 컨트롤이 필요한 경우에 유용하며, OR Mapping 방식을 사용하는 경우 OR Mapper가 SQL문을 자동으로 생성해주기 때문에 코드 량이 줄고 저장소를 다른 관계형 데이터베이스나 NO-SQL 저장소로 쉽게 변경할 때 유용하게 됩니다.

일반적으로 Business Logic 층이 Transaction Script 구조로 설계된 경우 SQL Mapper를 선택하고, 데이터 모델링을 먼저 수행하는 방식으로 진행을 하고 Business Logic 층이 Domain Model 구조로 설계된 경우에는 OR Mapper를 선택하고 도메인 객체 모델링을 먼저 수행하는 방식으로 진행하게 됩니다.

어떠한 메커니즘을 선택하느냐는 제공할 비즈니스 성격 및 팀원의 역량, 경험, 개발 효율성 등이 고려되어 선택되어야 합니다. 그리고 어떠한 방식이 선택되어도 Data Access 층에서는 Hexagonal이 추구하는 저장소나 RDB가 바뀌어도 Biz 로직에 영향을 미치지 않는 방향으로 메커니즘을 설계해야 합니다. 특히 직접 SQL문을 기술하는 방식인 SQL Mapper에서는 특정 RDB에 의존하는 SQL문을 기술하지 않도록 주의할 필요가 있습니다.