여태까지의 서비스 개발은, 하나의 프로젝트에서 필요한 모든 기능을 개발하고, 어느 시점에서든 사용자의 요청을 잘 처리할 수 있는 거대한 서버를 준비하는 방식으로 진행되어 왔습니다. 이러한 방식의 개발은,
•
개발 자체의 난이도
•
테스트 편의성
•
배포 편의성
•
확장 편의성
등의 장점을 가지고 있었습니다. 이러한 방식으로 개발된 어플리케이션의 설계를 일반적으로 Monolithic Architecture라고 부릅니다. Spring Boot를 생각하면, 하나의 JAR 파일로 만들어진 어플리케이션으로 볼 수 있습니다.
하지만 서비스라는 것은 고정되지 않고 계속해서 발전해 나갑니다. 저희가 일상적으로 사용하는 대규모 서비스들, 네이버, 유튜브 등의 서비스는 지속적으로 업데이트 되며, 새로운 기능과 모습으로 저희에게 다가옵니다. 때로는 고객의 요구에 따라, 기존의 사항들을 변경하거나, 추가하는 등, 어플리케이션의 업데이트 주기는 계속해서 짧아져 왔습니다. 그리고 여태까지 전통적이었던 Monolithic Architecture는, 빈번하게 업데이트가 일어나야 하는 현 상황에 적잖은 약점을 가져오게 되었습니다.
•
어플리케이션이 점진적으로 커지게 되어, 기능별로 서로에게 영향을 미치기 쉬워짐
•
작은 기능 갱신을 위해 연관성이 적은 다른 기능들도 다시 배포가 되어야 함
•
한 기능의 문제가 전체 어플리케이션을 위태롭게 만들 수 있음
등 다방면에서 문제를 야기하게 되었습니다. 그러면서 점진적으로 거대한 서비스 하나를 만들고 유지보수를 하기보다, 서로 독립적이고 자유로운, 다양한 작은 서비스들을 구현하고 서로 상호 작용하도록 설계를 하는 설계론이 힘을 얻게 됩니다. 이렇듯 작은 서비스(Microservice)들로 이루어져 전체 기능을 제공하는 형태의 설계를 Microservice Architecture라고 부르게 됩니다.
MSA를 하는 이유?
사실 MSA는 기본 개념은 간단해 보이지만, 하나의 어플리케이션을 만들때에 비해 헐씬 많은 난관을 가지고 있습니다. MSA를 기반으로 설계된 어플리케이션이라는 것도 결국, 여러 컴퓨터에 걸쳐 분산된 시스템입니다. 그리고 앞서 Spring Cloud Project를 봤듯이, 분산된 시스템에는 일반적인 어플리케이션에 비해 요구되는 기능들이 헐씬 다양합니다.
•
서로 분리되어 있기 때문에 네트워크의 영향을 받음
•
서로 다른 서비스의 기능을 요할때, 기능 구현 및 테스트가 어려워짐
•
자신이 필요로 하는 다른 서비스의 Health를 확인하기 어려움
•
배포 과정이 더 복잡함
작은 단위의 개발은 좀더 쉬울지 모를지어도, 각 개별의 Microservice는 전체 제공 서비스에서 담당하는 영역이 더 적고, 결과적으로 전체 시스템의 개발에 있어서 어려움을 야기하게 됩니다. 그럼에도 불구하고 많은 기업들이 MSA를 도입하며 그 장점들을 가져가고자 합니다.
•
상황에 맞는 기술 스택을 선택할 수 있음
•
서비스 기능이 각각 따로 발전하게 됨
•
개별 서비스의 복잡성이 적어짐
그 외에 상황에 따른 기술 부채 등 행정적인 부분에서도 MSA 도입을 고려하게 하는 요인이 됩니다.
하지만 MSA 설계는 반드시 진행하여야 하는것은 아닙니다. 비교적 소규모의 프로젝트에서는, 굳이 MSA의 형태를 띄지 않더라도, 충분히 사용자의 요구조건을 이뤄낼 수 있는 경우가 많습니다. 그래서 MSA를 기준으로 전체 시스템의 설계를 만들기 전, 기본적으로 Monolithic 방식으로 서비스 개발을 시작하는 것을 많은 전문가가 제안합니다.
MSA를 위한 Cloud Projects
사실 Microservice Architecture는 Spring Cloud의 목표인 분산된 시스템의 형태중 하나라고 볼 수 있습니다. 즉 대부분의 Spring Cloud Project는 MSA를 구현하는데 있어서 어느정도의 도움을 준다고 볼 수 있습니다. 특히 이미 앞서 소개한 Service Discovery, Gateway 등은 MSA 구현에 있어서 필수적이라고 할 수 있을 정도로 중요한 부분입니다.
