서비스의 규모가 확장되고, 데이터 저장 및 통신을 클라우드를 통해 요즘 시대에 기존의 방식인 모놀리식 (Monolithic Arcitecture)과 대비되는 MSA (Microservices Architecture)가 대두되고 있다. MSA와 모놀리식은 소프트웨어 애플리케이션을 설계하고 구축하는 두 가지 주요한 접근 방식이다. 이번 포스팅을 통해 MSA와 모놀리식의 차이점을 짚어보자.
1. 모놀리식(Monolithic Architecture)
애플리케이션은 하나의 아키텍처로 구성되어 있다. 대부분의 기업용 애플리케이션은 하나의 아키텍처를 두는 모놀리식으로 개발되었다. 모놀리식 아키텍처는 개발과 관리가 용이하다는 장점이 있으나, 시스템이 복잡해지고 커질수록 이해하기가 어려워져 유지보수가 어려워진다. 또한 사소한 것이라도 수정을 한다면 전체를 다시 빌드, 배포해야 한다는 점에서 서비스의 크기와 비례하여 시스템이 무거워진다.
장점
모든 기능들이 하나의 시스템에서 동작하므로 서버 환경, DB 환경이 하나이기에 환경 세팅 시간 소요가 상대적으로 적고, 환경을 고려한 개발이 쉽다. 그리고 모든 기능들이 하나의 시스템에서 동작함로, 모든 기능들에 대한 테스트를 하기 쉽다.
단점
하지만 하나의 시스템에 모든 기능이 담겨있다면 기능 하나가 수정되면 전체를 다시 빌드하고 배포해야한다. 만약 시스템의 크기가 크다면 빌드 및 배포 시간이 늘어난다는 것을 의미한다. 즉, 버그나 수정사항의 즉시 적용이 어렵다. 이와 같은 사항으로 특정 기능에 오류가 발생했을 때, 해당 오류로 인해 시스템이 죽으면 전체가 시스템이 먹통이 될 수 있는 특성이 있다. 마지막으로 하나의 시스템으로 구성되기 때문에 기능별로 알맞은 언어 및 프레임워크를 선택하기 어렵다. 쉽게 말하면 스프링으로 개발했다면, 스프링을 다룰 수 있는 개발자들만이 필요하다는 말이다.
모놀리식 한 눈에 보기
- 단일 모듈 구조
- 애플리케이션은 단일 모듈 또는 단일 코드베이스로 구성
- 주로 하나의 프로젝트 내에서 모든 기능과 컴포넌트가 통합되어 있다.
- 단일 데이터베이스
- 모든 기능이 하나의 데이터베이스에 접근
- 데이터베이스 스키마는 애플리케이션 전체에 공유
- 모듈 간 강한 결합
- 서로 다른 기능들이 밀접하게 결합되어 있어, 한 부분의 변경이 다른 부분에도 영향을 끼친다.
- 스케일링 어려움
- 특정 기능만 확정하거나 업데이트하기 어려우며, 전체 애플리케이션을 함께 업데이트해야 할 수 있다.
- 배포와 확장이 비교적 어려움
- 전체 애플리케이션을 한 번에 배포하고 확장해야 한다.
2. MSA (마이크로서비스 아키텍처, Microservices Architecture)
여러 모듈을 조합하여 애플리케이션을 구현하는 방식으로 모듈마다 자체 DB를 가지고 있기 때문에, 개발부터 배포까지 효율적으로 수행할 수 있다. 하지만 독립적이고 확장성을 고려한 설계가 어려운 점과, 모듈이 나눠져 있어 트랜잭션 처리가 어렵다는 단점이 있다. 즉, MSA란 여러 비즈니스 로직은 기능(모듈)별 각자의 DB 환경을 공유하고, 모듈별로 애플리케이션과 독립적으로 통신하는 것을 확인할 수 있다.
장점
각각의 기능들이 서로 독립적인 시스템으로 구성되어 있기 때문에 하나의 기능을 개발할 때 봐야 할 코드의 수도 적으며, 이해하기 쉽다. 적고 작은 만큼 유지보수가 쉽다는 뜻이다. 그래서 하나의 서비스에 해당하는 문제는 해당 서비스만 수정하여 빌드 및 배포하면 되므로 모놀리식에 비해 상대적으로 빠르다. 그리고 각 기능에 맞는 언어와 프레임워크를 선택할 수 있다.
단점
독립적으로 기능별 서비스가 나뉘어져 있는 만큼 되려 관리가 힘들 수 있다. 분산되어 있어 관리 및 모니터링이 힘들다. 그리고 모듈별로 애플리케이션과 통신하므로 다양한 통신에서 발생하는 오류가 상대적으로 잦다. 마지막으로 통합테스트 과정에서 각각의 모듈과 Gateway 등을 구동시켜야 하기 때문에 상대적으로 통합테스트 하기 어렵다는 단점이 있다.
MSA 한 눈에 보기
- 분리된 작은 서비스
- 애플리케이션은 작은 독립적인 서비스로 나뉜다. 각 서비스는 특정한 업무를 수행한다.
- 독립적인 데이터베이스
- 각 서비스는 필요에 따라 자체 데이터베이스를 가질 수 있다.
- 서비스 간 데이터 공유를 위해 API나 이벤트 기반 통신을 사용한다.
- 느슨한 결합
- 서비스 간의 결합도가 낮아, 한 서비스의 변경이 다른 서비스에 영향을 끼치지 않는다.
- 독립적인 확장
- 특정 서비스만 확장하거나 업데이트할 수 있다. 필요한 경우, 서비스를 추가하거나 제거할 수 있다.
- 배포 용이성
- 각 서비스는 독립적으로 배포할 수 있으며, 이는 빠르고 안전한 업데이트를 가능하게 한다.
- 기술 다양성
- 서비스 간에 다양한 기술을 사용할 수 있다. 각 서비스가 자체적으로 선택한 언어나 프레임워크를 사용할 수 있다.
3. 글을 마치며
- Monolithic은 간단한 애플리케이션을 빠르게 개발하고 배포할 때 유용할 수 있습니다.
- Microservices는 복잡한 애플리케이션 또는 대규모 팀이 작업하는 경우 유용할 수 있습니다. 또한 서비스 간의 독립성과 확장성이 필요한 경우에 적합합니다.
각 프로젝트의 요구사항과 팀의 구성원, 개발/배포 프로세스에 따라서 어떤 아키텍처를 선택할지 고려해야 합니다. 때로는 두 가지 아키텍처를 혼합해서 사용하는 하이브리드 방식도 적용될 수 있습니다.
마무리 쓸없 Tip. (쓸모없는 or 쓸모없지않은...)
- 공부할 때 해당 내용을 도식화 하면 이해하는데 큰 도움과 좋은 자료가 된다.