모놀리식 애플리케이션의 분해(분리) 전략 - Microservice

많은 서비스들이 성장하면서 모놀리식 애플리케이션(Monolithic Application) 이 된다. 비즈니스 피처를 붙이고 붙이다 보면 거대한 하나의 덩어리가 되고 기술 부채가 눈덩이처럼 쌓여서 팀의 퍼포먼스를 떨어뜨리는 요인으로 작용하는게 일반적이다.

이때 팀에서는 마이크로 서비스로 분리할 대상을 찾은 뒤에 어떤 전략을 실행해야하는지 선택해야 한다.

가장 일반적으로 선택할 수 있는 전략 두가지를 이야기하고자 한다.

 

모놀리식 애플리케이션의 분해 전략

1. 컴포넌트 기반 분해(Component-bated Decomposition)
   • 컴포넌트 기반 분해는 (애플리케이션의 논리적 구성 요소인) 컴포넌트를 정제/추출한 후 분산 아키텍처를 점진적으로, 제어 가능한 방향으로 구성하면서 다양한 리팩터링 패턴을 적용하는 방법
2. 전술적 분기(Tactical Forking)
   • 전술적 분기는 애플리케이션의 레플리카(Replica, 사본)을 만들고 필요 없는 부분을 하나씩 잘라내며 서비스를 조금씩 완성해 나가는 방법

분해 전략을 선택하는 기준

코드베이스를 분해할 수 있는지 따져보는 것이 먼저다.

코드의 컴포넌트가 Loose Coupling된 상태로 잘 관리되어 있다면 컴포넌트 기반 분해를 한다. 그렇지 않고 코드 베이스가 엉킨 실타래처럼 뒤섞여 있다면 전술적 분기를 한다.

function String get_시스템_분해_전략() {
	if ("컴포넌트가 체계적으로 구성되어 있는가?(Loose Coupling)" == true) {
		return "컴포넌트 기반 분해"
	} else {
		// 코드가 얽혀있는 엉킨 실타래 상태. IDE를 열었을때 책상을 엎어버리고 싶다면...
        return "전술적 분기" 
	}

컴포넌트 기반 분해(Component-bated Decomposition)

컴포넌트 기반으로 잘 정리된 코드 베이스에서 분리할 대상을 리팩토링하면서 조심조심 살~살~ 분리하는 작업 방식이다. 수술실에서 종양을 제거하는 수술처럼 아주 정교한 작업이 될 것이다.

전술적 분기(Tactical Forking)

시스템을 일부 추출한다는 개념을 뒤집어서 생각해보면 불필요한 부분을 제거한다는 것과 동일하다.

실행 순서
1. 모놀리스를 복제한다.
2. (Iteration) 팀별로 필요 없는 코드를 제거한다.
3. 최종적으로 두개의 서비스로 분리된다.

 

Pros/Cons

Pros

• 사전 분석에 많은 시간이 들어가지 않는다. 곧바로 할 수 있다.
• 개발자들의 거부감이 덜든다. 대체로 삭제에 대한 거부감이 적다.

Cons

• 빠르게 작업하더라도 모놀리스 코드가 서비스에 상당히 많이 남는다.
• 모놀리스의 난잡한 코드 형태가 개선되지 않는다.
• 기존 코드와 신규 코드가 구분이 안된다.

시스템의 분리에 초점을 맞춘 방법이다. 코드 베이스를 정리하고 개선하는 리팩토링은 별도로 진행해야 한다.(그래도 팀이 예전보다는 훨씬 빠르고 독립적인 개선 활동이 가능해진다.)

 

Conclusion

시스템을 분리하는 단 하나의 은탄환(Silver Bullet)은 없다. 현재 코드와 시스템의 상황에 맞춰서 유연하게 접근해야 한다.