읽으면서 배우는 소프트웨어 - MSA(Micro Service Architecture)

사진: Unsplash의Alex wong

 

 

Micro Service Architecture

 

Micro service architecture(이하 MSA)는 소프트웨어 설계 유형 중 하나입니다.

 

독립된 서비스의 조합으로 하나의 어플리케이션을 개발하는 설계로서 클라우드와 컨테이너의 발전과 함께 애플리케이션 개발에 널리 사용되고 있습니다.

 

 

장점

 

Micro Service Architecture는 배포와 확장성이 용이하다는 점이 가장 큰 장점입니다.

 

서비스가 독립적으로 수행되기 때문에 지속적인 변경에 의한 어플리케이션 영향이 적으며, 변경용이성 확보는 요구사항 변경에 대응을 빠르게 합니다. 급변하는 사용자 요구에 쉽게 대응할 수 있다는 점은 설계적인 관점에서 상당한 장점이 될 수 있습니다.

 

또한, 확장성을 통해 Availability와 Performance 를 보장할 수 있습니다. MSA를 채택하여 서비스를 운영하는 환경에서는 서비스 성능이 사전 협의 된 서비스 수준에 도달하지 못하는 경우 서비스를 여러 개 띄움으로써 대응할 수 있는 구조입니다.

 

서비스를 여러개 띄우는 방식은 가용성을 높이기 위해서도 좋은 선택지가 될 것입니다.

반응형

 

 

단점

 

 

MSA의 가장 큰 단점은 독립적인 서비스로 인한 애플리케이션의 복잡성입니다.

 

이로 인해 독립적으로 동작하는 서비스들이 모여 하나의 애플리케이션을 구성하기 때문에 테스트가 용이하지 않고, 애플리케이션이 어떻게 동작하는지 이해하기가 수월하지 않습니다.

 

어차피 필요한 기능을 서비스로 분리해서 구현했을 뿐이니 큰 차이가 아니라고 느끼실 수 있고, 실제로 하나의 팀이 개별 서비스를 전부 구현하고 이를 API로 연결하였다면 MSA 여부가 큰 차이가 아닐 수 있습니다.

 

작은 규모의 애플리케이션이라면 MSA 여부가 전체구조를 이해하는데 영향을 미치지 않을 수 있으나, MSA 내의 서비스를 아예 다른 팀이 붙어서 개발하는 경우라면 어떨까요?

 

다른 팀의 서비스가 어떻게 구현되고 있는지 전부 알기가 쉽지 않을뿐더러 repository를 공유하면서 review를 하지도 않게 될 것입니다.

 

그렇기에 MSA 구조는 서비스 모두를 이해하기가 어려운 설계방식이 될 수 있습니다.

 

독립적인 서비스를 연결하는 설계로부터 발생하는 단점들(API 관리, 서비스 간 통신의 복잡도 증가)이 있으니 MSA를 고민하고 있다면 이런 부분을 어떻게 해결해 나갈지 고민이 필요합니다.

 

저는 무조건 좋은 설계는 없다고 생각합니다. 그러니 No free lunch라는 말이 있는 것이겠지요.

 

Trade-off를 고려하여 쉽게 접근할 수 있는 방향으로 가는 것이 최선이니 MSA 채택을 고민하고 계시다면 다른 설계와 면밀히 비교 후 개발을 시작하시기 바라겠습니다.