MSA 설계

Monolithic Architecture ↔ Micro Service Architecture

 

Monolithic Architecture

전체 애플리케이션이 하나로 되어있어서 보통 동일한 개발 툴을 사용해 개발되며, 배포 및 테스트도 하나의 애플리케이션만 수행하면 되기 때문에 개발 및 환경설정이 간단함

각 컴포넌트들이 함수로 호출 되기 때문에 성능에 제약이 덜하고, 운영 관리가 용이하다.

작은 볼륨의 시스템을 개발할 때는 매우 유용하지만 시스템이 커지기 시작하고 여러 컴포넌트들이 더해지면 문제가 발생하기 시작

 

기능 추가시 발생하는 문제점

• 빌드 / 테스트 시간이 길어진다.
  • 작은 수정이 있음에도 시스템 전체를 빌드하고, 테스트 시간도 길어진다.
• 선택적 확장이 불가능
  • 트래픽이 증가할 경우에 프로젝트 전체를 확장해야함
• 한가지의 서비스가 모든 서비스에 영향
  • 한 서비스에서 트래픽이 몰려 서버가 다운된다 → 모든 서비스 다운

 

MSA란?

MSA란 마이크로 서비스 아키텍처(Micro Service Architecture)의 약자로 단일 프로그램을 각 컴포넌트 별로 나누어 작은 서비스의 조합으로 구축하는 방법

 

각 컴포넌트는 서비스 형태로 구현되고 API를 이용하여 타 서비스와 통신

각 서비스는 독립된 서버로 타 컴포넌트와 의존성이 없어 독립된 배포방식을 사용

그리고, 각 컴포넌트가 독립된 서비스로 개발이 되어서 부분적 확장이 가능하다. 예를들면 한 서비스에 트래픽이 몰리면 monolithic 구조의 경우에는 전체 서비스를 확장해야 하는 반면 MSA는 전체 적인 확장이 아닌, 트래픽이 증가하는 해당 구간의 경우에만 확장이 필요로 하기 때문

반면에 속도가 monolithic 구조에 비해서 느리다. 하나의 프로세스 내에서 이루어지지 않고 서비스간 호출을 API통신을 사용하기 때문이다. 통신에 사용되는 값을 데이터 모델로 변환시켜주는 오버헤드가 발생할수도있다.

• 데이터 분리
  • 데이터 저장 시 하나의 DB에 중앙집중화를 하지 않고, 서비스 별 별도의 DB를 사용
  • 같은 DB를 사용하더라도 나누어서 사용
  • 의존성이 없어 서비스를 독립적 개발, 배포, 운영가능
  • 타 컴포넌트의 데이터를 API통신을 통해 가져와야함 → 성능상의 문제 발생이 있을 수 있음
  • 트랜젝션으로 묶을 수 없는 문제가 발생
• API Gateway
  • 서버 URL이 각각 다를 수 밖에없음
  • API 서버 앞 단에서 모든 API 서버들의 End-Point를 단일화하여 묶어주는 역할을 수행
  • 거미줄처럼 복잡한 서비스간의 API호출 구조도 단순화
  • 라우팅, 로드밸런싱, 인증 역할 등 여러 역할 수행

MSA는 복잡한 웹 시스템에 맞춰 개발된 API기반의 서비스 지향적 아키텍쳐 스타일(SOA)

단순한 웹 시스템의 경우는 MSA 보단 monolithic에서 점차 변경하는것이 대중적이고, 안정적인 서비스로 나아가는 방향으로 생각할 수 있음