기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
스트랭글러 무화과 패턴
Intent
스트랭글러 피그 패턴은 변환 위험과 비즈니스 중단을 줄이면서 모놀리식 애플리케이션을 마이크로서비스 아키텍처로 점진적으로 마이그레이션하는 데 도움이 됩니다.
동기 부여
모놀리식 애플리케이션은 단일 프로세스 또는 컨테이너 내에서 대부분의 기능을 제공하도록 개발되었습니다. 코드는 밀접하게 결합되어 있습니다. 따라서 애플리케이션 변경 시 회귀 문제를 방지하려면 철저한 재테스트가 필요합니다. 변경 사항은 개별적으로 테스트할 수 없으므로 주기 시간에 영향을 미칩니다. 애플리케이션에 더 많은 기능이 추가됨에 따라 복잡성이 높으면 유지 관리에 소요되는 시간이 늘어나고 출시 시간이 길어지며 결과적으로 제품 혁신이 느려질 수 있습니다.
애플리케이션 규모가 확장되면 팀의 인지 부하가 증가하고 팀 소유권 경계가 불분명해질 수 있습니다. 부하에 따라 개별 기능을 확장할 수는 없습니다. 최대 부하를 지원하도록 전체 애플리케이션을 확장해야 합니다. 시스템이 노후화되면 기술이 더 이상 사용되지 않아 지원 비용이 증가할 수 있습니다. 모놀리식 레거시 애플리케이션은 개발 당시 이용 가능했지만 배포용으로 설계되지 않은 모범 사례를 따릅니다.
모놀리식 애플리케이션을 마이크로서비스 아키텍처로 마이그레이션하면 더 작은 구성 요소로 분할할 수 있습니다. 이러한 구성 요소는 독립적으로 확장할 수 있고, 독립적으로 릴리스할 수 있으며, 개별 팀이 소유할 수 있습니다. 변경 사항이 현지화되고 신속하게 테스트 및 릴리스할 수 있기 때문에 변경 속도가 빨라집니다. 구성 요소가 느슨하게 결합되고 개별적으로 배포될 수 있기 때문에 변경 사항이 미치는 영향 범위가 더 작습니다.
코드를 재작성하거나 리팩토링하여 모노리스를 마이크로서비스 애플리케이션으로 완전히 대체하는 것은 엄청난 작업이며 위험도 큽니다. 단일 작업으로 모놀리스를 마이그레이션하는 빅뱅 마이그레이션은 변환 위험과 비즈니스 중단을 초래합니다. 애플리케이션을 리팩토링하는 동안에는 새 기능을 추가하기가 매우 어렵거나 심지어 불가능하기도 합니다.
이 문제를 해결하는 한 가지 방법은 Martin Fowler가 도입한 스트랭글러 무화과 패턴을 사용하는 것입니다. 이 패턴에는 기능을 점진적으로 추출하여 마이크로서비스로 이동하고 기존 시스템을 중심으로 새 애플리케이션을 만드는 것이 포함됩니다. 모놀리스의 기능은 점차 마이크로서비스로 대체되고 있으며, 애플리케이션 사용자는 새로 마이그레이션된 기능을 점진적으로 사용할 수 있습니다. 모든 기능을 새 시스템으로 옮기면 모놀리식 애플리케이션을 안전하게 폐기할 수 있습니다.
적용 가능성
스트랭글러 무화과 패턴을 사용하는 경우는 다음과 같습니다.
-
모놀리식 애플리케이션을 마이크로서비스 아키텍처로 점진적으로 마이그레이션하고 싶을 것입니다.
-
빅뱅 마이그레이션 접근 방식은 모노리스의 크기와 복잡성 때문에 위험합니다.
-
기업은 새로운 기능을 추가하기를 원하며 전환이 완료될 때까지 기다릴 수 없습니다.
-
변환 과정에서 최종 사용자에게 미치는 영향을 최소화해야 합니다.
문제 및 고려 사항
-
코드 기반 액세스: 스트랭글러 fig 패턴을 구현하려면 모놀리스 애플리케이션의 코드 베이스에 액세스할 수 있어야 합니다. 기능이 모놀리스 외부로 마이그레이션되면 코드를 약간 변경하고 모놀리스 내에 손상 방지 계층을 구현하여 호출을 새 마이크로서비스로 라우팅해야 합니다. 코드베이스 액세스 없이는 통화를 가로챌 수 없습니다. 코드 기반 액세스는 들어오는 요청을 리디렉션할 때도 중요합니다. 프록시 계층이 마이그레이션된 기능에 대한 호출을 가로채서 마이크로서비스로 라우팅하려면 일부 코드 리팩토링이 필요할 수 있습니다.
-
불분명한 도메인: 시스템을 조기에 분해하면 비용이 많이 들 수 있으며, 특히 도메인이 명확하지 않은 경우 비용이 많이 들 수 있으며 서비스 경계를 잘못 설정할 수 있습니다. 도메인 기반 설계 (DDD) 는 도메인을 이해하기 위한 메커니즘이고 이벤트 스토밍은 도메인 경계를 결정하는 기법입니다.
-
마이크로서비스 식별: DDD를 마이크로서비스를 식별하는 핵심 도구로 사용할 수 있습니다. 마이크로서비스를 식별하려면 서비스 클래스 간의 자연스러운 구분을 살펴보세요. 많은 서비스가 자체 데이터 액세스 객체를 소유하며 쉽게 분리됩니다. 종속성이 없거나 거의 없는 관련 비즈니스 로직 및 클래스가 있는 서비스는 마이크로서비스에 적합합니다. 모놀리스를 분해하기 전에 코드를 리팩터링하여 긴밀한 결합을 방지할 수 있습니다. 또한 규정 준수 요구 사항, 릴리스 주기, 팀의 지리적 위치, 규모 조정 요구 사항, 사용 사례 기반 기술 요구 사항, 팀의 인지 부하도 고려해야 합니다.
-
손상 방지 계층: 마이그레이션 프로세스 중에 모놀리스 내의 기능이 마이크로서비스로 마이그레이션된 기능을 호출해야 하는 경우 각 호출을 적절한 마이크로서비스로 라우팅하는 손상 방지 계층 (ACL) 을 구현해야 합니다. 모놀리스 내에서 기존 발신자를 분리하고 변경을 방지하기 위해 ACL은 호출을 최신 인터페이스로 변환하는 어댑터 또는 파사드 역할을 합니다. 이에 대해서는 이 가이드 앞부분에 있는 ACL 패턴의 구현 섹션에서 자세히 설명합니다.
-
프록시 계층 장애: 마이그레이션 중에 프록시 계층은 모놀리식 애플리케이션으로 이동하는 요청을 가로채서 기존 시스템이나 새 시스템으로 라우팅합니다. 하지만 이 프록시 계층은 단일 장애 지점이나 성능 병목 현상이 될 수 있습니다.
-
애플리케이션 복잡성: 대형 모놀리스는 스트랭글러 피그 패턴의 이점을 가장 많이 누릴 수 있습니다. 전체 리팩토링의 복잡성이 낮은 소규모 애플리케이션의 경우 마이그레이션하는 대신 마이크로서비스 아키텍처에서 애플리케이션을 다시 작성하는 것이 더 효율적일 수 있습니다.
-
서비스 상호 작용: 마이크로서비스는 동기식 또는 비동기식으로 통신할 수 있습니다. 동기 통신이 필요한 경우 시간 초과로 인해 연결 또는 스레드 풀 소비가 발생하여 애플리케이션 성능 문제가 발생할 수 있는지 고려하세요. 이러한 경우에는 회로 차단기 패턴을 사용하여 장기간 실패할 가능성이 있는 작업에 대해 즉시 실패를 반환하십시오. 이벤트 및 메시징 대기열을 사용하여 비동기 통신을 수행할 수 있습니다.
-
데이터 집계: 마이크로서비스 아키텍처에서는 데이터가 데이터베이스 전체에 분산됩니다. 데이터 집계가 필요한 경우 프런트 AWS AppSync
엔드에서 사용하거나 백엔드의 CQRS (명령 쿼리 책임 분리) 패턴을 사용할 수 있습니다. -
데이터 일관성: 마이크로서비스는 자체 데이터 저장소를 소유하며, 모놀리식 애플리케이션도 이 데이터를 잠재적으로 사용할 수 있습니다. 공유를 활성화하려면 대기열 및 에이전트를 사용하여 새 마이크로서비스의 데이터 저장소를 모놀리식 애플리케이션의 데이터베이스와 동기화할 수 있습니다. 그러나 이로 인해 두 데이터 저장소 간에 데이터 중복과 최종 일관성이 발생할 수 있으므로 데이터 레이크와 같은 장기적인 솔루션을 구축할 수 있을 때까지는 전술적 솔루션으로 취급하는 것이 좋습니다.
구현
스트랭글러 그림 패턴에서는 특정 기능을 한 번에 하나의 구성 요소씩 새 서비스나 애플리케이션으로 대체합니다. 프록시 계층은 모놀리식 애플리케이션으로 이동하는 요청을 가로채서 레거시 시스템이나 새 시스템으로 라우팅합니다. 프록시 계층은 사용자를 올바른 애플리케이션으로 라우팅하므로 모놀리스가 계속 작동하도록 하면서 새 시스템에 기능을 추가할 수 있습니다. 새 시스템은 결국 기존 시스템의 모든 기능을 대체하므로 사용을 중지할 수 있습니다.
고수준 아키텍처
다음 다이어그램에서 모놀리식 애플리케이션에는 사용자 서비스, 카트 서비스, 계정 서비스라는 세 가지 서비스가 있습니다. 카트 서비스는 사용자 서비스에 따라 달라지며 애플리케이션은 모놀리식 관계형 데이터베이스를 사용합니다.
첫 번째 단계는 스토어프론트 UI와 모놀리식 애플리케이션 사이에 프록시 레이어를 추가하는 것입니다. 처음에는 프록시가 모든 트래픽을 모놀리식 애플리케이션으로 라우팅합니다.
애플리케이션에 새 기능을 추가하려면 기존 모놀리스에 기능을 추가하는 대신 새 마이크로서비스로 구현해야 합니다. 하지만 애플리케이션 안정성을 보장하기 위해 계속해서 모놀리스의 버그를 수정합니다. 다음 다이어그램에서 프록시 계층은 API URL을 기반으로 호출을 모놀리스 또는 새 마이크로서비스로 라우팅합니다.
손상 방지 계층 추가
다음 아키텍처에서는 사용자 서비스가 마이크로서비스로 마이그레이션되었습니다. 카트 서비스가 사용자 서비스를 호출하지만 모놀리스 내에서는 더 이상 구현을 사용할 수 없습니다. 또한 새로 마이그레이션된 서비스의 인터페이스가 모놀리식 애플리케이션 내의 이전 인터페이스와 일치하지 않을 수 있습니다. 이러한 변경 사항을 해결하려면 ACL을 구현해야 합니다. 마이그레이션 프로세스 중에 모놀리스 내의 기능이 마이크로서비스로 마이그레이션된 기능을 호출해야 하는 경우 ACL은 호출을 새 인터페이스로 변환하여 적절한 마이크로서비스로 라우팅합니다.
마이그레이션된 서비스와 관련된 클래스 (예: 또는) 로 모놀리식 애플리케이션 내에서 ACL을 구현할 수 있습니다. UserServiceFacade UserServiceAdapter 모든 종속 서비스를 마이크로서비스 아키텍처로 마이그레이션한 후에는 ACL을 사용 중지해야 합니다.
ACL을 사용하는 경우 카트 서비스는 여전히 모놀리스 내에서 사용자 서비스를 호출하고 사용자 서비스는 ACL을 통해 호출을 마이크로서비스로 리디렉션합니다. 카트 서비스는 마이크로서비스 마이그레이션을 인식하지 않고도 여전히 사용자 서비스를 호출해야 합니다. 회귀 현상과 비즈니스 중단을 줄이려면 이러한 느슨한 결합이 필요합니다.
데이터 동기화 처리
가장 좋은 방법은 마이크로서비스가 자체 데이터를 소유하는 것입니다. 사용자 서비스는 자체 데이터 스토어에 데이터를 저장합니다. 보고와 같은 종속성을 처리하고 아직 마이크로서비스에 직접 액세스할 준비가 되지 않은 다운스트림 애플리케이션을 지원하려면 데이터를 모놀리식 데이터베이스와 동기화해야 할 수 있습니다. 모놀리식 애플리케이션에는 아직 마이크로서비스로 마이그레이션되지 않은 다른 기능 및 구성 요소에 대한 데이터가 필요할 수도 있습니다. 따라서 새 마이크로서비스와 모놀리스 간에는 데이터 동기화가 필요합니다. 데이터를 동기화하려면 다음 다이어그램과 같이 사용자 마이크로서비스와 모놀리식 데이터베이스 간에 동기화 에이전트를 도입할 수 있습니다. 사용자 마이크로서비스는 데이터베이스가 업데이트될 때마다 이벤트를 대기열에 보냅니다. 동기화 에이전트는 대기열을 수신하고 모놀리식 데이터베이스를 지속적으로 업데이트합니다. 모놀리식 데이터베이스의 데이터는 결국 동기화 중인 데이터와 일치하게 됩니다.
추가 서비스 마이그레이션
카트 서비스가 모놀리식 애플리케이션 외부로 마이그레이션되면 새 서비스를 직접 호출하도록 코드가 수정되므로 ACL은 더 이상 해당 호출을 라우팅하지 않습니다. 다음은 이러한 아키텍처를 나타낸 다이어그램입니다.
다음 다이어그램은 모든 서비스가 모놀리스 밖으로 마이그레이션되고 모놀리스의 골격만 남아 있는 최종 교란 상태를 보여줍니다. 기록 데이터는 개별 서비스가 소유한 데이터 저장소로 마이그레이션할 수 있습니다. ACL을 제거할 수 있으며, 이 단계에서 모놀리스를 폐기할 준비가 되었습니다.
다음 다이어그램은 모놀리식 애플리케이션이 폐기된 후의 최종 아키텍처를 보여줍니다. 애플리케이션 요구 사항에 따라 리소스 기반 URL (예:http://www.storefront.com/user) 또는 자체 도메인 (예:) 을 통해 개별 마이크로서비스를 호스팅할 수 있습니다. http://user.storefront.com 호스트 이름과 경로를 사용하여 업스트림 소비자에게 HTTP API를 노출하는 주요 방법에 대한 자세한 내용은 API 라우팅 패턴 섹션을 참조하십시오.
AWS서비스를 사용한 구현
API Gateway를 애플리케이션 프록시로 사용
다음 다이어그램은 모놀리식 애플리케이션의 초기 상태를 보여줍니다. Amazon Elastic Compute Cloud (Amazon EC2) 인스턴스에서 실행되고 Amazon RDS (관계형 데이터베이스 서비스
다음 아키텍처에서는 Amazon API Gateway를
사용자 서비스가 Lambda 함수로 마이그레이션되고 Amazon DynamoDB
다음 다이어그램에서 카트 서비스도 모놀리스에서 Lambda 함수로 마이그레이션되었습니다. 추가 경로 및 서비스 엔드포인트가 Refactor Spaces에 추가되고 트래픽이 자동으로 Cart Lambda 함수로 전환됩니다. Lambda 함수의 데이터 스토어는 Amazon에서 관리합니다. ElastiCache
다음 다이어그램에서는 마지막 서비스 (계정) 가 모놀리스에서 Lambda 함수로 마이그레이션됩니다. 원래 Amazon RDS 데이터베이스를 계속 사용합니다. 이제 새 아키텍처에는 별도의 데이터베이스가 있는 세 개의 마이크로서비스가 있습니다. 각 서비스는 서로 다른 유형의 데이터베이스를 사용합니다. 마이크로서비스의 특정 요구 사항을 충족하기 위해 특별히 구축된 데이터베이스를 사용하는 이러한 개념을 다중 언어 지속성이라고 합니다. Lambda 함수는 사용 사례에 따라 다양한 프로그래밍 언어로 구현될 수도 있습니다. 리팩토링 중에 Refactor Spaces는 Lambda로의 트래픽 컷오버 및 라우팅을 자동화합니다. 이를 통해 빌더는 라우팅 인프라를 설계, 배포 및 구성하는 데 필요한 시간을 절약할 수 있습니다.
여러 계정 사용
이전 구현에서는 모놀리식 애플리케이션에 프라이빗 서브넷과 퍼블릭 서브넷이 있는 단일 VPC를 사용했으며, 단순성을 위해 동일한 VPC 내에 마이크로서비스를 배포했습니다. AWS 계정 하지만 마이크로서비스가 배포 독립성을 위해 여러 개로 배포되는 경우가 많은 실제 시나리오에서는 이런 경우가 거의 없습니다. AWS 계정 다중 계정 구조에서는 모놀리스에서 다른 계정의 새 서비스로의 라우팅 트래픽을 구성해야 합니다.
Refactor Spaces를 사용하면 모놀리식 애플리케이션 외부로 API 호출을 라우팅하기 위한 AWS 인프라를 만들고 구성할 수 있습니다. 리팩터링은 AWS 계정 내의 API Gateway
다음 다이어그램과 같이 사용자 및 카트 서비스가 서로 다른 두 계정에 배포되었다고 가정해 보겠습니다. 리팩터링 스페이스를 사용할 때는 서비스 엔드포인트와 라우트만 구성하면 됩니다. Refactor Spaces는 API Gateway—Lambda 통합 및 Lambda 리소스 정책 생성을 자동화하므로, 사용자는 모놀리스에서 서비스를 안전하게 리팩토링하는 데 집중할 수 있습니다.
스페이스 리팩터링 사용에 대한 동영상 튜토리얼은 앱을 사용하여 점진적으로 리팩터링하기
워크숍
블로그 레퍼런스
관련 콘텐츠
