마이크로서비스 UI - 마이크로프론트엔드

마이크로서비스 아키텍처의 모습은 현재까지 데이터 처리 단위를 최소로 나누어 처리하는데 집중하는 모습입니다. 하지만 궁극의 마이크로서비스 아키텍처가 지향하는 모습은 데이터 처리 뿐만 아니라 web page와 같은 웹사이트 전체를 담아낼 수 있는 아키텍처를 지향합니다.

 일반적인 웹 페이지 기반의 서비스를 마이크로 서비스 아키텍처로 적용하여 구축 시 현실적인 어려움점이 많습니다..

Data layer에 대한 부분은 데이터 종류, 비즈니스 도메인, 또는 사용기술에 따라 분리하고 별도의 작은 서비스 단위로 설계하고 구현하는 것은 UI에 비하여 비교적 용이합니다. 그러나 Web frontend 부분은 세부적으로 나누는 기준이 애매모호합니다.

이번 아티클에서는 마이크로 프론트엔드 (Micro frontend) 라는 이름으로 웹 프론트단 부분을 마이크로서비스 아키텍처에 맞추어 어떻게 구조적으로 나누면 좋고, 구현시 어떠한 방법들이 있는지 소개하려고 합니다.

우선 사이트의 구성요소를 분리하는 방법은 크게 수평적 구조 및 수직적 구조로 나눌 수 있습니다.


수평적 구조


각 화면요소는 헤더, 본문, 배너, 기타 다양한 정보의 조합을 볼 수 있습니다.

이러한 여러 요소를 하나의 페이지에 조합하여 보여줄 수 있는데 각각의 요소를 하나의 작은 frontend 요소로 나눌 수 있습니다. 

아래 화면의 Facebook 페이지로 각각의 요소가 별도의 서비스로 동작되며 페이지에서 결합되어 보여지는 예시입니다.

수직적 구조

수직적인 분리는 대(1 depth) 메뉴별 또는 컨텐트 디렉토리별 분리로 별도 개발하여 조합하는 방식인데, 이러한 방식은 이미 모노리틱 웹개발에서도 대규모 사이트 개발시 사용되는 방법입니다.

Java Web Application J2EE 기분으로 보면 하나의 큰 메뉴는 context 개별으로 별도의 war로 개발하고 하나의 ear 로 통합하여 개발 배포하는 방식입니다.

문제는 이러한 방식도 결국 하나의 거대한 ear 배포 방식으로 시스템 산출물이 생성되어 관리 및 빠른 주기의 개발이 용이하지 않습니다. 그리고 일반 기업에서 자주 사용되는 war 단위의 사이트 배포 단위가 매우 크다는 문제점을 가지고 있습니다.

결과적으로는 수평적 구조 및 수직적 구조를 동시에 고려하여 하나의 작은 단위로 UI 단을 개발한 후 조합하는 방식이 가장 이상적입니다.이러한 microfrontend 구축시 고려 되어야할 기술이 크게 2가지 있습니다.

바로 선택적으로 UI컨테이너를 선택해 줄 수 있는 router 와  각각의 UI 서비스를 조합해 줄 수 있는 통합 layout 서비스 기술입니다.

이러한 기술을 이용하 opensource 기술을 바탕으로 마이크로서비스 아키텍처 사상의 frontend 를 구축하기 위한 Project Mosaic (https://www.mosaic9.org/)이 있습니다.

아직은 여러 오픈소스 기술을 조합하고 안내하는 수준에 머물러 있는 프로젝트이지만, microfrontend 구축을 고려하는 경우 참고해 볼만한 사이트 입니다.


Layout Service


우선 이 기술에 대해 설명하기 전에 Facebook의 화면 구성에 대해 간략히 설명하겠습니다.

아래 페이지는 Facebook화면으로 각각의 구성요소가 Pagelet 이라는 기술을 통해 별도의 서버스로 개발되어 각각 별도의 서버에서 동작되는 기본 UI 구성요소 입니다.

각각의 요소를 합치는 경우는 일반적으로 생각할 수 있는 방법이 3가지 있습니다.


1) IFrame

 - 각 요소 부분을 IFrame으로 구분하고 해당 요소마다 별도의 URL을 호출하여 화면조합을 하는 형태입니다.

