마이크로서비스 아키텍처(MSA)의 등장 배경

마이크로서비스 아키텍처(Microservices Architecture, MSA)는 소프트웨어 시스템을 독립적으로 배포 가능한 작은 서비스 단위로 분리하여 운영하는 방식이다. 이는 기존의 모놀리식(monolithic) 아키텍처의 문제점을 해결하기 위해 등장했다. MSA는 현대적인 클라우드 환경과 DevOps 문화에 적합한 아키텍처로 자리 잡았으며, 대규모 서비스 확장성과 유지보수성을 높이기 위한 중요한 개발 패러다임으로 발전했다.

---

1. 모놀리식 아키텍처의 한계

과거 대부분의 애플리케이션은 모놀리식 아키텍처로 개발되었다. 모놀리식 아키텍처는 하나의 코드베이스에서 모든 기능이 통합된 형태로 운영되며, 단일 배포 단위(single deployment unit)로 이루어진다.

1) 모놀리식 아키텍처의 장점

• 모든 기능이 하나의 코드베이스로 관리되므로 개발 초기에는 구조가 단순하다.
• 한 번의 빌드 및 배포로 전체 시스템을 운영할 수 있어 초기 개발 속도가 빠르다.
• 단일 데이터베이스를 사용하기 때문에 데이터 정합성을 유지하기 쉽다.

그러나 애플리케이션이 커지면서 확장성과 유지보수성이 떨어지는 문제점이 발생했다.

2) 모놀리식 아키텍처의 문제점

① 배포의 어려움

• 코드 변경 사항이 있으면 전체 애플리케이션을 다시 빌드하고 배포해야 한다.
• 작은 수정이라도 전체 시스템에 영향을 미칠 수 있어 배포 시 장애 발생 가능성이 높다.
• 특정 기능만 독립적으로 배포할 수 없어 서비스 중단 가능성이 커진다.

② 개발 생산성 저하

• 여러 개발자가 하나의 코드베이스에서 동시에 작업하므로 코드 충돌(conflict)이 자주 발생한다.
• 코드가 커질수록 프로젝트 전반의 복잡도가 증가하고, 새로운 기능을 추가하는 데 시간이 오래 걸린다.

③ 기술 스택 변경의 어려움

• 하나의 애플리케이션이기 때문에 전체 시스템과의 호환성을 고려해야 하므로 새로운 기술을 도입하기 어렵다.
• 예를 들어, 일부 기능에서 NoSQL 데이터베이스를 사용하고 싶어도 기존 관계형 데이터베이스(RDBMS)와의 충돌을 해결해야 한다.

④ 확장성 문제

• 특정 기능(예: 결제 서비스)만 트래픽이 증가해도 애플리케이션 전체를 확장해야 한다.
• 시스템의 일부만 확장하는 수평적 확장(horizontal scaling)이 어렵고, 비효율적인 리소스 사용이 발생한다.

---

2. 분산 시스템과 서비스 지향 아키텍처(SOA)의 등장

모놀리식 아키텍처의 문제를 해결하기 위해 서비스 지향 아키텍처(SOA, Service-Oriented Architecture)가 등장했다.

1) SOA의 개념

SOA는 애플리케이션을 여러 개의 독립적인 서비스로 나누고, 서비스 간 통신을 통해 기능을 수행하는 아키텍처이다. 주요 특징은 다음과 같다.

• 각 서비스는 독립적으로 개발 및 배포 가능하다.
• 다양한 기술 스택을 사용할 수 있다.
• 서비스 간 통신을 위해 ESB(Enterprise Service Bus) 같은 미들웨어를 활용한다.

2) SOA의 한계

SOA는 모놀리식 아키텍처의 문제를 어느 정도 해결했지만, 새로운 한계를 가지고 있었다.

① 중앙 집중식 미들웨어(ESB)의 병목

• SOA는 서비스 간 통신을 ESB라는 중앙 집중식 미들웨어를 통해 관리하는데, ESB가 병목이 되면서 시스템의 확장성이 제한되었다.
• 특정 서비스가 과부하가 걸리면 ESB 전체가 영향을 받으면서 성능 저하가 발생했다.

