[MSA] MSA란 무엇일까❓

 

디지털 기술이 빠르게 발전함에 따라 소프트웨어 아키텍처도 지속적으로 진화하고 있습니다.

 

전통적인 모놀리틱 아키텍처에서 점점 더 많은 기업들이 MSA(Microservices Architecture)로 전환하고 있습니다. 이번 포스팅에서는 MSA의 기본 개념과 장단점, 그리고 모놀리틱 아키텍처와의 비교를 통해 MSA의 이점을 살펴보겠습니다.

MSA란❓

 

MSA(Microservices Architecture)는 소프트웨어 애플리케이션을 독립적이고 자율적으로 배포 가능한 작은 여러 서비스들로 나누는 아키텍처 스타일입니다.

 

각 마이크로서비스는 특정 기능이나 비즈니스 도메인을 담당하며, 다른 서비스와 독립적으로 개발, 배포, 확장 이 가능합니다. 이로 인해 복잡한 애플리케이션을 보다 관리하기 쉬운 조각들로 나눌 수 있게 됩니다.

 

서비스 간의 통신은 주로 HTTP/HTTPS, 메시지 큐 등을 통해 이루어집니다.

 

MSA의 특징 ✅

1. 독립적인 배포 가능성

MSA의 가장 큰 장점 중 하나는 각 마이크로서비스가 독립적으로 배포될 수 있다는 점입니다.

 

전통적인 모놀리틱 아키텍처에서는 애플리케이션 전체를 한 번에 배포해야 했습니다. 그러나 MSA에서는 각 서비스가 독립적으로 배포 가능하기 때문에, 새로운 기능을 추가하거나 버그를 수정할 때 전체 애플리케이션을 중단시킬 필요가 없습니다. 이로 인해 다음과 같은 이점이 있습니다.

• 문제 해결의 용이성
  •  서비스 하나에 문제가 발생해도 전체 시스템에 영향을 미치지 않으므로, 문제를 보다 신속하게 해결할 수 있습니다.
• 유연한 배포
  •  다양한 서비스가 서로 다른 배포 주기를 가질 수 있어, 비즈니스 요구에 맞춰 유연한 배포가 가능합니다.

---

2. 작은 팀 구성

MSA에서는 각 마이크로서비스가 독립적으로 관리되기 때문에, 소규모 팀이 각 서비스를 담당할 수 있습니다. 이는 다음과 같은 장점을 제공합니다.

• 팀의 자율성
  •  작은 팀이 특정 서비스에 집중할 수 있어, 서비스의 개발과 유지보수를 효율적으로 수행할 수 있습니다.
• 전문성 강화
  •  각 팀은 특정 도메인에 대한 전문성을 쌓을 수 있어, 더 나은 품질의 서비스를 제공할 수 있습니다.
• 효율적인 관리
  •  작은 팀이 각 서비스의 책임을 지기 때문에, 전체 시스템의 복잡성을 줄일 수 있습니다.

 

3. 기술 스택의 다양성

MSA의 또 다른 큰 장점은 각 마이크로서비스가 적절한 기술 스택을 자유롭게 선택할 수 있다는 점입니다. 이는 다음과 같은 장점을 제공합니다.

• 최적의 기술 선택
  •  각 서비스는 자신에게 가장 적합한 기술 스택을 선택할 수 있어, 성능과 효율성을 극대화할 수 있습니다.
• 기술 실험
  •  새로운 기술이나 도구를 실험하기에 좋은 환경을 제공하므로, 최신 기술을 신속하게 도입할 수 있습니다.
• 기술적 제약 감소
  •  서비스 간의 기술적 제약이 줄어들어, 혁신적인 설루션을 더 쉽게 도입할 수 있습니다.

 

모놀리틱 아키텍처란❓

모놀리틱 아키텍처는 애플리케이션의 모든 기능을 하나의 코드베이스와 배포 단위로 묶는 전통적인 설계 방식입니다.

 

이는 단일 코드베이스로 관리되는 장점이 있지만, 다음과 같은 단점이 있습니다.

• 배포의 어려움
  •  애플리케이션의 모든 부분이 한 번에 배포되기 때문에, 작은 변경도 전체 애플리케이션을 다시 배포해야 합니다.
    • 만약 위 아키텍처처럼 "Shoping Mall"이라면 아주 작은 기능 수정이나, 오류 수정, 새로운 기능(반품)이 추가가 된다면 일부를 수정 및 추가했지만 전체를 배포해야합니다.
• 확장성 제한
  •  전체 애플리케이션을 확장해야 하므로, 특정 기능에 대한 확장이 비효율적일 수 있습니다.
• 복잡한 코드베이스
  •  모든 기능이 하나의 코드베이스에 묶여 있어 코드 관리와 유지보수가 어려울 수 있습니다.

 

모놀리틱 아키텍처와 비교

 

 

MSA의 장단점 

 

장점

1. 독립적인 배포
   •  각 서비스가 독립적으로 배포되므로, 전체 애플리케이션에 영향을 미치지 않고 새로운 기능을 추가하거나 버그를 수정할 수 있습니다.
2. 스케일링 용이
   •  트래픽이 집중되는 특정 서비스만 확장할 수 있어 자원의 효율적인 사용이 가능합니다.
3. 기술 선택의 자유
   •  각 서비스가 서로 다른 기술 스택을 사용할 수 있어 최적의 솔루션을 선택할 수 있습니다.
4. 문제 격리
   •  하나의 서비스에서 문제가 발생해도 전체 시스템이 영향을 받지 않으므로, 문제를 빠르게 파악하고 해결할 수 있습니다.

단점

1. 복잡한 관리
   •  여러 개의 마이크로서비스를 관리해야 하므로 운영 복잡성이 증가할 수 있습니다.
2. 네트워크 지연
   •  서비스 간의 통신과 데이터 일관성 유지가 어려울 수 있으며, 네트워크 지연이나 오류로 인한 문제가 발생할 수 있습니다.
3. 배포 및 테스트의 어려움
   •  여러 서비스가 상호작용하기 때문에 배포와 테스트가 복잡해질 수 있습니다.
4. 자원 낭비
   •  각 서비스가 독립적인 인프라를 요구할 수 있어 자원 낭비가 발생할 수 있습니다.
5. 운영비용
   •  각 서비스의 모니터링, 로깅, 장애 대응 등을 개별적으로 관리해야 하므로 운영 비용이 증가할 수 있습니다.

---

 

 

위에서 본 모놀리틱 아키텍처와 달리, 회원, 상품, 주문 기능이 각각 별도의 애플리케이션으로 나눠져 있는 것을 볼 수 있습니다. 또한, 각 애플리케이션은 각각의 데이터베이스와 연동되어 있습니다.

 

새로운 기능을 개발할 때, 예를 들어 '반품(return)' 기능을 추가한다고 할 경우, 새로운 애플리케이션으로 개발을 진행하고 기존의 데이터베이스와 연결하거나 필요에 따라 새로운 데이터베이스를 추가하여 연동할 수 있습니다.

 

새로운 기능을 개발하고 나서 배포를 할 때는 전체 애플리케이션을 업데이트할 필요 없이, 새로 개발한 애플리케이션만 배포하면 되기 때문에 기존의 애플리케이션에 영향을 주지 않습니다.

 

물론 장점만 있는 것은 아니며, 장단점이 존재하므로 상황에 맞게 적절한 아키텍처를 선택하는 것이 중요합니다.