1,328 판독값

마이크로 프런트엔드 마이그레이션 여정 - 1부: 설계

~에 의해 Ildar Sharafeev13m2023/07/12

너무 오래; 읽다

마이크로 프런트엔드 아키텍처로 마이그레이션하려면 조직 구조 및 운영 기반 측면에서 상당한 투자가 필요했습니다. 대신 지연 로딩(동적 가져오기)을 활용하는 분산형 모놀리스 아키텍처로 시작하는 것이 더 나을 것입니다. 코드 베이스를 여러 팀이 관리하는 여러 소유권 영역으로 분할하는 것이 필수적입니다.

featured image - 마이크로 프런트엔드 마이그레이션 여정 - 1부: 설계

민첩성과 확장성이 중요한 오늘날의 빠르게 변화하는 디지털 세계에서 기업은 웹 애플리케이션의 성능과 유지 관리성을 향상시킬 수 있는 방법을 끊임없이 모색하고 있습니다.

이러한 목표를 달성하기 위한 인기 있는 접근 방식 중 하나는 모놀리식 아키텍처에서 분산 아키텍처(또는 마이크로 프런트엔드)로 마이그레이션하는 것입니다. 이 기사 시리즈 "마이크로 프런트엔드 마이그레이션 여정"에서는 AWS에 근무하는 동안 이러한 마이그레이션을 수행한 개인적인 경험을 공유합니다.

면책조항 : 시작하기 전에 이 기사에서는 개인적인 경험을 공유하고 있지만 AWS나 다른 조직의 도구, 기술 또는 특정 프로세스에 대한 독점 또는 내부 세부 정보를 공개할 수 없다는 점을 알아 두는 것이 중요합니다.

나는 법적 의무를 존중하고 이 기사가 마이크로 프런트엔드 마이그레이션 여정과 관련된 일반적인 개념과 전략에만 초점을 맞추도록 최선을 다하고 있습니다.

그 목적은 기밀 정보를 공개하지 않고 더 넓은 맥락에 적용할 수 있는 통찰력과 교훈을 제공하는 것입니다.

이주 동기

나는 Martin Fowler의 블로그 기사 에서 마이크로 프론트엔드에 대해 배웠습니다. 이는 프레임워크에 구애받지 않는 방식으로 마이크로 프런트엔드 아키텍처를 구성하는 다양한 방법을 제시했습니다.

주제를 더 깊이 파고들면서 기존의 모놀리식 아키텍처가 팀의 생산성에 심각한 병목 현상을 일으키고 애플리케이션의 전반적인 성능을 방해하고 있다는 것을 깨달았습니다.

제가 마이그레이션을 고려하게 된 주요 요인 중 하나는 애플리케이션의 번들 크기가 증가했다는 것입니다.

2020년 여름에 철저한 번들 분석을 수행한 결과, 2019년 초 처음 출시된 이후 번들 크기(gzipped)가 450KB에서 800KB(파싱된 경우 거의 4MB)로 증가하여 원래 크기의 거의 두 배에 달하는 것을 발견했습니다.

우리 서비스의 성공과 지속적인 성장 예측을 고려하면 이러한 추세가 지속되어 애플리케이션의 성능과 유지 관리 가능성에 더욱 영향을 미칠 것이 분명했습니다.

저는 마이크로 프론트엔드의 개념에 열광했지만, 우리가 직면한 특정 문제로 인해 아직 이를 채택할 준비가 되지 않았다는 점도 인식했습니다.

소규모 조직 구조: 제가 분석할 당시 우리 조직은 상대적으로 규모가 작았고, 저는 팀에서 유일한 풀타임 프론트엔드 엔지니어였습니다. 마이크로 프런트엔드 아키텍처로 마이그레이션하려면 조직 구조 및 운영 기반 측면에서 상당한 투자가 필요했습니다.

