MSA 란?
"하나의 큰 어플리케이션을 여러개의 작은 어플리케이션으로 쪼개어 변경과 조합이 가능하도록 만든 아키텍쳐"
MSA 등장 배경
- Monolithic Architecture
소프트웨어의 모든 구성요소가 한 프로젝트에 통합되어있는 형태
- 간단한 Architecture이고 , 유지보수가 용이
- 서비스/프로젝트가 커지면 커질수록, 영향도 파악 및 전체 시스템 구조의 파악에 어려움이 있습니다.
- 빌드 시간 및 테스트시간, 그리고 배포시간이 기하급수적으로 늘어나게 됩니다.
- 서비스를 부분적으로 scale-out하기가 힘듭니다.
- 부분의 장애가 전체 서비스의 장애로 이어지는 경우가 발생하게됩니다.
- Micro Service Architecture
- small services, each running in tis own process (스스로 돌아갈 수 있는 작은 서비스)
- independently deployable(독립적 배포 가능)
- 각각의 서비스는 그 크기가 작을 뿐, 서비스 자체는 하나의 모놀리틱 아키텍쳐와 유사한 구조를 가짐
- 각각의 서비스는 독립적으로 배포가 가능해야함.
- 각각의 서비스는 다른 서비스에 대한 의존성이 최소화 되어야함
- 각 서비스는 개별 프로세스로 구동 되며, REST와 같은 가벼운 방식으로 통신되어야 함.
MSA의 장단점
장점
-
배포(deployment) 관점서비스 별 개별 배포 가능 ( 배포 시 전체 서비스의 중단이 없음)
요구사항을 신속하게 반영하여 빠르게 배포할 수 있음.
-
확장(scaling) 관점특정 서비스에 대한 확장성이 용이함.
클라우드 사용에 적합한 아키텍쳐.
-
장애(failure) 관점장애가 전체 서비스로 확장될 가능성이 적음
부분적 장애에 대한 격리가 수월함
이외에도 신기술의 적용이 유연하고, 서비스를 polyglot하게 개발/운영할 수 있다.
단점
Monolithic Architecture은 단순한 아키텍쳐인데 비해 MSA는 보다 복잡한 아키텍쳐로, 전체 서비스가 커짐에 따라 그 복잡도가 기하급수적으로 늘어날 수 있습니다.
- 성능 - 서비스 간 호출 시 API를 사용하기 때문에, 통신 비용이나, Latency가 그만큼 늘어나게 됩니다.
- 한 트랜잭션 처리 및 각각의 어플리케이션 에러에 대한 처리가 필요하다
- 배포에 대한 자동화가 필수 요소이다
- 테스트 / 트랜잭션 - 서비스가 분리되어 있기 때문에 테스트와 트랜잭션의 복잡도가 증가하고, 많은 자원을 필요로 합니다.
- 데이터 관리 - 데이터가 여러 서비스에 걸쳐 분산되기 때문에 한번에 조회하기 어렵고, 데이터의 정합성 또한 관리하기 어렵습니다.
비교
MSA로 전환해야할 때 주의할 점
- MSA를 기술적인 프로젝트로만 간주해서 진행하면 안 되고, 비즈니스 가치를 제공하기 위한 것이라는 것을 염두에 두고 진행해야 한다
- MSA가 가치를 제공하기 위해서는 지속적인 애플리케이션의 변화를 신속하게 따라가면서 서비스를 선보여야 하는데, 만약 어떤 조직이 애플리케이션을 개발해 놓고 변화 없이 그대로 가는 경우에는 굳이 MSA가 필요 없다
- MSA에서 가치나 효과를 기대하기 위해서는 개발이 신속하게 이뤄져야 하는데, 그 전제조건으로 애자일(agile)한 개발, 데브옵스(DevOps)라던가 통합 파이프라인, 테스팅 자동화, 인프라 등이 갖춰져야 한다는 점이다. 이러한 부분이 되지 않으면 전환해봐야 별다른 가치를 갖지 못한다
- 전환과정이 점진적으로 이뤄져야 한다는 것이다. 모놀리식에서 MSA로 가는 부분에 있어 단계별 접근이 필요하다. 처음에는 큰 부분(macro)에서부터 점점 작은 부분(micro)으로 가면서, 효과를 체크하면서 가야 한다. 얻을 수 있는 가치가 적어지기 시작하면 마이크로로 갈 필요가 없다는 것이다. 때문에 단계적으로 추진해야 한다
일단은 중요한 것이, 너무 많은 변화를 한 번에 주면 실패에 대한 위험부담이 크다는 점이다. MSA를 도입하기 위해 프로세스를 한 번에 너무 많이 변경하면 실제 어떤 게 성공요인이었고 실패요인인지를 판단할 수 없다. 바꿔나가는 요소를 최소화해서 조그만 변화를 단계적으로 주는 것이 중요하기 때문이다
Monolithic 환경에서는 살아있던 서비스들이 간혹 죽어있다.
MSA에서 서비스는 다른 프로세스에서 실행되는 컴포넌트라는 의미다. 즉, 다른 서비스가 살아있음을 보장 할 수 없다. 다른 서비스를 호출했는데 503 (Service unavailable) 상태코드가 리턴된 경우, Circuit Breaker 패턴을 사용할 수 있다. 우리는 이를 위해 Hystrix를 적용했다. Hystrix는 죽어있는 서비스에 대해서 circuit을 open 해서 요청이 timeout 될 때까지 길게 기다리지 않게 하고, 비즈니스 요구사항에 맞게 fallback 정책을 가져갈 수 있다.
ACID가 보장이 안된다
MSA는 기본적으로 분산환경이다. 모든 서비스가 네트워크 상에 존재한다. 따라서 데이터의 일관성을 보장 하기 어렵다. 다른 서비스에 CRUD를 발생시켜야 하는 경우에 Event Driven Architecture를 적용하고 Eventual Consistency를 달성하고자 노력했다. Rabbitmq를 통해 message를 전달했다. rabbitmq가 qos level 1을 지원하므로 최소 한번은 전달하는 것을 보장해 준다.
하지만 message 전달이 실패하거나 서비스에서 처리 중 에 오류가 난 경우 보상작업을 해주거나 별도 비즈니스 흐름을 가져가야 하는 복잡함이 추가로 생겨난다.
Microservice Architecthure 적용기업
실제 사용사례
Uber (우버)
https://brunch.co.kr/@yesjun/2
카카오