개발문화탐구: 데브옵스 (DevOps) - Strangler Pattern: Migrate to Microservices
들어가기 전
이 포스트는 이전 포스트 마이크로 서비스 vs 모놀리식 서비스와 이어집니다.
매우 쉬운 내용이니 간단하게 훑고 오셔도 좋을 듯.
[개발문화탐구] 데브옵스 (DevOps) - 마이크로서비스 vs 모놀리식서비스
서비스 아키텍처의 진화
위 트렌드 그래프를 보면 아시겠지만, 마이크로 서비스에 관한 관심이 점차 많아지고 있습니다.
이전 포스트에서는 모놀리식 서비스도 경우에 따라서 더 좋을 수도 있다곤 했지만, 대부분에 서비스는 마이크로 서비스가 더 적합하다고 생각됩니다.
그럼 모놀리식 서비스는 어떻게 마이크로 서비스로 이전할 수 있을까요?
기존 서비스의 기능을 새로운 아키텍처로 처음부터 다시 짜야 할까요?
교살자 애플리케이션 패턴(Strangler Application Pattern)
유래
2004년 마틴 파울러옹이 호주 여행 중 본 덩굴을 보고 만든 용어입니다.
괴상한 넝쿨이 숙주 나무 위쪽 가지에 씨를 뿌리고, 나무를 타고 내려가며 성장.
결국, 숙주 나무를 죽이고 덩굴은 되려 환상적이고 아름다운 모양으로 자라는 걸 보고 말이죠.
점진적인 마이그레이션
위에서 말한 괴상한 넝쿨처럼, 기존 모놀리식 서비스의 기능별로 반복적으로 분리합니다.
이렇게 하면 새로운 아키텍처로 모든 기존 기능을 한 번에 다시 만들 필요가 없으며, 점진적으로 마이그레이션을 진행해 나갈 수 있습니다.
점진적인 마이그레이션을 통해 위험을 최소화하며, 유저는 이런 변화를 인식하지 못하고 동일한 서비스를 사용하게 됩니다.
여기서 중요한 점은 기존의 레거시 코드를 계속 유지해야 한다는 것입니다.
필요에 따라(오류 or 특정 상황) 이전 시스템을 호출할 수도 있어야 하기 때문에 마이그레이션을 하는 중에는 레거시 코드에 새로운 코드를 추가하지 않고, 새로운 코드를 새로운 서비스로 만들어야 합니다.
대상
헤아릴 수 없을 정도로 수많은 기업이 서비스 구조 개선 혹은 리팩토링을 위해 사용해온 패턴입니다.
교살자 패턴으로 이동된 최초의 서비스 사례는 무려 20년 전 IBM AS/400 중급 서버용 주문 관리시스템입니다.
시스코에서도 자사의 ERP 시스템을 클라우드로 옮길 때 교살자 패턴을 사용했습니다.
말이 필요 없을 정도로 많은 서비스가 리팩토링을 위해 이미 사용하던 패턴이지만 Strangler Application Pattern 용어는 자체는 마이크로 서비스를 위해서 정의된 듯 합니다.
보통 많은 서비스들이 이 패턴 이름은 몰랐어도 어느정도 이런 식으로 마이그레이션을 해왔을 것이라 생각합니다.
용어만 조금 낯설지 개념은 많은 분이 이미 알고 있으실 듯!
참고
StranglerApplication - martinfowler.com
Strangler Pattern: How to Keep Sane With Legacy Monolith Applications | OverOps Blog
스트랭글러 패턴 | Microsoft Docs
Refactoring a Monolith into Microservices - NGINX
마치며
교살자라는 용어를 사용해서 뭔가 좀 살벌하네요.. ㅋㅋ