MSA (Microservice Architecture)란 무엇일까요?

학습 배경

현재 다니고 있는 회사에서는 모놀리식 아키텍처(모노폴리 구조)를 기반으로 프로젝트를 진행하고 있습니다. 하나의 서비스 내에 여러 도메인이 섞여 있어 각 도메인 간의 비효율적인 개발이 발생하고 있었는데요. 이에 따라 현재 개발팀은 MSA(Microservice Architecture, 마이크로서비스 아키텍처)를 도입하여 모든 프로젝트를 더 유기적이고 효율적인 애플리케이션 구조로 변환하려는 대규모 프로젝트를 진행하고 있습니다. 이 과정에서 MSA의 이해도가 매우 중요하다고 생각되어, 제가 MSA를 학습하고 이를 통해 향후 프로젝트의 방향성에 기여할 수 있도록 글을 작성해보았습니다.

MSA란

MSA, 즉 마이크로서비스 아키텍처는 대규모 애플리케이션을 여러 개의 독립적이고 작은 서비스로 나누어 개발하는 아키텍처 스타일입니다. 각 서비스는 독립적으로 배포되고, 개별적으로 개발되며, 서로 다른 언어나 데이터베이스를 사용할 수 있습니다. 이러한 방식은 대규모 시스템을 효율적으로 관리하고 유연하게 확장할 수 있는 장점이 있습니다.

MSA의 특징

1. 분리된 서비스 : 마이크로서비스는 비즈니스 기능에 따라 여러 개의 독립적인 서비스로 나뉩니다. 각 서비스는 독립적으로 실행되고, 자체적인 데이터베이스와 데이터를 관리합니다.

2. 비즈니스 단위로 나누어짐 : 각 서비스는 특정 비즈니스 기능에 초점을 맞춰 개발됩니다. 예를 들어, 쇼핑몰 시스템에서는 결제, 주문, 배송 등 각기 다른 기능을 담당하는 서비스들이 독립적으로 운영됩니다.

3. 독립적인 배포 : 각 서비스는 독립적으로 배포되기 때문에 하나의 서비스 업데이트가 다른 서비스나 전체 시스템에 영향을 주지 않도록 할 수 있습니다.

4. 다양한 기술 선택 : 각 서비스는 필요한 기술 스택을 자유롭게 선택할 수 있습니다. 이를 ‘폴리글랏 아키텍처’라고도 하며, 각 서비스는 서로 다른 언어나 기술을 사용해도 됩니다.

MSA의 장점

독립적인 배포 : 각 서비스는 독립적으로 배포되고 업데이트될 수 있어, 전체 시스템의 안정성에 미치는 영향을 최소화할 수 있습니다.

기술 독립성 : 각 서비스는 다른 기술 스택을 선택하여 사용할 수 있어, 서비스마다 가장 적합한 언어와 도구를 사용 가능합니다. 예를 들어, 하나의 서비스는 Java로, 다른 서비스는 Python으로 개발할 수 있습니다.

확장성 : 특정 서비스의 트래픽이 급증할 경우, 해당 서비스만 독립적으로 확장할 수 있어 리소스를 효율적으로 관리할 수 있습니다.

장기적인 유지보수 용이 : 각 서비스가 독립적으로 운영되므로, 코드베이스가 깔끔하게 유지됩니다. 이 덕분에 각 서비스의 코드 수정이나 유지보수가 쉬워집니다.

MSA의 단점

복잡성 증가 : 서비스가 독립적으로 관리되기 때문에 시스템 전체의 구조가 복잡해질 수 있습니다. 특히, 서비스 간의 통신이나 데이터 일관성 관리가 어려울 수 있습니다.

서비스 간 의존성 : 마이크로서비스는 독립적이지만, 서로 의존하는 경우가 많습니다. 이로 인해 서비스 간의 통신 및 버전 관리가 복잡해질 수 있습니다.

배포 및 테스트 복잡성 : 여러 개의 서비스를 관리해야 하므로, 배포와 테스트 과정이 복잡해지고 많은 리소스가 필요할 수 있습니다.

데이터 관리 문제 : 마이크로서비스가 각자 데이터베이스를 가지고 있기 때문에, 데이터 일관성 유지나 분산 트랜잭션 관리가 어려워질 수 있습니다.

