스트랭글러 무화과 패턴

특정 기능을 새 애플리케이션 및 서비스로 점진적으로 대체하여 레거시 시스템을 증분 방식으로 마이그레이션합니다. 레거시 시스템의 기능을 바꾸면 새 시스템은 결국 모든 이전 시스템의 기능으로 구성됩니다. 이 방법은 이전 시스템을 해제할 수 있도록 표시하지 않습니다.

컨텍스트 및 문제

시스템이 발전함에 따라 개발 도구, 호스팅 기술 및 빌드된 시스템 아키텍처는 더 이상 사용되지 않을 수 있습니다. 새로운 기능과 기능이 추가되면 이러한 애플리케이션이 더 복잡해져서 유지 관리 또는 확장이 더 어려워질 수 있습니다.

전체 복잡한 시스템을 교체하는 것은 어렵습니다. 대신 점진적으로 새 시스템으로 마이그레이션하고 이전 시스템을 마이그레이션되지 않은 기능에 사용할 수 있습니다. 그러나 애플리케이션의 병렬 버전을 실행하는 경우 클라이언트는 각 기능을 포함하는 버전을 추적해야 합니다. 기능 또는 서비스를 마이그레이션할 때 클라이언트를 새 위치로 이동해야 합니다. 이러한 문제를 해결하려면 증분 마이그레이션을 지원하고 클라이언트에 대한 중단을 최소화하는 접근 방식을 채택합니다.

해결 방법

새 서비스 경계를 식별한 후 증분 프로세스를 사용하여 특정 기능을 새 애플리케이션 및 서비스로 대체합니다. 고객은 동일한 인터페이스를 계속 사용하며 마이그레이션이 진행 중임을 인식하지 못합니다.

이 아키텍처의 Visio 파일을 다운로드하십시오.

스트랭글러 무화과 패턴은 현대화에 대한 제어 및 단계적 접근 방식을 제공합니다. 이를 통해 기존 애플리케이션은 현대화 작업 중에 계속 작동할 수 있습니다. 외관(프록시)은 백 엔드 레거시 시스템으로 이동하는 요청을 가로챌 수 있습니다. 외관은 이러한 요청을 레거시 애플리케이션 또는 새 서비스로 라우팅합니다.

이 패턴은 팀이 프로젝트의 복잡성에 맞는 속도로 진행할 수 있도록 하여 마이그레이션 위험을 줄입니다. 기능을 새 시스템으로 마이그레이션하면 레거시 시스템이 사용되지 않으며 레거시 시스템을 서비스 해제합니다.

1. 스트랭글러 무화과 패턴은 클라이언트 앱, 레거시 시스템 및 새 시스템 사이에 외관(프록시)을 도입하는 것으로 시작합니다. 외관은 중개자 역할을합니다. 이를 통해 클라이언트 앱은 레거시 시스템 및 새 시스템과 상호 작용할 수 있습니다. 처음에 외관은 대부분의 요청을 레거시 시스템으로 라우팅합니다.

2. 마이그레이션이 진행됨에 따라 파사드는 레거시 시스템에서 새 시스템으로 요청을 점진적으로 이동합니다. 반복할 때마다 새 시스템에서 더 많은 기능을 구현할 수 있습니다.

   이 증분 접근 방식은 레거시 시스템의 책임을 점진적으로 줄이고 새 시스템의 범위를 확장합니다. 이 프로세스는 반복적입니다. 이를 통해 팀은 관리 가능한 단계에서 복잡성 및 종속성을 해결할 수 있습니다. 이러한 단계는 시스템이 안정적이고 기능적인 상태를 유지하는 데 도움이 됩니다.

3. 모든 기능을 마이그레이션하고 레거시 시스템에 대한 종속성이 없으면 레거시 시스템을 해제할 수 있습니다. 외관은 모든 요청을 새 시스템으로 독점적으로 라우팅합니다.

4. 외관을 제거하고 클라이언트 앱을 다시 구성하여 새 시스템과 직접 통신합니다. 이 단계는 마이그레이션 완료를 표시합니다.

문제 및 고려 사항

이 패턴을 구현하는 방법을 결정할 때 다음 사항을 고려합니다.

• 새 시스템과 레거시 시스템에서 모두 사용할 수 있는 서비스 및 데이터 저장소를 처리하는 방법을 고려합니다. 두 시스템이 동시에 이러한 리소스에 액세스할 수 있는지 확인합니다.

• 이후의 스트랭글러 무화과 마이그레이션에서 쉽게 가로채고 대체할 수 있도록 새 애플리케이션 및 서비스를 구성합니다. 예를 들어 각 파트를 개별적으로 마이그레이션할 수 있도록 솔루션의 일부 간에 명확한 경계를 설정하려고 합니다.

• 마이그레이션이 완료되면 일반적으로 스트랭글러 무화과 외관을 제거합니다. 또는 최신 클라이언트에 대한 핵심 시스템을 업데이트하는 동안 레거시 클라이언트가 사용할 어댑터로 외관을 유지할 수 있습니다.

  이를 과도기적 아키텍처로 개념화하고 이 아키텍처의 위험 완화 이점을 일시적인 인프라 비용과 균형을 이루세요.

• 외관이 마이그레이션을 따라야 합니다.

• 외관이 단일 실패 지점이나 성능 병목 상태가 되지 않도록 합니다.

