MSA란?

Monolithic 아키텍쳐와 MSA 아키텍쳐가 무엇인가

Monolithic Architecture

• 모든 소스 코드가 하나의 Application에 통합되어 빌드되고 배포되는 경우

하나의 Application 안에서 모든 서비스과 서비스 DB가 강하게 결합되어 있다.

단점

1. 서비스 하나의 장애가 서비스 전체의 영향을 미친다.

예를 들어, Board 서비스에 트래픽이 몰려서 장애가 발생한다고 가정해 볼 때, Board 서비스에 장애가 발생하면 전체 Application에 장애가 발생하여 Member 서비스에도 장애가 발생한다.

2. 각 서비스의 유지보수가 어렵다.

서비스들이 강하게 결합되어 있기 때문에, 하나의 서비스 기능을 수정하고 유지보수할 때 연관된 서비스까지 함께 고려해야 한다.

3. 빌드 및 배포 시간이 길어서 생산성이 낮아진다.

여러 서비스가 하나의 Application에 존재하기 때문에 빌드 및 배포 시간이 상대적으로 길다.

4. 특정 서비스만 Scale-out 하기 힘들다.

Board 서비스에만 트래픽이 몰리게 돼도 전체 Application을 Scale-out 해야하므로 비효율적이다.

이러한 단점을 극복하기 위해 나온 것이 MSA 아키텍쳐이다.

---

MSA(Micro Service Architecture)

서비스별로 독립적인 애플리케이션 환경에서 개발 및 배포되는 아키텍쳐

모놀리식 아키텍쳐는 하나의 Application 안에서 여러 서비스가 통합되어 있는 구조였다.
MSA는 반대로 여러 서비스가 각각 독립적으로 구성되어 있는 구조이다.

서비스별로 나누어서 개별적으로 개발 및 배포되는 아키텍쳐이다.
Application이 나뉘면서 서비스와 DB가 분리되었다.

MSA에서는 Application이 서비스별로 나뉘기 때문에 외부의 요청이 어떤 서비스 관련 요청인지 판단해서 해당 서비스에게 처리하도록 전달하는 과정이 필요하다.
이 작업을 처리하는 구성요소가 API Gateway이다.

장점 (모놀리식 아키텍쳐 단점 보완)

1. 도메인 하나의 장애가 전체 서비스에 영향을 미치지 않는다.

MSA에서는 Board, Member 도메인이 분리되어 있기 때문에 각각 서비스 장애가 전파되지 않는다.

2. 상대적으로 각 도메인의 유지보수가 쉽다.

서비스가 독립적으로 구성되기 때문에 도메인 유지보수가 상대적으로 쉽다.

3. 빌드 및 배포 시간을 줄여서 생산성을 높일 수 있다.

서비스가 독립적으로 구성되기 때문에 동시에 병렬적으로 여러 서비스 빌드 및 배포가 가능하다.

4. 특정 도메인만 Scale-out 할 수 있다.

MSA에서는 서비스가 독립적으로 분리되어 있기 때문에 도메인별로 Scale-out을 쉽게 할 수 있다.
만약 Board 기능에 트래픽이 많다면 Member 서버는 1대로 운영한 채로 Board 서버를 2, 3대로 Scale-out하여 운영할 수 있다.

MSA 전환 시 고려할 점

1. 외부 요청을 알맞는 서비스에 어떻게 전달할 것인가?

위에서 설명한 API Gateway를 도입하여 해결할 수 있다.

2. 서비스간 통신은 어떤 방식으로 할 것인가?

모놀리식 아키텍쳐는 비즈니스 로직 상 도메인 간 참조가 필요하면 애플리케이션 코드 단에서 직접 참조하여 다른 도메인의 정보를 가져올 수 있다.

하지만 MSA에서는 관련 정보를 가져오려면 다른 서비스에 요청을 보내서 정보를 가져와야 한다.

추가적인 리소스로 다른 서비스와의 통신을 하는 방식

• RestTemplate
• WebClient
• OpenFeign
• 메세지 브로커(Kafka, RabbitMQ, ActiveMQ 등)

3. 하나의 기능에서 트랜잭션을 어떻게 유지해야 할 것인가?

모놀리식 아키텍쳐는 하나의 Application에 통합 DB를 구성하여 데이터르 저장 및 조회했다.
MSA에서는 각 서비스가 분리됨에 따라 DB 또한 도메인별 DB로 분리된다.
따라서 하나의 기능에 대한 트랜잭션 관리가 어려워 진다.

이를 해결하기 위한 트랜잭션 패턴은 크게 2가지

• 2PC 패턴(Two-Phase Commit)
• Saga 패턴

이런 패턴을 사용하여 하나의 기능에 대해 트랜잭션을 관리할 수 있다.

4. 서비스들의 정보를 어떻게 관리할 것인가?

앞에서 MSA는 외부에서 오는 요청을 API Gateway로 전달되고, 서비스 간 통신도 이루어진다고 했다.
이때, API Gateway는 어떻게 서비스 Application의 정보를 알아서 전달하고, 각 서비스들도 어떻게 다른 서비스 Application의 정보를 알아서 통신할까?

간단히 API Gateway에서 모든 서비스 Application의 정보를 수동으로 등록하고, 각 서비스에서도 다른 서비스들의 정보를 수동으로 등록하면 해결된다.
그러나, 사용하지 않는 서비스, 추가해야 하는 서비스가 있을 수도 있다. 이때, 서비스가 확장/축소 될 때마다 수동으로 API Gateway에 각 서비스들의 정보들을 업데이트 해야한다.

MSA에서 각 서비스들의 정보를 등록/관리하는 서비스 디스커버리 패턴을 통해 처리한다.