[MSA] MSA 란?

MSA

MSA 는 하나의 어플리케이션을 다수의 독립적인 서비스들의 집합으로 구성하는 것입니다.

각자의 별도의 프로세스에서 실행되며 HTTP API 와 같은 가벼운 매커니즘으로 통신하는 작은 어플리케이션이라고도 볼 수 있습니다.

작은 서비스들은 각자의 비즈니스 기능을 담당하고 완전 자동화된 절차에 따라 독립적으로 배포되야 합니다.

각 서비스는 서로 다른 프로그래밍 언어나 서로 다른 데이터 저장 기술을 사용할 수 있습니다.

Microservice 는 Microservice Architecture, MSA, Microservices 라고도 부릅니다.

 

기존의 Monolithic 시스템에서 발생되는 문제들을 해결하기 위한 아키텍쳐 구조라고 볼 수 있고, 국내외에서 많은 관심과 유행되고 있습니다.

 

 

MSA를 현재 많이 선택하는 이유

비즈니스 환경이 점점 빠르게 급변하고 있고 비즈니스가 IT 기술에 의존하는 케이스가 매우 많습니다.

민첩한 IT 기술 없이 비즈니스의 빠른 변화를 추구하기에는 무리가 있기 때문에 빠르게 배포를 하거나 각 기능을 확장시키고 운영할 수 있는 MSA 가 채택되는 것입니다.

 

 

MSA 특징

• 서비스를 통한 컴포넌트화
  • 하나의 서비스 단위를 컴포넌트로 정의합니다.
  • 특정 비즈니스 기능을 담당하고, 독립적인 프로세스로 실행, 자율적으로 배포 가능해야 합니다.
  • 서비스는 응집도 높게 설계되어야 합니다.
  • 서비스 간에는 명확한 인터페이스를 제공하여 협력합니다.
• 비즈니스 역량에 따른 조직 구선
  • Conway 법칙 : 시스템을 설계하는 조직은 그 조직의 소통 구조를 닮은 아키텍처를 만든다.
  • 조직의 구조가 시스템의 아키텍쳐어 영향을 줍니다.
  • 단일 비즈니스 영역 기능의 변경이 다수의 팀 간의 협업을 필요로 합니다.
  • 각 서비스를 구현하기 위해 필요로 하는 팀들이 구성되어지는 것이 MSA를 잘 구현했다고 볼 수 있습니다.
• 프로젝트보다 제품에 집중
  • 기존에는 개발과 운영이 분리되어 있었지만 MSA 에서는 팀이 개발/운영을 포함한 전체 라이프 사이클을 책임집니다.
  • 단순이 기능을 개발하고 넘기는 것에 그치는 것이 아니라 SW가 어떻게 고객에게 가치를 전달할 수 있을지에 대한 고민하는 계기가 됩니다.
• 똑똑한 End Point, 단순한 Pipe
  • 도메인 로직은 각 서비스 내에 응집도 높게 유지합니다.
  • 각 서비스 간의 연결은 HTTP API, MQ 등을 사용합니다.
• 분산된 거버넌스
  • 중앙에 강력한 표준이나 절차의 준수를 강요하지 않습니다.
  • 스스로 효율적인 방법론과 도구, 기술을 찾아 적용합니다. (각 서비스에 가장 적합한 기술 사용)
• 분산된 데이터 관리
  • Monolithic은 일반적으로 단일 통합 데이터베이스를 사용하지만 MSA는 각각 서비스에 필요한 데이터베이스를 독립적으로 사용할 수 있습니다.
  • 따라서 서비스는 서로 다른 데이터 저장 기술을 사용할 수 있습니다. (Polyglot Persistence)
  • 각 서비스는 API를 통해서만 다른 서비스의 데이터에 접근합니다.
  • 트랜잭션 처리가 어렵습니다.
• 인프라 자동화
  • 다수의 서비스와 인스턴스가 존재하는 환경에서는 자동화가 필수입니다.
    자동화된 테스팅, 자동화된 CI, 자동화된 CD
• 장애 방지 설계
  • 특정 서비스의 장애는 항상 일어나고 다른 서비스로 전파되는데 이러한 전파를 분리가 되어있기 때문에 막을 수 있습니다.
  • 서비스에 이상 동작을 최대한 신속하게 알 수 있어야 합니다.
  • 가능하면 자동으로 복구될 수 있도록 설계되야 합니다. (kubernetes, spring cloud 기술 활용)

 

 

MSA 장점

• 빠른 Delivery
  • 각 서비스는 독립적으로 개발되고 느슨하게 결합됩니다.
  • 서비스가 작기 때문에 코드 수정에 대한 영향 범위가 상대적으로 적습니다.
    때문에 빠르게 영향도를 파악할 수 있고, 빠른 빌드, 테스트가 가능합니다.
  • 각 서비스들은 네트워크를 통한 interface로 느슨히 결합됩니다.
    서비스 간 자율적인 배포가 가능하죠.
• Polyglot Architecture 지원
  • 특정 목적에 맞는 가장 적절한 기술을 적용 가능합니다.
  • 각 서비스는 자신만의 고유한 언어나 프레임워크를 선택할 수 있습니다.
• 실험과 혁신 가능
  • 최근 비즈니스 상황에서는 기술의 혁신이 필수적이기 때문에 마이크로서비스는 새로운 기술들을 각자 쉽게 실험해볼 수 있습니다.
• 탄력적이고 선택적인 확장
  • 작은 서비스 단위로 확장이 가능합니다.
  • Monolithic은 전체 Scale Out이 필요하기 때문에 비효율적이지만 MSA는 서비스 단위로 각각 Scale Out할 수 있기 때문에 효율적입니다.
  • 각 서비스는 코드베이스가 작아 확장 비용이 상대적으로 저렴합니다.
