마이크로 프론트엔드(MF) 1. 배경 지식 및 개념 정리

주제
모놀리틱 아키텍처의 개념과 문제점
msa의 개념
마이크로프론트엔드(MFA)

 

회사 업무 중 마이크로 프론트 아키텍처(MFA)에 대해 알게 되었고
프론트엔드 개발 공부에 도움이 될 것 같아 간단하게 정리해보았다.

아키텍처에 전혀 문외한인지라
배경이 될만한 개념들부터 하나씩 살펴가겠다.

 

 

프로젝트 구조: monolithic 아키텍처부터 MSA의 등장

---

MSA는 백엔드에서 사용되는 아키텍처이나, 모놀리틱 아키텍처의 문제점을 극복하기 위해 사용된다는 점에서 알아볼 필요가 있다.

 

monolithic 아키텍처

1) 개념

의존성, 프레임워크	공통
개발	같은 프로젝트 내 모듈별 분리
패키징 & 빌드	전체 패키징 & 전체 빌드

 

모놀리틱 아키텍처란, 여러 서비스를 하나의 프로젝트 아래에 위치시키며 개발 및 운영을 하는 방식이다.

예컨대, 웹툰을 볼 수 있는 사이트가 있다면, 로그인 서비스, 웹툰 리스트 열람 서비스, 웹툰 보기, 결제, 이벤트 등의 하위 서비스를 하나의 프로젝트 아래에서 개발하는 방식이다.

그러므로 모든 서비스가 해당 프로젝트의 의존성 명세서에 있는 의존성에 따라야 하며 공통의 프레임워크 제한을 가지게 된다.

패키징 역시 전체 프로젝트 단위로 패키징 및 빌드가 이뤄지며, 개별 모듈 단위로 패키징을 할 수 없다.

주의사항

모놀리틱 아키텍처는 개발 코드가 담긴 프로젝트가 단일하다는 의미일 뿐, 
단일 레포 형상 관리(모노 레포)나 단일 서버와는 별개의 개념이니 헷갈리지 말자.

참고로, 서버 운영은 트래픽 분산과 지속적 운영을 위해 was 팜(여러 was를 운영) + 로드 벨런서의 조합이 일반적이다.

 

2) 문제

모놀리틱 아키텍처는 하나의 프로젝트 내 모듈별 분리 구조라는 점에서 가장 직관적이고 단순한 형태이다. 따라서 개발 난이도가 상대적으로 낮고 빠르게 개발이 가능하다는 장점이 있다.

하지만, 장기적인 서비스 확장성과 수정, 측면에서 아래 단점이 존재한다.

 

• 개발
  • 모듈마다 별개의 의존성 설정이 불가능하며, 하나의 프레임워크 및 언어로 제한된다. 예컨대, 자바의 스프링과 파이썬의 장고, 자바스크립트의 nodeJS를 함께 사용할 수 없다.
  • 아무리 모듈 단위로 분리를 했어도 공통 모듈과 서비스 모듈 간 완벽한 분리가 보장되지 않으므로 공통 모듈 변경 시 부작용의 예측이 어렵다.
• 배포 및 운영
  • 프로젝트 내 작은 서비스만 변경되어도 전체가 재배포를 해야하므로 시간이 많이 소모된다.

서비스 일부의 장애나 트래픽 부하 시, 다른 서비스 모듈에도 영향이 간다.이런 문제점 때문에 각 서비스를 분리 개발 및 배포 운영할 필요성이 생겨났고, 이 수요는 MSA와 SOA 구조가 확산되는 데 영향을 끼친 걸로 추정된다.

여기선 MSA만 살펴보자,

 

MSA(마이크로 서비스 아키텍처)

1) 개념

의존성, 프레임워크	서비스 별로 별도 선택 가능
개발	서비스 단위 개별 프로젝트 개발
패키징 & 빌드	독립적인 패키징 및 빌드, 운영
서비스 간 통신	REST API 등 네트워크 기반의 경량화된  프로토콜
운영	서비스별로 별도의 WAS을 갖춘 클라우드 서버, 분산 컴퓨팅 인프라에 적합

MSA는 프로젝트 내 여러 서비스를 별도의 하위 서비스 프로젝트로 개발, 배포, 운영을 하는 방식이다.

