🐹 MSA(Microservices Architecture)

#공부 #구조 #설계 #MSA #CloudNative

MSA(Microservices Architecture)란?

msa는 대규모 애플리케이션을 독립적으로 배포 가능한 작은 서비스들의 집합으로 구성하는 소프트웨어 설계 접근 방식이다.
각 서비스는 특정 비즈니스 기능을 담당하며, 자체 데이터 저장소를 보유하고(선택), 독립적으로 개발 및 배포가 가능하다.
msa는 확장성, 유지보수성, 유연성 향상 등의 이점을 제공하지만 복잡한 운영과 통신 관리 등의 문제도 동반하고있다.

모놀리식 아키텍처와 비교

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

모든 기능이 단일 코드베이스에 포함되어 하나의 배포 단위로 운영되는 방식.

초기개발과 배포가 빠르고 간단하지만, 애플리케이션이 비대화 될 수록 다음과 같은 문제 발생

확장성 제한: 전체 애플리케이션을 확장해야 하므로 자원 낭비가 발생할 수 있음
배포 리스크 증가: 작은 변경도 전체 시스템의 재배포를 요구하여 위험이 증가
유지보수 어려움: 코드베이스가 커지면 이해와 수정이 어려워짐

MSA는 애플리케이션을 작은 서비스로 분리하여, 각 서비스가 독립적으로 개발, 배포, 확장 될 수 있도록 한다. 즉, 위의 모놀리식 아키텍처의 단점을 모두 보완하는 특징을 갖고 있다.

MSA 장점

배포

서비스별 개별 배포가 가능(배포시 전체 서비스의 중단이 없음)
특정 서비스의 요구사항만을 반영하여, 빠르게 배포 가능

확장

특정 서비스에 대한 확장성(scale-out)이 유리하다.
Cloud Native Architecture에 적합하다.

▶ 🌩 Cloud-Native Architecture 분석 보러가기

장애

일부 장애가 전체 서비스로 확장될 가능성이 적다.(장애 격리가 쉽다)

그 외

새로운 기술을 적용하기 유연하다.(전체 서비스가 아닌 특정 서비스만 별도의 기술 또는 언어로 구현 가능)
각각의 서비스에 대한 구조 파악 및 분석이 모놀리식 구조에 비해 쉽다.

MSA 단점

설계의 어려움

MSA는 모놀리식에 비해 상대적으로 많이 복잡하다. 또한, 통신의 장애와 서버의 부하 등을 고려하여 transaction을 유지할지 결정해야 한다.

성능

서비스 간 호출 시 API를 사용하므로, 통신 비용이나 Latency에 대해 이슈가 존재.

테스트/데이터 트랜잭션

모놀리식에서는 단일 트랜잭션을 유지하면 됐지만 MSA에서는 비즈니스에 대한 DB를 가지고 있는 서비스도 각기 다르고, 서비스의 연결을 위해서는 통신이 포함되기 때문에 트랜잭션을 일관되게 유지하며 개발하는게 어렵다.
- 통합 테스트가 어렵다. 개발 환경과 실제 운영환경을 동일하게 가져가는 것의 어려움

데이터 관리

데이터가 여러 서비스에 분산되어 있어 관리하는데 어려움이 있다.

그래서 msa가 무조건 좋은것인가?

설계방식에 대한 정답은 없다. 하지만, 많은 기업들이 MSA를 적용하여 글로벌 서비스를 성공적으로 확장시켰다는 것은 확실하다.
또한, Cloud 기반의 서비스에 매우적합한 방식이라는 것도 자명하다. 하지만, MSA를 무조건 적으로 적용하는 것 보다는 현재프로젝트의 규모, 통신 방식등을 적절하게 산정/예상하여 단점보다 장점이 커 보인다고 생각될 때 적용하는 것이 바람직 해 보인다.

MSA의 핵심 원칙

MSA는 단순히 서비스를 여러 개로 나누는 것이 아니라, 개별 서비스가 독립적으로 개발, 배포, 운영될 수 있도록 설계하는 것이 핵심이다.

그렇지 않으면 모놀리식 아키텍처와 다를 바 없다. 따라서, 적절한 설계 원칙을 적용하여 설계를 진행하여야 한다.

1. 단일 책임 원칙(SRP: Single Responsibility Principle)

SRP는 각 서비스가 하나의 명확한 역할을 수행해야 한다는 원칙이다. 이를 따르지 않으면 서비스가 점점 커지면서 결국 모놀리식 구조와 다름없어질 수 있음을 알아야 한다.

응집도와 결합도

