모놀리식 아키텍처 VS 마이크로 서비스 아키텍처

모놀리식(Monolithic architecture) 아키텍처

모놀리식 VS 마이크로 서비스

• 전통적인 아키텍처, 기존에 사용하던 서비스 방법 
• 서비스가 하나의 애플리케이션으로 돌아가는 구조 
• 기존의 개발 방식을 사용해 개발하여 간단히 배포 
• 하나의 서비스 또는 어플리케이션이 하나의 거대한 아키텍처
• 다양한 기능을 동작하는 서비스를 서버에서 실행하여 서비스

단점

모놀리식 서비스 아키텍처를 스케일링하면

인기 없는 서비스까지 같이 복사해야한다(불필요한 리소스 사용)

• 기존의 애플리케이션을 그대로 복제하여 로드밸런싱 
• 불필요한 서비스까지 모두 복제

종속적인 라이브러리의 충돌

종속적인 라이브러리까지의 충돌이 발생한다(다른 서비스의 라이브러리 버젼의 충돌이 발생한다)

• 각각의 기능들은 서로 다른 기능을 제공하여 버전의 종속성을 필요한 경우가 존재
• 각 기능의 따른 라이브러리를 매 업데이트마다 관리하기 매우 어려움

조금만 수정해도 전체 빌드 및 배포 필요

수정사항을 양이 적어도 전체 빌드, 베포 과정 필요

• 소스코드 전체가 하나로써 동작하기 작은 수정만 있더라도 전체를 빌드하여 다시 배포해야 함 
• 프로그램의 크기가 어느정도 커지면 한 번만 컴파일해서 전체 테스트를 돌려도 30분 내지 수 시간 소모 
• 하루에 버그가 여러 개 순차적으로 발견되면? → 지옥

마이크로 서비스 아키텍처

• 모놀리식 아키텍처의 대안으로 반대되는 개념
• 애플리케이션의 각각의 기능을 분리하여 개발 및 관리
• 마이크로 서비스 장점 
  • 서비스 단위 빠른 개발: 개발자가 특정 비즈니스 로직에 대해서만 집중하여 개발 가능 
  • 배포 용이: 개별 서비스 단위로 개발, 패키징, 빌드, 테스트, 배포로 각 서비스마다 유연한 스케줄 
  • 서비스 단위 고효율 저비용 Scale-Out 구조: 서비스 단위로 스케일링이 가능하여 불필요한 서비스는 줄이고 더 많은 자원이 필요한 서비스는 확장 가능
• 분산 시스템 환경에서 Transaction 보장, 테스트, 배포, 관리 복잡

모놀리식 라이프 사이클 VS 마이크로 서비스 라이프 사이클

마이크로 서비스 장점

서로 다른 가상 환경에서 제공되기에 라이브러리 종속성 문제 해결

• 서비스 단위 고효율 저비용 Scale-Out 구조 
  • 서비스 단위로 스케일링이 가능하여 불필요한 서비스는 줄이고 더 많은 자원이 필요한 서비스는 확장 가능
• 라이브러리 종속성 고민 끝!

​