MSA(Micro Service Architecture)는 무엇인가?

안녕하세요. 뜨현입니다.

여러분은 MSA에 대해서 들어보셨나요?

넷플릭스와 테슬라 등 유명 테크 기업들의 성공 비결이 MSA로 알려지면서, 그에 대한 관심은 식을 줄을 모르고 있습니다.

대체 뭐길래 수많은 테크 기업들이 MSA를 외치는 것일까요?

요즘 대세를 떠나서 거의 필수적으로 알아야 한다는 MSA에 대해서 알아보시죠.

 

 

MSA(Micro Service Architecture)

MSA, 즉 마이크로 서비스 아키텍처는 독립적으로 배포 할 수 있는 일련의 서비스를 이용하는 아키텍처 방법입니다.

 

MSA에 대해 알아보기 전에 기존의 방식인 모놀리식(Monolithic)을 먼저 알아야 합니다.

모놀리식은 소프트웨어의 모든 구성요소가 한가지 프로젝트에 몰려있는 것을 의미합니다. 

프로젝트가 거대한 한 덩어리로 존재하고, 그 안에 그 프로젝트를 구성하는 요소들이 포함된 것입니다. 

간단하게 생각하면, 프로젝트를 구성하는 서버와 DB 등이 하나로 통일되어 운영, 배포 등의 작업들이 그냥 한 몸처럼 움직이는 것이죠. 

모놀리식을 이용하면 코드 관리가 편하고, end-to-end 테스트가 편하다는 장점이 있습니다.

(end-to-end 테스트란, 사용자 중심으로 처음부터 끝까지 애플리케이션 흐름을 테스트하는 소프트웨어 테스트 방법입니다) 

그렇기 때문에 모놀리식은 주로 소규모 프로젝트에 적합하다고 볼 수 있습니다.

그 이야기인즉슨, 사용량이 많아지면 감당하기 힘들다는 단점이 존재하는 것이죠. 단점은 이것뿐만은 아닙니다.

모놀리식의 경우에는 작은 수정에도 시스템 전체를 빌드해야 하고 그에 따라 테스트 시간도 길어집니다. 또한, 특정 이벤트로 인해 서비스 접속량이 폭증하게 된다면 프로젝트 전체를 확장해야 합니다. 하나의 덩어리로 존재하기 때문에, 트래픽이 몰려 하나의 서버가 죽게 된다면 전체 서버가 마비되는 참사가 벌어집니다. 

요즘 우리가 자주 사용하는 Netflix 역시 기존에 모놀리식 방법으로 운영했지만 서비스에 대한 수요를 인프라가 감당할 수 없는 지경에 이르러 결국 MSA로 전환하게 되었습니다.

 

자 그렇다면 Netflix가 택한 MSA는 과연 무엇일까요?

MSA는 독립적으로 배포가 가능한 일련의 서비스를 이용하는 아키텍처 방법입니다. 단일 프로그램을 컴포넌트별로 나누어 작은 서비스의 조합으로 구축하는 방법입니다. 

여러 개의 서비스가 독립적으로 운영되며 그 서비스들을 결합하면 하나의 애플리케이션이 됩니다.

쉽게 말하자면, 애플리케이션을 여러 개의 서비스로 나누고 그 안에서 서버와 DB 등을 각자 정해서 운영하는 방식입니다.

마치 미국처럼 주가 여러 개 있고 그 주마다 법과 운영방식은 차이가 있지만 결국에는 주가 모여서 미국이라는 하나의 국가를 이루는 것과 같다고 볼 수 있죠.

그렇다 보니 사용량이 많아지게 되어도 애플리케이션 이용 부담은 적어집니다. 특정 서비스에 사용량이 몰려도 다른 서비스에는 영향이 가지 않기 때문이죠.

 

MSA는 각 서비스가 다른 서비스와는 독립적으로 확장이 가능합니다.

확장이 필요할 경우에는 프로젝트 전체를 확장할 필요 없이 특정 서비스만 확장하면 됩니다. 정말 편리하죠? 

배포 역시 독립적입니다.

미세한 오류가 있어서 배포가 필요할 때, 모놀리식은 무조건 전체를 배포해야 했지만 MSA는 해당 서비스만 배포하면 됩니다. 

 

MSA에서의 팀 모델

 

MSA에서는 서비스별로 팀을 나누고 서비스 기획에서부터 설계 개발 운영이 팀 내에서 이루어지기 때문에 다른 팀에 대한 의존성이 사라지게 됩니다. 역할별 요청과 피드백이 빨라지고 그로 인해 유연하고 지속적인 운영과 개발이 함께 하게 됩니다. 

 

 

이렇게 좋아 보이는 MSA에도 단점은 존재합니다.

서비스가 분산되어있기 때문에 관리가 용이하지 않고, 각 서비스가 서로 연결이 원활한지 확인하는 것도 필요하죠. 

비용이나 설계 방식이 간단하지 않다는 것도 단점입니다.

MSA 팀 모델의 경우에도 인력 리소스 관리에 어려움이 생기게 됩니다. 각 팀의 역할 담당자들은 기본적인 업무 성숙도를 가지고 있어야 하고, 특히 개발자들은 운영팀의 고유 영역이었던 인프라 핸들링이 가능해야 합니다. 

 

 

정리하자면, 결국 완벽한 방식은 없다는 것입니다!

MSA는 API 기반의 서비스 지향적 아키텍처 스타일입니다. 최근 유행하고 있지만 꼭 정답은 아닙니다. 업무나 비즈니스 특징에 따라 적절한 아키텍처를 선택해야 합니다. 시스템에 대한 설계뿐만 아니라 팀의 구조, 프로젝트 관리 방법까지 달라지기 때문에 프로젝트에 미치는 영향이 크거든요. 그렇기 때문에 거시적인 관점에서 고려해야 합니다. 

실제로도 많은 기업이 MSA 방식을 선택하지만, 그렇다고 해서 모든 기업이 MSA 방식으로 운영하는 것은 아닙니다. 이처럼 거시적인 관점에서 고려해야 할 필요가 있으며, MSA가 필요하다고 해도 꼭 시작을 MSA로 할 필요는 없습니다.

많은 장점을 가지고 있지만 개개인의 높은 숙련도 필요한 편이기 때문이죠. MSA를 구축한 많은 기업이 첫 시작은 모놀리식으로 시작하여 팀원들의 숙련도를 높이고 피드백을 주고받으며 시스템을 발전시키는 과정에서 MSA로 전환한 사례들도 있습니다. 위에 예시로 들었던 Netflix처럼요! 프로젝트의 목적이나 팀의 상황에 맞는 유연한 선택이 필요합니다.

 

모놀리식 아키텍처와 마이크로 서비스 아키텍처에 대해 알아보았는데요. 다들 어떠셨나요?

도움이 되셨길 바랍니다.

감사합니다.