서비스 내부의 응집도는 높이고, 서비스 간의 결합도는 낮춰야 한다. 응집도가 높은 서비스는 유지보수가 용이하며, 변경 시 다른 기능에 영향을 최소화할 수 있다. 반면, 결합도가 높으면 서비스 간 변경 사항이 전파되면서 독립적인 배포가 어려워지고, 장애 전파의 위험도 커진다.

서비스의 역할 명확화

각 서비스는 명확한 도메인 역할을 가져야 한다(DDD). 예를 들어, 주문 서비스는 주문 관련 로직만을 담당하고, 결제 서비스는 결제와 관련된 기능만을 처리해야 한다. 이를 통해 개발, 배포, 확장이 용이해지고, 운영 비용을 절감할 수 있다.

2. 서비스 독립성

서비스는 서로 독립적으로 운영될 수 있어야 한다. 특정 서비스가 다운되더라도 전체 시스템이 영향을 받지 않도록 설계하는 것이 중요하다.

느슨한 결합

서비스 간 통신은 동기 호출보다는 비동기 메시징 또는 이벤트 기반 방식을 활용하는 것이 좋다. 이를 통해 특정 서비스가 응답하지 않아도 전체 시스템이 멈추지 않도록 할 수 있다.

서비스 간 의존성 최소화

서비스 간의 직접적인 의존성을 최소화해야 한다. 예를 들어, 한 서비스가 다른 서비스의 데이터베이스에 직접 접근하는 것은 피해야 하며, API나 이벤트 기반 방식으로 데이터를 교환해야 한다.

3. 장애 격리

MSA 환경에서는 특정 서비스에서 장애가 발생하더라도 다른 서비스로 확산되지 않도록 격리하는 것이 필수적이다.

서킷 브레이커 패턴

서킷 브레이커는 특정 서비스가 응답하지 않을 때, 일정 횟수 이상 요청이 실패하면 추가 요청을 차단하는 패턴이다. 이를 통해 과부하를 방지하고, 장애가 확산되는 것을 막을 수 있다.

폴백 전략

서비스 장애 발생 시, 기본적인 대체 응답을 제공하는 폴백 전략을 사용하면 사용자 경험을 유지할 수 있다. 예를 들어, 추천 서비스가 장애가 발생하면 기본 인기 상품 목록을 반환하는 식.

애플리케이션 성능 모니터링

서비스의 상태를 지속적으로 모니터링하여 장애 발생을 사전에 감지하고 대응할 수 있도록 해야 한다.

4. 자동화

MSA에서는 수많은 서비스가 존재하므로 수작업으로 운영하기에는 한계가 있다. 따라서 CICD 파이프라인과 Kubernetes 기반의 자동화가 필수적이다.

CI/CD 파이프라인 구축

코드 변경 사항을 빠르게 배포할 수 있도록 지속적인 통합 및 배포(CI/CD)를 구축해야 한다. 이를 통해 배포 속도를 높이고, 변경에 대한 위험을 줄일 수 있다.

Kubernetes를 이용한 서비스 배포 및 관리 자동화

Kubernetes를 활용하면 서비스 배포, 확장, 롤백을 자동화할 수 있다. 이를 통해 인프라 관리의 복잡도를 줄이고, 서비스 안정성을 확보할 수 있다.

▶🚢Kubernetes(k8s)란

5. 모니터링 및 로깅

MSA에서는 서비스가 분산되어 있기 때문에, 효과적인 모니터링과 로깅이 필수적이다.

분산 추적 시스템

서비스 간 요청 흐름을 추적하기 위해 분산 추적 시스템(OpenTelemetry, Jaeger)을 활용하여 성능 저하 원인을 빠르게 파악할 수 있다.

중앙 집중식 로깅

각 서비스에서 발생하는 로그를 한곳에 수집하여 관리해야 한다. 중앙 집중식 로깅 시스템(ELK Stack, Grafana Loki)을 활용하면 장애 발생 시 원인을 빠르게 분석할 수 있다.

성능 모니터링

서비스의 CPU, 메모리 사용량, 응답 시간 등을 지속적으로 모니터링하고, 이상 징후를 사전에 감지하여 대응할 수 있도록 해야 한다.

서비스 분해(경계 선정) 전략 및 패턴

MSA를 설계할 때, 적절한 서비스 분해 전략을 선택하는 것 또한 매우 중요하다. 일반적인 분해 전략은 다음과 같다.

비즈니스 기능 기반 분해: 각 서비스가 특정 비즈니스 기능을 담당하도록 분해한다. 예를 들어, 주문 관리, 결제 처리, 사용자 인증 등을 각각의 서비스로 나눌 수 있다.