• 시스템 간 종속성을 계획합니다. 마이그레이션하는 동안 두 시스템은 공존하고 통신해야 합니다. 예를 들어 새 시스템은 레거시 시스템에서 이동되지 않은 기능을 호출해야 할 수 있으며, 마이그레이션되지 않은 레거시 구성 요소는 새 시스템에서 마이그레이션된 기능을 호출해야 할 수 있습니다. 이러한 호출을 관리하려면 손상 방지 계층 패턴을 사용합니다. 손상 방지 계층은 두 시스템 간의 요청을 변환하는 어댑터 역할을 합니다. 이 계층은 레거시 시스템이 중요한 코드 변경 없이 새 서비스에 도달할 수 있도록 레거시 의미 체계로부터 새 시스템의 디자인을 보호합니다. 이 어댑터가 없으면 시스템 간 종속성이 구성 요소를 중단하거나 새 시스템에서 레거시 규칙을 채택하도록 강제할 수 있습니다.

이 패턴을 사용하는 경우

다음 경우에 이 패턴을 사용합니다.

• 특히 대규모 시스템, 주요 구성 요소 또는 복잡한 기능을 대체하면 위험이 발생하는 경우 백 엔드 애플리케이션을 새 아키텍처로 점진적으로 마이그레이션합니다.

• 원래 시스템은 마이그레이션 작업 중에 장시간 계속 존재할 수 있습니다.

이 패턴은 다음과 같은 경우에 적합하지 않을 수 있습니다.

• 백 엔드 시스템에 대한 요청은 가로챌 수 없습니다.

• 레거시 시스템의 소스 코드에 액세스할 수 없습니다. 마이그레이션된 기능을 사용하지 않도록 설정하고 내부 호출을 리디렉션하려면 레거시 시스템의 소스 코드를 수정할 수 있어야 합니다.

• 작은 시스템을 마이그레이션하고 전체 시스템을 교체하는 것은 간단합니다.

• 원래 솔루션을 신속하게 완전히 해제해야 합니다.

워크로드 디자인

워크로드 디자인에서 스트랭글러 무화과 패턴을 사용하여 Azure Well-Architected Framework 핵심 요소의 목표와 원칙을 해결하는 방법을 평가합니다. 다음 표에서는 이 패턴이 각 핵심 요소의 목표를 지원하는 방법에 대한 지침을 제공합니다.

이 패턴이 도입할 수 있는 다른 핵심 요소의 목표에 대한 장편을 고려합니다.

예시

레거시 시스템은 일반적으로 여러 도메인을 제공하는 중앙 집중식 모놀리식 데이터베이스에 의존합니다. 시간이 지남에 따라 이 공유 데이터베이스는 도메인 간 종속성 때문에 관리 및 개선이 어려워집니다. 이 문제를 해결하기 위해 Strangler Fig 패턴은 모놀리식 데이터베이스에서 격리된 도메인 데이터베이스로 도메인별 테이블, 저장 프로시저 및 관련 데이터를 증분 방식으로 추출합니다. 각 데이터베이스에는 하나의 도메인만 포함됩니다. 모놀리식 데이터베이스가 완전히 분해될 때까지 추출 프로세스를 반복합니다.

1. 도메인에 대한 요청을 관리하기 시작하는 새 시스템 서비스를 소개합니다. 새 시스템 서비스는 여전히 도메인 테이블의 모놀리식 데이터베이스에서 읽고 씁니다. 레거시 시스템은 다른 모든 도메인에 계속 서비스를 제공합니다.

2. 새 시스템에 대해 격리된 도메인 데이터베이스를 소개합니다. ETL(추출, 변환 및 로드) 프로세스를 사용하여 관련 도메인 테이블 및 해당 기록 데이터를 새 데이터베이스로 마이그레이션합니다. CDC(변경 데이터 캡처) 프로세스는 모놀리식 데이터베이스의 도메인 데이터를 새 도메인 데이터베이스로 동기화합니다. 이 단계에서 레거시 시스템은 모놀리식 데이터베이스에서 계속 읽고 쓰며 새 시스템은 새 도메인 데이터베이스에 씁니다. 중단하기 전에 두 데이터베이스 간의 일관성을 확인합니다.

3. 유효성 검사 후 새 도메인 데이터베이스는 해당 도메인에 대한 레코드 시스템입니다. 새 시스템은 도메인 데이터베이스에 대해 모든 읽기 및 쓰기 작업을 수행합니다. 모놀리식 데이터베이스에서 해당 도메인 테이블, 저장 프로시저 및 종속성을 제거합니다. 모놀리식 데이터베이스가 완전히 분해될 때까지 각 도메인에 대해 이 프로세스를 반복합니다.

   도메인 테이블 및 동기화 프로세스가 모놀리식 데이터베이스에 여전히 있는 경우 2단계 및 3단계 시작 시 모놀리식 데이터베이스로 롤백할 수 있습니다. 모놀리식 데이터베이스에서 도메인 테이블, 저장 프로시저 및 동기화 프로세스를 제거한 후 모놀리식 데이터베이스로 롤백하려면 해당 개체를 복원하고 데이터 변경 내용을 재생해야 합니다. 그러나 이 프로세스는 노력과 위험을 크게 증가합니다. 레거시 개체 제거를 각 도메인에 대한 의도적인 최종 단계로 처리합니다. 새 시스템의 유효성을 검사한 후에만 레거시 개체를 제거합니다.

기여자

Microsoft는 이 문서를 유지 관리합니다. 이 문서를 작성한 기여자는 다음과 같습니다.

주요 작성자:

• 아드난 칸 | 선임 클라우드 솔루션 설계자
• 오바이스 메부브 아메드 칸 | 선임 클라우드 솔루션 설계자

LinkedIn 비공개 프로필을 보려면, LinkedIn에 로그인하세요.

다음 단계

• 스트랭글러 무화과 패턴 애플리케이션에 대한 마틴 파울러의 블로그 게시물 읽기

관련 리소스

• 메시징 브리지 패턴
• Amazon Web Services에서 Azure