micro-frontend 아키텍쳐에 대해서 설명해주세요.
해당 개념을 실무에 도입해본 경험이 있나요? 있다면 장점, 단점, 어려웠던점, 해결방안에 대해서 설명해주세요.
MicroService Architecture(MSA) 란?
-
작은 서비스 여러개가 모여 하나의 시스템을 제공하는 것
-> 데이터 단위로 작게 나누어 작은 문제를 하나씩 해결하는 것 -
작고 독립적이며 느슨하게 결합되어있음
-> 때문에 서비스들을 독립적으로 배포 할 수 있다 -
기존 서비스 아키텍쳐인
Monolithic ArchitecturePermalink의 단점을 보완하고자 나온 여러 아키텍쳐 중 하나 -
클라우드환경에 친화적이다
-> 사용량이 적은 모듈을 삭제한다고 하더라도 전체 시스템의 스펙은 변하지 않기 때문에 사용량단위로 과금을 해야하는 cloud환경에서는 비효율적이다.
-> 하지만 MicroService구조는 서비스단위로 기능을 분리해서 구축할 수 있기 때문에, 사용하지 않는 기능 또는 사용량이 적은 기능을 축소해서 효율화시킬 수 있다.
장점
- 어플리케이션의 확장이 용이하고 개발 속도를 앞당길 수 있다.
- 전체프로그램을 다시 배포하지 않고도 업데이트가 가능하다.
- 독립적인 개발 가능
- 일부 서비스가 다운 되더라도 전체 서비스에 영향을 끼치지 않음
- 서비스를 독립적으로 확장 가능하고, 리소스의 유연한 운용이 가능하다.
단점
- 서비스간 통신방법이 필요하고 복잡함
- 서비스끼리 테스트가 어렵다
- 복잡하고 독립된 구조로 통합적인 유지관리가 어렵다
마이크로프론트엔드 란?
- 대규모 서비스를 개발할 때 용이하다
- 마이크로 서비스처럼 전체 화면을 작동할 수 있는 단위로 나누어 개발한 후 서로 조립하는 방식
- 개별적으로 개발/테스트/배포 할 수 있는 작고 간단한 서비스 단위로 개발하는 패턴
장점
- 분리배포가 가능하다
-> 전 범위 배포가 아닌, 변경된 부분 배포라 이슈가 생길확율이 줄어듬 - 프론트엔드 개발의 점진적 업그레이드 / 재작성 / 리팩토링이 수월해 진다.
-> 쪼개진 단위로 각자 업그레이드 할 수 있음
-> 재사용으로 인한 개발시간 단축 - 심플하고 유지보수가 용이한 코드베이스를 갖는다
- CI/CD가 쉬워진다.
단점
- 개발 환경의 차이로 인한 복잡도가 상승한다
- 작은 단위로 각각 나눠져있기 때문에 운영 / 관리가 복잡함
- 여러 서비스를 하나로 묶기에 복잡성 증가, 퍼포먼스 오버헤드 발생 가능하다
우리 회사의 웹프론트코드는 view단위로 설계되어있다.
또한 view와 viewModel이 1:1관계이다보니 view의 일부를 재사용하고싶어도 필요없는 api 콜이 많아지고 무거워지는 것이였다.
그래서 재사용성이 많겠다 판단되는 기능(서비스)들을 서비스컴퍼넌트로 분리하기로했다
분리될 서비스가 크게 tax관련 서비스이기에 tax-invoice > view 폴더에 동일 선상으로 page 와 components를 분리 했다.
components는 tax와 관련된 서비스컴퍼넌트로, 분리된 하나의 서비스 기능이다.
그렇기에 해당 기능별로 viewmodel이 존재하고, 사용자는 필요한 곳에 해당 파일만 import해서 사용하면 된다.
동일한 기능, 서비스를 다른 곳에서 사용해야할 일이 생겼는데 해당 기능을 재사용하니 개발시간이 절반이상 줄었다.
디자인패턴도 적용되어있던 서비스여서 더이상 손볼 곳이 1도 없었다.
근데 사실 완벽한 마이크로프론트엔드라고 하기엔,, 어색한 부분이 많아보인다.