예컨대, 웹툰 사이트가 있다면, 로그인 서비스, 웹툰 리스트 열람 서비스, 웹툰 보기, 결제, 이벤트 등의 기능을 별도의 서비스로서 따로 별도로 개발하고 서로 분리된 서버에서 운영한다.

거의 별도의 프로그램처럼 개발된 상황에서 서비스 간 상태 공유를 위해 경량화된 REST API 같은 프로토콜을 사용한다.

SOA와의 차이
이처럼 서비스 단위의 분리 개발 방식으로 "서비스 지향 아키텍처", 즉 SOA가 있는데, 
프론트엔드 입문 수준의 지식으로는 잘 이해가 되지 않았다.

그래서 SOA는 중앙 집중식 메타 데이터 관리 라는 것을 통해 각 서비스 간 좀 더 결합되어 있는 방식인 반면, MSA는 각 서비스가 더 독립된 구조라는 차이점이 있다는 정도로만 알고 있으려 한다.

 

2) 장단점

• 개발
  
  • 서비스마다 별도의 의존성 및 프레임워크을 가질 수 있다.
  • 다른 서비스와 독립적으로 패키징 및 배포가 가능하므로 시간을 단축시킬 수 있다.
  • 서비스별로 분리되어 있어 통합 테스트가 어렵다
• 운영 및 배포
  • 각 서비스가 독립적으로 운영되므로 한 서비스의 에러가 다른 부분으로 전파되는 부분이 예상하기 쉽다.
  • 내부 통신 시스템 설정이 복잡하고, 서비스간 네트워크 통신 비용 및 시간 소모가 발생한다.

클라우드 서버를 이용할 수 없는 on-promise 서버, 내부망 통신, 폐쇄형 운영에는 모놀리틱 아키텍처가 더 적합한 경우도 있다.

 

정리

• 모놀리틱 아키텍처는 단일한 프로젝트 소스코드 및 패키징을 사용하며, MSA는 서비스 단위로 소스코드 및 패키징을 완전 분리한다.
• 운영단에서 MSA는 각 서비스를 별도의 서버단에 배포한다.
• 모놀리틱 아키텍처는 설정이 간단하고 직관적이지만, 서비스 규모가 확장될수록 배포 및 빌드 시간이 낭비된다.
• MSA는 개발 과정 내 모듈 간 독립성, 배포 및 빌드 시간 감소 등에서 개발 유지 보수 개선을 할 수 있다. 하지만, 설정이 복잡하고, 서비스간 네트워크 비용이 발생한다.
• 따라서, MSA는 확장성의 측면에서 대규모 프로젝트를 개발할 때 모놀리틱 아키텍처의 문제를 해결할 수 있다.

 

마이크로 프론트엔드: 개념

---

MSA륾 모놀리식 백엔드 아키텍처의 대안으로 볼 수 있듯이, MFA(마이크로프론트엔드)도 모놀리식 프론트엔드의 대안으로 이해하며 접근해보자.

 

모놀리식 프론트엔드

의존성, 프레임워크	공통
개발	같은 프로젝트 내 모듈별 분리
패키징 & 빌드	전체 패키징 & 전체 빌드

앞서 본 모놀리식 아키텍처의 문제는 프론트엔드에서도 동일하게 적용된다.

단순한 구조 덕분에 초기 개발 속도는 빠르지만, 규모가 커질수록, 구조 상 모듈 간 완벽한 분리의 어려움, 빌드 및 배포 시간 낭비 문제가 발생한다.

 

 

페이지 분할 프론트엔드

의존성, 프레임워크	별도
개발	별도의 프로젝트로 서비스 단위로 분리 개발
패키징 & 빌드	서비스 단위로 패키징 및 빌드
운영	URL 라우팅에 따라 서버에서 각 서비스 프론트엔드로 전환하는 방식

페이지 분할 프론트엔드는 각 서비스를 서로 분리된 앱으로 개발하고 라우팅에 따라 호출하는 방식이다.

즉, 웹툰 사이트라면, 로그인 서비스를 위해 로그인 라우트로 접근하면 해당 프론트엔드 앱이 열리고, 결제 서비스를 이용하려면 해당 라우트로 접근하여 다른 프론트엔드 앱을 로드하는 방식이다.

 

이렇게 보면, MSA와 유사한 구조이나, 가장 큰 차이점은 공통 모듈의 처리방식에 있다.

