프로젝트 시작 시 모놀리스 VS 마이크로 서비스?

처음 프로젝트를 시작 시 시스템을 Monolith로 시작할 것인지 마이크로 서비스로 시작할 것인지 고민이 있을 수 있습니다. 제 경험 상 한 팀에서 개발을 진행한다면 가능하면 마이크로 서비스를 사용하지 말라고 조언하고 싶습니다. 각 Aggregate 별 시스템의 리소스를 얼마나 사용하는지도 모르는 상태에서 마이크로 서비스 아키텍처를 수용하게 되면 관리 포이트만 많아지기 때문에 피곤한 일이 자주 발생합니다. 지금도 불필요하게 시스템을 작게 쪼개놓아서 새로운 개발자가 이해하기도 어렵고, 유지보수에 시간이 더 많이 소요되고 있거든요. 이와 관련된 좋은 내용이 있어 공유해 드립니다. 마틴 파울러 형님의 글이고, 원본은 이곳에서 읽으실 수 있습니다.

https://martinfowler.com/bliki/MonolithFirst.html

bliki: MonolithFirst

내가 마이크로 서비스 아키텍처를 사용하는 팀에 대해 들을 때마다 자주 듣게 되는 이야기가 있습니다.

1. 거의 모든 성공적인 마이크로 서비스 스토리는 처음에는 거대한 모놀리스 아키텍처에서 시작하였으나 작은 마이크로 서비스로 쪼개서 재개발을 진행하였다는 점.
2. 처음부터 마이크로 서비스로 시작한 대부분의 경우는 심각한 문제들을 일으켰다는 점

이 두가지 사실은 나의 동료들과 우리는 새로운 프로젝트 시작 시 아무리 시스템이 크더라도 절대 마이크로 서비스로 시작하면 안 된다는 주장을 하게되었습니다. 

마이크로서비스는 유용한 아키텍처이지만 옹호자들조차 마이크로서비스 아키텍처를 사용하면 상당한 프리미엄(프리미엄이란 이득이 아닌 비용의 발생을 의미함)이 발생한다고 말합니다. 즉, 아주 복잡하여 세분화해야 하는 시스템에나 마이크로 서비스가 적합하다는 뜻입니다. 기본적으로 서비스 제품군을 관리하는데 드는 비용이라는 것은 팀 속도를 늦추게 하고, 단순한 모놀리스 애플리케이션을 선호하게 만듭니다. 이는 나중에 마이크로서비스 아키텍처의 이점을 얻을 가능성이 있다고 생각하더라도 초기에 새로운 애플리케이션을 모놀리스로 우선적으로 빌드해야 전략에 대한 강력한 주장으로 이어집니다.

