TL;DR

  • 새 시스템은 나중에 마이크로서비스가 필요할 것 같더라도 우선 모놀리스로 구축하는 편이 대체로 유리하며, 성공한 마이크로서비스 사례 대부분도 너무 커진 모놀리스에서 출발함.
  • 마이크로서비스 프리미엄(Microservice Premium)은 서비스 묶음 관리 비용으로 팀의 속도를 늦추므로, 초기에는 빠른 개발과 피드백 주기를 중시하는 모놀리스가 적합함.
  • 안정적인 서비스 경계를 처음부터 정하기는 어려우며, 모놀리스에서 경계를 파악한 뒤 분리하면 기능 재설계와 서비스 간 리팩터링 부담을 줄일 수 있음.
  • 모놀리스 우선 전략은 모듈을 점진적으로 분리하거나, 모놀리스를 교체하거나, 거친 단위의 서비스 몇 개에서 시작해 경계가 안정되면 세분화하는 방식으로 실행할 수 있음.
  • 처음부터 마이크로서비스로 시작하는 방식도 팀의 서비스 개발 경험이 충분하고 경계가 일찍 안정될 가능성이 큰 시스템 교체 프로젝트에서는 고려할 수 있지만, 이를 뒷받침하는 사례는 제한적임.

모놀리스 우선

  • 마이크로서비스를 성공적으로 도입한 사례 대부분은 너무 커진 모놀리스를 분해하면서 시작했으며, 처음부터 마이크로서비스 시스템으로 구축한 사례는 심각한 문제에 빠지는 경우가 많음.
  • 이러한 패턴을 근거로 동료 다수는 애플리케이션이 커질 것이라고 확신하더라도 새 프로젝트를 마이크로서비스로 시작하지 말아야 한다고 주장함.
  • 마이크로서비스는 유용한 아키텍처지만, 지지자들도 서비스 묶음 관리 비용인 마이크로서비스 프리미엄이 상당하다고 인정함. 따라서 복잡한 시스템에서만 유용할 수 있으며, 단순한 애플리케이션에서는 팀의 속도를 늦춰 모놀리스에 유리하게 작용함.
  • 이에 따라 새 애플리케이션을 우선 모놀리스로 만들고, 나중에 마이크로서비스 아키텍처가 유리해지더라도 전환을 미루는 모놀리스 우선 전략이 설득력을 가짐.
  • 첫 번째 이유는 고전적인 YAGNI(You Aren’t Gonna Need It) 원칙임. 새 애플리케이션이 사용자에게 유용할지 확신하기 어려우며, 설계가 나쁜 성공적인 소프트웨어 시스템을 확장하는 일이 어렵더라도 그 반대 상황보다는 나음.
  • 소프트웨어 아이디어의 유용성을 확인하는 가장 좋은 방법은 단순한 버전을 만들어 실제로 얼마나 잘 작동하는지 살펴보는 것인 경우가 많음. 이 초기 단계에서는 속도와 피드백 주기를 우선해야 하므로 마이크로서비스 프리미엄은 부담으로 작용함.
  • 두 번째 이유는 마이크로서비스가 서비스 간 안정적인 경계, 즉 적절한 바운디드 컨텍스트(Bounded Context)를 정하는 데 달려 있기 때문임.
  • 서비스 간 기능을 리팩터링하는 일은 모놀리스 내부에서 같은 작업을 하는 것보다 훨씬 어려움.
  • 익숙한 도메인에서 일하는 숙련된 아키텍트조차 처음부터 경계를 올바르게 정하기 어려움.
  • 먼저 모놀리스를 구축하면 마이크로서비스 설계가 경계에 부담을 더하기 전에 적절한 경계를 파악할 수 있으며, 세분화된 서비스를 위한 마이크로서비스 전제 조건(Microservice Prerequisites)을 개발할 시간도 확보됨.
  • 모놀리스 우선 전략을 실행하는 한 가지 방법은 소프트웨어의 모듈성에 주의를 기울여 모놀리스를 세심하게 설계하는 것임. API 경계와 데이터 저장 방식 모두를 고려해야 하며, 이를 잘하면 마이크로서비스로 비교적 쉽게 전환할 수 있음. 다만 이 방식이 성공한 사례를 충분히 접하기 전까지는 확신하기 어려움.
  • 임의의 시스템을 마이크로서비스로 분해할 수 있다고 가정할 수 없음. 대부분의 시스템은 모듈 사이에 의존성이 지나치게 많이 생겨 합리적으로 분리하기 어려움.
  • 모놀리스 분해를 시도했다가 빠르게 엉망이 된 사례도 많음. 점진적인 마이크로서비스 전환에 성공한 사례도 일부 있지만, 처음부터 비교적 우수한 모듈형 설계가 필요했음.
  • 더 흔한 방식은 모놀리스의 가장자리에서 마이크로서비스를 점진적으로 떼어내는 것임. 이 방식은 마이크로서비스 아키텍처 한가운데 상당한 규모의 모놀리스를 남길 수 있지만, 모놀리스가 비교적 안정된 상태를 유지하는 동안 새로운 개발 대부분은 마이크로서비스에서 진행됨.
  • 또 다른 흔한 방식은 모놀리스를 완전히 교체하는 것임. 이를 자랑스러운 접근 방식으로 보는 사람은 많지 않지만, 모놀리스를 희생 아키텍처(Sacrificial Architecture)로 구축하는 데에는 장점이 있음. 모놀리스로 시장에 빠르게 진입할 수 있다면 나중에 폐기할 모놀리스를 만드는 일을 두려워할 필요가 없음.
  • 처음부터 예상하는 것보다 큰 단위의 서비스 두어 개로 시작하는 방법도 있음. 이런 거친 단위의 서비스를 통해 여러 서비스를 운영하는 데 익숙해지는 동시에, 서비스 간 리팩터링을 줄일 수 있음. 경계가 안정되면 더 세분화된 서비스로 나눔.
  • 엄밀히는 이를 ‘듀올리스(duolith)’라고 불러야 할 수도 있지만, 먼저 거친 단위로 시작해 지식을 얻고 나중에 분리한다는 점에서 모놀리스 우선 전략의 핵심을 따르는 방식임.
  • 주변의 다수는 모놀리스 우선 접근을 지지하지만, 의견이 모두 일치하는 것은 아님.
  • 반대 의견은 마이크로서비스로 시작하면 마이크로서비스 환경의 개발 리듬에 익숙해질 수 있다는 것임.
  • 모놀리스를 나중에 쉽게 분해할 수 있을 만큼 모듈화하려면 상당한, 어쩌면 지나치게 많은 규율이 필요함. 마이크로서비스로 시작하면 각자가 작은 팀에서 개발하는 방식에 일찍 익숙해지고, 서비스 경계에 따라 팀을 분리하면 필요할 때 개발 규모를 확장하기 쉬움.
  • 안정적인 경계를 초기에 정할 가능성이 더 높은 시스템 교체 프로젝트에서는 이 방식이 특히 실현 가능함. 근거가 충분하지는 않지만, 팀에 마이크로서비스 시스템 구축 경험이 어느 정도 없다면 처음부터 마이크로서비스로 시작하지 않는 편이 좋다는 판단임.
  • 모놀리스 우선 전략을 언제 선택할지 확고한 결론을 내릴 만큼 사례가 충분하지 않음. 마이크로서비스는 아직 초기 단계이고 참고할 사례도 비교적 적으므로, 이 주제에 관한 조언은 아무리 자신감 있게 제시되더라도 잠정적인 것으로 봐야 함.

