최근 소프트웨어 개발 환경에서는 애플리케이션의 복잡성과 요구사항의 다양성이 증가함에 따라 새로운 아키텍처 패턴이 필요해졌습니다. 그 중에서도 마이크로서비스 아키텍처(Microservices Architecture, MSA)는 기존의 모놀리스 아키텍처의 한계를 극복하고 더 나은 유연성과 확장성을 제공하는 혁신적인 접근 방식입니다.
MSA의 역사
1. 모놀리스 아키텍처 (Monolithic Architecture)
초기 소프트웨어 개발은 하나의 큰 코드베이스에서 전체 애플리케이션을 개발하고 배포하는 모놀리스 아키텍처를 중심으로 이루어졌습니다.
모놀리스는 단일 코드베이스에서 실행되기 때문에 개발, 배포, 확장이 상대적으로 단순하지만, 시간이 지남에 따라 유지보수의 어려움과 확장성의 한계가 드러나기 시작했습니다.
2. SOA (Service-Oriented Architecture)
SOA는 모놀리스의 한계를 극복하고 더 나은 유연성과 재사용성을 제공하기 위한 시도로 등장했습니다.
SOA는 서비스라 불리는 독립적인 기능 단위로 애플리케이션을 나누는 방식으로, 각 서비스는 독립적으로 개발, 배포, 실행됩니다.
이러한 서비스는 표준화된 인터페이스를 통해 상호작용하며, 이로써 시스템 간의 느슨한 결합을 유지할 수 있었습니다.
하지만 SOA도 여전히 서비스 간의 의존성이 높고 복잡한 설정이 필요한 등의 한계를 가지고 있었습니다.
3. MSA (Microservices Architecture)
MSA는 SOA의 원칙을 기반으로 하면서도 더 작고 독립적인 단위의 서비스를 강조하는 아키텍처로 진화했습니다.
MSA에서는 각 서비스가 자체 데이터베이스를 가지고 독립적으로 실행되며, 경량화된 통신 프로토콜을 통해 서비스 간 상호작용이 이루어집니다.
각 서비스는 자체적인 생명주기를 가지고 개발, 배포, 확장이 가능하며, 개발팀은 자율적으로 서비스를 개발하고 운영할 수 있습니다.
이로써 빠른 개발 주기, 높은 유연성, 안정성, 확장성이 가능해지면서, MSA가 현재의 소프트웨어 아키텍처의 주류로 자리잡게 되었습니다.
MSA가 주류가 된 배경
1. 클라우드 컴퓨팅의 보편화
클라우드 컴퓨팅의 보편화로 인해 인프라스트럭처를 빠르게 확장하고 축소할 수 있게 되었습니다. 클라우드 서비스를 사용하면 필요한 리소스를 신속하게 프로비저닝하고 비용을 절감할 수 있습니다.
MSA는 각 서비스를 독립적으로 배포하고 확장할 수 있기 때문에 클라우드에서의 유연한 확장성과 효율적인 자원 활용이 가능해졌습니다.
2. 컨테이너 기술의 발전
Docker와 같은 컨테이너 기술의 발전으로 애플리케이션과 그 종속성을 격리된 환경에 패키징할 수 있게 되었습니다.
MSA는 각 서비스를 컨테이너로 패키징하여 실행함으로써 환경의 일관성과 이식성을 확보할 수 있게 되었습니다. 이는 배포 프로세스를 간소화하고 더 빠르게 확장 및 축소할 수 있게 향상시켰습니다.
3. CI/CD (Continuous Integration / Continuous Deployment)의 증가
CI/CD 파이프라인의 증가로 인해 개발자들은 지속적으로 코드를 통합하고 테스트하며, 신속하게 배포할 수 있게 되었습니다.
MSA는 독립적인 배포가 가능하기 때문에 CI/CD를 통해 지속적으로 각 서비스를 업데이트하고 배포할 수 있습니다. 이는 빠른 개발 주기를 가능케 하며 사용자 요구에 빠르게 대응할 수 있게 합니다.
4. API의 중요성 증대
API(Application Programming Interface)의 중요성이 증대되면서 서비스 간의 통신과 통합이 더욱 중요해졌습니다.
MSA에서는 각 서비스 간에 API를 통해 통신하므로, 서비스 간의 느슨한 결합을 유지할 수 있습니다. 이는 각 서비스를 독립적으로 개발하고 업데이트할 수 있게 합니다.
5. 분산 시스템 및 마이크로서비스 아키텍처에 대한 이해 증가
개발자들의 분산 시스템 및 마이크로서비스 아키텍처에 대한 이해도가 증가했습니다.
MSA는 서비스 간의 독립성과 확장성을 강조하는 아키텍처로, 이러한 이해도의 증가는 MSA의 채택을 더욱 촉진하고 있습니다.
모놀리스 아키텍처의 문제점과 MSA의 해결책
1. 단일 장애 지점 (Single Point of Failure)
모놀리스 아키텍처에서는 애플리케이션 전체가 하나의 큰 코드베이스에서 실행되기 때문에, 특정 구성 요소 또는 서비스의 장애가 전체 시스템에 영향을 미칠 수 있습니다.
MSA에서는 각 서비스가 독립적으로 실행되기 때문에 특정 서비스의 장애가 전체 시스템에 영향을 미치는 것을 방지하고, 전체 시스템의 안정성을 향상시킵니다.
2. 확장성의 한계
모놀리스 아키텍처에서는 전체 애플리케이션을 단일 단위로 확장해야 하기 때문에 특정 기능이나 서비스에 대한 확장성이 제한될 수 있습니다.
MSA에서는 각 서비스가 독립적으로 확장될 수 있어, 특정 서비스에 대한 확장성이 더 유연하게 이루어집니다.
3. 기술 스택의 제한
모놀리스에서는 전체 애플리케이션이 특정 기술 스택으로 개발되어야 하기 때문에, 서비스 간에 다양한 기술을 사용하기 어렵습니다.
MSA에서는 각 서비스가 독립적으로 개발되기 때문에, 각각의 서비스가 최적의 기술 스택을 선택하여 사용할 수 있습니다.
4. 배포 및 업데이트 어려움
모놀리스에서는 전체 애플리케이션을 다시 배포해야 하므로, 작은 변경 사항도 전체 시스템을 중단시켜야 합니다.
MSA에서는 각 서비스가 독립적으로 배포 및 업데이트될 수 있어, 빠르게 새로운 기능을 배포하고 문제가 발생했을 때 해당 서비스만 롤백할 수 있습니다.
'인프라 > MSA' 카테고리의 다른 글
| [MSA] 분산 트랜잭션 - ACID (1) | 2023.12.18 |
|---|---|
| [MSA] Hexagonal Architecture (0) | 2023.12.07 |
| [MSA] MSA가 어려운 이유 (0) | 2023.12.01 |
| [MSA] MSA의 핵심 원칙 (0) | 2023.11.30 |
| [MSA] 모놀리스 아키텍처란 무엇인가? (0) | 2023.11.30 |