그 첫 번째 이유는 고전적인 Yagni(You aren't gonna need it는 프로그래머가 필요하다고 간주할 때까지 기능을 추가하지 않는 것이 좋다는 익스트림 프로그래밍(XP)의 원칙이다)입니다. 새 응용 프로그램을 시작할 때 사용자에게 유용할 것이라고 얼마나 확신하십니까? 확장성에 대해 제대로 설계되지 않았지만 잘 돌아가는 어플리케이션 시스템을 확장하는 것은 어려울 수 있지만 반대의 경우보다는 여전히 더 낫습니다. 우리가 지금 인식하고 있는 것처럼 소프트웨어 아이디어가 유용한지 알아보는 가장 좋은 방법은 단순한 버전을 만들고 그것이 얼마나 잘 작동하는지 확인하는 것입니다. 이 첫 번째 단계에서는 개발 속도(사용자 피드백 주기)에 우선 순위를 부여해야 하므로 마이크로서비스의 비용을 최소화로 해야 합니다.

마이크로서비스를 시작할 때의 두 번째 문제는 서비스 간에 훌륭하고 안정적인 경계가 있는 경우에만 제대로 작동한다는 것입니다. 이는 본질적으로 올바른 Bounded Context 집합을 그리는 작업입니다. 서비스 간의 기능 리팩토링은 모놀리스에서보다 훨씬 어렵습니다. 게다가 친숙한 영역에서 작업하는 숙련된 아키텍트라도 처음에는 경계를 바로 잡는 데 큰 어려움을 겪습니다. 먼저 모놀리스를 구축하면 마이크로서비스 설계가 서로 간의 경계를 제대로 파악하지 못해 중구난방의 시스템이 되는 것을 방지하면 올바른 경계가 무엇인지 파악할 수 있습니다. 또한 세분화된 서비스에 필요한 Microservice Prerequisites를 개발할 시간을 제공합니다.

나는 모놀리스 우선 전략을 실행하는 다양한 방법을 들었습니다. 논리적인 방법은 API 경계와 데이터 저장 방식에서 소프트웨어 내의 모듈성에 주의하면서 모놀리스를 신중하게 설계하는 것입니다. 이를 잘 수행하면 마이크로서비스로 전환하는 것은 비교적 간단한 문제입니다. 그러나 나는 이 방법이 그런 식으로 효과가 있었다는 상당한 수의 이야기를 들었다면 이 접근 방식이 훨씬 더 편안하다고 느낄 것입니다.

보다 일반적인 접근 방식은 모놀리스로 시작하여 가장자리에서부터 마이크로서비스로 전환하는 것입니다. 이러한 접근 방식은 마이크로서비스 아키텍처의 핵심에 상당한 모놀리스를 남길 수 있지만, 마이크로 서비스로 전환 개발로 인해 모놀리스는 비교적 작은 포션을 차지할 것입니다.

또 다른 일반적인 접근 방식은 모노리스를 완전히 교체하는 것입니다. 이것을 자랑스러워 할 접근 방식으로 보는 사람은 거의 없지만 프로젝트 초기에 Sacrificial Architecture(지금 짜고 있는 코드가 최상의 코드가 아니라 조만간 폐기될 것이라는 믿음)로 모놀리스를 구축한다는 생각한다면 이 접근 방식은 이점이 있습니다. 특히 단일체가 시장에 빨리 출시될 수 있는 경우 폐기할 단일체를 구축하는 것을 두려워하지 마십시오.

내가 만난 또 다른 경로는 예상보다 큰 몇 가지 거친 서비스로 시작하는 것입니다. 이러한 대략적인 서비스를 사용하여 여러 서비스와의 작업에 익숙해지십시오. 이러한 작은 작업들이 향후 수행해야 하는 서비스 간 리팩토링의 양을 줄여준다는 사실을 즐기십시오. 그런 다음 경계가 안정화되면 세분화된 서비스로 세분화하면 됩니다.

내 주의의 대부분은 모놀리스 우선 접근 방식을 선호하지만 만장일치로 동의하는 것은 아닙니다. 반대 주장에 따르면 마이크로 서비스로 시작하면 마이크로 서비스 환경에서 개발하는 리듬에 익숙해질 수 있다고 하지만, 모놀리스를 마이크로서비스로 쉽게 나눌 수 있도록 충분히 모듈화된 방식으로 구축하려면 많은, 아마도 너무 많은 훈련이 필요합니다. 마이크로 서비스로 시작하면 처음부터 모든 사람이 별도의 소규모 팀에서 개발하는 데 익숙해지고 팀을 서비스 경계로 분리하면 필요할 때 개발팀을 훨씬 쉽게 확장할 수 있습니다. 이것은 초기에 안정적으로 충분한 경계를 찾을 수 있는 더 나은 기회가 있는 시스템 교체에 특히 유용합니다. 증거가 희박하지만 팀에서 마이크로 서비스 시스템을 구축한 합리적인 경험이 없으면 마이크로 서비스로 시작해서는 안된다고 생각합니다.

모놀리식 우선 전략을 사용할지 여부를 결정하는 방법을 확실히 다루기에는 아직 케이스가 충분하지 않다고 생각합니다. 이것은 마이크로 서비스의 초기 단계이므로 배울 수 있는 케이스 상대적으로 적습니다. 따라서 이러한 주제에 대한 누군가의 조언은 그들이 아무리 자신있게 주장하더라도 바로 받아들이기 보다는 충분한 검토를 거쳐야 합니다.