마이크로서비스 아키텍처(MSA) 개념 소개
프리랜서로 일하고 있는 지인이 최근 구직을 하고 있었습니다. 그러면서 하는 말이 요즘 IT업계 구직시장에서 최고의 화두가 MSA라는 이야기를 했습니다. 한참 유행했던 시기는 5년 전쯤인데 이제는 어떻게 보면 당연한 개발 방법이 되어가고 있는 느낌입니다. 내용을 공유하고자 MSA에 대해 간단히 소개 및 정리를 해보겠습니다.
MSA가 도입되기 전의 모습(Monolithic Architecture)
<Monolithic의 사전적 정의 – 네이버 영어 사전 >
기존에 우리가 사용하던 전통적인 방식의 개발 방법을 모노리틱 아키텍처 스타일이라고 합니다. 위의 사전적 정의대로 한 덩어리의 구조라고 볼 수 있습니다.
< 간단한 온라인 쇼핑몰 monolithic architecture 예시 >
전체 애플리케이션이 하나로 되어있어서 보통 동일한 개발 툴을 사용해 개발되며, 배포 및 테스트도 하나의 애플리케이션만 수행하면 되기 때문에 개발 및 환경설정이 간단합니다. 또한 각 컴포넌트들이 함수로 호출 되기 때문에 성능에 제약이 덜하고, 운영 관리가 용이합니다. 이런 장점 때문에 작은 볼륨의 시스템을 개발할 때는 매우 유용하지만 시스템이 커지기 시작하고 여러 컴포넌트들이 더해지면 문제가 발생하기 시작합니다.
< 기능이 추가된 온라인 쇼핑몰의 monolithic architecture 예시 >
위의 예시처럼 이제 온라인 쇼핑몰에 몇몇 기능이 추가되었습니다.
빌드/테스트 시간이 길어집니다.
작은 수정에도 시스템 전체를 빌드해야 하며, 테스트 시간도 길어집니다. 요즘처럼 CI/CD가 강조되는 시점에서는 큰 문제가 될 수 있습니다.
선택적 확장이 불가능합니다.
이벤트로 인해 서비스 접속 량이 폭증할 경우 프로젝트 전체를 확장해야만 합니다.
하나의 서비스가 모든 서비스에 영향을 줍니다.
이벤트 서비스에 트래픽이 몰려 해당 서버가 죽게 된다면 다른 모든 서비스 역시 마비 되는 상황이 오게 됩니다.
MSA란?
MSA란 마이크로 서비스 아키텍처(Micro Service Architecture)의 약자로 단일 프로그램을 각 컴포넌트 별로 나누어 작은 서비스의 조합으로 구축하는 방법입니다.
< 온라인 쇼핑몰에 MSA적용 예시 >
각 컴포넌트는 서비스 형태로 구현되고 API를 이용하여 타 서비스와 통신하게 됩니다. 각 서비스는 독립된 서버로 타 컴포넌트와 의존성이 없기 때문에 독립된 배포를 하게 됩니다. 또한 각 컴포넌트가 독립된 서비스로 개발되어있기 때문에 부분적인 확장이 가능합니다. 온라인 쇼핑몰에서 주문 서비스에 트래픽이 증가한다면 해당 서버만 확장을 해주면 됩니다.
물론 이처럼 장점만 있는 것은 아닙니다. 모노리틱 아키텍처가 서비스간의 호출이 하나의 프로세스 내에서 이루어지기 때문에 속도가 빠르지만 MSA의 경우 서비스간 호출을 API통신을 이용하기 때문에 속도가 느리고, 통신에 사용하기 위해 값을 데이터 모델로 변환시켜주는 오버헤드가 발생하기도합니다. MSA는 다음과 같은 특징들을 가지고 있습니다.
데이터 분리
데이터 저장 시 하나의 DB에 중앙 집중화를 하지 않고 서비스 별 별도의 데이터 베이스를 사용합니다. DB의 종류를 별도로 가져갈 수도 있고, 같은 DB를 사용하더라도 나누어서 사용하게 됩니다. 데이터가 분산되어있기 때문에 다른 서비스 컴포넌트에 대한 의존성이 없이 서비스를 독립적으로 개발 및 배포/운영 할 수 있지만, 다른 컴포넌트의 데이터를 API통신을 통해 가져와야 하기 때문에 성능상의 문제가 발생 할 수 있고, 트렌젝션으로 묶을 수 없는 문제가 발생하기도 합니다.
API Gateway
MSA의 문제점 중 하나는 각 서비스가 다른 서버에 분리 배포되어있기 때문에 서버 URL이 각기 다를 수 밖에 없습니다. 이때 API Gateway는 API 서버 앞 단에서 모든 API 서버들의 End-Point를 단일화하여 묶어주는 역할을 합니다. 또한 거미줄처럼 복잡한 서비스간의 API호출 구조도 단순화 시켜줍니다. 그 외에 라우팅, 로드밸런싱, 인증 역할 등등 여러 역할을 수행합니다.
팀의 변화
< 모노리틱 아키텍처에서의 팀 모델 >
기존의 팀 모델은 역할별로 나누어진 모델로 팀을 구분했습니다. 이러한 팀 모델은 인력 관리와 운영에 유연성을 부여하지만 팀간의 커뮤니케이션이 원활하지 않고 협업에 걸리는 시간이 지연되는 경우가 많았습니다.
< MSA에서의 팀 모델 >
MSA에서는 서비스 별로 팀을 나누고 서비스 기획에서부터 설계 개발 운영이 팀 내에서 이루어지기 때문에 다른 팀에 대한 의존성이 사라지게 됩니다. 역할별 요청과 피드백이 빨라지고, 때문에 유연하고 지속적인 운영과 개발이 함께하게 됩니다.
물론 장점만이 있는 것은 아닙니다. 아무래도 인력 리소스 관리에 어려움이 생기게 됩니다. 각 팀의 역할 담당자들은 기본적인 업무 성숙도를 가지고 있어야 하고, 특히 개발자들은 운영 팀의 고유 영역이었던 인프라 핸들링이 가능해야 합니다. 그리고 이러한 일이 가능하게 된 것은 AWS같은 클라우드 서비스 발달입니다. 직접적인 인프라 운영 없이 클라우드 서비스를 이용하여 개발자가 운영 환경을 설정할 수 있게 되었습니다.
정리하자면
MSA는 복잡한 웹 시스템에 맞춰 개발된 API기반의 서비스 지향적 아키텍처 스타일입니다. MSA가 유행을 하고 있지만 꼭 정답은 아니고, 업무나 비즈니스 특징에 따라 적절한 아키텍처가 선택됩니다. 근래의 아키텍처 모델은 시스템에 대한 설계뿐만 아니라 팀의 구조나 프로젝트 관리 방법까지 달라지기 때문에 프로젝트에 미치는 영향이 매우 크며, 때문에 거시적인 관점에서 고려할 필요가 있습니다.
MSA가 필요하다고 해도 꼭 시작을 MSA로 해야 하는 것은 아닙니다. MSA가 서비스의 재사용 성, 유연한 아키텍처구조, 대용량 웹 서비스에 적합한 구조 등 많은 장점을 가지고 있지만 개개인의 높은 숙련도가 필요한 편입니다. MSA를 구축한 많은 기업들이 시작은 모노리틱 시스템으로 시작하여 팀원들의 숙련도를 높이고 피드백을 통해 시스템을 발전 시키는 과정에서 MSA로 전환한 사례들도 있습니다. 프로젝트의 목적이나 팀의 상황에 맞는 유연한 선택이 필요합니다.
출처 : http://clipsoft.co.kr/wp/blog/%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4-%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98msa-%EA%B0%9C%EB%85%90/
