[MSA 전환하기 1편] 모놀리식 아키텍처와 MSA란 무엇인가?

1. 개요

최근 기존 모놀리식(monolithic) 아키텍처 기반의 티켓 예매 프로젝트를 MSA(Microservices Architecture)로 전환해보았습니다. 이번 포스팅에서는 전환 과정에 대해 다루기에 앞서, 먼저 모놀리식 아키텍처와 MSA란 무엇인지 간단히 살펴보고, 두 가지 아키텍처의 차이점을 비교해보려 합니다.

 

 

 

2. 모놀리식(monolithic) 아키텍처란?

모놀리식 아키텍쳐란 모든 로직이 하나의 애플리케이션 형태로 패키지 되어 서비스되고, 애플리케이션에서 사용하는 데이터 또한 한 곳에 모인 데이터를 참조해 서비스되는 형태를 의미합니다.

하나의 애플리케이션으로 배포

 

위와 사진과 같이 애플리케이션이 하나의 패키지로 서비스 되기 때문에 배포가 단일 프로세스가 이루어져 간단하고, 한 곳에서 모든 로직을 관리할 수 있어 직관적이고 편리하다는 장점이 있습니다.

 

하지만 애플리케이션이 날이 갈수록 커지고, 비즈니스의 변화가 빨라 수시로 애플리케이션을 적용해야하는 환경에서는 모놀리식 아키텍처의 여러 단점이 나타나게 됩니다.

 

2-1 모놀리식 아키텍처의 단점

1. 특정 기능만 수정해도 전체를 재배포해야 한다.

현재 모놀리식 아키텍처로 구성된 티켓 예매 프로젝트는 티켓 예매, 유저 관리, 결제와 같은 모든 기능이 하나의 애플리케이션으로 묶여 있습니다. 예를 들어, 유저 관련 기능을 추가하거나 수정하려고 한다면, 티켓 예매, 결제 기능과 관련 없는 코드까지 포함하여 전체 애플리케이션을 빌드하고 배포해야 합니다. 이는 비효율적 개발 및 배포 프로세스를 초래하게됩니다.

 

 

2. 애플리케이션이 커질 경우 배포시간이 길어진다.

시간이 지나면서 애플리케이션의 규모가 커지고 기능이 많아질수록 전체 애플리케이션 빌드와 배포에 소요되는 시간이 점점 길어집니다. 이로 인해 단순한 수정 사항이 있음에도 배포 시간이 길어지면서 개발 효율성이 떨어지고, 긴 배포 시간으로 인해 서비스 중단 시간이 늘어날 위험도 있습니다.

 

 

3. 유지보수와 확장이 어렵다.

모놀리식 아키텍처에서는 도메인 간의 높은 연관성으로 인해 유지보수가 복잡해질 수 있습니다.
예를 들어, 유저 관리와 결제 시스템 간의 코드 의존성이 존재한다고 가정해보면, 하나의 도메인을 수정할 때 다른 도메인에도 영향을 줄 가능성이 높습니다.

• 코드 변경이 연쇄적으로 이어질 수 있어 디버깅과 테스트가 복잡해지고 시간 소모 증가한다.
• 특정 도메인에서 트래픽이 급증했을 때 애플리케이션 전체를 확장해야 하는 제약이 발생한다.

 

4. 장애가 서비스 전체 영향을 미친다.

모놀리식 애플리케이션에서는 하나의 서비스에서 장애가 발생했을 때, 전체 애플리케이션이 중단될 위험이 큽니다.
예를 들어, 결제 기능에서 오류가 발생했을 경우, 티켓 예매나 유저 관리와는 무관한 부분임에도 서비스 전체가 작동하지 않을 수 있습니다.

 

이러한 단점들은 시스템이 커지고 복잡해질수록 더욱 두드러지게 나타납니다. 이를 해결하기 위해 MSA가 등장하게 되는데, 지금부터는 MSA와 장단점에 대해 알아보도록 하겠습니다.

 

 

 

3. MSA (Microservices Architecture)의 등장

클라우드가 발전하고, 과거와 다르게 서비스를 유연하고 안정적으로 운영할 수 있는 기술과 인프라 자원의 등장하면서 더 나은 소프트웨어 설계 방식을 가능하게 했습니다. 이런 배경에서 등장한 것이 바로 MSA(Microservices Architecture) 입니다.

 MSA(Microservices Architecture)는 애플리케이션을 독립적인 작은 서비스들로 분리하여 설계하는 아키텍처로 각 서비스는 특정 기능에 집중하며, 서로 독립적으로 개발, 배포, 확장할 수 있습니다.

서비스 별로 애플리케이션이 분리

 

