모놀리식(Monolithic) 아키텍처 특성에는 다음과 같은 강점이 있습니다.
- 모놀리식 애플리케이션은 지원 데이터베이스를 포함하여 모든 비즈니스 서비스와 기능을 단일 플랫폼으로 배포하므로 소프트웨어 개발 및 배포가 비교적 빠르고 쉽습니다.
- 단일 IDE 인스턴스 내에서 전체 프로젝트를 열 수 있기 때문에 디버깅도 더 간단합니다.
그러나 이러한 이점과 반대로 모놀리식은 유지 관리, 리팩터링 및 확장이 복잡합니다.
수년에 걸쳐 비즈니스 기능을 개별적으로 배포 가능한 서비스로 분리하여 이러한 문제를 해결하는 것을 목표로 여러 아키텍처 패턴이 발전했습니다.
두 가지 진화된 패턴은 마이크로서비스(Microservice)와 미니서비스(Miniservice) 아키텍처입니다.
마이크로서비스 아키텍처(Microservice Architecture)
마이크로서비스 아키텍처는 소프트웨어 애플리케이션을 별개의 인터페이스를 사용하여 느슨하게 결합되고 독립적으로 배포 가능한 서비스 집합으로 설계하는 개발 접근 방식을 따릅니다.
이러한 개별 기능 모듈은 구체적으로 정의된 별도의 작업을 자율적으로 수행합니다.
마이크로서비스 아키텍처의 특징
마이크로서비스 아키텍처는 특정 비즈니스 기능을 중심으로 설계된 자율 마이크로서비스 모음입니다.
기본적으로 이러한 서비스는 주 응용 프로그램을 구성하고 작동하는 소형 응용 프로그램입니다.
마이크로서비스 설계의 필수 특성에는 다음이 필요합니다.
- 각 마이크로서비스에는 특정 비즈니스 기능을 중심으로 구축된 하나의 역할만 포함됩니다. (ex. 전자 메일 보내기, 경고 발생, 티켓 할당 등)
- 모든 마이크로서비스에는 다른 서비스와 데이터 스토리지를 공유하지 않는 자체 데이터베이스가 있습니다.
- 각 마이크로서비스는 독립적으로 개발, 배포, 유지 관리 및 실행됩니다. 따라서 각 마이크로서비스에는 고유한 코드베이스와 배포 환경이 있습니다.
- 마이크로서비스는 느슨하게 결합되어 있습니다 . 즉, 다른 마이크로서비스를 업데이트하거나 영향을 주지 않고 하나의 마이크로서비스를 변경할 수 있습니다.
- 모든 마이크로서비스는 게시자-구독자 패턴을 실행하는 이벤트 기반 통신을 통해 서로 통신합니다.
마이크로서비스 사용의 이점
마이크로서비스 아키텍처를 채택하면 SDLC(소프트웨어 개발 수명 주기)의 효율성을 높이는 다양한 추가 이점을 얻을 수 있습니다. 이러한 이점은 다음과 같습니다.
- [ 확장성 향상 ] 각 마이크로서비스는 전체 애플리케이션 프레임워크를 확장하는 대신 독립적으로 확장할 수 있습니다. 예를 들어, 효율성을 확장하기 위해 특정 서비스에 추가 리소스를 할당할 수 있습니다. 이러한 기능은 마이크로서비스를 모놀리식보다 운영 효율성을 높여줍니다.
- [ 시스템 복원력 향상 ] 어플리케이션은 여러 개의 독립적인 서비스로 구성됩니다. 설계상 하나의 서비스가 실패해도 전체 시스템은 거의 영향을 받지 않습니다. 이를 통해 올바른 팀이 영향을 받는 서비스에서 작업하는 동안 애플리케이션이 계속 작동할 수 있습니다.
- [ 결함 격리 ] 느슨하게 결합된 마이크로서비스의 특성으로 인해 특정 서비스의 결함을 쉽게 찾아 격리하고 수정하여 해결 시간을 단축할 수 있습니다.
- [ 유지 보수 향상 ] 다른 서비스에 영향을 주지 않고 더 나은 성능을 위해 각 서비스를 유지 관리, 최적화 또는 향상할 수 있으므로 마이크로 서비스 기반 애플리케이션을 유지 관리하기가 더 쉽습니다.
- [ 더 빠른 배포 ] 각 서비스에는 개별 컨테이너에서 실행되는 자체 코드베이스가 있습니다. 이를 통해 효율적인 DevOps 모델을 따르는 빠른 개발 및 배포 주기가 가능합니다.
- [ 기술 스택 선택의 유연성 ] 개발자는 특정 프로그래밍 언어나 라이브러리에 얽매이지 않습니다. 이는 팀이 서비스 구현에 가장 적합한 언어와 라이브러리를 자유롭게 선택할 수 있음을 의미합니다. 더욱이 모든 서비스는 다른 서비스에서 사용하는 기술과 다를 수 있는 자체 기술을 실행하도록 설계되었습니다.
마이크로서비스의 한계
마이크로서비스 아키텍처는 향상된 효율성과 향상된 복원력이라는 이점으로 인해 인기를 얻고 있지만 한계와 과제도 함께 따릅니다.
- [ 복잡성 증가 ] 관리해야 할 구성 요소가 더 많고 이러한 구성 요소에는 서로 다른 배포 프로세스가 있습니다. 이벤트 기반 커뮤니케이션의 도입은 또 다른 과제입니다. 이러한 디자인은 비교적 복잡하고 관리할 새로운 기술이 필요합니다.
- [ 복잡한 테스트 ] 각 마이크로 서비스에 필요한 다양한 테스트 종속성으로 인해 마이크로 서비스 기반 응용 프로그램을 테스트하기가 어렵습니다. 서비스가 서로 다른 런타임 환경에서 실행되기 때문에 마이크로서비스 아키텍처에서 자동화된 테스트를 구현하는 것은 훨씬 더 많은 작업입니다.
- [ 더 높은 유지보수 오버헤드 ] 처리할 서비스가 많을수록 관리, 모니터링 및 유지 관리할 리소스가 추가됩니다. 풀타임 보안 지원도 필요합니다. 마이크로서비스는 분산 특성으로 인해 공격 벡터에 더 취약합니다.
미니서비스 아키텍처(Miniservice Architecture)
모놀리식 아키텍처는 확장하기 어렵고, 마이크로서비스는 오케스트레이션 및 유지 관리가 훨씬 더 복잡하기 때문에 이러한 문제를 해결하는 아키텍처가 필요했습니다.
미니서비스 아키텍처는 모놀리식과 마이크로서비스 아키텍처 사이의 중간 지점에 적합하며,
마이크로서비스 개념을 구현하는 데 보다 현실적인 접근 방식을 가정하는 설계입니다.
미니서비스 아키텍처는 다중 역할 기능 및 공유 데이터 저장소가 있는 도메인 경계 서비스(Domain Boundary Service) 모음이 있는 아키텍처 프레임워크입니다.
서비스와 구현 세부 정보가 완전히 분리된 마이크로서비스와 달리, 미니서비스는 라이브러리와 데이터베이스를 공유할 수 있습니다.
미니서비스 아키텍처의 특징
- 서로 관련된 서비스 및 모듈들은 동일한 데이터베이스를 공유할 수 있습니다. 예를 들어, 미니 서비스는 이미지 처리, 이미지 렌더링 또는 응용 프로그램에 대한 기타 관련 기능을 비롯한 여러 기능을 한 서비스에서 수행할 수 있습니다.
- 서비스 간 통신은 REST API를 통해 이루어집니다.
- 서로 관련된 서비스는 배포에 사용되는 코드베이스 및 인프라를 공유할 수 있습니다.
미니서비스 아키텍처의 이점
미니서비스는 마이크로서비스에서 파생된 설계이므로
확장성, 내결함성 및 견고성을 포함하여 마이크로서비스 아키텍처의 모든 이점을 가지고 있습니다.
- [ 성능 향상 ] 도메인 간의 서비스, 상호 연결 및 네트워크 트래픽 수를 줄임으로써 미니 서비스는 애플리케이션 성능을 향상시킵니다.
- [ 공유 유지 관리 오버헤드 감소 ] 다양한 관련 기능을 처리하는 서비스를 통해 마이크로서비스와 관련된 유지 관리 오버헤드가 줄어듭니다.
- [ 개발자 친화적 ] 미니서비스는 종종 각 개별 서비스 작업을 전담하는 소규모 개발 팀을 만들 여력이 없는 회사에 더 적합합니다.
미니서비스 아키텍처의 한계
엔드투엔드 테스트는 단일 서비스와 관련된 종속성의 수로 인해 미니서비스 프레임워크에서 어려울 수 있습니다.
이것은 또한 효율적인 오류 처리 및 버그 발견 과 관련하여 복잡성을 증가시킵니다.
마이크로서비스 대 미니서비스 (Microservice vs Miniservice)
모놀리식 아키텍처의 대안인 마이크로서비스 및 미니서비스 아키텍처는 애플리케이션을 특정 경계 컨텍스트 내에서 더 작은 조각으로 나눕니다.
기본 수준에서 미니서비스는 공유 데이터 스토리지 및 인프라를 허용한다는 점에서 마이크로서비스와 다릅니다.
미니서비스는 마이크로서비스보다 실용적인 접근 방식으로 꾸준히 추진력을 얻고 있습니다.
이러한 각 아키텍처에는 장점과 제한 사항이 있으므로 조직에서 올바른 아키텍처를 선택하기 전에 철저한 실사를 수행하는 것이 중요합니다.
예산 초과 및 운영 중단을 피하기 위해 장기적으로 각 프레임워크를 유지하는 데 필요한 기술, 기술 및 노력을 고려하는 것도 똑같이 중요합니다.
Microservices vs Miniservices: Choosing the Right Framework – BMC Software | Blogs
Microservices vs Miniservices: Choosing the Right Framework
www.bmc.com
'IT' 카테고리의 다른 글
PaaS 컨테이너 플랫폼 비교 (Redhat OpenShift, VMware Tanzu) (0) | 2023.07.04 |
---|---|
Tomcat vs TomEE 비교 (0) | 2023.06.01 |
클라우드 비용 관리의 중요성 (The Cost of Cloud, a Trillion Dollar Paradox) (0) | 2023.04.22 |
2023년 클라우드 현황 보고서 (Flexera 2023 State of the Cloud) (0) | 2023.04.22 |
리눅스 tar 파일 압축 및 압축 해제 명령어(tar, tar.gz) (0) | 2023.04.07 |