스트랭글러 패턴

1. 스트랭글러(교살자) 패턴 - 마틴 파울러

스트랭클러 무화과 나무(strangler fig) - 출처 :https://martinfowler.com/bliki/StranglerFigApplication.html

마틴 파울러가 호주 여행을 하면서 상위 나무 가지에서 자라기 시작해서 땅에 뿌리를 내릴때 까지 아래로 자라는 위 나무를 보고 중요한 시스템를 다시 작성하는 방법에 대한 비유를 든다.

중요한 시스템을 다시 작성하는 것은, '새로운 것을 다시 만들면 되는것 아닌가?' 하고 쉽게 생각 할 수 있지만, 생각보다 훨씬 복잡하고 위험성이 있다.

마감일은 다가오고, 압력은 더 심해진다. 하지만 새로운 기능은 추가되는 것들이 있고, 기존 기능은 정상적으로 동작되어야한다. 이전 버그 또한 다시 작성된 시스템에 추가되기도 한다.

 

새로 작성하는 대신, 대안의 방법은 점진적으로 새로운 시스템을 기존의 가장자리로 부터 생성해 나가는 것이다.

기존 시스템이 교살될 때까지 (죽을때 까지) 몇 년에 걸쳐 천천히 성장하도록 내버려 두는 것이다.

이 작업을 수행하는 것이 어렵게 들리지만, 충분히 시도되지 않은 방법 중 하나라고 생각한다.

기초적인 전략은 EventInterception으로서 점진적으로 기능을 스트랭글러 무화과로 옮겨 가면서 AssetCapture를 가능하게 한다.

 

다시 프로그램을 작성하는 것 보다 스트랭글러 무화과 애플리케이션을 고려하는 것의 가장 중요한 이유는 위험 감소다.

스트랭글러 무화과는 꾸준히 가치를 줄 수 있고, 자주 릴리즈 하면서 진행 상황을 더 주의깊게 모니터링할 수 있다.

사람들은 이 스트랭글러 무화과가 더 비용이 발생할 것이라 생각하기에 고려하지 않지만, 마틴 파울러는 이에 확신하지 못하는 것이, 더 짧은 릴리즈 사이클을 사용하기에 재작성이 필요한 불필요한 기능을 피할 수 있기 때문이다.

 

또한, 새로운 어플리케이션을 디자인 할때, 미래에 교살되기 쉽도록 디자인을 해야한다.

우리가 현재 작성하는 것은 내일의 레거시가 된다.

스트랭글러 무화과를 미래에 추가하기 쉽도록 만들면서, 오늘의 일이 우아하게 사라지는 것을 가능하게 한다.

 

2. 마이크로스프트의 Strangler-fig 설명

특정 기능을 새로운 애플리케이션 및 점진적으로 교체해 레거시 시스템을 단계으로 마이그레이션 한다.

레거시 시스템의 기능이 교체되면 결국 기존 시스템의 모든 기능을 대체하여 기존 시스템을 중단하고 서비스를 해제할 수 있다.

 

 

(1) 컨텍스트 및 문제점

시스템 사용 기간이 오래되면서, 기존의 개발도구, 호스팅 기술, 구축된 시스템 아키텍처 등 점차 사용하지 않게 될 수 있다. 이때, 새로운 기능이 추가되면 애플리케이션의 복잡성이 매우 증가해 새 기능을 유지 관리 / 추가 하는 것이 더 어려워질 수 있다.

복잡한 시스템을 완전히 교체하는 것은 매우 어려운 작업일 수 있기에, 경우에따라 아직 마이그레이션 되지 않은 기능을 처리하도록 기존 시스템을 유지하면서 점진적으로 새 시스템으로 마이그레이션해야 한다.

그러나 애플리케이션의 두 개의 별도 버전을 실행하려면 클라이언트가 특정 기능의 위치를 파악해야 한다.

기능 또는 서비스를 마이그레이션 할 때마다 새 위치를 가리키도록 클라이언트를 업데이트 해야한다.

 

(2) 해결 방법

출처 : https://learn.microsoft.com/ko-kr/azure/architecture/patterns/strangler-fig

특정 부분의 기능을 새로운 애플리케이션 및 서비스로 점진적으로 교체한다.

백엔드 레거시 시스템으로 이동하는 요청을 가로채는 외관을 만든다. (Strangler Facade) 

외관은 레거시 애플리케이션 또는 새 서비스로 이러한 요청을 라우트 한다.

기존 기능을 새로운 시스템으로 점차적으로 마이그레이션 할 수 있으며, 클라이언트는 마이그레이션이 발생한 것을 인식하지 못하고 동일한 인터페이스를 계속 사용할 수 있다.

 

이러한 패턴을 통해 마이그레이션의 위험을 최소화하고 시간이 지남에 따라 개발 활동을 분산할 수 있다.

레거시 애플리케이션이 사용자에게 계속 작동하도록 하면서 원하는 속도로 새 시스템에 기능을 추가할 수 있다.

시간이 지남에 따라 새 시스템에 기능이 마이그레이션되므로 결국 레거시 시스템은 교살되고 더이상 필요 없어 진다. 이 프로세스가 완료되면 레거시 시스템을 안전하게 사용 중지 할 수 있다.

 

(3) 문제 및 고려사항

• 새 시스템 및 레거시 시스템 모두에서 잠재적으로 사용되는 서비스 및 데이터 저장소를 처리하는 방법을 고려한다. 둘다 리소스에 병행해 엑세스 할 수 있는지 확인한다.
• 향후 strangler-fig에서 쉽게 가로채고 대체할 수 있는 방식으로 새 애플리케이션 및 서비스를 구성해야한다.
• 어느 시점에 마이그레이션이 완료되면 strangler-fig 외관은 사라지거나 레거시 클라이언트용 어댑터로 발전한다.
• 외관에서 마이그레이션이 지속되는지 확인한다.
• 외관이 단일 실패 지점 또는 성능 병목 상태가 되지 않도록 확인한다.

(4) 이 패턴을 사용해야 하는 경우

백엔드 애플리케이션을 새로운 아키텍처로 점진적으로 마이그레이션 하는 경우 이 패턴을 사용한다.

대량 교체의 복잡성이 낮은 소규모 시스템이거나 백엔드 시스템에 대한 요청을 가로챌 수 없는 경우는 이 패턴이 적합하지 않을 수 있다.

 

참고 링크 :https://martinfowler.com/bliki/StranglerFigApplication.html

bliki: StranglerFigApplication

https://learn.microsoft.com/ko-kr/azure/architecture/patterns/strangler-fig

스트랭글러 그림 패턴 - Azure Architecture Center