3-1 MSA 의 장점

1. 독립적인 배포와 유지보수가 쉬워진다.
각 서비스는 독립적으로 배포할 수 있으므로, 특정 기능에 대한 변경 사항이 다른 서비스에 영향을 미치지 않습니다.
예를 들어, 결제 서비스 기능을 수정해도 티켓 예매와 유저 관리 서비스는 그대로 유지되며 정상적으로 작동합니다.

 

2. 유연한 확장성을 가질 수 있다.

서비스가 분리되어 있기 때문에 트래픽이 많은 서비스만 별도로 확장할 수 있어 효율적인 리소스 사용이 가능합니다.

 

3. 장애 발생시 서비스 영향 최소화할 수 있다.
하나의 서비스에 장애가 발생하더라도, 다른 서비스에는 영향을 최소화할 수 있습니다.
예를 들어, 티켓 예매 서비스에 트래픽이 몰려 장애가 발생했더라도, 유저 서비스는 독립적으로 동작하기 때문에 회원가입이나 로그인 같은 기능은 정상적으로 사용할 수 있습니다. 이를 통해 시스템 전반의 안정성을 크게 향상시킬 수 있습니다.

 

4. 기술 스택의 다양성을 가질 수 있다.

각 서비스는 서로 독립적으로 개발되므로, 서비스별로 가장 적합한 언어와 프레임워크를 선택할 수 있습니다.
예를 들어, 채팅 기능은 빠른 응답 속도와 실시간 처리가 중요한 만큼 Node.js로 개발하고, 비즈니스 로직이 복잡한 티켓 예매 서비스는 Spring으로 설계할 수 있습니다. 이를 통해 각 서비스에 맞는 최적의 기술을 적용하여 개발 효율성을 높일 수 있습니다.

 

하지만, 모든 설계 방식이 그렇듯 MSA 역시 장점만 있는 것은 아닙니다. 다음으로 MSA의 단점을 살펴보겠습니다.

 

 

3-2 MSA 의 단점

1. 초기 설계가 복잡하다.

MSA는 서비스 간의 경계 설정, 데이터 분리, 서비스 간 통신 방식 등이 필요하여 초기 설계 단계가 복잡합니다.
도메인을 기반으로 각 서비스의 역할과 책임을 명확히 정의해야 하며, 이를 잘못 설계하면 서비스 간 의존도가 높아지고 유지보수 비용이 증가할 수 있습니다.

 

2. 서비스 간 통신 오버헤드가 늘어난다.

MSA 환경은 서비스가 서로 분리되어 있기 때문에 HTTP, 메시지 큐 등을 통한 네트워크 통신이 필수적입니다.
이로 인해 통신 지연이나 네트워크 장애에 대한 대책이 필요합니다.

 

3. 분산 트랜잭션 관리의 어려움과 추가적인 작업이 필요하다.
MSA에서는 데이터베이스가 각 서비스에 분리되어 있는 경우가 많아, 트랜잭션이 여러 서비스에 걸쳐 있을 때 분산 트랜잭션 관리가 복잡해집니다. 예를 들어, 티켓 예매 서비스에서 결제가 성공했는지 확인하는 과정에서 데이터 일관성이 보장되지 않으면, 사용자 경험에 큰 영향을 미칠 수 있습니다. 이를 해결하기 위해 사가 패턴(Saga Pattern), 이벤트 소싱(Event Sourcing) 등 분산 시스템에 적합한 트랜잭션 관리 방식이 필요합니다.

 

4. 운영 및 배포의 복잡성이 증가한다.
서비스가 많아질수록 CI/CD 파이프라인, 서비스 디스커버리, 인프라 모니터링 등 운영 관련 작업이 대폭 증가합니다.

 

4. 총정리

지금까지 모놀리식 아키텍처와 MSA에 대해 알아보았습니다. 아래는 두 아키텍처의 주요 특징을 간단히 비교한 표입니다.

	모놀리식 아키텍처	MSA
구조	단일 애플리케이션	독립적인 여러 애플리케이션
배포 방식	하나의 패키지로 배포	서비스 단위 독립적 배포
확장성	수평적 확장	수직 / 수평적(서비스별로 가능)
장애 대응	한 부분의 장애가 전체 시스템에 영향	특정 서비스의 장애가 다른 서비스 미치는 영향을 최소화
개발 속도	초기 개발이 상대적으로 빠름	초기 설계 및 구현이 복잡

 

다음 포스팅에서는 MSA로 전환하는 과정을 본격적으로 다뤄보도록 하겠습니다.

 

 

참고 

자바 기반의 마이크로서비스 이해와 아키텍처 구축하기