Monolith vs Microservices

Monolith 아키텍처

 

• 모든 업무 로직이 하나의 애플리케이션 형태로 패키지 되어 서비스
• 애플리케이션에서 사용하는 데이터가 한 곳에 모여 참조되어 서비스되는 형태

해당 방식의 문제점

 

하나의 시스템에 애플리케이션을 구성하고 있는 모든 서비스라든가 요소들이 패키징되어 서비스가 되고 있기 때문에

서비스의 일부가 수정되거나 삭제된다 하더라도 전체 애플리케이션을 다시 빌드하고 테스트하고 패키징하고 배포하는 과정을 거쳐야한다는 점

 

MicroService 아키텍처

 

• 여러 개의 작은 서비스 단위로 쪼개져서 개발, 배포가 되고 운영하는 방식
• 작은 단위로 만들어지고 개별적으로 분리되어 있는 서비스
• 개발과 배포와 운영이 각각 독립적인 사이클을 갖고 만들어진다는 것이 가장 큰 특징
• 서로 간의 통신을 위해 HTTP프로토콜 사용 - 필요한 데이터 요청 및 전달 받음
• 비즈니스 기능을 중심으로 구축되어야함.
• 비즈니스 도메인을 어떻게 서비스로 분해할 것인지 고민을 해야함
• 구분되어 있는 서비스들은 완전히 자동화되어 있는 배포 시스템을 이어서 독립적인 배포가 가능해야한다고 정의됨

 

위의 특징들은 클라우드 네이티브이 가지고 있는 네가지 특징에 적합함

 

1. 마이크로서비스 아키텍처

2. 컨테이너 가상화 기술

3. DevOps를 통해 사용자의 니즈와 개선사항을 빠르게 반영 및 개발

4. 자동화 배포 파이프라인 구축

 

 

마이크로 서비스의 아버지, 마틴 파울러가 정의한 마이크로서비스들이 가져야되는 특징

 

1.  각각의 서비스들은 최소한의 중앙 집중관리가 필요하다.

2. 서로 다른 프로그래밍 언어라든가 서로 다른 데이터 스토리지를 가져야한다.

 

마이크로서비스에서는 프로그래밍 개발 언어와 데이터베이스를 전체 어플리케이션에서 통일하는 것이 아니라 각각의 서비스 별로 특생에 맞게끔 최적화되어 있는 언어와 데이터베이스를 사용하는 것을 권장하고 있음.

 

 

즉,

서비스의 종류와 기능에 맞춰 개발 언어를 선택하고 각각의 서비스들이 자신이 제공해야 하는 어떠한 서비스라든가 

데이터 API에 맞도록 스토리지라든가 기술 스택을 정의해야 함.

 

Front&Back

 

모노리스 방식과 마이크로 서비스 방식 중간 정도의 개발 방식으로서 프론트엔드, 백엔드 각각을 분리해서 개발하는 방식

 

서로에게 필요한 통신만 가능하여 각각 최적화되어 있는 개발 환경을 독립적으로 유지할 수 있는 것이 가능해짐

 

사용자에게 보여지고자 하는 어떤 어플리케이션의 인터페이스라든과 화면을 변경한다 하더라도 백엔드

사이드를 빌드를 할 피요는 없음

 

 

MSA

 

독립적인 서비스에 맞춰서 분리되어 관리

 

Aggregation Layer (ex. BFF , GraphQL)

 

서비스가 다양하게 분리되었을 때 분리된 서비스의 데이터를 하나로 통합하거나 우리가 가지고 있는 프론트에 맞는 최적화 되어 있는 백엔드를 별도로 구성해서 서비스를 하는 등 마이크로서비스 아키텍처에 필요한 다양한 패턴들에서 사용되는 용어