MSA의 정의
MSA를 정의하는 방법은 여러가지 관점이 존재한다.
서비스 크기별로 정의할 수도 있고 운영 방식으로도 정의할 수 있고 데이터 참조 관계로도 정의할 수 있다.
- 서비스 크기별로는 하나의 프로젝트로 관리되는 기존 모놀리딕 방식의 서비스를 독립적으로 확장/배포가 가능한 마이크로 서비스로 분해해 운영하는 것이 MSA다 라고 할 수 있다.
- 운영 방식으로는 각 회사의 부서별로 서비스를 담당하며 여러 서비스들과 통신과 데이터 관리를 진행하는데 각 서비스는 독립적으로 진행된다. 예로 결제 서비스가 다운됐다 하더라도 회원가입 서비스는 진행 가능한 것처럼. 이런 식으로 운영을 서비스별로 잘게 나눠서 아키텍처를 구성하는 것이 MSA라고 할 수 있다.
- 데이터 참조 관계로는 복잡한 하나의 큰 데이터 베이스에서 각 테이블별로 복잡한 참조관계를 가지면서 운영하는 것보다 비슷한 테이블끼리 묶어서 따로 관리하고 필요한 경우에 폴링을 통한 마이그레이션으로 테이블을 캐싱하는 방식으로 운영하는 것을 MSA라고 할 수있다.
내가 생각하는 MSA의 정의는 우선 MSA를 도입하려는 목적에서 시작한다.
MSA 도입 목적
- Business Agility : 빠르고 다양한 사업 환경 변화 및 고객의 요구사항에 적시 대응하여 비지니스 경쟁력을 확보하는 것
- Rapid/Frequent/Reliable software delivery 를 제공하기 위함
- 자원 효율성 증가
나의 MSA 정의
MSA는 독립적인 확장/배포가 가능한 서비스 단위인 마이크로 서비스로 아키텍처를 구성해 고객의 요구사항에 대해 Business Agility 를 확보하려는 개발 방법론이다.
SOA
MSA 가 나오기 전 아키텍처 방법론으로 SOA ( Service Oriented Architecture ) 가 있다.
서비스 지향 아키텍처는 소프트웨어 구성 요소를 사용해 비지니스 어플리케이션을 생성하는 소프트웨어 개발 방식이다.
개발자들은 SOA를 사용해서 서로 다른 시스템의 서비스를 재사용하거나 독립적인 여러 서비스를 결합하여 복잡한 태스크를 수행한다.
MSA와 유사한 부분이 있다. 바로 논리적으로 공통된 부분을 구분해서 유지보수하고 확장하는 행동에 이득을 얻기 위한 노력이다.
다만 공통 모듈화 정도의 저수준 그룹화는 문제가 없지만 서비스 단위의 고수준 그룹화는 구분하기 쉽지 않고 논리적으로 서비스를 구분할 뿐 하나의 프로세스에서 같은 자원을 공유하기 때문에 하나의 논리적 서비스의 장애가 전체 프로세스의 장애를 유발한다는 점에서 개선점이 많이 필요한 개발 방법론이다.
따라서 이를 해결하기 위해 나온 개발 방법론이 MSA이다.
MSA 특징
앞서 살펴본 정의와 같이 비지니스 환경의 빠른 변화와 모놀리딕 방식의 문제점들을 극복하기 위해 MSA가 탄생했다.
모놀리딕은 서비스 규모가 커져가면서 코드의 볼륨이 커지고 의존 관계가 늘어나며 개발이 복잡해지고 개별 컴포넌트를 확장할 수 없고 모듈에 오류가 있으면 애플리케이션 전체의 가용성에 문제가 있을 수 있다.
또한 트래픽 확장에 있어서 스케일 아웃을 할 수 없고 스케일 업을 해야하며 이는 성능 측면에서 단점이 될 수 밖에 없다.
하지만 중요한 점은 MSA역시 하나의 아키텍처란 점이다. MSA가 정답은 아니고 앞서 살펴본 것처럼 프로젝트가 Business Agility를 확보해야 하는 환경인지 아닌지 우선적으로 판단해야 한다.
MSA의 서비스를 나누는 것은 실무에서 업무 중심으로 분해한다고 한다. 조직의 팀의 구성에 따라서 서비스를 나누는 경우가 대부분이다. 따라서 서비스를 구분할 때 도메인 전문가들이 모여서 서비스 단위와 업무 조직 단위를 최대한 연관시켜서 분석해야 한다.
또한 서비스의 단위를 정할 때 이런식으로 서비스를 나누었을 때 얻는 효과에 대해 팀이 어떤 방향을 원하는지를 지속적으로 생각해야한다.
장애 전파 중지가 목적인지, 트래픽 분산이 목적인지, 원활한 스케일 아웃을 위한 논리적 구분이 목적인지 등 조직의 원하는 방향에 따라 서비스 구분 바운더리가 달라진다.
MSA 장점
물리적 분리 / 독립
독립적으로 확장/배포가 가능한 단위로 서비스를 나누어서 운영하기에 물리적으로 분리 / 독립 돼 서비스 별 스케일 아웃이 자유롭다.
업무 상황이나 특징에 맞게 서비스를 추가하거나 변경할 수 있고 논리적으로 분리함으로써 유지보수에 도움이 될 수 있다.
하나의 어플리케이션을 하위 단위인 서비스로 나누기 때문에 코드 복잡도가 줄어들고 독립적으로 운영 가능하다
배포
Rapid/Frequency/Reliable Software Delivery 가 가능하고, 서비스 별로 개별 배포가 가능해 유동적으로 어플리케이션을 배포할 수 있고 무중단 서비스를 운영할 수도 있다. Business Agility를 만족하기 위해 요구사항을 신속/적시에 반영할 수 있다는 것이 가장 큰 장점이다.
장애
각 서비스가 독립적으로 운영되고 물리적으로 분리돼있기 때문에 장애 전이가 방지되고 장애가 한 서비스에서 격리된다. 즉, 장애로 인한 전체 운영 중단으로 이어지지 않아 비지니스 피해를 최소화 시킬 수 있다.
확장
독립적으로 배포/확장할 수 있고, 특정 업무, 시점을 고려해서 유동적으로 어느 부분만 업데이트할 수 있다. 사업 환경 변화에 대응하기 용이하다.
기술/환경/조직
사용하는 프레임워크나 언어에 제한받지 않고 다양한 스택을 서비스별로 따로 운영할 수 있다.
Polyglot
단일 개발 표준에 국한되지 않고, 서비스 별 특징에 따라 개별 시스템에 최적화된 언어, 프레임워크, 아키텍처, 디비 등을 개별 적용할 수 있음을 일컫는 말이다.
MSA 단점
여러 장점이 있음에도 MSA를 쉽게 도입하지 못하는 이유는 서비스를 구분하면서 생기는 이해관계와 복잡도 때문이다.
먼저 서비스간 호출 시 API통신을 하게 되는데 서비스간 이해관계에 따라 요청 깊이가 달라져 중간에 에러가 터졌을 때 어느 서비스에서 문제가 발생했는지 찾기가 쉽지 않다.
서비스 별로 이해관계가 종속돼있는 경우가 있기 때문에, ( 서비스가 다운되는 것과는 별개 ) 테스트를 진행할 때 이 종속 관계를 잘 파악해서 테스트를 짜야한다.
또한 분산 환경으로 같은 데이터베이스를 사용하지 않고 분리해서 운용하기 때문에 DBMS 내 트렌잭션 처리가 불가능하다. ( 커밋이나 롤백이 불가능하다. )
여러 서비스별로 데이터를 가져와야 하는 경우에도 서비스별로 데이터를 가지고 있기 때문에 모니터링을 위해서는 여러 서비스에서 데이터를 요청해 가져와야 한다.
이런 분산된 DB 환경 트렌잭션 쿼리를 위한 별도의 설계, 개발, 테스트가 추가로 요구된다.