기타

MSA(Microservice Architecture)란?

imsoncod 2021. 2. 1. 00:58

개요

MSA(Microservice Architecture)는 소프트웨어 개발 기법의 일종으로 간단하게 큰 애플리케이션을 작게 나누는 방법입니다.

image

좌측의 Monolithic Architecture는 UI, Business Logic, Data Access Layer가 한 곳에 모여있는 것을 볼 수 있습니다.(마치 대학시절 제가 진행하던 프로젝트를 연상시키는군요...)

반면에, Microservice Architecture는 여러 서비스와 데이터베이스가 분산되어 있습니다.
두 개의 Architecture는 서로다른 장단점을 가지고 있습니다. 어떤 것이 항상 Best Practice라고 단정지을 수 없죠.

이번 글에서는 MSA를 중심으로 장단점에 대해 간단하게 핵심만 알아보겠습니다.

장점

1. 장애 격리와 복구가 쉽습니다.

A서비스에서 장애가 발생하면, 이 장애는 A서비스 내에 격리되기 때문에 빠른 탐지와 복구가 가능합니다.

2. 빠르고 잦은 배포가 가능합니다.

서비스들이 분산되어 독립성을 유지하기 때문에 빠르고 잦은 배포가 가능합니다.

이는 서비스 개선 속도의 증가로도 이어집니다.

3. 생산성이 향상됩니다.

Monolithic와 비교하여 서비스 하나의 규모가 작기 때문에 코드의 양도 적고 쉽게 수정할 수 있습니다.

4. 신기술 도입이 쉽습니다.

신기술을 도입할 서비스를 구현하는 팀에게 선택권이 있기 때문에 구현이후 다른 팀에게 공유할 수 있습니다.

반면, Monolithic에서는 신기술을 도입하기 위해 모든 팀원이 의사결정에 참여하고 움직여야 합니다.

5. Polyglot 프로그래밍이 가능합니다.

Polyglot는 필요에 따라 여러 언어를 자유롭게 사용하는 프로그래밍 방식입니다.

MSA에서는 각 서비스에 최적화된 개발 언어와 데이터베이스를 선택할 수 있습니다.

단점

1. 서비스별로 분산된 트랜잭션을 처리하기가 어렵습니다.

2. 여러 서비스에 걸쳐져 있는 Feature의 경우, 테스팅이 복잡합니다.

3. 서비스의 개수가 많고 분산되어 있어 CI/CD 관리가 복잡합니다.

MSA는 어떤 서비스에 적용해야 할까?

MSA라고 무조건 다 좋은것은 아니기에, 서비스가 MSA에 적합한지 고려해야 합니다.
위의 장단점을 기반으로 고려해야 할 사항들을 몇 가지 생각해볼 수 있습니다.

  • 빠르고 잦은 배포가 필요한 서비스인가? -> 반드시 DevOps를 적용해야 합니다.
  • 서비스가 분산되어 통신 횟수가 증가 -> 퍼포먼스에 민감한 서비스인가?
  • 분산 트랜잭션이 필요한 서비스인가? -> 최근에는 이 이슈를 해결하기 위한 해결책이 등장했습니다
    ex) Two-Phase Commit, Saga
  • 분산된 서비스를 관리할 수 있는 팀 또한 함께 운영되어야 합니다.
반응형