MSA (Micro Services Architecture)란?

MSA (Microservices Architecture)란?

MSA(Microservices Architecture, 마이크로서비스 아키텍처)는 하나의 큰 애플리케이션을 작은 독립된 서비스들로 나누어 개발하고 배포하는 소프트웨어 아키텍처 스타일이다.

각 마이크로서비스는 독립적으로 배포 가능하며, 고유한 비즈니스 기능을 수행한다.

이 방식은 전통적인 모놀리식 아키텍처(Monolithic Architecture)와 대조된다.

모놀리식 아키텍처는 애플리케이션이 하나의 큰 코드베이스로 구성되어 있는 반면, MSA는 여러 개의 작은 서비스들이 각각의 역할을 수행하며, 이들이 협력하여 하나의 시스템을 구성한다.

---

MSA의 주요 개념

1. 독립된 서비스 (Independent Services)
   • MSA의 핵심은 작은 단위의 서비스로 나뉘어져 있다는 것이다. 각 마이크로서비스는 하나의 비즈니스 기능 또는 도메인을 담당하며, 자체적인 데이터베이스와 비즈니스 로직을 가진다. 이 서비스는 다른 서비스와 독립적으로 개발되고, 배포되며, 실행된다.
   • 예를 들어, 전자 상거래 시스템에서는 ‘사용자 관리’, ‘상품 관리’, ‘주문 처리’와 같은 각각의 기능이 마이크로서비스로 분리될 수 있다.
2. 자율적 개발 및 배포 (Autonomous Development and Deployment)
   • 마이크로서비스는 독립적으로 개발 및 배포될 수 있다. 이는 각 서비스가 서로 다른 프로그래밍 언어나 기술 스택을 사용할 수 있다는 것을 의미하며, 팀들은 각 서비스에 대해 독립적인 개발, 테스트, 배포 주기를 가질 수 있다.
   • 한 마이크로서비스에 대한 업데이트나 유지보수 작업이 다른 서비스에 영향을 미치지 않으므로, 전체 시스템에 대한 위험을 최소화할 수 있다.
3. 작은 규모의 팀 (Small, Cross-Functional Teams)
   • 각 마이크로서비스는 작은 팀이 담당하여 개발 및 운영한다. 이는 팀 간의 의사결정 속도를 높이고, 책임과 소유권을 명확히 할 수 있다. 각 팀은 자신이 담당하는 마이크로서비스의 설계, 개발, 배포, 유지보수를 모두 책임다.
4. 서비스 간 통신 (Inter-Service Communication)
   • 마이크로서비스는 서로 독립적이지만, 시스템 내에서 협력해야 한다. 이를 위해 HTTP/REST, gRPC, 메시징 시스템(RabbitMQ, Kafka) 등을 이용한 API 통신이 필요하다.
   • 서비스 간 통신에는 동기적인 방식(예: HTTP 요청)과 비동기적인 방식(예: 메시지 큐) 모두를 사용할 수 있다.
5. 폴리글랏 퍼시스턴스 (Polyglot Persistence)
   • 각 마이크로서비스는 고유한 비즈니스 요구사항을 충족하기 위해 적합한 데이터 저장소를 선택할 수 있다. 이를 폴리글랏 퍼시스턴스라고 하며, 예를 들어, 사용자 서비스는 NoSQL 데이터베이스(MongoDB)를, 주문 서비스는 관계형 데이터베이스(MySQL)를 사용할 수 있다.
6. 유연한 확장성 (Scalability)
   • MSA는 각 서비스가 독립적이기 때문에, 특정 서비스만 개별적으로 확장할 수 있다. 트래픽이 많은 특정 기능(예: 결제 서비스)은 수평 확장을 통해 처리 성능을 높일 수 있다. 이를 통해 리소스 사용의 효율성을 극대화할 수 있다.
7. 실패에 대한 복원력 (Fault Tolerance and Resilience)
   • MSA는 각 서비스가 독립적으로 운영되기 때문에, 한 서비스가 실패하더라도 시스템 전체가 중단되지 않도록 설계할 수 있다. 서킷 브레이커 패턴이나 재시도 메커니즘을 통해 오류를 관리하고, 실패에 대한 복원력을 강화할 수 있다.

---

MSA의 장점

1. 확장성과 유연성
   • 특정 서비스만 확장하거나 수정할 수 있기 때문에 유연한 확장이 가능하다. 예를 들어, 특정 서비스에만 부하가 많이 걸리는 경우, 해당 서비스만 수평 확장하여 트래픽을 처리할 수 있다.
2. 빠른 개발 및 배포
   • 각 서비스는 독립적으로 개발되고 배포될 수 있기 때문에, 빠른 배포 주기를 가질 수 있다. 새로운 기능 추가나 수정 작업이 전체 시스템에 영향을 미치지 않으므로, 작은 단위로 자주 배포할 수 있다.
