MSA 이해하기 1. MSA 개념, 장단점

MSA 개념 : 마이크로서비스 아키텍처(MSA)는 애플리케이션이 작고, 느슨하게 결합되고, 독립적으로 배포 가능한 서비스 모음으로 구성된 소프트웨어 개발에 대한 접근 방식입니다.

각 서비스는 특정 비즈니스 기능에 해당하며 잘 정의된 API를 통해 다른 서비스와 통신합니다.

MSA 주요 특징

단일 책임

각 마이크로서비스는 단일 기능 또는 소규모 관련 기능 집합을 수행하도록 설계되었습니다. 이러한 모듈성을 통해 더욱 집중적이고 효율적인 개발이 가능해졌습니다.

독립적 배포

마이크로서비스는 독립적으로 개발, 배포 및 확장될 수 있습니다. 즉, 한 서비스의 업데이트나 변경 사항이 반드시 다른 서비스에 영향을 미치지는 않습니다.

분산형 데이터 관리

각 마이크로서비스는 일반적으로 자체 데이터베이스 또는 데이터 스토리지를 관리합니다. 이를 통해 단일 중앙 집중식 데이터베이스의 병목 현상을 방지하고 보다 유연하고 확장 가능한 데이터 관리가 가능해집니다.

Technology Agnostic

API를 통해 서로 통신할 수 있는 한, 다양한 프로그래밍 언어, 프레임워크 또는 기술을 사용하여 다양한 마이크로서비스를 개발할 수 있습니다.

서비스 간 통신

마이크로서비스는 종종 HTTP/REST, gRPC 또는 메시징 대기열과 같은 경량 프로토콜을 사용하여 네트워크를 통해 서로 통신합니다.

확장성

개별 마이크로서비스는 수요에 따라 독립적으로 확장될 수 있습니다. 이를 통해 보다 효율적인 리소스 사용과 향상된 성능 관리가 가능해집니다.

Monolithic 설계

MSA와 반대로 monolithic(단일) 설계가 있습니다. monolithic 설계는 애플리케이션의 모든 구성 요소와 기능이 긴밀하게 통합되어 단일 단위로 실행되는 소프트웨어 아키텍처를 의미합니다.

대표적인 웹 기반 어플리케이션의 설계는 다음과 같이 3 계층으로 이루어져 있습니다.

이 3 계층은 단일 코드 베이스인 애플리케이션 계층에 비즈니스 로직과 백엔드 개발이 집중되기 때문에 monolithic 설계로 불리며 가장 많이 사용하는 아키텍쳐입니다.

이 단일 아키텍쳐는 사용하는 것이 매우 쉽습니다.

소규모 프로젝트는 소규모 팀에서 단일 아키텍쳐 방식으로 충분히 문제를 해결할 수 있습니다.

하지만 비즈니스가 계속 성공하고 확장된다면 다음과 같이 monolithic 설계는 점점 문제가 생길 수 있습니다

확장성 문제

너무 많은 엔지니어가 동일한 코드베이스로 작업 -> 조직의 확장성이 낮아짐

monolithic 아키텍쳐의 경우 코드 병합에서 충돌이 심하게 일어날 수 있습니다.

때문에 더 많은 계획과 조정이 필요하며 더 많은 회의가 필요하게 됩니다.

배포의 어려움

지속적인 배포 및 통합은 아무리 작은 변경이라도 전체 배포 주기가 필요하기 때문에 구현하기가 더 어렵습니다. 이로 인해 가동 중지 시간 및 배포 실패 위험이 증가합니다.

신뢰성 및 내결함성

애플리케이션의 어느 부분에서든 오류가 발생하면 전체 시스템이 다운될 수 있습니다. 이러한 오류 격리 부족은 전체 애플리케이션이 오류에 대한 복원력이 낮다는 것을 의미합니다.

기술적 제약

애플리케이션은 일반적으로 단일 기술 스택을 사용하여 구축됩니다. 이는 각각의 특정 기능에 가장 적합한 도구나 언어를 사용하는 능력을 제한하여 잠재적으로 성능과 개발 효율성을 방해합니다.

MSA 이점

개발 유연성

팀은 다양한 서비스를 동시에 작업할 수 있으므로 개발 주기가 빨라지고 지속적인 제공이 가능해집니다.

회복력

서비스는 독립적이기 때문에 하나의 서비스에 장애가 발생해도 전체 시스템에 장애가 발생할 가능성이 적습니다. 이는 애플리케이션의 전반적인 신뢰성을 향상시킵니다.

확장성

서비스는 특정 요구 사항에 따라 독립적으로 확장될 수 있으므로 리소스를 보다 효율적으로 사용할 수 있습니다.

배포 용이성

CI/CD(지속적 통합 및 지속적 배포) 파이프라인은 구현 및 관리가 더 쉬워서 빈번하고 안정적인 릴리스가 가능합니다.

MSA 과제

복잡성

여러 서비스와 해당 상호 작용을 관리하는 것은 복잡할 수 있으므로 강력한 모니터링, 로깅 및 추적 메커니즘이 필요합니다.

데이터 일관성

특히 분산 환경에서는 다양한 서비스 전반에서 데이터 일관성을 보장하는 것이 어려울 수 있습니다.

네트워크 지연 시간

네트워크를 통한 서비스 간 통신이 증가하면 대기 시간이 발생하고 잠재적인 장애 지점이 발생할 수 있습니다.

통합 테스트의 어려움

각 서비스가 다른 팀에 속해 있을 때, 어느 팀이 이 통합 테스트를 수행해야하는지 결정하는 것은 매우 어렵습니다.

디버깅 및 책임 범위 설정

사용자가 수정을 요청한 사항이 여러 개의 마이크로서비스들을 통과하면서 결과적으로 사용자는 정확한 정보를 받지 못하거나 오류가 발생하거나 정확한 정보를 받기는 하지만 너무 긴 지연을 경험하는 상황이 있다고 가정해봅니다.

이 버그나 성능 문제를 처리하는데 어떤 마이크로서비스가 책임이 있는지 파악하는 게 어려울 수 있습니다.

참고한 글

Demystifying Server-Side Development: Monolithic and Microservices Architecture (robosoftin.com)

The A to Z Of Microservice Architecture – (systango.com)

Leave a Comment

목차