분산 아키텍처를 효과적으로 처리하고 다양한 프런트엔드 구성 요소 간의 종속성을 반영할 수 있는 성숙한 구조를 갖는 것이 중요했습니다.
제한된 비즈니스 도메인: 마이크로 프런트엔드는 제한된 컨텍스트와 비즈니스 기능을 기반으로 분할될 수 있지만(" 마이크로 프런트엔드 아키텍처의 도메인 중심 설계" 게시물에서 자세히 알아보기) 우리의 핵심 비즈니스 도메인은 완전한 분리를 정당화할 만큼 충분히 광범위하지 않았습니다. 여러 마이크로 프런트엔드. 그러나 분산 아키텍처를 개척하고 전환하는 데 적합한 애플리케이션 내에는 눈에 띄는 경계가 있었습니다.

이러한 점을 고려하여 점진적인 접근이 필요하다는 것을 깨달았습니다. 마이크로 프런트엔드로 완전히 마이그레이션하는 대신 분산 아키텍처의 이점을 누릴 수 있는 애플리케이션 내 특정 영역을 식별하는 것이 목표였습니다.

이를 통해 전반적인 조직 구조를 방해하거나 비즈니스 영역의 무결성을 손상시키지 않으면서 성능 및 확장성 문제를 해결할 수 있습니다. 또한 팀을 성장시키고 비즈니스 방향을 관찰할 시간도 갖게 될 것입니다.

mciro-frontend 아키텍처를 통해서만 앱의 성능(번들 크기) 문제를 해결하려는 경우 이것이 최선의 방법이 아닐 수도 있습니다. 대신 지연 로딩(동적 가져오기)을 활용하는 분산형 단일체 아키텍처로 시작하는 것이 더 나을 것입니다.

