MSA란 무엇인가??

실전 프로젝트의 주제와 기술에 대해서 이야기하던 중  MSA를 적용해보는 것이 좋지 않을까?

라는 이야기가 나와서 MSA라는 것이 무엇인지 알고 싶어 정리를 하며 이해하고자 한다.

 

MSA는 Micro Service Architecture의 줄임말로

예전에는 소프트웨어를 개발할때 모든 요소들이 해당 Appllication 하나에 모두 통합되어 개발이 되고

빌드와 배포까지 하는 설계가 많았다고 한다.

이렇게 되면 여러가지 한계점이 발생하는데 

 

1. 부분 장애가 전체 시스템 장애로 확대 될수 있다.

2. 결합도가 높다

3. 클라우드 환경에 적합하지 못하다.

4. 배포가 용이하지 않다.

 

통합되어 있기 때문에 위와 같은 한계점이 있다.

그래서 이를 극복하고자 MSA를 도입하게 되는데 서비스별로 작은단위로 분산시키고 

REST기반의 API 통신으로 통신하여 하나의 서비스에 장애가 발생해도 다른 서비스에서 받는 영향은 제한적이게 된다.

 

통신방법은 여러가지가 있어서 적절하게 이용하면 된다고 한다.

 

MSA를 도입할 때 장점은

외부와의 Interface만 알면 자신의 업무파악의 집중 할수 있고 효율성이 증가하고 

작은 서비스 단위의 개발과 테스트, 운영 배포가 용이하고 

새로운 언어나 기술의 도입이 쉽다고 한다.

 

단점은 

1. 아키텍처 관점에서 보면 단조롭지 않고 복잡하다. 그렇다보니 장애가 발생할 경우 대처하는 방법도 까다롭다고 한다.

2. DB의 트랜잭션을 유지하기 어렵다는게 가장 큰 이슈 중 하나라고 한다.
왜냐하면 각 서비스 별로 DB 가 분리되어 있어서 어느 하나의 서비스에서 오류가 발생했을 때는 이미 완료 처리된 

서비스를 Rollback  하는게 쉽지 않다고 한다.
그런데 Sping Cloud 같은 프레임워크가 있어서 그나마 편리하게 구성할수 있다고 하니 

이 부분도 공부하려한다.

3. 최초 프로젝트 시작할 경우 많은 시간과 비용이 발생한다고 한다.

설계부터 다양한 기술 결정, 구현, 테스트 등 전반적인 과정에서 더 많은 시간과 비용이 발생한다.

 

여기까지 알아보고 팀회의를 거친 결과

1. 팀 프로젝트 규모가 크지 않아 MSA를 적용하기에 적합하지 않다

2. 6주라는 시간동안 MSA를 구현하는데에 집중하여 프로젝트를 완성시키지 못할것이다.

라는 2가지 이유가 가장 커서 이번 프로젝트에서는 MSA는 적용하지 않기로 했다.

다만, 프로젝트를 완성 시키고 추후에 확장시켰을 때 MSA를 적용해 보기로 했다.

프로젝트를 성공적으로 마무리하고 확장시켜서 MSA를 적용해보고 싶다라는 생각을 했다.