• 대체 가능성
  • 언어/프레임워크를 완전히 새롭게 개발 가능합니다.
    또는 오픈 소스 / 커머셜 솔루션으로 대체할 수 있습니다.
  • 각 서비스는 작고 서비스 간에 느슨하게 연결되어 있기 때문에 대체될 수 있습니다.
• 기술 부채의 경감
  • SW는 지속적으로 관리하지 않으면 기술적인 부채가 쌓입니다.
  • Monolithic은 강한 결합도 때문에 코드 수정이 어렵습니다.
  • 하지만 MSA는 각각 나누어져 있어서 서비스의 크기가 적절하기 때문에 품질 관리에 용이합니다.
  • 품질 향상을 위한 코드 개선 시 영향도도 작습니다.

 

 

MSA 단점

• 컴퓨팅 자원의 사용이 Monolithic 보다 비효율적입니다.
• 성능 Monolithic 보다 안좋을 수 있습니다. 예를 들어 내부 호출보다 느린 것을 예로 들 수 있습니다.
• 운영 관리가 어렵습니다.
• 모니터링 대상이 증가합니다.
• 배포 대상 서비스들이 증가하거나 기술이 너무 다양화될 수 있습니다.
• 다양한 장애 상황이 발생될 수 있습니다.
• 단위 테스트, 컴포넌트 테스트 와 같은 테스트에 대한 난이도가 증가할 수 있습니다.
• DB 트랜잭션 처리가 어렵습니다.
• 서비스 간 Polyglot Data Store 를 사용합니다.
• 분산 환경에서 트랜잭션이 어렵습니다.

 

---

 

기존의 전통적 개발 방법 (Monolithic Architecture / System)

전체 기능을 단일 코드베이스로 개발하고, 대규모 단일 코드 베이스를 빌드하고 배포합니다.

단일 통합 데이터베이스를 사용하게 되기도 합니다.

이것을 Monolithic System, Monolithi Architecture 라고도 부릅니다.

 

 

Monolithic System의 단점

• 스케일 아웃 시 전체 시스템을 확장해야 하기 때문에 비효율적입니다.
• 빌드 / 배포 / 테스트 시간이 오래 걸립니다.
• 작은 수정에도 전체 시스템 빌드 / 배포 해야합니다.
• 하나의 버그에 전체 시스템이 실패할 수 있습니다.
• 기능들 간의 결합도가 높습니다. (다른 테이블에 직접 접근 하기도 합니다.)
• 기능 변경 시 영향도 파악이 어렵습니다. (코드의 의존관계나 데이터 의존 관계 등)
• 결과적으로 코드가 운영환경에 민첩하게 배포되기 어렵습니다.

 

 

Monolithic System의 장점

• 상대적으로 운영하기가 용이합니다. (코드 관리. 장애 관리, 로그 관리, 모니터링)
• 내부 메소드 호출로 성능에 문제 없습니다. (MSA는 네트워크를 통해 인터페이스를 호출해야합니다.)
• 트랜잭션 관리에 용이합니다.

 

 

Monolithic System의 종류

(1) Single Monolithic System

가장 일반적인 형태의 시스템입니다.

 

 

(2) Modular Monolithic System

각 기능별로 모듈화되어있는 형태입니다.

Package나 Multi-module project로 운영되는 것을 예로 들 수 있습니다.

MSA의 좋은 대안이 될 수 있습니다.

 

 

Monolithic의 가장 큰 문제는 기능 간의 결합도, 코드 수정 시에 대한 영향도에 있는데 Modular Monolithic 이 기능마다 모듈화하여 결합도를 낮출 수 있도록 다룰 수 있기 때문에 유지보수성이 높은 SW 가 가능하게 됩니다.

 

하지만 Modular Monolithic 도 문제는 있습니다.

배포와 확장에 대한 이슈는 여전히 존재하거니와, 데이터에 대한 이슈도 존재합니다

타 기능 데이터에 직접적으로 접근해야할 수도 있기 때문에 결합도에 대한 이슈도 완전히 해소된 것은 아니죠.

따라서, Modular Monolithic의 장점을 발휘하기 위해서는 모듈 간의 결합도를 자주 관리해야 합니다.

 

 

(3) Distributed Monolithic System

분산된 Monolithic입니다.

쪼개진 것처럼 보이기 때문에 MSA 라고 볼 수도 있지만 MSA가 아닙니다.

쪼개진 서비스 간에 매우 강하게 결합된 형태를 나타내고 있으며, 항상 모든 서비스가 같이 배포되는 형태입니다.

이 Distributed Monolithic System의 경우에는 Monolithic의 영향도, 결합도에 대한 단점이 모두 존재합니다.

또한 분산 시스템으로서 MSA 가 가진 문제점도 존재합니다.

예를 들면 네트워크를 통한 협력에 의해 성능이 저하되는 문제와 관리가 어렵다는 문제가 대표적입니다.

 

 

##

이렇게 정리한 것처럼 Monolithic보다 MSA가 더욱 좋다, 모든 Monolithic은 안티 패턴이다. Monolithic은 반드시 MSA로 바꿔야 한다 이렇게 오해할 수 있지만 그것은 틀립니다.

Monolithic은 하나의 아키텍쳐일 뿐이고, 많은 상황에서 사용되고 있는 좋은 아키텍쳐입니다.

단점만 있는 것이 아니라 관리 용이성, 트랜잭션, 성능에 대한 부분들에 많은 장점을 가지고 있습니다.

따라서 필요한 환경에 따라 맞는 아키텍쳐를 선택하여 사용하는 것이 중요합니다.