모놀리식에서 MSA로의 전환: 기술적 변화와 장단점 분석

MSA란?

"Microservices Architecture"의 약자로, 어플리케이션을 작고 독립적인 서비스들로 구성된 소프트웨어 아키텍처 패턴입니다.

• 애플리케이션 구성요소가 통신프로토콜을 통해 다른 구성요소에 서비스를 제공하는 아키텍처 접근 방식
• 대규모 컴퓨터 시스템을 구축할 때의 개념으로 소프트웨어 기능을 서비스로 판단하여 그 서비스를 네트워크상에 연동하여 시스템 전체를 구축해 나가는 방법론
• 여기서 '서비스'는 기능의 독립적 단위

예를들면 다음과 같은 기능들이 각각 별도의 마이크로서비스로 동작하고 있다고 생각하면 됩니다.

• ott(넷플릭스, youtube 등..) 서비스에서의 마이크로서비스 동작은 다음과 같습니다.

1. 영화추천 서비스: 사용자의 과거 시청 이력, 선호 장르 등을 바탕으로 개인화된 영화와 TV 프로그램을 추천하는 서비스입니다.
2. 비디오 스트리밍 서비스: 선택한 영화나 TV 프로그램을 스트리밍 해주는 서비스입니다.
3. 사용자 인증 서비스: 사용자의 로그인 요청을 처리하고, 사용자를 인증하는 서비스입니다.
4. 결제 처리 서비스: 사용자의 결제를 처리하는 서비스입니다.

각각의 마이크로서비스는 독립적으로 개발되고, 배포될 수 있습니다.
따라서 한 서비스에 문제가 생겨도 다른 서비스들에는 영향을 주지 않으며, 특정 서비스에 대한 개선이나 확장 작업도 훨씬 빠르고 유연하게 처리될 수 있습니다.

MSA 등장배경

• Monolithic Architecture는 소프트웨어의 모든 구성요소가 한 프로젝트에 통합되어 있는 서비스입니다.
• 현재 많은 회사들의 소프트웨어가 레거시 또는 필요로 인해 Monolithic 형태로 구현되어 있습니다.
• 소규모의 프로젝트에서는 Monolithic 형태는 간단하며, 유지보수가 편하기 때문에 선호됩니다.
• 그러나 일정 규모 이상을 넘어가면 Monolithic은 많은 한계점에 봉착합니다.

기존 Monolithic Architecture의 한계

• 부분 장애가 전체 서비스의 장애로 확대될 수 있음
• 전체 시스템 구조 파악이 어려움
• 서비스 변경이 어렵고, 수정 시 영향도(사이드 이펙트 등) 파악이 힘듬
• 빌드 시간 및 테스트, 배포 시간의 급증
• 서비스의 특정 부분만 스케일아웃(scale-out)하기 어려움

MSA 특징

• MSA는 API를 통해서만 상호작용할 수 있습니다.
• 즉, 마이크로 서비스는 서비스의 end-point(접근점)을 API 형태로 외부에 노출하고, 실질적인 세부 사항은 모두 추상화합니다.
• 내부의 구현 로직, 아키텍처와 프로그래밍 언어, 데이터베이스, 품질 유지 체계와 같은 기술적인 사항들은 서비스 API에 의해 철저하게 가려집니다.
• 제대로 설계된 마이크로서비스는 하나의 비즈니스 범위에 맞춰 만들어지므로 하나의 기능만 수행합니다.
• 즉, 어플리케이션 출시처럼 하나의 목표를 향해 일하지만 자기가 개발하는 서비스만 책임집니다.
• 그리고 여러 어플리케이션에서 재사용할 수 있어야합니다.
• 어플리케이션은 항상 기술 중립적 프로토콜을 사용해 통신하므로 서비스 구현 기술과는 무관합니다.
• 따라서 마이크로서비스 기반의 어플리케이션을 다양한 언어와 기술로 구축할 수 있다는 것을 의미합니다.
• 마이크로서비스는 SOA에서 사용되는 집중화된 관리 체계를 사용하지 않습니다.
• 마이크로서비스 구현체의 공통적인 특징 중 하나는 ESB(Entrerprise Service Bus)와 같은 무거운 제품에 의존하지 않는다는 점입니다.
• REST 등 가벼운 통신 아키텍처, 또는 Kafka 등을 이용한 message stream을 주로 사용합니다.

데이터 분리