현대의 프론트엔드 앱 개발은 SPA로서, 각 서비스가 별개의 리소스 파일(html, css, js, 이미지 등 자원)로 분리된 대신, 하나의 프로그램처럼 공통 컨테이너 모듈 아래에서 돌아가는 걸 지향한다.

하지만, 페이지 분할 프론트엔드는 라우팅을 이용하여 리소스 파일을 새로 받아야 하므로, 공통 모듈 역시 새로 받아야 하는 문제가 있다.

따라서 각 서비스 앱은 빌드 단계에서 컨테이너 앱 역할을 하는 공통 모듈을 함께 가지고 있어야 하니, 용량이 증가하며 만약 공통 모듈에 문제가 있을 경우 서비스 코드에도 문제가 생길 수 있다.

이는 유저 관점에서는 하나의 앱을 사용하는 게 아니라, 매번 새로운 로딩창을 봐야함으로써 마치 옛날의 정적 웹을 보는 듯한 부드럽지 못한 경험을 줄 수 있다.

 

마이크로 프론트엔드

의존성, 프레임워크	별도
개발	별도의 프로젝트로 서비스 단위로 분리 개발
패키징 & 빌드	서비스 단위로 패키징 및 빌드
운영	런타임에 각 모듈을 불러와 통합하는 방식 (호스트 앱이 리모트 앱을 호출)

마이크로프론트엔드는 모놀리틱 프론트엔드와 페이지 분할 프론트엔드의 대안으로서 바라볼 수 있다.

페이지 분할 프론트엔드처럼 각 서비스 단위로 앱을 구성하되, 라우팅에 따라 리소스를 완전히 새로 부르지 않는다.

대신, js파일만을 추가로 불러와 기존의 컨테이너 사이트 내에서 새로운 서비스 컴포넌트를 생성하는 방식이다.

 

아마 이 얘기를 들으면, react-router-dom(RRD)이나 코드 스프릿팅(react의 lazy loading) 떠오를지 모른다. 이들은 목적이나 작동원리에서 유사성이 존재하긴 한다. 거대한 코드를 분할이기 때문이다.

 

하지만, RRD와 코드 스플릿팅은 한 프로젝트 내에 있는 코드를 분할하여 런타임 후 특정 시점(URL, 이벤트 등)에 불러오는 데 반해, MFA는 개발 단계에서부터 별도의 프로젝트로 개발된 앱을 컨테이너 역할의 앱에 런타임에 통합시킨다.

 

중간 정리

• 개발 및 빌드 시점에 하나의 패키지로 통합되는 모놀리틱과 다르게, MFA는 런타임 시점에 통합
• 페이지 분할 방식은 URL에 따라 완전히 별개의 서비스 앱을 호출하는 반면, MFA는 공통 모듈을 가진 호스트 앱 내에서 각 서비스 모듈의 리모트 앱을 호출하고 통합하는 방식

 

장단점

• 공통 모듈을 각 서비스가 중복으로 가지고 있을 필요가 없다.
• 호스트 앱 아래에 리모트 앱을 호출하는 방식은 컴포넌트 단위 개발과 유사성을 가진다.
• 페이지 분할에 비해 공통 모듈과 서비스 기능 간에 상태를 공유하기가 편리하다.

 

참고자료(마이크로 프론트엔드의 개념, webpack 기반의 도입)

---

https://velog.io/@kylexid/%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%ED%94%84%EB%A1%A0%ED%8A%B8%EC%97%94%EB%93%9C-%EC%95%84%ED%82%A4%ED%85%8D%EC%B3%90

마이크로프론트엔드 아키텍쳐

 

https://www.lgcns.com/blog/cns-tech/cloud/50598/

개발자의 업무 효율을 높여주는 새로운 아키텍처! 마이크로 프론트엔드 A to Z - LG CNS

 

https://www.kimcoder.io/blog/micro-frontend-module-federation

Home

 

https://maxkim-j.github.io/posts/module-federation-concepts/

Module Federation의 컨셉과 작동 원리 이해하기

 

https://blog.gangnamunni.com/post/saas-microfrontends/

[SaaS] Micro Frontends를 위해 Module Federation 적용하기

 

https://s-core.co.kr/insight/view/webpack5-module-federation-%EC%86%8C%EA%B0%9C/

에스코어

 

https://isa-dev.tistory.com/256

[프론트엔드] 코드 스플릿에 대한 정리