3. 다양한 기술 스택 사용 가능
   • MSA에서는 각 마이크로서비스가 독립적으로 설계되기 때문에, 특정 서비스에 맞는 최적의 기술 스택을 선택할 수 있다. 예를 들어, 한 서비스는 Java로, 다른 서비스는 Python으로 개발될 수 있으며, 각각의 데이터베이스도 상황에 맞게 다르게 선택할 수 있다.
4. 단순화된 유지보수
   • 모놀리식 애플리케이션은 시스템이 커질수록 코드베이스가 복잡해지고 유지보수가 어려워진다. 반면, MSA는 각 서비스가 작은 규모로 유지되므로, 유지보수 및 코드 관리가 더 쉬워진다. 각각의 마이크로서비스는 이해하기 쉽고, 변경 사항도 국소적으로 관리된다.
5. 장애 격리
   • MSA에서는 하나의 서비스가 실패하더라도 전체 시스템이 중단되지 않고, 부분적인 서비스만 중단되도록 설계할 수 있다. 이로 인해 시스템의 안정성과 가용성이 높아진다.
6. 팀의 독립성 증가
   • 서비스가 분리되어 있기 때문에 팀은 각자의 마이크로서비스에 대한 완전한 소유권을 가진다. 이는 팀이 독립적으로 의사결정을 하고, 개발 및 배포를 관리할 수 있음을 의미한다.

---

MSA의 단점

1. 복잡한 통합 관리
   • 서비스가 여러 개로 분리되면, 서비스 간의 통신과 데이터 일관성을 관리하는 것이 어려워질 수 있다. API 게이트웨이와 같은 추가적인 관리 계층이 필요하며, 서비스 간 통신에서 발생하는 네트워크 오버헤드를 고려해야 한다.
2. 데이터 일관성 문제
   • MSA는 각 서비스가 독립적인 데이터 저장소를 가질 수 있기 때문에, 데이터 일관성을 유지하는 것이 어려울 수 있다. 분산 트랜잭션을 관리하거나, 이벤트 기반 아키텍처를 도입하여 데이터 일관성을 보장해야 한다.
3. 복잡한 배포 및 운영
   • 많은 수의 마이크로서비스를 배포하고 운영하는 것은 매우 복잡할 수 있다. 이를 위해 CI/CD 파이프라인, 컨테이너 관리 시스템(Kubernetes), 모니터링 툴과 같은 인프라 자동화와 관리 도구가 필요하다.
4. 운영 비용 증가
   • 마이크로서비스는 각 서비스가 개별적으로 배포되고 모니터링되어야 하므로, 운영 비용이 증가할 수 있다. 특히 각 서비스의 배포, 모니터링, 장애 대응을 위한 추가적인 관리 도구 및 인력이 필요하다.
5. 네트워크 통신의 성능 문제
   • 마이크로서비스 간에 HTTP/REST 또는 메시지 큐를 통해 통신하기 때문에, 네트워크 통신 오버헤드로 인한 성능 저하가 발생할 수 있다. 또한, 네트워크 장애나 지연도 고려해야 한다.

---

MSA 적용 시 고려사항

1. 서비스 설계
   • 도메인 주도 설계(DDD)와 같은 기법을 사용하여 서비스의 경계를 명확히 정의하고, 서비스 간의 의존성을 최소화하는 것이 중요하다.
2. 서비스 간 통신
   • 서비스 간의 통신 방식을 설계할 때, RESTful API, gRPC, 메시지 큐 등 적절한 기술을 선택하여 성능과 신뢰성을 고려해야 한다.
3. 데이터 관리
   • 각 서비스가 독립적인 데이터베이스를 가질 때, 데이터 일관성을 유지하기 위한 전략을 세워야 한다. 데이터 동기화와 트랜잭션 관리를 신중하게 처리해야 한다.
4. 보안
   • 서비스 간의 통신과 데이터 전송을 보호하기 위해 적절한 보안 조치를 취해야 한다. 인증 및 권한 부여, 데이터 암호화 등을 고려해야 한다.
5. 자동화와 오케스트레이션
   • 배포, 스케일링, 모니터링 등 자동화와 오케스트레이션 도구를 사용하여 서비스 관리를 효율적으로 수행해야 한다. 컨테이너와 Kubernetes와 같은 도구가 많이 사용된다.

---

결론 

MSA는 애플리케이션을 독립적인 서비스로 분리하여 개발하고 운영할 수 있는 유연하고 확장 가능한 아키텍처 스타일이다. 이는 시스템의 복잡성을 관리하고, 빠른 개발과 배포, 높은 가용성을 추구하는 데 도움을 준다.

그러나 서비스 간의 통합, 모니터링, 데이터 관리 등에서 발생할 수 있는 복잡성에 대한 신중한 접근이 필요하다.