② 복잡한 운영 및 유지보수

• SOA에서는 서비스 간 데이터 공유 및 통신을 위해 XML 기반의 SOAP 프로토콜을 사용했는데, 이 방식은 무겁고 복잡했다.
• 특정 서비스를 변경하려면 여러 서비스와 ESB까지 수정해야 하는 경우가 많아 운영이 어려웠다.

---

3. 클라우드 네이티브 환경과 MSA의 등장

SOA의 한계를 해결하고, 현대적인 소프트웨어 개발 방식에 맞춰 마이크로서비스 아키텍처(MSA)가 등장했다.

1) 클라우드 컴퓨팅과 컨테이너 기술의 발전

• 클라우드 환경에서는 수평적 확장(horizontal scaling)이 필수적이며, 독립적인 서비스 단위로 운영하는 것이 효율적이었다.
• Docker와 같은 컨테이너(Container) 기술이 발전하면서, 서비스별로 독립적인 배포 및 확장이 가능해졌다.
• Kubernetes와 같은 오케스트레이션 기술이 MSA의 운영을 더욱 쉽게 만들었다.

2) DevOps 및 CI/CD 자동화의 필요성

• 빠른 개발과 배포가 가능한 DevOps 문화가 확산되면서, 독립적으로 배포할 수 있는 마이크로서비스 방식이 적합했다.
• CI/CD(Continuous Integration / Continuous Deployment) 파이프라인을 통해 서비스의 지속적인 업데이트와 자동화된 배포가 가능해졌다.

3) 경량화된 서비스 간 통신 방식

• 기존 SOA의 SOAP 기반 통신 대신, MSA에서는 RESTful API나 gRPC를 활용해 경량화된 서비스 간 통신이 가능해졌다.
• JSON, Protocol Buffers 같은 경량 데이터 포맷을 사용하여 성능을 개선했다.
• 이벤트 기반 통신을 위해 Kafka, RabbitMQ 같은 메시지 큐 시스템이 활용되었다.

---

4. 마이크로서비스 아키텍처(MSA)의 주요 개념

MSA는 SOA의 단점을 보완하면서도, 독립적인 서비스 단위로 운영할 수 있도록 설계된 아키텍처이다. 주요 개념은 다음과 같다.

1) 독립적인 배포 및 운영

• 각 서비스는 개별적으로 개발, 배포, 운영될 수 있다.
• 특정 기능에 대한 변경이 필요하면 해당 마이크로서비스만 수정하여 배포하면 된다.

2) 개별적인 데이터베이스 관리

• 모놀리식 아키텍처에서는 하나의 데이터베이스를 공유했지만, MSA에서는 각 서비스가 자체적인 데이터베이스를 가지는 구조가 일반적이다.
• 이는 데이터 정합성 문제를 해결하기 위해 이벤트 소싱(event sourcing) 및 CQRS(Command Query Responsibility Segregation) 패턴을 활용하는 경우가 많다.

3) 경량화된 통신 방식

• REST API, gRPC, 메시지 큐(Kafka, RabbitMQ) 등을 활용해 서비스 간 통신을 효율적으로 수행한다.
• 서비스 간 강한 결합(tight coupling)을 피하기 위해, 비동기 방식의 이벤트 기반 아키텍처를 적용하는 경우가 많다.

4) 서비스 디스커버리 및 로드 밸런싱

• MSA에서는 Netflix Eureka, Consul, Kubernetes Service Discovery 등을 활용하여 서비스 간 동적인 검색이 가능하다.
• 서비스 간 로드 밸런싱을 위해 Spring Cloud Gateway, NGINX, AWS API Gateway 등을 활용한다.

5) 무중단 배포와 확장성

• Kubernetes(K8s) 및 Docker와 같은 컨테이너 오케스트레이션 기술을 활용해 각 서비스를 자동으로 확장하고 배포할 수 있다.
• Blue-Green Deployment나 Canary Release와 같은 기법을 활용해 무중단 배포를 지원한다.

---