마이크로서비스(Microservices)가 만병통치약은 아니다!
마이크로서비스(Microservices) 아키텍처는 코드베이스(Codebase) 분할, 독립적인 팀 운영, 그리고 확장성(Scalability) 확보에 유리하지만, 과도한 도입은 오히려 문제를 야기할 수 있음
모놀리식(Monolithic) 아키텍처 내에서 모듈 경계(Module Boundaries)를 명확히 하고, 추적 시스템(Tracing System)을 구축하는 것이 우선적으로 고려되어야 함
개발자 커뮤니티에서는 마이크로서비스(Microservices) 도입의 득실에 대한 다양한 의견이 존재하며, 상황에 맞는 아키텍처 선택의 중요성을 강조함
150명 이상의 개발자 규모에서 마이크로서비스(Microservices)가 효과적일 수 있지만, 그 이하 규모에서는 오히려 복잡성(Complexity)만 증가시킬 수 있다는 지적도 있음
마이크로서비스(Microservices) 도입의 함정
게시물에 따르면, 마이크로서비스(Microservices)는 배포 파이프라인(Deployment Pipeline) 증가, 로그(Log) 관리의 어려움, 그리고 장애 지점(Failure Point) 증가를 야기할 수 있다. 특히, 14개의 서비스로 분할된 모놀리스(Monolith)는 14개의 배포 파이프라인, 로그 스트림(Log Stream), 그리고 잠재적인 장애 지점을 갖게 된다. 이는 개발팀의 운영 부담(Operational Overhead)을 가중시키며, 문제 해결 시간을 늘릴 수 있다.
모듈 경계(Module Boundaries) 설정의 중요성
게시물은 마이크로서비스(Microservices) 도입 전에 모놀리식(Monolithic) 아키텍처 내에서 모듈 경계(Module Boundaries)를 설정하고, 추적 시스템(Tracing System)을 구축할 것을 권장한다. 이는 코드베이스(Codebase)의 가독성을 높이고, 팀 간의 결합도(Coupling)를 줄이는 데 기여한다. 또한, 모듈 경계 설정은 향후 마이크로서비스(Microservices)로의 전환을 위한 기반을 마련하며, 스트랭글러 피그 패턴(Strangler Fig Pattern)을 적용하는 데 용이하게 한다.
마이크로서비스(Microservices)의 적절한 시점
게시물은 마이크로서비스(Microservices)가 적합한 경우로, 팀의 독립적인 운영, 확장성(Scalability) 요구 사항의 차이, 그리고 150명 이상의 개발자 규모를 제시한다. 특히, 결제 서비스(Payment Service)와 콘텐츠 서비스(Content Service)처럼 데이터 계층에서 서로 관련이 없는 도메인(Domain)을 분리하는 것은 독립적인 배포(Independent Deployment)를 가능하게 한다. 하지만, 작은 규모의 팀에서는 오히려 복잡성(Complexity)만 증가시킬 수 있다.
모놀리스(Monolith) vs 마이크로서비스(Microservices) 트레이드오프(Trade-offs)
모놀리스(Monolith)는 개발 및 배포가 간단하고, 코드베이스(Codebase)를 이해하기 쉽다는 장점이 있다. 하지만, 코드 변경 시 전체 시스템에 영향을 미칠 수 있으며, 확장성(Scalability)에 제약이 있을 수 있다. 반면, 마이크로서비스(Microservices)는 각 서비스의 독립적인 배포와 확장성(Scalability)을 제공하지만, 분산 시스템(Distributed System)의 복잡성, 데이터 일관성(Data Consistency) 문제, 그리고 운영 비용(Operational Cost) 증가의 위험이 있다.
