반응형
MSA(MicroService Architecture)란?
내가 생각하기에 MSA를 이해하기 가장 쉬운 한줄 정의는 '하나의 큰 어플리케이션을 여러개의 작은 어플리케이션으로 쪼개어 변경과 조합이 가능하도록 만든 아키텍처' 이다.
왜 이런 아키텍처가 나왔을까? 대부분의 어플리케이션은(현재 우리도 그렇다) 전통적인 아키텍처를 뜻하는 모놀리식(Monolithic)이다.
모놀리식 아키텍처는 소규모 프로젝트에서 합리적이고 간단한 아키텍처이지만, 일정 규모 이상의 서비스가 되면 아래와 같은 한계가 발생하게 된다.
- 시스템 구조 파악의 어려움
- 빌드, 테스트, 배포 시간이 기하급수적으로 늘어남
- 서비스를 부분적으로 Scale Out하기 어려움
- 부분의 장애가 전체 서비스로 이어지는 경우가 존재(일부 모듈 변경사항 때문에 전체 애플리케이션 프로세스가 영향을 받을 수 있음)
- 모듈 확장의 어려움, 모듈별 특성에 맞는 신기술 또는 구조를 적용하기 어려움
2021/01/24 - [프로그래밍 노트/인프라] - ScaleOut, ScaleUp (스케일아웃, 스케일업)
MSA의 장점
MSA에서 기억해야할 중요한 단어는 2가지이다. (https://martinfowler.com/articles/microservices.html)
- small service, each running in its own process(스스로 돌아갈 수 있는 작은 서비스)
- independently deployable(독립적 배포 가능)빠른 배포
- 특정 서비스에 대한 확장 용이(Scale Out)
- 장애가 전체 서비스로 확장될 가능성이 적음(부분적 장애 격리)
- 서비스를 팀단위로 운영 가능 - 팀단위로 적절한 기술 스택을 선정하여 적용 가능
MSA의 단점
- 장애추적, 모니터링, 매니징의 어려움
- ELK, EFK 등 서비스를 연동하는 방안 고려
- 테스트/트랜잭션을 다루기 어려움
- 보상 트랜잭션(compensation transaction), 복합 서비스(composite service) 고려
- 서비스 간의 의존성(dependency)가 있는 경우 배포가 까다로움
※ ELK : ElasticSearch, Fluentd, Kibana (잘모름.)
※ 보상 트랜잭션 : 한 트랜잭션처리에서 오류 발생시, 에러 처리 로직을 구현해줌으로써 트랜잭션 일관성 유지
※ 복합 서비스 : 트랜잭션을 묶어야 하는 두 개의 시스템을 트랜잭션을 지원하는 네이티브 프로토콜을 이용해서 구현 후 API로 노출시키는 방법
참고) https://bcho.tistory.com/948
참고) https://waspro.tistory.com/429?category=857035
반응형
