하나의 거대한 모놀리스로 되어 있는 오래된 시스템을 구조 개선을 하기 위해 분석중이다. 분석을 시작하기 전에는 마이크로서비스에 대한 언급이 많았다. 마이크로서비스는 훌륭한 방법이긴 하다. 모듈식이며 확장 가능하고 내결함성도 좋다. 이름만 들어도 익히 알고 있는 유명한 곳에서 이 모델을 사용하여 큰 성공을 거두었기에 마이크로서비스로 아키텍처를 잡는 것이 훌륭하게 보일 수 있다.
그러나 마이크로서비스로 성공한 대부분의 기업은 처음부터 마이크로서비스로 시작하진 않았다. 트위터나 에어비앤비 같은 경우는 마이크로서비스로 전환을 했지만, 현재 복잡성과 대면을 하고 있다. 마이크로서비스를 사용해서 성공한 회사도 최선의 방법을 계속 찾고 있는 것이다.
모놀리스에서 마이크로서비스로 개선하는 것은 간단한 작업도 아니고… 더군다나 PL/SQL, DB Custom Function, Trigger, EAI로 도배되어 있는 현 시스템을 바로 전환하기에는 무리가 있다. 궁극적으로는 향후에는 마이크로서비스로 갈 것이지만, 기술 부채를 먼저 해결하는 Goal을 설정했다. 그 이유는 아래와 같다.
마이크로서비스는 성숙한 제품이어야 가능
마틴파울러가 작성한 MonolithFirst(https://martinfowler.com/bliki/MonolithFirst.html) 에는 마이크로서비스로 시작하는 경우에 대한 케이스가 있다.
- 성공적인 마이크로서비스는 너무 거대해서 부서지게된 모놀리스에서 시작한 경우
- 처음부터 마이크로서비스로 구축된 시스템이 실패로 끝나는 경우
초기 설계를 제대로 하지 못한다면 모놀리스보다 마이크로서비스를 리팩토링하는 것이 훨씬 어렵기에 초기 설계를 잘해야 한다. 현재는 마이크로서비스로 전환한다라고 얘기할 단계가 아니고, 더욱 성숙되게 만드는 작업이 우선시되어야 한다.
내가 일하고 있는 회사는?
스타트업에서 처음 서비스를 만든다고 가정하면 초반에는 확장성이 필요하지 않을 것 같다. 아마도 필요한 시점은 서비스 런칭 후 몇 년내에 발생할 것이다. (잘 된다는 가정) 따라서, 처음부터 복잡한 아키텍처를 선택할 이유는 없을 것이다.
반면, 이미 운영되고 있는 서비스는 얘기가 달라진다. 확장성과 유연성이 필요할 것이다. (현재 내 상황이 이렇다.) 그래서 DB에 집중되어 있는 비즈니스 로직을 애플리케이션으로 이동시키면서 Miniservice 형태의 서비스 분리를 고려중이다. (서비스별 DB 분리는 어려운 상황이다.)
어르신 시스템 생명 주기
모든 애플리케이션은 생명 주기가 존재한다. 레거시 시스템은 오래되고 복잡한 부분이 많고, 현재 사용되고 있지 않은 기술들도 많이 적용되어 있다. 이런 시스템을 마이크로서비스로 전환한다면 기존 코드를 버리는 것이 효과적일 것이다. 하지만, 작동을 하고 있는 제품을 버리기는 쉽지 않다. 비용을 고려해야 하기 때문이다. 우선 모듈화를 선행해야 한다.
모듈화에도 많은 공수가 들어가지만, 개발을 보다 간단하게 만들기 때문에 가치는 충분하다. 모듈화라는 것은 큰 모놀리스를 작게 만들기 때문이다. 모듈화는 마이크로서비스로 전환하기 전에 꼭! 필요한 단계이다. 모듈식 모놀리스로 만들면 코드는 독립적인 모듈로 분할하여 얽혀있는 코드 문제를 해결해야 한다. 모듈식 모놀리스는 마이크로서비스와는 달리 네트워크 통신이 아닌 내부 API 호출로 통신하게 된다. 기존 소스를 활용하진 않지만, 모듈형태로 구성이 되어 있는지 확인해야 하고, 되어 있지 않다면 모듈화를 설계상 고려해야 한다.
준비가 안되거나 견고한 설계 없이 마이크로서비스로 여정을 시작한다면 매우 힘든 시간을 겪을 것이다. 결국 바꾸고 싶은 모습으로 가기 위한 선행 작업들을 진행해야 한다. 최종 Goal로 가기위한 선행 조건을 만족시키는 것이 이번 프로젝트의 목표이다.(기반이 튼튼해야 하기에…)
잠깐, 글이 유익했나요?
