이 블로그에서 MSA를 다룰까 말까 굉장히 고민했었다..
deep한 기술이기도 하고, 취준생의 입장으로써 내가 msa를 얼마나 이해했고, 그것들을 표현할 수 있을까.. 하고 말이다.
하지만 최근 정말 핫한 기술이기도 하고, 신입으로써 msa 역량을 묻는 경우도 많다 보니 일단 이번 시간에 msa의 개념에 대해서 알아보도록 하겠다.
다음에 시간이 되면,, 구현 방식에 대해서도 추가로 다루겠다.
MSA?
MicroService Architecture의 줄임말
작고 독립적으로 배포 가능한 각각의 기능을 수행하는 서비스로 구성된 프레임워크
MSA 등장배경
Monolithic Architecture는 소프트웨어의 모든 구성요소가 한 프로젝트에 통합되어 있는 서비스
기존 Monolithic Architecture의 한계
- 부분 장애가 전체 서비스의 장애로 확대될 수 있음
- 전체 시스템 구조 파악이 어려움
- 서비스 변경이 어렵고, 수정 시 영향도 파악이 힘듦
- 빌드 시간 및 테스트, 배포 시간의 급증
- 서비스의 특정 부분만 Scale-Out하기 어려움
- 한 Framework와 언어에 종속적
MSA 특징
- MSA는 API를 통해서 상호작용할 수 잇다.
- 마이크로 서비스는 서비스의 end-point를 API형태로 외부에 노출하고, 실질적인 세부사항은 모두 추상화한다.
- 제대로 설계된 마이크로서비스는 하나의 비즈니스 범위에 맞춰 만들어지므로 하나의 기능만 수행한다.
- 마이크로 서비스간 통신으로 REST등 가벼운 통신 아키텍처, Kafka 등을 이용한 message stream을 주로 사용한다.
MSA 장점
- 배포
- 서비스별 개별 배포가 가능하다.
- 특정 서비스를 배포해도 전체 서비스의 중단이 없다.
- 특정 서비스의 요구사항만을 반영하여, 빠르게 배포 가능하다.
- 확장
- 특정 서비스에 대한 확장성(scale-out)이 유리하다.
- 클라우드 기반 서비스 사용에 적합하다.
- 장애
- 일부 장애가 전체 서비스로 확장될 가능성이 적다.
- 부분적으로 발생하는 장애에 대한 격리가 수월하다.
- 언어
- 서비스별로 다양하고 별도의 언어와 framework로 구현이 가능하다.
- 분석
- 각각의 서비스에 대한 구조 파악 및 분석이 모놀리식 구조에 비해 쉽다.
MSA 단점
- 설계의 어려움
- 서비스가 모두 분산되어 있기 때문에 개발자는 내부 시스템의 통신을 어떻게 가져가야할지 정해야한다.
- 통신의 장애와 서버의 부하 등이 있을 경우 어떻게 transaction을 유지할지 결정하고 구현해야한다.
- 성능
- 서비스 간 호출 시 API를 사용하므로, 통신 비용이나 Latency에 대해 이슈가 존재한다.
- 테스트
- 모놀리식에서는 단일 트랜잭션을 유지하면 됐지만 MSA에서는 비즈니스에 대한 DB를 가지고 있는 서비스도 각기 다르고, 서비스의 연결을 위해서는 통신이 포함되기 때문에 트랜잭션을 유지하는게 어렵다.
- 통합 테스트가 어렵다. 개발 환경과 실제 운영환경을 동일하게 가져가는게 쉽지 않다.
- 데이터 관리
- 데이터가 여러 서비스에 분산되어 있어 조회하기 어렵다.
- 데이터를 관리하기 어렵다.
야호