하위 도메인 기반 분해: 도메인 주도 설계(DDD)를 활용하여 하위 도메인별로 서비스를 분리한다. 고객이 발생시키는 이벤트를 시작점으로 하여 Path를 발경하는 Event Storming 기법도 있다.

트랜잭션 경계 기반 분해: 트랜잭션 경계를 기준으로 서비스를 분리하여 데이터 일관성을 유지한다.

이러한 분해 전략을 통해 서비스 간의 결합도를 낮추고, 독립적인 개발과 배포가 가능하도록 설계할 수 있다.

주의점

MSA를 도입하며, 기능(도메인)의 경계를 명확히 하는것은 생각보다 쉽지 않다.
특히 핵심 기능을 분리할 때 어려운 점이 있다.

핵심 기능은 다른 기능들과의 결합도가 높다
핵심 기능일 수록 장기간의 유지보수로 인하여, 도메인간의 경계가 명확하지 않을 가능성이 높다

이러한 핵심 기능들은 사람의 눈으로만 판단하는데 어려움이 있기 떄문에, 다양한 정적 분석도구를 활용하면 좋다.

MSA 서비스 분리 원칙

다음은 MSA에서 유연성과 확장성을 확보하기 위한 주요 서비스 분리 원칙이다.

1. 코드의 재개발

분리 대상 서비스를 확정하고 나서는, 기존 모놀리식 코드를 재사용 할것인지, 재개발 할것인지를 고민해야한다.
일반적으로 코드를 재사용하여 서비스를 구성하는 것이 효율적으로 보이지만 오히려 비효율을 초래할 가능성이 크다.

오랜 기간 유지보수 된 코드의 문제점

기술부채가 많이 쌓여있고, 기술 자체가 오래되었을 가능성이 큼
수없이 변경된 요구사항으로, 비즈니스 도메인이 명확하게 반영되어있지 않을 가능성이 큼

기능의 완전한 재작성의 장점

요구사항을 다시 파악하여 해당 기능에 대한 비즈니스 도메인을 명확히 할 수 있음
비즈니스에 대한 더놓은 이해를 바탕으로 아키텍처 재설계 가능
기존의 기술부채 해결
새로운 기술 스텍을 도입할 수 있음

2. 진화적/점진적/반복적 분리

모놀리식으로 구현되어있는 코드 전체를 MSA로 전환하는 것은 아주 길고 비용이 많이 드는 일이다. 때문에, 작고 명확한 계획의 여러단계를 만들어 진행하는 것이 유리하다.

또한, 서비스를 분리할 때 서비스 범위를 너무 좁게 잡으면 각서비스는 응집도 높은 비즈니스 없이 CRUD만 수행하며 개수는 크게 증가하여 복잡도만 높아질 수 있다.

결론

우선 서비스 단위를 크게 분리한 후, 이후에 설계에 대한 고민을 반복적으로 수행하며 분리작업을 점진적으로 진행하는 것이 가장 바람직 하다고 볼 수 있겠다.

통신 및 데이터 관리

마이크로서비스 아키텍처에서는 서비스 간 통신과 데이터 관리가 중요한 이슈이다.

통신 방식

동기 통신: RESTful API, gRPC 등을 사용하여 실시간으로 요청과 응답을 주고받는 방식. 구현이 간단하지만, 서비스 간의 강한 결합을 초래할 수 있다.
비동기 통신: 메시지 큐(Kafka, RabbitMQ 등)를 활용하여 비동기적으로 메시지를 전달하는 방식. 이는 서비스 간 결합도를 낮추고, 시스템의 확장성과 탄력성을 향상시킨다.

데이터 관리

데이터베이스 분리: 각 서비스는 자체 데이터베이스를 보유하여 데이터 독립성을 확보한다.
데이터 일관성 유지: 분산 트랜잭션을 피하기 위해 SAGA 패턴, 이벤트 소싱 등을 활용하여 데이터 일관성을 유지한다.

마무리

MSA는 단순히 시스템을 여러 개의 서비스로 나누는 것이 아니라, 서비스의 독립성, 장애 격리, 자동화, 모니터링 등의 원칙을 철저히 준수하는 것이 핵심이다. 이러한 원칙이 지켜지지 않으면, 시스템은 오히려 더 복잡해지고 운영 비용이 증가할 뿐 아니라 장애 대응도 어려워진다.

특히 단일 책임 원칙, 서비스 독립성, 장애 격리, 자동화, 모니터링은 MSA에서 반드시 적용해야 하는 필수 요소이다. 이 원칙들을 바탕으로 MSA를 설계하면 유연한 확장성, 높은 가용성, 효율적인 운영이 가능한 시스템을 구축할 수 있겠다.