[백엔드] MSA(Microservice Architecture)란 무엇인가

| 서론

안녕하세요, 팡일입니다.

 

최근 많은 기업들이 MSA(Microservice Architecture)라는 아키텍처를 도입하고 있습니다.

특히 대규모 트래픽을 처리하거나 여러 팀이 동시에 서비스를 개발해야 하는 환경에서는 MSA가 하나의 중요한 선택지가 되기도 합니다.

 

하지만 MSA는 단순히 “요즘 많이 쓰는 아키텍처”라는 이유만으로 도입하기에는 고려해야 할 요소가 많은 구조이기도 합니다. 실제로 많은 서비스들은 처음부터 MSA로 시작하기보다는 모놀리식 아키텍처로 시작한 뒤, 서비스 규모가 커지면서 점진적으로 MSA로 전환하기도 합니다.

 

따라서 MSA를 이해하기 위해서는 먼저 모놀리식 아키텍처와 어떤 차이가 있는지, 그리고 MSA가 어떤 문제를 해결하기 위해 등장한 구조인지를 함께 이해하는 것이 중요합니다.

 

이번 글에서는

• MSA가 무엇인지
• 모놀리식 아키텍처와의 차이점은 무엇인지
• MSA의 핵심 특징과 장점은 무엇인지
• 그리고 어떤 상황에서 MSA 도입을 고려해야 하는지

를 중심으로 정리해보겠습니다.

 

 

 

| MSA(Microservice Architecture)란?

 

MSA는 하나의 큰 애플리케이션을 여러 개의 작고 독립적인 서비스로 나누어 개발하고 운영하는 소프트웨어 아키텍처를 의미합니다.

 

기존의 하나의 프로젝트 안에 모든 기능을 구현하는 방식과 달리, MSA에서는 기능별로 서비스를 분리하여 각 서비스가 독립적으로 개발, 배포, 운영될 수 있도록 설계합니다.

 

 

 

| 모놀리식 아키텍처 (Monolithic Architecture)

모놀리식 아키텍처는 하나의 프로젝트 안에 모든 기능을 구현하는 방식입니다.

예를 들어 하나의 서비스에 다음과 같은 기능들이 있다고 가정해 보겠습니다.

• 인증 API
• 결제 API
• 상품 API

모놀리식 구조에서는 이러한 기능들을 하나의 프로젝트 안에서 모두 구현하게 됩니다.

 

또한 대부분의 경우 하나의 데이터베이스를 함께 사용하는 구조를 가지고 있습니다.

 

이 방식은 구조가 단순하고 초기 개발이 빠르다는 장점이 있지만, 서비스 규모가 커질수록 여러 가지 한계가 발생할 수 있습니다.

 

 

 

| MSA 아키텍처

 

MSA에서는 서비스에 필요한 기능들을 하나의 프로젝트에 모두 구현하지 않고 여러 개의 서비스로 나누어 개발합니다.

 

예를 들어 다음과 같이 서비스를 분리할 수 있습니다.

• 인증 서비스
• 결제 서비스
• 상품 서비스
• 주문 서비스

이처럼 독립적으로 분리된 하나의 프로젝트를 서비스(Service)라고 부릅니다.

 

또한 MSA에서는 서비스별로 데이터베이스를 분리하여 운영하는 경우가 많습니다.

 

이 구조를 통해 각 서비스는 서로 독립적으로 동작하게 됩니다.

 

 

 

| MSA의 핵심 특징 및 장점

MSA의 가장 중요한 특징은 독립성(Independence)입니다.

 

하나의 애플리케이션을 여러 개의 독립적인 서비스로 분리함으로써 각 서비스가 개발,*배포, 확장, 운영 측면에서 서로 영향을 최소화하도록 설계됩니다.

 

이러한 독립성 덕분에 다양한 장점이 생기게 됩니다.

1) 서비스별 독립적인 배포가 가능하고 배포 사이클이 빨라진다

하나의 큰 프로젝트를 수십 명이 함께 작업하는 것보다 여러 개의 프로젝트로 나누어 각 팀이 담당 서비스를 관리하는 것이 훨씬 효율적일 수 있습니다.

 

서비스가 분리되어 있기 때문에 아래의 효과를 볼 수 있습니다.

• 팀 간 의사소통 비용이 줄어든다.
• 각 팀이 독립적으로 개발과 배포를 진행할 수 있다.
• 코드 규모가 작아 테스트와 빌드 시간이 단축된다.

예를 들어 우아한형제들(배달의민족)의 경우 아래와 같이 여러 팀이 각각의 서비스를 담당하고 있습니다.

• 배민상품시스템팀
• 정산시스템팀
• 주문시스템팀

즉, 하나의 서비스(배달의민족)를 여러 개의 프로젝트로 나누어 관리하는 구조라고 볼 수 있습니다.

 

 

2) 데이터베이스를 서비스별로 분리할 수 있어 대규모 트래픽 처리에 유리하다.

모놀리식 아키텍처에서는 대부분 단일 데이터베이스 구조를 사용합니다.

하지만 서비스 규모가 커지면 트래픽이 하나의 데이터베이스에 집중되는 문제가 발생할 수 있습니다.

 

