MA와 MSA 구조

모놀리식 아키텍처(MA)

모놀리식 아키텍처는 마치 "대형 마트에서 사고자 하는 물품 쇼핑을 한번에 할 수 있는 것" 과 같습니다.

 

당연히 마트 한 곳에서 모든 물품을 살 수 있기 때문에 편하고 구매 속도가 빠르겠죠!

하지만 마트가 문을 닫는다면 아예 물품을 못사기도 하겠네요😞

 

쇼핑몰 어플리케이션을 예로 들면,

사용자의 로그인부터 주문, 상품 정보 등 모든 기능(마트에서 사고자 하는 물품)이 하나의 거대한 프로젝트(대형 마트) 안에서 통합 관리되고 개발되는 것입니다.

 

[모놀리식 아키텍처의 장점]

특히 작은 팀이나 간단한 프로젝트에서는, 속도감 있는 프로토타이핑과 배포의 단순함을 추구하며 주로 모놀리식 방식을 택합니다. 이런 접근법은 프로젝트의 아키텍처를 간단히 유지할 수 있게 해 주어, 디버깅이나 테스팅, 그리고 배포 과정이 한결 수월해집니다.

 

때문에 우리가 토이 프로젝트를 할 때는 주로 모놀리식 아키텍처로 개발을 합니다.

토이 프로젝트의 경우는 주로 팀과 프로젝트의 규모가 작고, 빠르고 쉬운 배포가 목적이기 때문입니다!

 

[모놀리식 아키텍처의 단점]

하지만, 네이버나 카카오 같은 대기업에서는 수많은 개발자가 하나의 거대한 프로젝트에 참여하게 됩니다.

이러한 경우, 코드의 복잡성이 급격히 증가하고, conflict도 빈번하게 발생하고, 아주 사소한 오류 하나로도 전체 시스템이 마비될 위험이 커집니다.

 

더욱이, 한 프로젝트 안에서 기술 스택을 바꾸는 일은 상당히 어렵습니다. 예를 들어, AI 모델을 통합할 때 Spring 내에서는 모델 구현이 어렵기에 Flask나 Django가 더 적합할 수 있으나, 모놀리식 구조에서는 이런 전환이 쉽지 않습니다.

 

코드 간의 높은 결합도도 하나의 문제입니다.

하나를 변경하려고 하면 그와 관련된 모든 것들을 함께 수정해야 하기 때문에, 시스템의 확장성이 제한됩니다.

결국, 애플리케이션 규모가 커지면 관리와 업데이트가 점점 더 어려워지고, 모든 요청을 단일 프로젝트에서 처리해야 하니 성능의 병목 현상도 발생할 수 있습니다.

 

마이크로서비스 아키텍처(MSA)

마이크로서비스 아키텍처(MSA)는 여러 상점들이 각자의 상품을 판매하면서도, 고객이 필요로 하는 모든 것을 한 거리에서 찾을 수 있게 하는 쇼핑 거리와 같습니다.

 

각 서비스(상점)는 특정 비즈니스 기능(상점에서 판매하는 상품)을 전문적으로 담당하면서도, 전체 시스템(쇼핑 거리)의 일부로서 서로 유기적으로 연결되어 있습니다. 이걸 '느슨한 결합'이라고 표현합니다.

 

[MSA의 느슨한 결합]

느슨한 결합은 서비스들이 서로 강하게 의존하지 않고, 독립적으로 개발 및 배포될 수 있도록 하는 설계 원칙입니다.

이로 인해 하나의 서비스가 변경되거나 실패해도 전체 시스템에 미치는 영향을 최소화할 수 있습니다.

각 서비스는 마치 상점이 자신만의 재고를 관리하고 독립적인 영업 활동을 하는 것처럼, 자신의 데이터를 관리하고 독립적으로 운영합니다.

 

[MSA의 내부 추상화]

이러한 MSA 구조에서는 '내부 추상화'도 중요한 개념입니다.

각 서비스의 복잡성을 내부로 숨기고, 서비스 간에는 간단하고 명확한 인터페이스(API)만을 노출합니다.

 

이런 방식으로 MSA는 서비스 지향 아키텍처(SOA)의 원칙을 더 발전시킨 형태로 볼 수 있습니다.

SOA는 여러 서비스가 통합하여 하나의 기능을 수행하는 방식을 의미하는데, MSA는 SOA의 이러한 원칙에 더해 각 서비스의 독립성과 확장성을 강조합니다.

 

따라서 쇼핑몰 어플리케이션을 MSA 방식으로 개발할 때,

사용자 로그인, 주문 처리, 상품 정보 조회 등의 기능을 각각 독립된 작은 프로젝트(서비스)로 분리하여 개발합니다.