게다가 마이크로 프런트엔드 아키텍처는 공급업체 청크로 분리되지 않은 일부 공유 코드를 가질 가능성이 매우 높으며 애플리케이션 번들에 내장된다는 점을 고려하면 마이크로 프런트엔드 아키텍처보다 번들 크기 문제를 더 우아하게 처리할 것이라고 생각합니다( 이는 분산 아키텍처의 단점 중 하나입니다. 무엇을 공유할지, 언제, 어떻게 공유할지 균형을 맞춰야 합니다.

그러나 분산형 모놀리스 아키텍처는 마이크로 프런트엔드만큼 확장되지 않습니다. 조직이 빠르게 성장하면 팀도 같은 속도로 성장할 가능성이 높습니다.

코드 베이스를 여러 팀이 제어하는 여러 소유권 영역으로 분할하는 것이 필수적입니다.

그리고 각 팀은 다른 팀과 독립적인 자체 릴리스 주기를 가져야 하며, 각 팀은 코드 베이스가 해당 도메인에만 집중되어 있는지 감사하게 생각하고 빠르게 구축할 것입니다(코드 격리 -> 유지 관리 용이성 향상/유지 관리할 코드 감소 및 빌드 -> 더 나은 테스트 가능성/유지 관리 및 실행에 필요한 테스트 감소).

시작

리더십의 지원을 얻기 위해 웹 바이탈 지표를 포함한 포괄적인 성능 분석을 포함하고 분산 프런트엔드로의 마이그레이션의 다양한 단계를 설명하는 설득력 있는 기술 비전 문서를 작성했습니다.

이 마이그레이션의 중간 단계 중 하나는 핵심 서비스와 위젯 간에 S3 버킷 및 CDN과 같은 공유 인프라를 활용하면서 지연 로딩 기술을 통해 여러 모듈/위젯이 비동기적으로 제공될 수 있는 분산형 모놀리스 아키텍처를 구축하는 것이었습니다. .

이전 기사 에서 간략히 설명했듯이 이러한 유형의 문서의 주요 아이디어는 목표가 달성되고 가장 큰 문제가 해결된 후 원하는 대로 미래를 설명하는 것입니다. 실행 계획에 관한 것이 아닙니다!

거의 1년 후, 마침내 마이크로 프론트엔드 마이그레이션 계획을 실행에 옮길 때가 왔습니다. 새로운 도메인으로의 확장이 임박하고 더 큰 팀을 보유하게 되면서 우리는 마이그레이션을 실행할 준비가 잘 되었습니다.

놓칠 수 없는 절호의 기회처럼 느껴졌습니다.

결국 모놀리식 아키텍처에 계속 갇혀 있다는 것은 그 한계와 끊임없이 씨름하는 것을 의미합니다.

새로운 영역으로 확장하기 위한 제한된 일정이 촉매제 역할을 하여 짧고 느린 반복을 수행하는 대신 더 확장 가능하고 유지 관리가 가능한 아키텍처를 즉시 구축할 수 있게 되었습니다!

마이그레이션을 실행하고 동시에 새 도메인의 작업을 처리하기 위해 팀을 두 개의 전담 그룹으로 나누었습니다. 우선순위가 높은 기능 작업에는 더 많은 리소스가 필요하고 더 빠른 속도로 반복해야 했습니다.

마이그레이션 프로세스의 무결성과 포괄적인 이해를 보장하기 위해 마이그레이션 처리를 특별히 담당하는 소규모 전담 팀을 배정하는 것이 합리적이었습니다.

그러나 먼저 마이크로 프런트엔드 개념이 성공할 것이라는 보장 없이는 기능 작업을 진행할 수 없었습니다.

위험을 완화하고 명확한 로드맵을 제공하려면 정확한 추정치와 철저한 위험 평가가 포함된 낮은 수준의 설계 문서를 만드는 것이 중요했습니다. 이 문서는 마이그레이션에 필요한 단계와 고려 사항을 간략하게 설명하는 청사진 역할을 했습니다.

이 프로세스의 중추적인 이정표는 설계에 따른 모든 구성 요소의 성공적인 통합을 보여주는 개념 증명의 개발이었습니다.

"돌아갈 수 없는 지점"이라고 적절하게 명명된 이 이정표는 마이크로 프런트엔드 아키텍처의 타당성과 효율성을 검증하는 것을 목표로 했습니다.

저는 마이그레이션의 성공을 낙관했지만 만일의 사태에 대비하는 것도 필수적이었습니다. 그래서 초기 컨셉이 원하는 결과를 얻지 못할 경우를 대비해 백업 전략으로 작용하는 플랜 B를 고안했습니다.

여기에는 특히 제가 베개에 기대어 울도록 하기 위해 추정치에 7일을 추가로 할당하고 지연 로딩을 통해 새로운 기능 모듈 항목을 코어에 연결하기 위해 며칠을 할당하는 것이 포함되었습니다(분산된 모노리스를 기억하시나요?).

디자인

마이크로 프런트엔드를 디자인할 때 일반적으로 구성에 대한 3가지 접근 방식이 있으며, 각각은 런타임 앱 확인이 이루어지는 위치에 중점을 둡니다. 이러한 접근 방식의 장점은 상호 배타적이지 않고 필요에 따라 결합할 수 있다는 것입니다.

서버측 구성

기본 아이디어는 역방향 프록시 서버를 활용하여 페이지당 마이크로 프런트엔드 번들을 분할하고 경로 URL을 기반으로 하드 페이지 다시 로드를 수행하는 것입니다.

장점:

구현이 간단함

단점:

전역 상태는 마이크로 프런트엔드 앱 간에 동기화되지 않습니다. 우리는 클라이언트 측에서 장기간 실행되는 백그라운드 작업을 수행했기 때문에 이는 우리에게 있어서는 절대 안 되는 지점이었습니다.

이 작업의 "대기열" 스냅샷을 로컬 저장소에 유지하고 하드 다시 로드한 후 읽을 수 있다고 주장할 수도 있지만 보안상의 이유로 이를 구현할 수 없었습니다.

이는 전역 상태의 한 예일 뿐이지만 다음은 측면 탐색 패널 상태(확장/접기), 토스트 메시지 등의 모습을 보여주는 또 다른 예입니다.

마이크로 앱을 탐색할 때 강제 새로 고침은 고객 친화적이지 않습니다. 서비스 워커를 사용하여 공유 HTML을 캐시하는 방법이 있지만 유지 관리가 더욱 복잡해집니다.

인프라에 대한 추가 운영 및 유지 관리 비용: 각 마이크로 프런트엔드 앱에 대한 프록시 서버(CDN에서 직접 읽는 경우 피할 수 있음), 여러 페이지에서 재사용할 공통(공급업체) 종속성을 배포하기 위한 별도의 인프라 및 적절하게 브라우저에 의해 캐시됩니다.

엣지사이드 구성

마이크로 프런트엔드 구성에 대한 또 다른 접근 방식은 CDN과 같은 에지 레이어에서 마이크로 프런트엔드를 결합하는 에지 측 구성입니다. 예를 들어 Amazon CloudFront는 Lambda@Edge 통합을 지원하므로 공유 CDN을 사용하여 마이크로 프런트엔드 콘텐츠를 읽고 제공할 수 있습니다.

장점:

유지 관리할 인프라 부분 감소: 프록시 서버가 필요 없고 각 마이크로 앱마다 별도의 CDN이 필요하지 않습니다.

서버리스 기술을 사용한 사실상 무한한 확장

독립형 프록시 서버에 비해 대기 시간이 더 좋습니다.

단점:

콜드 스타트 시간이 문제가 될 수 있음

다중 지역(격리된) 인프라가 필요한 경우 Lambda@Edge는 모든 AWS 지역에서 지원되지 않습니다.

클라이언트 측 구성

클라이언트 측 구성은 서버 구현에서 분리된 클라이언트 측 마이크로 프런트엔드 오케스트레이션 기술을 활용하는 마이크로 프런트엔드 아키텍처에 대한 또 다른 접근 방식입니다.

이 아키텍처의 핵심 플레이어는 다음과 같은 책임을 맡은 컨테이너(셸) 애플리케이션입니다.

교차 문제 해결: 컨테이너 애플리케이션은 중앙 집중식 앱 레이아웃, 사이트 탐색, 바닥글 및 도움말 패널을 처리합니다. 교차 편집 문제가 있는 마이크로 프런트엔드와의 통합은 이벤트 버스를 통해 이루어지며, 여기서 합성 이벤트는 전역 창 범위 내에서 전송되고 처리됩니다.

마이크로 프런트엔드 오케스트레이션: 컨테이너 앱은 로드할 마이크로 프런트엔드 번들과 애플리케이션 요구 사항 및 사용자 상호 작용을 기반으로 시기를 결정합니다.

전역 종속성 구성: 컨테이너 앱은 React, SDK 및 UI 라이브러리와 같은 모든 전역 종속성을 구성하고 이를 마이크로 프런트엔드 간에 공유할 수 있는 별도의 번들(vendor.js)로 노출합니다.

일반적인 아이디어는 각 마이크로 프런트엔드 번들이 두 가지 유형의 자산 파일을 생성한다는 것입니다.

{hash}/index.js: 이는 마이크로 프런트엔드 애플리케이션의 진입점 역할을 하며 해시는 전체 빌드의 고유 식별자를 나타냅니다.

해시는 S3 버킷의 각 번들에 대한 접두사 키 역할을 합니다. 여러 진입점이 존재할 수 있지만 해시는 모든 진입점에서 동일하게 유지된다는 점에 유의하는 것이 중요합니다.

매니페스트.json: 마이크로 프런트엔드 애플리케이션의 모든 진입점에 대한 경로가 포함된 매니페스트 파일입니다. 이 파일은 항상 S3 버킷의 루트에 남아 있으므로 컨테이너가 쉽게 찾을 수 있습니다.

변경 사항을 더 잘 관찰할 수 있도록 S3 버킷에서 이 파일의 버전 관리를 활성화하는 것이 좋습니다. Webpack을 사용하여 프로젝트를 빌드하는 경우 모든 어려운 작업을 수행하는 WebpackManifestPlugin을 적극 권장합니다.

컨테이너는 단계와 지역을 기반으로 마이크로 프런트엔드 자산 소스 도메인 URL(CDN 원본)만 인식합니다. 초기 페이지 로드 중에 컨테이너는 각 마이크로 프런트엔드 애플리케이션에 대한 매니페스트 파일을 다운로드합니다.

매니페스트 파일은 페이지 로드 시간에 영향을 주지 않도록 크기가 작습니다(~100바이트). 하나의 컨테이너 내에 여러 마이크로 프런트엔드를 집계하는 경우에도 잘 확장됩니다. 공격적인 캐싱을 방지하려면 매니페스트 파일을 브라우저의 캐시 저장소에서 변경할 수 없는 것으로 간주하는 것이 중요합니다.

올바른 오케스트레이션 라이브러리를 선택하는 것은 이 구성에서 가장 큰 과제이며 다음 장에서 논의됩니다.

장점:

서버 구현에 구애받지 않음: 이 접근 방식은 특정 서버 요구 사항 없이 구현될 수 있으므로 사용되는 백엔드 기술에 유연성을 제공합니다. 위 그림처럼 서버가 없어도 가능합니다.

전역 상태 유지: 컨테이너(셸) 앱을 사용하면 마이크로 프런트엔드 간 전환 시 전역 상태를 유지할 수 있습니다. 이는 원활한 사용자 경험을 보장하고 전환 중에 컨텍스트 손실을 방지합니다.

분산형 접근 방식: 각 마이크로 프런트엔드는 자체 부트스트랩을 위해 브라우저에 전달할 데이터를 독립적으로 결정할 수 있습니다. 컨테이너 앱은 잘 정의된 계약을 따르므로 더 큰 자율성과 모듈성을 허용합니다.

간단한 로컬 설정: 개발 요구 사항에 따라 프로덕션 URL과 로컬 URL 간에 자산 소스를 쉽게 조정할 수 있습니다. 매니페스트 파일은 컨테이너 앱이 필요한 마이크로 프런트엔드를 검색하고 로드하는 데 도움이 됩니다. 개발자는 작업 중인 컨테이너와 특정 마이크로 프런트엔드만 실행하는 데 집중할 수 있습니다.

단점:

매니페스트 파일을 가져오기 위한 더 많은 네트워크 홉: 컨테이너가 각 마이크로 프런트엔드에 대한 매니페스트 파일을 검색해야 하므로 다른 구성 접근 방식에 비해 추가 네트워크 요청과 잠재적인 대기 시간이 있을 수 있습니다. 이는 초기 페이지 로드 시 모든 매니페스트를 미리 로드하거나 일부 사전 로드 기술을 도입하여 완화할 수 있습니다.

공통 계약 준수: 모든 마이크로 프런트엔드는 빌드 생성을 위한 공통 계약을 준수해야 합니다. 이는 마이크로 프런트엔드 전반에 걸쳐 일관성을 보장하기 위해 공유 구성 및 표준화된 개발 방식을 통해 촉진될 수 있습니다(자세한 내용은 다음 부분에서 설명).

하이브리드 구성

이 장의 앞부분에서 언급했듯이 이러한 모든 구성 패턴은 동일한 셸 응용 프로그램 내에서 혼합되고 일치될 수 있습니다. 다음은 그 모습의 예입니다.

오케스트레이션 라이브러리 선택

마이크로 프런트엔드 아키텍처에서 클라이언트측 구성을 구현하는 경우 올바른 오케스트레이션 라이브러리를 선택하는 것이 중요한 결정입니다.

선택한 라이브러리는 컨테이너 애플리케이션 내에서 마이크로 프런트엔드의 동적 로딩 및 조정을 관리하는 데 중요한 역할을 합니다.

널리 사용되는 여러 오케스트레이션 라이브러리가 있으며 각각 고유한 장점과 고려 사항이 있습니다.

싱글스파

Single-spa는 마이크로 프런트엔드 구성에 유연하고 확장 가능한 접근 방식을 제공하는 널리 채택된 오케스트레이션 라이브러리입니다. 이를 통해 개발자는 여러 마이크로 프런트엔드의 로드 및 언로드를 조정하는 셸 애플리케이션을 만들 수 있습니다.

단일 SPA는 수명 주기 이벤트에 대한 세밀한 제어를 제공하고 다양한 프레임워크와 기술을 지원합니다.

장점:

프레임워크에 구애받지 않음: 라이브러리는 React, Angular, Vue.js 등과 같은 다양한 프런트엔드 프레임워크와 잘 작동합니다.

유연한 구성: 라우팅, 지연 로딩 및 공유 종속성을 위한 강력한 구성 옵션을 제공합니다.

강력한 생태계: Single-SPA는 활발한 커뮤니티와 풍부한 플러그인 및 확장 생태계를 갖추고 있습니다.

단점:

학습 곡선: 단일 스파를 시작하려면 개념과 API에 대한 초기 학습과 이해가 필요할 수 있습니다.

사용자 정의 복잡성: 마이크로 프런트엔드 아키텍처가 복잡해짐에 따라 오케스트레이션을 구성하고 관리하는 것이 어려워질 수 있습니다.

첸쿤

Qiankun 은 Ant Financial(Alibaba) 팀이 개발한 강력한 오케스트레이션 라이브러리입니다. 구성을 위해 부분적인 HTML 접근 방식을 사용합니다. 마이크로 프런트엔드 앱 측에서는 로드할 모든 진입점이 포함된 일반 HTML 스니펫을 생성합니다.

이 HTML 파일을 사용한 후 컨테이너는 모든 조정을 수행하고 앱을 탑재합니다. 이 구성에서는 부분 HTML이 이전 장에서 이야기한 매니페스트 파일의 역할을 합니다.

장점:

프레임워크에 구애받지 않음: Qiankun은 React, Vue.js, Angular 등을 포함한 다양한 프런트엔드 프레임워크를 지원합니다.

단순화된 통합: Qiankun은 마이크로 프런트엔드 생성 및 관리를 위한 사용하기 쉬운 API 및 도구 세트를 제공합니다.

확장성 및 성능: Qiankun은 코드 샌드박싱, 상태 격리 및 마이크로 프런트엔드 간 통신을 위한 효율적인 메커니즘을 제공합니다.

단점:

종속성 충돌: 공유 종속성을 관리하고 마이크로 프런트엔드 간의 호환성을 보장하려면 신중한 구성과 고려가 필요할 수 있습니다.

학습 곡선: Qiankun은 광범위한 문서를 제공하지만 새로운 라이브러리를 채택하면 개발 팀의 학습 곡선이 필요할 수 있습니다.

유선으로 전송된 중복 데이터: 부분 HTML 스니펫에는 네트워크를 통해 전송해야 하는 중복 데이터(본문, 메타, DOCTYPE 태그)가 포함되어 있습니다.

모듈 연합

Webpack에서 제공하는 기능인 모듈 페더레이션은 웹 개발 커뮤니티에서 상당한 관심과 과대광고를 받았습니다. 이 기술을 사용하면 개발자는 런타임에 여러 애플리케이션 간에 코드를 공유할 수 있으므로 마이크로 프런트엔드를 구축하는 데 매력적인 옵션이 됩니다.

Webpack과의 원활한 통합 및 런타임 유연성을 통해 모듈 페더레이션은 마이크로 프런트엔드를 관리하고 조정하는 데 널리 사용되는 선택이 되었습니다.

장점:

Webpack과의 원활한 통합: 이미 Webpack을 빌드 도구로 사용하고 있는 경우 모듈 페더레이션을 활용하면 설정 및 통합 프로세스가 단순화됩니다.

런타임 유연성: 모듈 연합은 종속성의 동적 로드 및 공유를 가능하게 하여 마이크로 프런트엔드 관리에 유연성을 제공합니다.

단점:

제한된 프레임워크 지원: 모듈 페더레이션은 여러 프런트엔드 프레임워크와 호환되지만 특정 사용 사례에 대한 추가 구성이나 해결 방법이 필요할 수 있습니다.

커뮤니티 지원: 모듈 페더레이션은 Webpack 5에서 핵심 플러그인으로 출시된(나중에 v4 로 백포팅된) 상대적으로 새로운 기술입니다. Next.js 라이브러리도 최신 버전으로 최근 오픈 소스로 출시되었습니다. 모든 새로운 도구와 마찬가지로 커뮤니티 규모도 더 작고 지원도 더 적을 수 있습니다. 마감 기한이 촉박하거나 쉽게 답변할 수 없는 질문에 직면할 것으로 예상되는 경우 이 요소를 고려하는 것이 중요합니다.