물론 다음과 같은 방법으로 문제를 해결하려고 시도할 수 있습니다.

• 읽기 전용 데이터베이스(Read Replica) 추가
• 캐시 시스템 도입 (Redis 등)

하지만 트래픽이 매우 커질 경우 이러한 방식만으로는 한계가 있을 수 있습니다.

 

MSA에서는 서비스별로 데이터베이스를 분리하여 운영할 수 있기 때문에 아래와 같이 트래픽을 여러 데이터베이스로 분산할 수 있습니다.

• 인증 서비스 → 인증 DB
• 결제 서비스 → 결제 DB
• 주문 서비스 → 주문 DB

이러한 구조는 대규모 트래픽을 처리하는 데 큰 장점이 됩니다.

 

 

3) 장애 전파를 최소화할 수 있습니다

모놀리식 구조에서는 대부분 하나의 데이터베이스와 하나의 애플리케이션을 사용하기 때문에 특정 기능에서 문제가 발생하면 전체 서비스에 영향을 줄 가능성이 높습니다.

 

예를 들어, 결제 API에서 데이터베이스 장애가 발생하면, 결제와 관련 없는 기능들도 함께 영향을 받을 수 있습니다.

 

하지만 MSA 구조에서는 서비스가 분리되어 있고, 데이터베이스도 독립적으로 운영되기 때문에 결제 서비스에 문제가 발생하더라도 다른 서비스는 정상적으로 동작할 가능성이 높습니다.

 

즉, 장애 전파를 최소화할 수 있는 구조입니다.

 

 

 

| MSA의 핵심 키워드

MSA를 한 단어로 표현하면 독립성입니다.

 

이 독립성 덕분에 다음과 같은 장점이 생깁니다.

1. 서비스별 독립적인 배포가 가능해 배포 속도가 빨라집니다
2. 데이터베이스를 분리하여 대규모 트래픽을 처리할 수 있습니다
3. 서비스 간 장애 전파를 최소화할 수 있습니다

 

 

| MSA는 언제 도입하는 것이 좋을까?

MSA는 모든 프로젝트에 반드시 필요한 구조는 아닙니다.

오히려 많은 경우 모놀리식 구조로 시작하는 것이 더 적합할 수도 있습니다.

 

하지만 다음과 같은 상황이 발생한다면 MSA 도입을 고려해볼 수 있습니다.

 

1) 배포 속도가 너무 느려지는 경우

: 프로젝트 규모가 커지고 개발 인원이 많아지면서 배포 사이클이 점점 느려지는 경우입니다.

 

2. 대규모 트래픽을 처리해야 하는 경우

: 모놀리식 구조에서는 감당하기 어려운 수준의 트래픽이 발생하는 경우입니다.

 

3)  장애 전파 문제가 자주 발생하는 경우

: 특정 기능의 장애가 전체 서비스로 확산되는 문제가 반복되는 경우입니다.

 

이러한 문제 중 하나라도 심각하게 발생한다면 MSA 전환을 고려해볼 수 있습니다.

 

 

 

| MSA 도입 시 고려해야 할 점

MSA는 많은 장점을 가지고 있지만 모놀리식 아키텍처보다 구조가 훨씬 복잡합니다.

 

예를 들어 아래와 같이 다양한 요소를 추가로 고려해야 합니다.

• 서비스 간 통신
• 분산 트랜잭션
• 서비스 모니터링
• 배포 및 운영 관리

또한 MSA로 전환하는 과정에서 많은 시간과 비용이 필요할 수 있습니다.

 

따라서 MSA 도입은 단순히 기술적인 유행을 따르기보다는 도입했을 때 얻을 수 있는 이점이 실제로 더 큰지 신중하게 판단한 후 결정하는 것이 중요합니다.

 

 

 

| 결론

MSA는 하나의 거대한 애플리케이션을 여러 개의 독립적인 서비스로 분리하여 개발,*배포, 확장, 운영을 보다 유연하게 만들기 위한 아키텍처입니다.

 

이러한 구조를 통해 다음과 같은 장점을 얻을 수 있습니다.

• 서비스별 독립적인 배포가 가능해 개발 속도를 높일 수 있습니다
• 데이터베이스를 분리하여 대규모 트래픽을 보다 효율적으로 처리할 수 있습니다
• 특정 서비스에 장애가 발생하더라도 전체 시스템에 미치는 영향을 최소화할 수 있습니다

하지만 MSA는 그만큼 시스템 구조가 복잡해지고 운영 비용이 증가할 수 있는 아키텍처이기도 합니다.

서비스 간 통신, 분산 트랜잭션, 모니터링, 배포 관리 등 다양한 요소를 추가로 고려해야 하기 때문입니다.

 

따라서 MSA는 모든 서비스에 반드시 필요한 구조라기보다는, 서비스 규모와 팀 구조, 트래픽 수준 등을 종합적으로 고려하여 선택해야 하는 아키텍처라고 볼 수 있습니다.

 

결국 중요한 것은 특정 아키텍처 자체가 아니라 현재 서비스의 상황에 가장 적합한 구조를 선택하는 것입니다.
그렇기에, MSA 역시 이러한 관점에서 이해하고 도입을 검토하는 것이 바람직하다고 생각합니다.