모놀리틱 아키텍처
- 모놀리틱 아키텍처란 UI, 비즈니스 로직, DB등을 하나의 패키지에 담아 빌드하고 배포하는 아키텍처이다.
- 마이크로서비스 아키텍처의 반대 개념
- 장점
- 어떤 기능(서비스)이든지 개발되어 있는 환경이 같아서 복잡하지 않음
- 쉽게 고가용성 서버 환경을 만들 수 있다.(같은 어플리케이션으로 하나 더 만들면 됨)
- End-to-End 테스트가 용이함(MAS의 경우 테스트에 필요한 서비스들을 모두 동작시켜야 함)
- 단점
- 한 프로젝트의 덩치가 너무 커져서 어플리케이션 구동시간이 늘어나고 빌드, 배포 시간도 길어진다.
- 조그마한 수정사항이 있어도 전체를 다시 빌드하고 배포를 해야한다.
- 많은 양의 코드가 몰려 있어 개발자가 모두를 이해할 수 없고 유지보수도 힘들다.
- 일부분의 오류가 전체에 영향을 미친다.
- 기능별로 알맞는 기술, 언어, 프레임워크를 선택하기가 까다롭다.
마이크로 서비스
- 하나의 큰 애플리케이션을 여러 개의 작은 애플리케이션으로 쪼개어 변경과 조합이 가능하도록 만든 아키텍처이다.
- 어플리케이션을 핵심기능 별로 세분화하고 각 기능을 서비스라고 부르며, 독립적으로 구축하고 배포할 수 있다.
- 서비스는 각자 별도의 프로세스에서 실행되며, API 와 같은 가벼운 매커니즘으로 통신하며 하나의 어플리케이션을 만든다.
- 서비스들은 각자의 비즈니스 기능을 담당하고 완전 자동화된 절차에 따라 독립적으로 배포가 가능하다.
- 서로 다른 프로그래밍 언어나 DB여도 가능하다.
- 장점
- 기능별로 마이크로서비스를 개발하고, 작업 할당을 서비스 단위로 하면 개발자가 해당 부분을 온전히 이해할 수 있다.
- 새로 추가되거나 수정사항이 있는 마이크로서비스만 빠르게 빌드, 배포가 가능하다.
- 해당 기능에 맞는 기술, 언어 등을 선택하여 사용할 수 있다.
- 일부분의 오류가 있으면 해당 기능에만 오류가 발생하고 그 부분만 빠르게 고쳐서 정상화가 가능하다.
- 단점
- 관리가 힘들다. 작은 여러 서비스들이 분산되어있기 때문에 모니터링이 힘듬
- 서로를 호출하여 전체 서비스가 이러우지기 때문에 무조건 다른 서비스를 호출하는 코드가 추가되는데 이부분이 모놀리식 아키텍쳐의 개발보다 까다롭다.
- 통신 관련 오류가 잦을 수 있다. 마이크로 서비스들끼리 서로 계속 통신을 하다보니 모놀리식 아키텍쳐에 비해 통신관련 오류가 잦은편임
- 테스트가 불편함. 예로 End-to-End 테스트를 위해 UI, Gateway등등 여러개의 마이크로 서비스를 각각 구동시켜줘야 함.