추가 읽을거리

  • Sam Newman이 그린필드 프로젝트에서 마이크로서비스 도입을 검토한 팀의 사례 연구를 설명함.

주석

  • 임의의 시스템을 마이크로서비스로 분해할 수 있다고 가정할 수 없음. 대부분의 시스템은 모듈 사이의 의존성이 지나치게 많아 합리적으로 나누기 어려움. 모놀리스 분해를 시도했다가 빠르게 엉망이 된 사례가 많으며, 점진적인 전환에 성공한 일부 사례는 처음부터 비교적 우수한 모듈형 설계를 갖추고 있었음.
  • 엄밀히는 ‘듀올리스(duolith)’라고 부를 수도 있지만, 거친 단위로 시작해 지식을 얻고 나중에 분리한다는 점에서 모놀리스 우선 전략의 핵심을 따르는 방식임.

감사의 말

  • James Lewis, Sam Newman, Thiyagu Palanisamy, Evan Bottcher에게서 많은 생각을 얻음.
  • 이전 초안에 대한 Stefan Tilkov의 의견이 생각을 명확히 하는 데 중요한 역할을 함.
  • Chad Currie가 멋진 글리피 드래곤을 제작함.
  • Steven Lowe, Patrick Kua, Jean Robert D'amore, Chelsea Komlo, Ashok Subramanian, Dan Siwiec, Prasanna Pendse, Kief Morris, Chris Ford, Florian Sellmayr가 내부 메일링 리스트에서 초안을 논의함.