MSA 도입 시 고려해야 할 사항

서비스의 독립성 : 각 서비스는 독립적으로 운영되어야 하므로, 서비스 간 의존도를 최소화해야 합니다.

API 관리 : 서비스 간 통신은 주로 API를 통해 이루어지므로, API 설계와 버전 관리가 매우 중요합니다.

모니터링 및 로깅 : 각 서비스의 상태를 모니터링하고, 로그를 중앙에서 관리하는 시스템이 필요합니다.

배포 및 테스트 자동화 : MSA에서는 CI/CD 파이프라인을 활용한 자동화된 배포와 테스트가 필수적입니다.

MSA와 모놀리식 아키텍처의 비교

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

모놀리식 아키텍처는 모든 비즈니스 로직과 기능을 하나의 큰 애플리케이션으로 묶는 방식입니다. 이를 확장하려면 시스템 전체를 확장해야 하며, 각 기능이 하나의 코드베이스에 포함됩니다.

하나의 코드베이스 : 모든 기능이 하나의 코드베이스에 포함되어 있어 관리가 단순하지만, 확장성에 제약이 있습니다.

확장성의 제약 : 전체 애플리케이션을 확장해야 하므로 비효율적일 수 있습니다.

배포의 어려움 : 애플리케이션의 일부라도 수정되면 전체 시스템을 재배포해야 하므로, 배포 과정이 번거롭고 시간이 오래 걸릴 수 있습니다.

마이크로서비스 아키텍처(MSA)

마이크로서비스 아키텍처는 애플리케이션을 여러 개의 독립적인 서비스로 나누어 개발하고 배포하는 방식입니다. 각 서비스는 독립적으로 배포되고, 서비스 간 통신은 API나 메시징 시스템을 통해 이루어집니다.

독립적인 서비스 : 각 서비스는 독립적으로 개발 및 배포됩니다.

유연한 확장 : 서비스 단위로 확장할 수 있어, 필요한 서비스만 확장 가능하며, 효율적인 리소스 관리가 가능합니다.

기술 독립성 : 각 서비스가 서로 다른 기술을 사용할 수 있어 기술 스택에 구애받지 않습니다.

결론

MSA는 대규모 애플리케이션을 관리하고 확장하는 데 매우 유리한 아키텍처 스타일입니다. 다만, 모놀리식 아키텍처에 비해 더 많은 복잡성 및 리소스를 요구하므로, MSA를 도입하기 전에는 충분한 고려와 준비가 필요합니다. 각 서비스가 독립적으로 운영되기 때문에, 서비스 간의 의존성 관리, 자동화된 배포 시스템 설계 등 여러 요소들을 잘 준비하는 것이 중요합니다.

Strangler Fig 패턴을 통한 점진적 전환

하지만 기존 시스템인 모노폴리 구조를 MSA로 전환하는 작업은 고비용과 고위험을 동반하는 복잡한 과정입니다. 이때, Strangler Fig 패턴을 활용하여 점진적으로 전환하는 방법을 고려할 수 있습니다. 이 패턴은 기존 시스템과 새로운 시스템이 일정 기간 공존하면서, 새로운 시스템이 점차적으로 기존 시스템의 기능을 대체해 나가는 방식입니다. 해당 접근 방식은 개발본부장님께서 제시해주신 방법으로, 전환 과정에서의 리스크를 최소화하고 안정성을 확보할 수 있는 전략이라고 생각합니다.

Strangler Fig 패턴 특징

점진적 마이그레이션 : 기존 시스템의 특정 부분을 하나씩 대체하거나 개선하여 새로운 시스템으로 전환합니다. 이를 통해 전체 시스템을 한 번에 바꾸는 부담을 줄일 수 있습니다.

공존 : 새로운 시스템과 기존 시스템이 일정 기간 동안 함께 실행됩니다. 이 기간 동안 두 시스템이 병행되며, 새로운 시스템은 점진적으로 기존 시스템의 기능을 대체해 나갑니다.

리스크 감소 : 한 번에 전체 시스템을 전환하는 대신 점진적으로 변화를 적용하기 때문에, 큰 리스크 없이 안정적으로 시스템을 전환할 수 있습니다.

@banhogu

안녕하세요 배움을 나누며 함께 전진하는 1년차 주니어 개발자 방호진입니다.