MSA란?
마이크로서비스란 작고, 독립적으로 배포 가능한 각각의 기능을 수행하는 서비스를 의미합니다. 작고 독립적으로 배포 가능한 서비스를 구성함으로서 마이크로서비스를 기반으로 한 프로젝트는 기능을 추가하거나 변경할 때, 기존 모놀리틱 아키텍쳐보다 좀 더 손쉽게 수정할 수 있어 확장성과 유연성이라는 큰 장점을 가지게 된다.
이걸 왜 하는가?
기존에 주로 사용되었던 아키텍쳐는 모놀리식 아키텍쳐(Monolithic Architecture)로 하나의 거대한 시스템에 다양한 서비스가 상호 작용하여 사용자에게 기능을 제공하였다.
여기서 발생하는 가장 큰 문제는 추가 요구사항 도입 및 수정과 장애 대응이다. 시스템은 계속해서 최적화되고 추가적인 기능이 제공되어야 사용자들이 만족하고 사용하게 된다. 하지만 기존의 모놀리식 아키텍쳐는 하나의 코드를 수정하면 어느 부분에 영향을 미치는지 영향도 분석에 큰 어려움을 가지게 되고, 기능을 추가하기 위해서는 기존 시스템에 영향을 주지 않는 선에서 추가하여야 하기 때문에 개발보다 분석에 많은 시간을 투자한다.
코드는 맨 처음 나올때의 시스템에 덧붙이기 형식으로 구현이 되다보니 점차 스파게티 코드가 되고, 몇년 후 이 시스템은 아무도 알아볼 수 없는 슬픈 코드로 변하게 된다.
또한, 모놀리식 아키텍쳐는 특정 부분에서 장애가 발생할 경우 시스템이 다운되는 큰 문제를 가지고 있다. 몇십만명이 이용하는 시스템에서 한 부분이 장애가 났다고 전체기능을 사용하지 못하는 것은 너무나도 슬픈 일이다...
MSA를 하는 이유
이러한 문제를 해결하기 위해 MSA를 여러 기업에서 도입하기 시작했다. 독립적인 작은 서비스들로 분리하여 시스템을 운영한다면, 이후, 기능을 추가하거나 수정함에 있어 보다 더 용이하며, 특정 기능에 장애가 발생하여도 전체 시스템은 정상적으로 동작하는 장점이 있다.
MSA를 통해 기업들은 민첩한 대응을 하여 사용자의 요구사항을 빠르게 반영하는 새로운 패러다임을 제시할 수 있으며 개발자 또한 본인이 속한 도메인의 코드만 이해한다면 개발을 할 수 있기에 기존보다 빠른 적응을 할 수 있다는 장점이 있다.
별첨. 내가 생각하는 MSA
내가 직접 이용하면서 느낀 MSA를 정의하자면... 다음과 같은 프로젝트에 MSA 적용하면 최고의 선택이라고 생각한다.
- 각각의 기능이 명확히 구분되어지는 서비스들로 구성된 프로젝트
- 크기가 엄청나게 큰 대형프로젝트가 아닌 소형 프로젝트
- 애자일 방법론으로 유연하게 진행하는 프로젝트
MSA를 한다는 것은 결국 각각의 독립적인 기능을 수행하는 서비스들이 상호간의 연계를 통해 하나의 큰 서비스를 사용자에게 제공한다는 의미이다. 그렇기 때문에 각각의 기능이 명확하지 않은? 것들을 가지고 MSA로 하자! 라는 것은 설계 장인이 와야 겨우겨우 진행될 것 같다.
또한, 타 서비스의 API를 이용하는 것이 생각보다 까다롭다... 이 API를 사용하면 무슨 데이터가 오는지를 명확히 이해해야 하는데 대형 시스템에선 수쳔개 이상의 API를 제공하기 때문에 이게뭔지 혼동이 올때가 많았다. 따라서, 시작하는 파일럿 프로젝트에서 MSA를 이용하는 것이 개발에 있어 최적화되지 않았나 싶다.
결론
기존 모놀리식 아키텍쳐와 마이크로 아키텍쳐는 각각 장단점이 있다.
하지만 새로운 것을 빠르게 적용하는 민첩성 과 유연성이 중요한 이 시대에는 MSA 가 보다 더 적합한 구조이지 않나라는 생각이 든다.
이미 수많은 기업들이 MSA를 도입하기 시작하였고 이에 따라 우리도 빠르게 MSA를 받아들이고 적용해봐야 되지 않을까라는 생각을 하게 되었다.
다음편은 MSA-DDD 방식 설계에 대해 설명해보겠다 빠잉~><
