이 패턴은 특정 기능 부분을 새 애플리케이션 및 서비스로 점진적으로 대체하여 레거시 시스템을 증분 방식으로 마이그레이션합니다. 레거시 시스템의 기능을 바꾸면 새 시스템은 결국 모든 이전 시스템의 기능으로 구성됩니다. 이 방법은 이전 시스템을 해제할 수 있도록 표시하지 않습니다.
컨텍스트 및 문제
시스템이 발전함에 따라 개발 도구, 호스팅 기술 및 빌드된 시스템 아키텍처는 더 이상 사용되지 않을 수 있습니다. 새로운 기능과 기능이 추가되면 이러한 애플리케이션이 더 복잡해져서 유지 관리 또는 확장이 더 어려워질 수 있습니다.
전체 복잡한 시스템을 대체하는 것은 거대한 사업입니다. 대신, 많은 팀은 점진적으로 새 시스템으로 마이그레이션하고 이전 시스템을 유지하여 이동되지 않은 기능을 처리하는 것을 선호합니다. 그러나 두 개의 개별 버전의 애플리케이션을 실행하면 클라이언트가 개별 기능이 있는 버전을 추적해야 합니다. 팀이 기능 또는 서비스를 마이그레이션할 때마다 클라이언트를 새 위치로 이동해야 합니다. 이러한 문제를 해결하기 위해 증분 마이그레이션을 지원하고 클라이언트에 대한 중단을 최소화하는 접근 방식을 채택할 수 있습니다.
해결 방법
증분 프로세스를 사용하여 특정 기능을 새 애플리케이션 및 서비스로 대체합니다. 고객은 이 마이그레이션이 수행되고 있다는 사실을 모르고 동일한 인터페이스를 계속 사용할 수 있습니다.
스트랭글러 무화과 패턴은 현대화에 대한 제어 및 단계적 접근 방식을 제공합니다. 이를 통해 기존 애플리케이션은 현대화 작업 중에 계속 작동할 수 있습니다. 외관(프록시)은 백 엔드 레거시 시스템으로 이동하는 요청을 가로챌 수 있습니다. 외관은 이러한 요청을 레거시 애플리케이션 또는 새 서비스로 라우팅합니다.
이 패턴은 팀이 프로젝트의 복잡성에 맞는 속도로 진행할 수 있도록 하여 마이그레이션 위험을 줄입니다. 기능을 새 시스템으로 마이그레이션하면 레거시 시스템이 사용되지 않으며 레거시 시스템을 서비스 해제합니다.
스트랭글러 무화과 패턴은 클라이언트 앱, 레거시 시스템 및 새 시스템 사이에 외관(프록시)을 도입하는 것으로 시작합니다. 외관은 중개자 역할을합니다. 이를 통해 클라이언트 앱은 레거시 시스템 및 새 시스템과 상호 작용할 수 있습니다. 처음에 외관은 대부분의 요청을 레거시 시스템으로 라우팅합니다.
마이그레이션이 진행됨에 따라 파사드는 레거시 시스템에서 새 시스템으로 요청을 점진적으로 이동합니다. 반복할 때마다 새 시스템에서 더 많은 기능을 구현할 수 있습니다.
이 증분 접근 방식은 레거시 시스템의 책임을 점진적으로 줄이고 새 시스템의 범위를 확장합니다. 이 프로세스는 반복적입니다. 이를 통해 팀은 관리 가능한 단계에서 복잡성 및 종속성을 해결할 수 있습니다. 이러한 단계는 시스템이 안정적이고 기능적인 상태를 유지하는 데 도움이 됩니다.
모든 기능을 마이그레이션하고 레거시 시스템에 대한 종속성이 없으면 레거시 시스템을 해제할 수 있습니다. 외관은 모든 요청을 새 시스템으로 독점적으로 라우팅합니다.
외관을 제거하고 클라이언트 앱을 다시 구성하여 새 시스템과 직접 통신합니다. 이 단계는 마이그레이션 완료를 표시합니다.
문제 및 고려 사항
이 패턴을 구현하는 방법을 결정할 때 다음 사항을 고려합니다.
새 시스템과 레거시 시스템에서 모두 사용할 수 있는 서비스 및 데이터 저장소를 처리하는 방법을 고려합니다. 두 시스템이 동시에 이러한 리소스에 액세스할 수 있는지 확인합니다.
이후의 스트랭글러 무화과 마이그레이션에서 쉽게 가로채고 대체할 수 있도록 새 애플리케이션 및 서비스를 구성합니다. 예를 들어 각 파트를 개별적으로 마이그레이션할 수 있도록 솔루션의 일부 간에 명확한 경계를 설정하려고 합니다.
마이그레이션이 완료되면 일반적으로 스트랭글러 무화과 외관을 제거합니다. 또는 최신 클라이언트에 대한 핵심 시스템을 업데이트하는 동안 레거시 클라이언트가 사용할 어댑터로 외관을 유지할 수 있습니다.
외관이 마이그레이션을 따라야 합니다.
외관이 단일 실패 지점이나 성능 병목 상태가 되지 않도록 합니다.
이 패턴을 사용하는 경우
다음 경우에 이 패턴을 사용합니다.
특히 대규모 시스템, 주요 구성 요소 또는 복잡한 기능을 대체하면 위험이 발생하는 경우 백 엔드 애플리케이션을 새 아키텍처로 점진적으로 마이그레이션합니다.
원래 시스템은 마이그레이션 작업 중에 장시간 계속 존재할 수 있습니다.
이 패턴은 다음과 같은 경우에 적합하지 않을 수 있습니다.
백 엔드 시스템에 대한 요청은 가로챌 수 없습니다.
작은 시스템을 마이그레이션하고 전체 시스템을 교체하는 것은 간단합니다.
원래 솔루션을 신속하게 완전히 해제해야 합니다.
워크로드 디자인
워크로드 디자인에서 스트랭글러 무화과 패턴을 사용하여 Azure Well-Architected Framework 핵심 요소의 목표와 원칙을 해결하는 방법을 평가합니다. 다음 표에서는 이 패턴이 각 핵심 요소의 목표를 지원하는 방법에 대한 지침을 제공합니다.
| 기둥 | 이 패턴으로 핵심 목표를 지원하는 방법 |
|---|---|
| 안정성 디자인 결정은 워크로드가 오작동에 대한 복원력을 갖도록 하고 오류가 발생한 후 완전히 작동하는 상태로 복구 되도록 하는 데 도움이 됩니다. | 이 패턴의 증분 접근 방식은 한 번에 큰 시스템 변경에 비해 구성 요소 전환 중에 위험을 완화하는 데 도움이 될 수 있습니다. - RE:08 테스트 |
| 비용 최적화는 워크로드의 ROI(투자 수익률)를 유지하고 개선하는 데 중점을 둡니다. | 이 방법의 목표는 증분 방식으로 현대화하면서 현재 실행 중인 시스템에 대한 기존 투자 사용을 최대화하는 것입니다. 이를 통해 낮은 ROI 교체 전에 높은 ROI 교체를 수행할 수 있습니다. - CO:07 구성 요소 비용 - CO:08 환경 비용 |
| 운영 우수성은 표준화된 프로세스와 팀 응집력을 통해 워크로드 품질을 제공하는 데 도움이 됩니다. | 이 패턴은 지속적인 개선 방법을 제공합니다. 시간이 지남에 따라 약간 변경되는 증분 교체는 구현하기 더 위험한 대규모 시스템 변경보다 선호됩니다. - 워크로드 개발을 위한 OE:06 공급망 - OE:11 안전한 배포 사례 |
이 패턴이 도입할 수 있는 다른 핵심 요소의 목표에 대한 장편을 고려합니다.
예시
레거시 시스템은 일반적으로 중앙 집중식 데이터베이스에 따라 달라집니다. 시간이 지남에 따라 중앙 집중식 데이터베이스는 많은 종속성으로 인해 관리 및 발전하기 어려울 수 있습니다. 이러한 문제를 해결하기 위해 다양한 데이터베이스 패턴은 이러한 레거시 시스템에서의 전환을 용이하게 할 수 있습니다. 스트랭글러 무화과 패턴은 이러한 패턴 중 하나입니다. 스트랭글러 무화과 패턴을 단계적 접근 방법으로 적용하여 레거시 시스템에서 새 시스템으로 점진적으로 전환하고 중단을 최소화합니다.
새 시스템을 도입하면 새 시스템이 클라이언트 앱에서 일부 요청을 처리하기 시작합니다. 그러나 새 시스템은 여전히 모든 읽기 및 쓰기 작업에 대한 레거시 데이터베이스에 의존합니다. 레거시 시스템은 작동 상태를 유지하므로 즉각적인 구조적 변경 없이 원활한 전환을 용이하게 합니다.
다음 단계에서는 새 데이터베이스를 소개합니다. ETL(추출, 변환 및 로드) 프로세스를 사용하여 데이터 로드 기록을 새 데이터베이스로 마이그레이션합니다. ETL 프로세스는 새 데이터베이스를 레거시 데이터베이스와 동기화합니다. 이 단계에서 새 시스템은 섀도 쓰기를 수행합니다. 새 시스템은 두 데이터베이스를 병렬로 업데이트합니다. 새 시스템은 일관성의 유효성을 검사하기 위해 레거시 데이터베이스에서 계속 읽습니다.
마지막으로 새 데이터베이스가 레코드 시스템이 됩니다. 새 데이터베이스는 모든 읽기 및 쓰기 작업을 인수합니다. 레거시 데이터베이스 및 레거시 시스템 사용 중단을 시작할 수 있습니다. 새 데이터베이스의 유효성을 검사한 후 레거시 데이터베이스를 사용 중지할 수 있습니다. 이 은퇴는 마이그레이션 프로세스를 최소한의 중단으로 완료합니다.
다음 단계
스트랭글러 무화과 패턴 애플리케이션에 대한 마틴 파울러의 블로그 게시물을 읽어보세요.