• 데이터 저장 시 하나의 DB에 중앙 집중화를 하지 않고 서비스 별 별도의 데이터 베이스를 사용합니다.
• DB의 종류를 별도로 가져갈 수도 있고, 같은 DB를 사용하더라도 나누어서 사용하게 됩니다.
• 데이터가 분산되어 있기 때문에 다른 서비스 컴포넌트에 대한 의존성이 없어 서비스를 독립적으로 개발 및 배포/운영 할 수 있지만, 다른 컴포넌트의 데이터를 API통신을 통해 가져와야 하기 때문에 성능상의 문제가 발생 할 수 있고, 트랜잭션으로 묶을 수 없는 문제가 발생하기도 합니다.

API Gateway

• MSA의 문제점 중 하나는 각 서비스가 다른 서버에 분리 배포되어있기 때문에 서버 URL이 각기 다를 수 밖에 없습니다.
• 이때,API Gateway는 API 서버 앞 단에서 모든 API 서버들의 End-Point를 단일화하여 묶어주는 역할을 합니다.
• 또한, 거미줄처럼 복잡한 서비스간의 API 호출 구조도 단순화 시켜줍니다.
• 그 외에 라우팅, 로드밸런싱, 인증 역할 등 여러 역할을 수행합니다.

팀 변화

모놀리식 팀 모델

• 기존 팀 모델은 역할별로 나누어진 모델로 팀을 구분했습니다.
• 이러한 팀 모델은 인력 관리와 운영에 유연성을 부여하지만 팀간의 커뮤니케이션이 원활하지 않고 협업에 걸리는 시간이 지연되는 경우가 많습니다.

MSA에서의 팀 모델

• MSA에서는 서비스 별로 팀을 나누고 서비스 기획에서부터 설계, 개발, 운영이 팀 내에서 이루어지기 때문에 다른 팀에 대한 의존성이 사라지게 됩니다.
• 역할별 요청과 피드백이 빨라지고, 유연하고 지속적인 운영과 개발이 함께하게 됩니다.
• 물론 장점만 있는것은 아닙니다. 아무래도 인력 리소스 관리에 어려움이 생기게 됩니다.
• 각 팀의 역할 담당자들은 기본적인 업무 성숙도를 가지고 있어야 하고, 특히 개발자들은 운영팀의 고유 영역이었던 인프라 핸들링이 가능해야 합니다.
• 그리고 이러한 일이 가능하게 된 것은 AWS 같은 클라우드 서비스 발달입니다.
• 직접적인 인프라 운영 없이 클라우드 서비스를 이용하여 개발자가 운영 환경을 설정할 수 있게 되었습니다.

MSA 장점

1. 배포

• 서비스별 개별 배포가 가능합니다.
• 배포시 전체 서비스의 중단이 없습니다.
• 특정 서비스의 요구사항만을 반영하여, 빠르게 배포 가능합니다.

2. 확장

• 특정 서비스에 대한 확장성(scale-out)이 유리합니다.
• 클라우드 기반 서비스 사용에 적합합니다.

3. 장애

• 일부 장애가 전체 서비스로 확장될 가능성이 적습니다.
• 부분적으로 발생하는 장애에 대한 격리가 수월합니다.

4. 그외

• 새로운 기술을 적용하기 유연합니다.
• 통신을 통해 애플리케이션이 운영되므로 전체 서비스가 아닌 특정 서비스만 별도의 기술 또는 언어로 구현 가능합니다.
• 각각의 서비스에 대한 구조 파악 및 분석이 모놀리식 구조에 비해 쉽습니다.

MSA 단점

1. 설계의 어려움

• MSA는 모놀리식에 비해 상대적으로 많이 복잡합니다.
• 서비스가 모두 분산되어 있기 때문에 개발자는 내부 시스템의 통신을 어떻게 가져가야 할지 정해야합니다.
• 통신의 장애와 서버의 부하 등이 있을 경우 어떻게 transaction을 유지할지 결정하고 구현해야합니다.

2. 성능

• 서비스 간 호출시 API를 사용하므로, 통신 비용이나 Latency에 대해 이슈가 존재합니다.

3. 테스트 / 데이터 트랜잭션

• 모놀리식에서는 단일 트랜잭션을 유지하면 됬지만 MSA에서는 비즈니스에 대한 DB를 가지고 있는 서비스도 각기 다르고, 서비스의 연결을 위해서는 통신이 포함되기 때문에 트랜잭션을 유지하는게 어렵습니다.
• 통합 테스트가 어렵습니다.
• 개발 환경과 실제 운영환경을 동일하게 가져가는 것이 쉽지 않습니다.

4. 데이터 관리

• 데이터가 여러 서비스에 분산되어 있어 조회하기 어렵습니다.
• 데이터를 관리하기 어렵습니다.