[MSA] MSA?

in Study on MSA

MSA 개념과 장단점

목차

MSA

MSA 개념

The Microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies. - James Lewis, Martin Fowler -

  • MSA는 애플리케이션을 개발하는 방식 중 하나.
  • 각각 프로세스를 갖는 작은 서비스들로 구성
  • 서비스 분리는 업무 중심의 기준 적용
  • 서비스별 자동 배포에 의한 독립적 배포
  • 독립적인 서비스이기 때문에 서로 다른 프로그래밍 언어, DB로 구성할 수 있음

왜 MSA인가?

  • 비즈니스 요구에 빠르게 적용하기 위해서.
    • 기존에는 팀 구성이 각 기술 단위로 나뉘어져 있었으나 MSA 적용을 통해 비즈니스 단위로 팀을 구성할 수 있음
  • 빠른 개발, 적용, 검증, 확장
    • 서비스 분리로 기존 Monolithic 구조보다 빠르게 추가 기능 구현 가능

MSA 장단점

MSA 장점

  1. 물리적 분리
    • 비즈니스 별 특징에 맞게 환경 구성 가능
    • 복잡도 감소
    • 서비스 별 개발, 배포, 운영 가능
  2. 배포
    • 독립적인 배포 가능
    • 기존 Monolith 보다 빠른 배포 가능
  3. 장애
    • 서비스 분리를 통해 장애 요소 분리
    • 전체 서비스의 장애 방지
  4. 확장
    • 업무 확장 : 추가 서비스 로직 추가 용이
    • 물리 확장(Auto scailing) : docker 등의 컨테이너 + K8S 등을 통한 오토 스케이링 적용 용이
    • 비즈니스 로직 수정, 확장에 유연성

MSA 단점

  1. 성능
    • 서비스간 네트워크 통신(API, 메시지)으로 인한 시간 증가
  2. 테스트
    • 서비스 분리로 인한 테스트 어려움
    • 서비스 간 종속성으로 인해 테스트 코드 생성 어려움 발생
  3. 트랜잭션
    • 분산 환경으로 인한 DBMS 트랜잭션 처리 불가
  4. 데이터 쿼리
    • 업무 기준 서비스/DB 분리로 인한 여러 데이터 한 번에 조회 어려움 발생
  5. 복잡도
    • 분산 환경, 트랜잭션, 쿼리 등을 처리하기 위한 별도 기능 개발 필요
    • 서비스 호출 추적, 디버깅, 모니터링 등 어려움 발생 —> ELK, EFK 등의 서비스를 연동하는 방안으로 해결 가능




MSA 프로젝트 설계 단계를 경험하고 있는 주니어 개발자의 짧은 식견이지만, 개인적인 생각으론 MSA 이전에 기존 Monolith 소스를 리팩토링 하는 것이 우선되어야 한다고 생각된다.

기존 스파게티 코드를 가지고 MSA를 바로 적용한다는 것은 AS-IS 시스템을 잘 아는 사람만으로 프로젝트 팀을 구성할 수 없다면 프로젝트의 성공을 바라는 것은 과한 욕심이 아닌가 싶다.

우선적으로 난잡한 코드에 대해 클린 코드, 리팩토링 진행을 통해 업무 간 서비스 로직이 정리될 때 MSA의 서비스 단위를 도출하는 것이 더 쉬울 것이고, 차후 서비스를 분리할 때도 더 편할 것이다.

프로젝트 경험이라고 해봤자 아직은 많이 부족하지만 프로젝트를 경험하면서 가장 아쉬웠던 점은 리팩토링, 클린코드에 대해 아무도 관심이 없다는 점이었다. SI의 경우 숨가쁜 일정으로, SM의 경우 계속해서 요구되는 수정사항으로, 그리고 SI/SM 모두 공통적으로 시스템에 대한 안전과 보수지향성으로 인해 리팩토링의 필요성에 대해 대두되는 곳이 적은 것 같아 그저 아쉬운 마음이다.

MSA의 서비스 분리로 인한 단점으로 다시 모노리스로 회귀한 경우도 있다고 한다. 우아한 형제들의 박용권 님의 우아한 모노리스 세미나 영상을 보면 잦은 API 통신, 분리한 서비스 간의 지나친 의존성 등으로 모노리스로 회귀했다고 한다. 다만 도메인 기반의 개발, 모듈화를 통해 느슨한 연관을 가지도록 만들었다고 한다.


참조