MSA로의 변환하기 위한 바탕

• MSA는 모든 Application에 적용할 수 있는 것은 아니다.
• MSA로 이동해야 한다면, 기존 Monolithic 에서 감수해 내야만 하는 것들을 결정해야 한다.
• 매우 드문 경우에만 Monolithic 모듈 그대로를 분리하여 MSA 화 할 수 있다. 그 외의 경우에는 기존 프로세스를 유지하지 못한다.(코드 레벨까지 수정 혹은 재개발이 필요함)
• MSA가 비즈니스 확장성 및 생산성에 큰 이점이 있는 것은 사실이지만, 어떤 경우에는 Monolithic을 그대로 유지하여 개발하고, 운영하는 것이 더 큰 비즈니스 밸류를 가져다 주기도 한다.
• Monolithic은 단일 객체 그 자체이기 때문에 해당 아키텍처에 속해있는 데이터 모델 및 데이터베이스를 변경하는 것은 매우 어렵거나 거의 불가능에 가깝다. 이를 위해서는 데이터에 대한 리팩토링이 필요하다.

#MSA 변환의 이유

1.기존 모노리틱 구조의 한계점

1. 부분 장애가 전체 서비스로 전파된다.
2. 부분적인 서비스의 scale-out이 어렵다
3. 서비스의 개선이 어렵고, 수정 시 장애의 영향도 파악이 어렵다.
4. 서비스의 전체 코드가 하나의 프로젝트로 구성되어 배포가 오래걸린다.
5. 하나의 framework와 개발언어에 종속되어 서비스에 적절한 기술을 사용하기 어렵다.

--> 시스템을 여러 개의 서비스로 분리하여 서비스 간의 의존성을 제거하는 MSA로의 전환이 필요함.

모놀리식 아키텍처

UI, 비즈니스 로직 컴포넌트, 데이터관리 컴포넌트, 데이터들이 하나의 공간에서 밀접하게 연결되어 있음.

반면, 서비스 지향 아키텍처는 공통 또는 특정 결과를 처리하기 위해 비즈니스로직 컴포넌트와 데이터관리 컴포넌트를 하나의 단일 서비스화하여
반복적인 비즈니스 동작들을 논리적이며 독립적인 형태로 구분지어 분리해 놓음.

-> 마이크로서비스는 위의 서비스들을 더 잘게 나누기 위해 특정 도메인 바운더리, 즉 영역을 정의하고 해당 영역 안에서 필수불가결한 비즈니스 로직을 처리할 수 있도록
더 작은 단위로 서비스 화함.

2. MSA GOALS

1. 하나의 서비스 장애가 다른 서비스로 전파되지 않는다.
2. 코드 복잡성 및 의존성을 제거하여 영향도 파악을 용이하게 한다.
3. 고 가용성과 확장성을 확보한다.
4. 각 모듈의 독립성을 유지하기 위해서는 반드시 데이터가 분리되어야 한다.

How to

1. MicroService 분리

• Step 1. 모듈에 대한 식별 : 기존 모듈을 유지하거나, 새로운 모듈 작성
• Step 2. 데이터베이스 재정의 : 각 모듈에 해당하는 테이블을 분리하고 서비스로 wrap up
• Step 3. 코드 업데이트 : 새로운 서비스를 호출하기 위해 DB 테이블에 직접 호출했던 코드 업데이트
• Step 4. 위 방법을 지속적으로 강화 및 반복

주의 깊게 확인해봐야 하는 것들

1. 현재 존재하는 많은 수의 Monolithic app은 위와 같은 방법으로 깔끔한 모듈화가 어렵다
2. 테이블 간의 정규화, 엔티티 결합, 무결성 제약 조건 등을 유지하기 까다롭다.
3. Monolithic에 복잡한 Query 코드를 작성했을 때, 어떤 테이블을 어떻게 사용했는지 이해하기 힘들 수 있다.
4. 단순하게 모듈을 쪼개는 방식이 아닌 매우 까다롭고 비용이 많이 드는 Migration이 있을 수 있다.
5. 모듈화를 진행하다 보면 오히려 쪼개지 않는 쪽에 이점이 많아질 가능성도 있다.