MSA ( Microservice Architecture) 기본개념

MSA(Microservice Architecture)란?

 

마이크로서비스는 애플리케이션을 느슨히 결합된 서비스의 모임으로 구조화하는 서비스 지향 아키텍처(SOA)스타일의 일종인 소프트웨어 개발 기법이다.

마이크로서비스 아키텍처에서 서비스들은 섬세(fine-grained)하고 프로토콜은 가벼운 편이다.

애플리케이션을 더 조그마한 여러 서비스로 분해할 때의 장점은 모듈성을 개선시키고 애플리케이션의 이해, 개발, 테스트를 더 쉽게 해주고 애플리케이션 침식에 더 탄력적으로 만들어 준다.

규모가 작은 자율적인 팀들이 팀별 서비스를 독립적으로 개발, 전개, 규모 확장을 할 수 있게 함으로써 병렬로 개발할 수 있게 한다.

또, 지속적인 리팩토링을 통해 개개의 서비스 아키텍처가 하나로 병합 될 수 있게 허용한다. 

 

 

MSA 장점

 

1. 어플리케이션의 빠른 성장

        - 어플리케이션의 규모가 작을 경우 MSA를 적용할 필요도 없고 얻는 이점이 거의 없다. 오히려 MSA를 운영하는 비용이 더 큼

        - 하지만 단일 어플리케이션의 규모가 커지게 되면 한개발자가 코드를 수정해 배포하면 배포가 끝날때까지 다른 개발자들이 기다려야             하는 답답한 상황이 발생한다.

        - MSA의 경우 각 팀에서 각 컴포넌트를 담당한다. 

        - 데이터베이스를 따로 갖음

        - 소스코드 리포지토리도 따로 갖음

        - 다른 팀을 신경쓰지 않고 각 컴포넌트의 배포가 가능함

          => 어플리케이션이 빠르게 성장 할 수 있음

 

 2. 신기술 적용이 쉽다

        - MSA에서는 각 팀에서 컴포넌트를 담당한다. 

        - 각 팀에서 어떤 기술을 사용해서 구현할지는 팀에 선택권이 있다.

        - 한 팀에서 새로우 기술을 적용해서 성공하면, 공유 세션을 열어서 다른 팀에게 신기술을 전파 할 수 도 있다.

        - 팀마다 사용하는 기술이 다르기 때문에 새로운 것을 해보고 싶은 개발자가 회사를 나가기보다 팀을 이동할 수 있음

 

MSA 단점

 

1. 장애 추적이 어렵다.

       - 작은 단위로 팀이 나뉘어져 있다보니 어떤 기능이 동작을 안한다고 하면 여러팀의 도움이 필요하다. 

       - API를 이용한 동기 호출이면 그나마 장애 추적이 쉽지만 대부분의 대용량 처리는 메시징 큐를 사용한다.

       - 메시징 큐는 비동기로 동작하기 때문에 장대 추적이 더 어렵다.

 

2. 테스트가 어렵다.

       - MSA에서는 팀이 서로 의지한다. 

       - 다른팀의 개발서버가 동작을 안하다면 테스트를 할 수가 없다.