MSA

MSA가 뭘까

Micro Service Architecture

MSA는 기존에 하나의 거대한 서비스를 여러 개의 작은 독립적인 서비스로 나누어 구성하는 소프트웨어 설계 방식이다.

그럼 기존에는 어떠한 형식으로 소프트웨어를 설계하였는가?

Monolithic

모놀리식의 철자가 헷갈려서 구글에 monolithic을 검색했는데
단단히 짜여 하나로 되어 있는 이라는 번역 결과가 상단에 나왔다.

이처럼 모놀리식 아키텍처는 어플리케이션의 모든 기능을 하나의 실행 파일,
즉 하나의 거대한 서비스로 구현되어 있는 아키텍처를 말한다.

Why MSA?

그렇다면 왜 MSA 구조를 사용할까?

효율적인 리소스 사용

만든 서비스의 트래픽양이 많아져서 어플리케이션의 스케일업이 필요할 때
MSA의 경우 트래픽이 몰리는 특정 서비스만 선택적으로 확장이 가능하다.

주문 트래픽이 집중되더라도 리뷰 기능의 사용량은 상대적으로 적기 때문에, 주문 서비스만 선택적으로 확장하고 리뷰 서비스는 그대로 유지할 수 있습니다.

그러면 모놀리식은 스케일 아웃이 불가능한가?

모놀리식 아키텍처도 스케일 아웃이 가능합니다.
하지만 전체 어플리케이션을 스케일 아웃해야 하니 리소스가 낭비됩니다

유지보수와 배포의 유연성

MSA 구조에서는 각 서비스가 독립적으로 개발되고 배포될 수 있기 때문에, 일부 기능만 수정하더라도 전체 시스템을 재배포할필 요가 없다.

예를 들어, 리뷰 기능에 새로운 로직을 추가하고자 할 때해당 서비스만 따로 테스트하고 배포하면 되므로개발 속도와 안정성을 모두 확보할 수 있다.

반면, 모놀리식 아키텍처에서는 전체 시스템이 하나로 묶여 있어리뷰 기능 하나를 고치더라도 어플리케이션 전체를 빌드하고 배 포해야 한다. 이 과정에서 예기치 않은 사이드 이펙트가 발생할 위험도 크다.

서비스마다 다른 개발 환경(프레임워크, 언어)을 가져갈 수 있다는 것도 장점이다.

장애 격리

MSA는 서비스 간 결합도가 낮기 때문에, 특정 서비스에 장애가 발생하더라도그 영향이 다른 서비스로 전파되지 않는다.

예를 들어, 리뷰 서비스에 문제가 생겨도 주문, 결제, 사용자 인증 등다른 핵심 기능은 정상적으로 동작할 수 있다. 이러한 장 애 격리성은 전체 시스템의 가용성을 높이는 핵심 장점 중 하나입니다

모놀리식에서는 하나의 서비스에서 예외나 메모리 누수가 발생하면전체 애플리케이션이 영향을 받을 수 있다. 즉, 일부 기능의 문제로 전체 서비스가 중단될 수 있는 구조다.

MSA의 단점

물론 MSA도 마냥 좋은 사실들만 있는 것은 아니다.

가장 큰 문제로는 서비스마다 독립적인 DB를 사용하면 데이터 일관성(Data consistency) 을 유지하기 어렵다.

예를 들어 한 서비스에서 데이터를 업데이트했지만 다른 서비스에는 반영되지 않는 경우가 발생할 수 있다

그러면 다른 서비스의 DB에 접근하면 안됨?

위와 같은 행위를 하게 될 경우 MSA가 아닌 파편화된 모놀리식 아키텍처가 될 수 있어 매우 지양한다.

결국 상황에 맞게

MSA는 느슨한 결합으로 확장성이 용이하여 대규모 서비스를 운영하기 위한 강력한 설계 패턴이지만, 그만큼 복잡성과 운영 난이도가 증가한다

모놀리식이 잘못된 것도 없고 MSA가 잘못됐다는 말도 아니다
단지 주어진 상황에 맞는 최선의 선택을 하는 것이 중요하다고 생각한다