장점

 - 구조가 단순하여 만들기 용이하다.

단점

 - 웹접근성 문제 및  검색엔진의 크롤링 문제가 있을 수 있다.

 - 각 iframe요소가 외부에서 손쉽게 호출될 수 있어 보안상 악용될 수 있다.



2)  frontend 비동기 호출 - AJAX

일반적으로 ajax 호출을 통해 해당 요소의 데이터 또는 렌더링된 HTML을 가져와서 조합하는 방식입니다.

장점

 - SPA(Single Page Application)에 결합되어 frontend 의 개발이 간결해 질 수 있다.

단점

 - 모든 상황에 맞는 외부 API 를 제공해야 한다.

 - 필요한 데이터도 모두 fetch 하여 사용자에게 데이터 부하를 줄 수 있다.

 -  각 API 마다 외부 노출에 대한 API보안을 신경 써야 한다.


3) Server side include

JSP인 경우 include 하는 방식으로 내부의 pagelet 요소를 호출하여 렌더링된 html 요소를 include 하는 방식입니다. 

장점

이미 렌더링된 HTML UI 요소만을 가져와서 Client 의 통신량이 적다.

사용되는 페이지마다 렌더링된 HTML 을 넘겨주기 때문에 통합관리가 용이

주요 UI 요소는 내부 네트워크 보안 처리를 통해 별도의 API auth_key 나 별도의 인증과정없이 처리가 가능하다.

단점

일반적인 include 방식으로 사용하면 순차처리 방식으로 호출 갯수가 많아지면 많아질 수도 성능이 저하된다.


위의 다양한 방법들이 있지만 이러한 문제점을 해결하고자 Faceook에서는 비동기 layout 조합이 가능한 BigPipe 라는 페이지 조합 기술을 개발하였고 아래 URL을 통해 소개하고 있습니다.

https://www.facebook.com/notes/facebook-engineering/bigpipe-pipelining-web-pages-for-high-performance/389414033919/

위의 성능결과 같이 기존 일반방식보다 빠른 응답속도를 보이고 있습니다.


결론적으로는 비동기식 server side UI 조합 및 AJAX 를 통한 API 호출을 적절이 혼합해서 사용하는 것이 가장 이상적으로 보입니다.

비동기식 서버사이드 include 의 시초는 Facebook의 bigpipe에서 유래가 되었고 앞서 설명들인 Project Mosaic 에서는 tailor (https://github.com/zalando/tailor) 로 소개되고 있습니다.

Tailor는 Node JS 기반이기 때문에 java 환경에서 이런 유사 기능을 사용하고자 하는 경우는 BigPipe Java (https://github.com/crazysoftwarecoder/bigpipe) 가 있습니다.

위와 같은 방식으로 layout 조합 모듈을 사용한다면 병렬로 다양한 UI 모듈을 조합하며 관리의 편이성을 높일 수 있습니다.

마이크로 프론트엔드 관련되서 다음에는 ROUTE 기술 및 docker container 기술을 이용한 서비스 분리에 대해 계속 연재하도록 하겠습니다.


관련 Link

  • https://micro-frontends.org/
  • https://allegro.tech/2016/03/Managing-Frontend-in-the-microservices-architecture.html
  • https://www.mosaic9.org/

'프론트엔드' 카테고리의 다른 글

디자인 구현을 위한 원칙  (0) 2017.11.02
underscore 알아보기 (3)  (0) 2017.10.10
마이크로서비스 UI - 마이크로프론트엔드  (0) 2017.09.14
underscore 알아보기 (2)  (0) 2017.09.07
underscore 알아보기 (1)  (0) 2017.07.19
!# 해쉬뱅 알아보기  (0) 2017.05.29

New Multi-Channel Dynamic CMS