[MSA] - MSA 아키텍처

chancehee·2023년 1월 12일
0

MSA

목록 보기
2/2
post-thumbnail

0. 글을 작성하는 이유

집을 지으려면 무작정 벽돌부터 쌓으면 될까요?
물론 집을 만들수도 있지만 수많은 시행착오를 겪게되고 끝내 완성도가 낮은 집을 만들 것입니다.
만약 집을 어떻게 무엇으로 지을 것인가 계획을 꼼꼼히 세우고 전체적인 구상을 하고 진행한다면 시행착오를 줄이고 더욱 완성도 높은 집을 지을 수 있을 것입니다.

개발도 마찬가지 입니다.
그중에서도 Monolithic, SOA, Microservices 와 같은 용어들이 존재합니다.
3가지 용어를 요즘 대세인 MSA와 비교하여 알아보겠습니다.🤗

1. MSA

Microservice Architecture의 약자로, 애플리케이션을 느슨하게 결합된 서비스의 모임으로 구조화하는 *서비스 지향 아키텍처(SOA) 스타일의 일종인 소프트웨어 개발 기법 입니다.

*서비스 지향 아키텍처(Service Oriented Architecture)

  • 애플리케이션의 구성요소가 통신프로토콜을 통해 다른 구성요소에 서비스를 제공하는 아키텍처 접근 방식
  • 대규모 컴퓨터 시스템을 구축할 때의 개념으로 업무상에 일 처리에 해당하는 소프트웨어 기능을 서비스로 판단하여 그 서비스를 네트워크상에 연동하여 시스템 전체를 구축해 나가는 방법론
  • 여기서 '서비스'는 기능의 독립적 단위

2. MSA 등장배경

MA(Monolithic Architecture)는 소프트웨어의 모든 구성요소가 한 프로젝트에 통합되어 있는 서비스로 대부분의 기업용 애플리케이션은 하나의 거대한 서비스 형태로 개발되어 왔습니다. 모놀리식 아키텍처는 개발·관리가 용이하다는 장점이 있습니다.
그러나 시스템 규모가 커질 경우 복잡도도 증가해 코드의 이해와 분석이 어려워지고 작은 수정사항에도 전체를 전체를 빌드·배포해야 하는 비효율이 발생하는 등 개선과 확장이 어려운 단점도 존재합니다.

이에 대응하년 개념이 MSA입니다. 경량화되고 독립적인 여러 개의 서비스를 조합하여 애플리케이션을 구현하는 방식으로 서비스마다 자체 데이터베이스를 가지고 동작하기 때문에 개발부터 빌드·배포까지 효율적으로 수행할 수 있습니다.

3. Monolithic 의 한계

  • 부분 장애가 전체 서비스의 장애로 확대될 수 있습니다.
  • 전체 시스템 구조 파악이 어렵습니다.
  • 서비스 변경이 어렵고, 수정 시 영향도 파악이 힘듦니다.
  • 빌드 시간 및 테스트, 배포 시간이 오래 걸립니다.
  • 서비스의 특정 부분만 스케일아웃하기 어렵습니다.

4. MSA 특징

  • MSA는 API를 통해서만 상호작용할 수 있습니다. 즉, 마이크로 서비스는 서비스의 end-point(접근점)을 API 형태로 외부에 노출하고, 실질적인 세부 사항은 모두 추상화하는 것입니다.
  • 내부의 구현 로직, 아키텍처와 프로그래밍 언어, 데이터베이스, 품질 유지 체계와 같은 기술적인 사항들을 서비스 API에 의해 철저하게 가려집니다.
  • 제대로 설계된 MSA는 하나의 비즈니스 범위에 맞춰 만들어지므로 하나의 기능만 수행합니다.
  • 애플리케이션은 항상 기술 중립적 프로토콜을 사용해 통신하므로 서비스 구현 기술과는 무관합니다.
  • MSA는 SOA에서 사용되는 집중화 관리 체계를 사용하지 않습니다. 따라서 REST 등 가벼운 통신 아키텍처 또는 Kafka 등을 이용한 Message Stream을 주로 사용합니다.

5. MSA 장점

  • 서비스별 개별 배포가 가능하므로 배포시 전체 서비스의 중단이 없고 특정 서비스의 요구사항만을 반영하여, 빠르게 배포가 가능합니다.
  • 특정 서비스에 대한 확장(scale-out)이 유리합니다.
  • 일부 장애가 전체 서비스로 확장될 가능성이 적습니다.
  • 새로운 기술을 적용하기 유연합니다.
  • 각각의 서비스에 대한 구조 파악 및 분석이 모놀리식 구조에 비해 쉽습니다.

6. MSA 단점

  • 모놀리식 아키텍처에 비해 상대적으로 많이 복잡하여 설계가 어렵습니다.
  • 서비스 간 호출 시 API를 사용하므로, 통신 비용이나 Latency에 대한 이슈가 존재합니다.
  • 비즈니스에 대한 DB를 가지고 있는 서비스가 각기 다르고, 서비스와 연결을 위해서는 통신이 포함되기 때문에 트랜잭션을 유지하는게 어렵습니다.
  • 통합 테스트가 어렵습니다.
  • 데이터를 관리하기 어렵습니다.

7. 결론

결국 MSA는 복잡한 웹 시스템에 맞춰 개발된 API 기반의 서비스 지향적 아키텍처 스타일입니다.
MSA가 유행을 하고 있지만 꼭 정답은 아닙니다. (장점만 있는건 아니니까)
따라서 업무나 비즈니스 특징에 따라 적절한 아키텍처 선택이 중요합니다.
아키텍처 모델은 시스템에 대한 설계뿐만 아니라 팀의 구조나 프로젝트 관리 방법까지 달라지기 때문에 프로젝트에 미치는 영향이 매우 큽니다..
때문에 거시적인 관점에서 고려할 필요가 있습니다.🧚

출처

0개의 댓글