이러한 각각의 서비스는 독립적으로 개발되고 배포될 수 있으며, 필요한 정보를 주고받기 위해 RESTful API나 gRPC와 같은 경량의 통신 방식을 통해 협력합니다.

 

 

[마이크로서비스 아키텍처의 장점]

마이크로서비스 아키텍처(MSA)는 대규모 프로젝트와 복잡한 시스템 개발에 최적화된 구조를 제공합니다.

특히 대규모 E-커머스 플랫폼, 클라우드 기반 SaaS 제품, 또는 대기업의 엔터프라이즈 시스템 개발에 이상적입니다.\

 

왜냐하면 MSA는 시스템의 확장성과 유연성을 극대화하기 때문입니다.

추가하고자 하는 도메인 기능이 생겼다면 그저 또 다른 프로젝트를 만들면 됩니다!

이처럼 서비스별로 독립적인 개발과 배포가 가능하므로,

각 팀은 자신의 서비스에 집중할 수 있어 효율성 또한 증가합니다.

 

더불어 다양한 기술 스택을 서비스별로 자유롭게 선택할 수 있어 기술적 제약이 줄어들고,

만약 한 서비스에 문제가 발생하더라도, 그 영향이 전체 시스템에 미치지 않고 빠르게 문제를 해결할 수 있습니다.

 

예를 들면,

사용자 로그인, 주문 처리, 상품 정보 조회 기능을 각각 Spring, Node, Flask로 개발해도 전혀 상관이 없겠죠👍

 

[마이크로서비스 아키텍처의 단점]

그러나 MSA가 모든 문제의 해결책은 아닙니다.

서비스 간 통신이 필요하기에 복잡하고, 데이터 일관성을 유지하기 어렵습니다.

예를 들어 사용자가 로그인한 후 상품을 검색하고 주문하는 과정에서,이 세 서비스는 사용자의 세션 정보, 주문 데이터, 그리고 상품 정보를 서로 일관되게 유지해야 합니다.서비스 간 통신이 매끄럽게 이루어지지 않거나, 데이터 동기화에 실패한다면,사용자는 잘못된 주문 정보를 보게 되거나, 최악의 경우 주문 자체가 실패할 수 있습니다.

 

이처럼 각각의 마이크로서비스가 독립적으로 운영되기 때문에, 서비스 간의 데이터 일관성을 유지하는 것이 중요한 도전 과제 중 하나입니다. 각 서비스가 자체 데이터베이스를 유지할 경우, 이러한 일관성을 유지하기 위해 복잡한 데이터 동기화 및 트랜잭션 관리 전략이 필요하게 됩니다.

 

그리고 전체 시스템이 분산되어있기에, 시스템 관리가 더 복잡해지고 이에 따른 비용이 증가합니다.

예를 들어, 서비스 A의 변경 사항이 서비스 B와 C에 영향을 미친다면,이 과정에서 의존성 관리와 버전 호환성 문제가 발생할 수 있으며,서비스를 동시에, 문제없이 배포하기 위해 안정성과 관련된 추가 작업들이 요구됩니다.

 

또한, 서비스 간 통신으로 인한 오버헤드, 트랜잭션 처리의 복잡성, 그리고 보안 문제들도 극복해야 하는 과제입니다.

예를 들어, 서비스 A에서 B로의 요청이 네트워크 지연이나 서비스 B의 오류로 실패하게 되면,전체 작업의 일관성을 보장하기 위한 복잡한 롤백 메커니즘이 필요하게 됩니다.이와 더불어, 각 서비스 사이의 데이터 전송 시 보안을 유지하기 위한 강력한 인증과 암호화 방식의 적용이 필수적입니다.

 

결론

MA와 MSA는 각각 독특한 이점과 적합한 사용 사례를 가지고 있습니다.

프로젝트의 규모, 팀의 경험, 기대되는 트래픽 양, 그리고 유지보수 전략을 고려해 가장 알맞은 아키텍처를 선택해야 합니다.

 

이렇게 비교해보면,

토이 프로젝트를 MSA로 개발하기엔 무리가 있지 않을까 싶은 생각이 들었습니다..

이번에 캡스톤 과제를 진행하며 MSA 구조로 진행해보자! 싶었는데ㅎㅎ

데이터 일관성과 서비스들 간의 통신이 정말 난관이겠다 싶네요

 

혼자 BE를 개발 하는거고 기능이 많지 않아서 굳이 MSA로 개발할 필요는 없지만

개발하며 발생하는 문제들을 하나씩 해결하고 고민하면 많이 성장할 것 같아서

일단 한번 시도해보고 트러블 슈팅 열심히 해야겠다는 생각~