MSA란?
하나의 큰 서비스를 작은 단위로 쪼개서 원하는 서비스를 조합하는 아키텍처
MSA는 여러개의 작고, 독립적인 서비스들을 조합하여 복잡한 application을 만드는 Architecture이다.
각각의 독립적인 서비스는 MSA에 유연성을 부여하고 이 유연성은 개발 및 운영 과정에 많은 이점을 가져다 준다.
Monolithic Architecture Vs. MicroService Architecture
Monolithic이란, 소프트웨어의 모든 구성요소가 한 프로젝트에 통합되어있는 형태를 말한다.
모든 서비스가 하나의 파일로 묶인 뒤 배포되어 동작하게 된다.
서비스들의 경계가 모호하고 하나의 DB를 공유하고 있는 구조로 서로 의존성이 높아질 수 밖에 없다. 따라서 서비스가 변경되거나 DB가 변경되면 연관된 서비스들도 변경해야하는 문제가 발생하게 된다.
하나의 파일로 묶여서 배포가 되기 때문에 서비스의 한 부분을 수정한다면 전체 프로젝트를 다시 패키징해서 배포해야되는 상황이 발생하기 때문에 일반적으로는 소규모 프로젝트에 더 적합하다.
소규모 프로젝트에 적용한다면 통합되어 있기때문에 간단한 형태를 갖고있어 유지보수에 용이하게된다.
MicroService Architecture는 대규모 프로젝트에 더 적합하다.
microservice는 완전히 독립적으로 배포가 가능하고, 서로 다른 기술 스택을 사용하여 단일 비즈니스 로직을 구현한 것으로 각각의 작은 단위의 서비스를 나누어 개발하기 때문에 전체 서비스가 커지는 경우 시스템 구조 파악에 유리한 점이 있다.
각 서비스는 논리적으로 DB를 나누어(꼭 물리적으로 나눠져있을 필요는 없다) 사용하기 때문에 상호간의 결합이 약해 유연한 운영이 가능해진다.
MSA의 특징
API를 통해서만 상호작용할 수 있다. 각 서비스의 end-point를 API형태로 외부에 노출하고, 실질적인 세부 사항은 모두 추상화한다. 내부의 구현 로직, 아키텍처와 프로그래밍언어, 데이터베이스, 품질 유지 체계와 같은 기술적인 사항들은 서비스 API에 의해 철저하게 가려진다.
따라서 SOA(Service Oriented Architecutre)의 특징을 다수 공통으로 가진다.
SOA
대규모 컴퓨터 시스템을 구축할 때의 개념으로 업무상 일 처리에 해당하는 소프트웨어 기능을 서비스로 판단하고 그 서비스를 네트워크상에 연동하여 시스템 전체를 구축해가는 방법론이다. 업무 처리 변화를 시스템에 빠르게 반영하고자 하는 수요에 대응하는 방법론.
플랫폼에 종속되지 않는 표준 인터페이스를 통해 기업의 업무를 표현한 '느슨하게 연결되고 상호 조합 가능한 소프트웨어'
SOA에서는 각각의 서비스가 데이터 계층, 비즈니스 로직, 뷰에 대한 모듈을 모두 가지고 있고, 각 서비스 간의 의존성이 최소화된다.
SOA 시스템의 규모가 증가함에 따라 서비스의 중복이 발생할 수 있고, 이를 방지하기 위해 이미 구현된 서비스가 있는지를 검색할 수 있어야 한다.
API GateWay
각 서비스에 접근하기 위해 사용되는 gateway
loadbalancing
MSA로의 변환하기 위한 바탕
- MSA는 모든 Application에 적용할 수 있는 것은 아니다.
- MSA로 이동해야 한다면, 기존 Monolithic 에서 감수해 내야만 하는 것들을 결정해야 한다.
- 매우 드문 경우에만 Monolithic 모듈 그대로를 분리하여 MSA 화 할 수 있다. 그 외의 경우에는 기존 프로세스를 유지하지 못한다.(코드 레벨까지 수정 혹은 재개발이 필요함)
- MSA가 비즈니스 확장성 및 생산성에 큰 이점이 있는 것은 사실이지만, 어떤 경우에는 Monolithic을 그대로 유지하여 개발하고, 운영하는 것이 더 큰 비즈니스 밸류를 가져다 주기도 한다.
- Monolithic은 단일 객체 그 자체이기 때문에 해당 아키텍처에 속해있는 데이터 모델 및 데이터베이스를 변경하는 것은 매우 어렵거나 거의 불가능에 가깝다. 이를 위해서는 데이터에 대한 리팩토링이 필요하다.
MSA 변환의 이유
1.기존 모노리틱 구조의 한계점
- 부분 장애가 전체 서비스로 전파된다.
- 부분적인 서비스의 scale-out이 어렵다
- 서비스의 개선이 어렵고, 수정 시 장애의 영향도 파악이 어렵다.
- 서비스의 전체 코드가 하나의 프로젝트로 구성되어 배포가 오래걸린다.
- 하나의 framework와 개발언어에 종속되어 서비스에 적절한 기술을 사용하기 어렵다.
--> 시스템을 여러 개의 서비스로 분리하여 서비스 간의 의존성을 제거하는 MSA로의 전환이 필요함.
모놀리식 아키텍처
UI, 비즈니스 로직 컴포넌트, 데이터관리 컴포넌트, 데이터들이 하나의 공간에서 밀접하게 연결되어 있음.
반면, 서비스 지향 아키텍처는 공통 또는 특정 결과를 처리하기 위해 비즈니스로직 컴포넌트와 데이터관리 컴포넌트를 하나의 단일 서비스화하여
반복적인 비즈니스 동작들을 논리적이며 독립적인 형태로 구분지어 분리해 놓음.
-> 마이크로서비스는 위의 서비스들을 더 잘게 나누기 위해 특정 도메인 바운더리, 즉 영역을 정의하고 해당 영역 안에서 필수불가결한 비즈니스 로직을 처리할 수 있도록
더 작은 단위로 서비스 화함.
2. MSA GOALS
- 하나의 서비스 장애가 다른 서비스로 전파되지 않는다.
- 코드 복잡성 및 의존성을 제거하여 영향도 파악을 용이하게 한다.
- 고 가용성과 확장성을 확보한다.
- 각 모듈의 독립성을 유지하기 위해서는 반드시 데이터가 분리되어야 한다.
How to
1. MicroService 분리
- Step 1. 모듈에 대한 식별 : 기존 모듈을 유지하거나, 새로운 모듈 작성
- Step 2. 데이터베이스 재정의 : 각 모듈에 해당하는 테이블을 분리하고 서비스로 wrap up
- Step 3. 코드 업데이트 : 새로운 서비스를 호출하기 위해 DB 테이블에 직접 호출했던 코드 업데이트
- Step 4. 위 방법을 지속적으로 강화 및 반복
주의 깊게 확인해봐야 하는 것들
현재 존재하는 많은 수의 Monolithic app은 위와 같은 방법으로 깔끔한 모듈화가 어렵다
테이블 간의 정규화, 엔티티 결합, 무결성 제약 조건 등을 유지하기 까다롭다.
Monolithic에 복잡한 Query 코드를 작성했을 때, 어떤 테이블을 어떻게 사용했는지 이해하기 힘들 수 있다.
단순하게 모듈을 쪼개는 방식이 아닌 매우 까다롭고 비용이 많이 드는 Migration이 있을 수 있다.
모듈화를 진행하다 보면 오히려 쪼개지 않는 쪽에 이점이 많아질 가능성도 있다.
참조
https://ssup2.github.io/theory_analysis/Micro_Service_Architecture/
https://wooaoe.tistory.com/57
