msa

모놀리틱 아키텍처와 마이크로서비스 아키텍처

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

- https://www.nginx.com/blog/introduction-to-microservices/
애플리케이션 안에 모든 비즈니스 로직이 다 들어가 있는 구조
전통적인 IT 프로젝트의 근간이 되는 단일 구조 형식
특징
- 단일화된 통합 데이터베이스를 사용
- 서비스를 이루고 있는 전체 기능을 단 하나의 코드베이스로 개발(일원화된 코드 체계)
장점
- 모든 것이 하나의 프로젝트에 들어가 있기 때문에 개발, 빌드, 배포, 테스트가 용이합니다.
- 기존 IDE와 툴을 이용해 개발하기가 용이합니다.
- 같은 애플리케이션을 여러 개 두고 로드 밸런서를 앞에 두는 방법으로 쉽게 확장(scale)할 수 있습니다.
단점
- 기술이 끊임없이 바뀌는 환경에서 기존 프레임워크에 의존성이 생기며 잠재적인 문제 발생 가능합니다.
- 기능이 많아지고 규모가 커져 복잡해질수록 지속적 통합/배포(CI/CD) 및 유지보수가 어렵습니다.
- SPOF(Single Point of Failure) : 한 가지 기능 장애 발생 시 전체 서비스 장애 및 사용 불가
- 여러 모듈이 함께 존재하기 때문에 각 모듈별 특성에 맞는 하드웨어 확장(scale-out)을 하기 어려움
- 전체 프로세스가 하나의 프로세스에서 돌기 때문에 안정성에도 문제가 있습니다. 해당 프로세스에서 메모리 누수(memory leak)가 일어나거나 프로세스가 죽는 경우, 버그가 발생하는 경우 등 모든 영향을 한꺼번에 받음
- 새로운 기술, 언어, 프레임워크 등을 적용하기 어렵습니다. 부분적으로 들어내는 것이 어렵기 때문에 기술 노후가 올 때까지 내버려 두게 되고, 한참 뒤에야 차세대 프로젝트로 전체를 갈아엎게 됩니다.

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

- https://www.nginx.com/blog/introduction-to-microservices/
마이크로서비스는 애플리케이션을 느슨하게 결합된 서비스의 모임으로 구조화하는 서비스 지향 아키텍처(SOA) 스타일의 일종인 소프트웨어 개발기법
애플리케이션을 더 조그마한 여러 서비스를 분해할 때의 장점은 모듈성을 개선하고 애플리케이션의 이해, 개발, 테스트를 더 쉽게 해 주고 애플리케이션 침식에 더 탄력적으로 만들어 줍니다.
마이크로서비스를 사용하면 서비스를 잘게 분리함으로써 애자일한 개발 환경과 점점 더 복잡해지는 애플리케이션에서 분명한 이점이 있지만, 서비스를 분리하면서 생기는 단점도 존재합니다.
규모가 작은 자율적인 팀들이 팀별 서비스를 독립적으로 개발, 전개, 규모 확장을 할 수 있게 함으로써 병렬로 개발할 수 있게 합니다. 지속적인 리팩터링을 통해 개개의 서비스 아키텍처가 하나로 병합될 수 있게 허용합니다.
콜 관리, 고객 관리 등 서비스 단위로 나누고 각각의 서비스들은 API 형태로 제공됩니다. 각각의 서비스는 하나의 작은 애플리케이션처럼 배포가 가능합니다. 따라서 부분적으로 새로운 기능을 추가하거나, 새로운 기술을 적용할 수도 있습니다. 또한 부분적으로 장애가 발생하더라도 복구하는 동안 해당 서비스와 연관이 없는 다른 서비스는 정상 동작합니다.
마이크로서비스 기반 아키텍처는 지속적 배포와 전개(디플로이)를 가능케 합니다.
특징
- MSA의 서비스들은 HTTP와 같은 기술 불가지론적인 프로토콜을 사용하여 목표를 달성하기 위해 네트워크를 통해 통신하는 프로세스들인 경우도 있습니다.
- 마이크로서비스 아키텍처의 서비스들은 독립적인 전개(deploy)가 가능합니다.
- 서비스 교체가 쉽습니다.
- 서비스는 기능별로 분류됩니다.
- 서비스는 최적의 조건에 부합하는 바에 따라 각기 다른 프로그래밍 언어, 데이터베이스, 하드웨어, 소프트웨어 환경을 사용하여 구현할 수 있습니다.
- 서비스들은 규모가 작고, 메시지 전달이 가능하며 컨텍스트별로 묶이며 자율적으로 개발되며 독립적으로 전개할 수 있으며 분산적이며 빌드가 되며 자동화된 프로세스들로 출시됩니다.
장점
- 서비스별로 독립적인 배포가 가능합니다.
- 스케일링(Scaling) : 특정 서비스 부하로 스케일링이 필요할 경우 해당 서비스만 확장
- 장애 대응 : 전체 서비스 제공에 미치는 영향 최소화
- 다중언어(Polyglot) : 각 서비스마다 다양한 언어/환경 구성 가능
단점
- 마이크로서비스 애플리케이션이 분산 시스템이라는 사실에서 발생하는 복잡성입니다.
- 마이크로서비스 기반 애플리케이션을 테스트 및 배포하는 것도 훨씬 더 복잡합니다.
아키텍처
- 모듈성이 있는 구조를 자연스럽게 강제함
- 자기 자신을 지속적 배포 소프트웨어 개발 프로세스에 위치시킵니다. 애플리케이션의 사소한 부분의 변경은 하나 이상의 적은 수의 서비스의 다시 빌드, 재전개만을 필요로 합니다.
- 섬세한 인터페이스(독립적으로 서비스를 전개할 수 있음), 비즈니스 주도의 개발(도메인 드리븐 디자인), 클라우드 애플리케이션 아키텍처, 폴리곳 프로그래밍, 퍼시스턴스, 가벼운 컨테이너 전개, 탈중심화된 지속적 배포, 전체론적인 서비스 모니터링을 갖춘 데브옵스와 같은 원칙들을 고수합니다.
- 확장성에 이득이 되는 특징들을 제공합니다.
- 각 서비스는 서로 API를 제공하고 이를 이용해서 서로 호출합니다. 각 서비스는 비동기(async)로 동작하고 메시지 기반으로 통신
- 마이크로서비스 아키텍처는 아주 작은 단위로 동작하는 서비스가 구동되도록 시스템 및 소프트웨어의 구성과 구성요소 간의 관계를 정의한 아키텍처
- 모든 요소를 하나의 애플리케이션에 구축하는 전통적인 모놀로식 접근 방식 대신 마이크로서비스에서는 모든 요소가 독립적이며 연동되어 동일한 태스크를 완수
구성 원칙
- 단일 책임의 원칙(Single Responsibility) : 각 서비스는 하나의 책임만 가짐
- 독립적인 배포(Independently Deployable) : 각 서비스를 독립적으로 배포
- 느슨한 결합(Loosely Coupled) : 각 서비스 간 의존성을 최소화
- 높은 유지성, 테스트 가능성(Highly Maintainable and Testable) : 분리된 서비스별 관리 및 유지가 편하고 테스트도 독립적으로 가능
- 팀 단위 구성이 가능(Owned by a Small Team) : 서비스 단위로 팀 구성을 하여 개발/운영 가능
- 사업 단위(서비스 단위)의 조직(Organized around Business Capabilities) : 각 서비스의 단위를 사업의 단위로 판단할 수 있음
구성 요소
- - https://developers.redhat.com/blog/2016/12/09/spring-cloud-for-microservices-compared-to-kubernetes
  - Config Management : 서비스의 재빌드, 재부팅 없이 설정사항을 반영
  - Service Discovery : MSA 기반 서비스 배포 시 서비스 검색 및 등록
  - API Management : 클라이언트 접근 요청을 일원화
  - Centralized Logging : 서비스별 로그의 중앙집중화
  - Distributed Tracing : 마이크로서비스 간의 호출 추적
  - Centralized Monitoring : 서비스별 메트릭 정보의 중앙집중화
  - Resilience & Fault Tolerance : MSA 구조에서 하나의 실패한 서비스가 체인에 연결된 전체 서비스들에 파급 효과를 발생시키지 않도록 하기 위한 계단식 실패 방지 구조
  - Auto-Scaling & Self-Healing : 자동 스케일링, 복구, 자동화를 통한 서비스 관리 효율화
MSA를 구현하는 기반 기술
- - https://developers.redhat.com/blog/2016/12/09/spring-cloud-for-microservices-compared-to-kubernetes
모놀리틱 아키텍처와 비교
- 모놀리틱 아키텍처는 하나의 애플리케이션의 모든 기능이 하나의 구조에 통합되어 있는 형태로 전통적인 소프트웨어 개발 방법론에서 자주 사용되던 방법론으로 하나의 구성환경만 관리하면 되기 때문에 개발 및 테스트가 용이하다는 장점이 있지만 배포의 어려움과 프로젝트가 커지면 전체 코드를 파악하기 힘들다는 단점이 있으며 소규모 애플리케이션 개발에 적합한 구조입니다.
- MSA는 하나의 애플리케이션을 여러 단위의 기능 별로 나누는 형태로 기능 별로 나누어서 배포를 가능하고 유연한 확장이 가능하다는 장점이 있지만, 연관된 여러 모듈들 간의 통합 테스트가 어렵고, 흩어진 설정들을 통합적으로 잘 관리해야 한다는 단점이 있습니다. 복잡한 대규모 어플리케이션 개발에 적합한 구조입니다.

Reference

https://www.oreilly.com/library/view/infrastructure-as-code/9781098114664/
http://www.yes24.com/Product/Goods/64728692
http://www.yes24.com/Product/Goods/69304366
https://www.oreilly.com/library/view/cloud-native-devops/9781492040750/

Previousonpremises_cloud NextKubernetes

Last updated 1 year ago

모놀리틱 아키텍처와 마이크로서비스 아키텍처

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

https://www.nginx.com/blog/introduction-to-microservices/

애플리케이션 안에 모든 비즈니스 로직이 다 들어가 있는 구조

전통적인 IT 프로젝트의 근간이 되는 단일 구조 형식

특징

단일화된 통합 데이터베이스를 사용
서비스를 이루고 있는 전체 기능을 단 하나의 코드베이스로 개발(일원화된 코드 체계)

장점

모든 것이 하나의 프로젝트에 들어가 있기 때문에 개발, 빌드, 배포, 테스트가 용이합니다.
기존 IDE와 툴을 이용해 개발하기가 용이합니다.
같은 애플리케이션을 여러 개 두고 로드 밸런서를 앞에 두는 방법으로 쉽게 확장(scale)할 수 있습니다.

단점

기술이 끊임없이 바뀌는 환경에서 기존 프레임워크에 의존성이 생기며 잠재적인 문제 발생 가능합니다.
기능이 많아지고 규모가 커져 복잡해질수록 지속적 통합/배포(CI/CD) 및 유지보수가 어렵습니다.
SPOF(Single Point of Failure) : 한 가지 기능 장애 발생 시 전체 서비스 장애 및 사용 불가
여러 모듈이 함께 존재하기 때문에 각 모듈별 특성에 맞는 하드웨어 확장(scale-out)을 하기 어려움
전체 프로세스가 하나의 프로세스에서 돌기 때문에 안정성에도 문제가 있습니다. 해당 프로세스에서 메모리 누수(memory leak)가 일어나거나 프로세스가 죽는 경우, 버그가 발생하는 경우 등 모든 영향을 한꺼번에 받음
새로운 기술, 언어, 프레임워크 등을 적용하기 어렵습니다. 부분적으로 들어내는 것이 어렵기 때문에 기술 노후가 올 때까지 내버려 두게 되고, 한참 뒤에야 차세대 프로젝트로 전체를 갈아엎게 됩니다.

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

https://www.nginx.com/blog/introduction-to-microservices/

마이크로서비스는 애플리케이션을 느슨하게 결합된 서비스의 모임으로 구조화하는 서비스 지향 아키텍처(SOA) 스타일의 일종인 소프트웨어 개발기법

애플리케이션을 더 조그마한 여러 서비스를 분해할 때의 장점은 모듈성을 개선하고 애플리케이션의 이해, 개발, 테스트를 더 쉽게 해 주고 애플리케이션 침식에 더 탄력적으로 만들어 줍니다.

마이크로서비스를 사용하면 서비스를 잘게 분리함으로써 애자일한 개발 환경과 점점 더 복잡해지는 애플리케이션에서 분명한 이점이 있지만, 서비스를 분리하면서 생기는 단점도 존재합니다.

규모가 작은 자율적인 팀들이 팀별 서비스를 독립적으로 개발, 전개, 규모 확장을 할 수 있게 함으로써 병렬로 개발할 수 있게 합니다. 지속적인 리팩터링을 통해 개개의 서비스 아키텍처가 하나로 병합될 수 있게 허용합니다.

콜 관리, 고객 관리 등 서비스 단위로 나누고 각각의 서비스들은 API 형태로 제공됩니다. 각각의 서비스는 하나의 작은 애플리케이션처럼 배포가 가능합니다. 따라서 부분적으로 새로운 기능을 추가하거나, 새로운 기술을 적용할 수도 있습니다. 또한 부분적으로 장애가 발생하더라도 복구하는 동안 해당 서비스와 연관이 없는 다른 서비스는 정상 동작합니다.

마이크로서비스 기반 아키텍처는 지속적 배포와 전개(디플로이)를 가능케 합니다.

특징

MSA의 서비스들은 HTTP와 같은 기술 불가지론적인 프로토콜을 사용하여 목표를 달성하기 위해 네트워크를 통해 통신하는 프로세스들인 경우도 있습니다.
마이크로서비스 아키텍처의 서비스들은 독립적인 전개(deploy)가 가능합니다.
서비스 교체가 쉽습니다.
서비스는 기능별로 분류됩니다.
서비스는 최적의 조건에 부합하는 바에 따라 각기 다른 프로그래밍 언어, 데이터베이스, 하드웨어, 소프트웨어 환경을 사용하여 구현할 수 있습니다.
서비스들은 규모가 작고, 메시지 전달이 가능하며 컨텍스트별로 묶이며 자율적으로 개발되며 독립적으로 전개할 수 있으며 분산적이며 빌드가 되며 자동화된 프로세스들로 출시됩니다.

장점

서비스별로 독립적인 배포가 가능합니다.
스케일링(Scaling) : 특정 서비스 부하로 스케일링이 필요할 경우 해당 서비스만 확장
장애 대응 : 전체 서비스 제공에 미치는 영향 최소화
다중언어(Polyglot) : 각 서비스마다 다양한 언어/환경 구성 가능

단점

마이크로서비스 애플리케이션이 분산 시스템이라는 사실에서 발생하는 복잡성입니다.
마이크로서비스 기반 애플리케이션을 테스트 및 배포하는 것도 훨씬 더 복잡합니다.

아키텍처

모듈성이 있는 구조를 자연스럽게 강제함
자기 자신을 지속적 배포 소프트웨어 개발 프로세스에 위치시킵니다. 애플리케이션의 사소한 부분의 변경은 하나 이상의 적은 수의 서비스의 다시 빌드, 재전개만을 필요로 합니다.
섬세한 인터페이스(독립적으로 서비스를 전개할 수 있음), 비즈니스 주도의 개발(도메인 드리븐 디자인), 클라우드 애플리케이션 아키텍처, 폴리곳 프로그래밍, 퍼시스턴스, 가벼운 컨테이너 전개, 탈중심화된 지속적 배포, 전체론적인 서비스 모니터링을 갖춘 데브옵스와 같은 원칙들을 고수합니다.
확장성에 이득이 되는 특징들을 제공합니다.
각 서비스는 서로 API를 제공하고 이를 이용해서 서로 호출합니다. 각 서비스는 비동기(async)로 동작하고 메시지 기반으로 통신
마이크로서비스 아키텍처는 아주 작은 단위로 동작하는 서비스가 구동되도록 시스템 및 소프트웨어의 구성과 구성요소 간의 관계를 정의한 아키텍처
모든 요소를 하나의 애플리케이션에 구축하는 전통적인 모놀로식 접근 방식 대신 마이크로서비스에서는 모든 요소가 독립적이며 연동되어 동일한 태스크를 완수

구성 원칙

단일 책임의 원칙(Single Responsibility) : 각 서비스는 하나의 책임만 가짐
독립적인 배포(Independently Deployable) : 각 서비스를 독립적으로 배포
느슨한 결합(Loosely Coupled) : 각 서비스 간 의존성을 최소화
높은 유지성, 테스트 가능성(Highly Maintainable and Testable) : 분리된 서비스별 관리 및 유지가 편하고 테스트도 독립적으로 가능
팀 단위 구성이 가능(Owned by a Small Team) : 서비스 단위로 팀 구성을 하여 개발/운영 가능
사업 단위(서비스 단위)의 조직(Organized around Business Capabilities) : 각 서비스의 단위를 사업의 단위로 판단할 수 있음

구성 요소

- https://developers.redhat.com/blog/2016/12/09/spring-cloud-for-microservices-compared-to-kubernetes
- Config Management : 서비스의 재빌드, 재부팅 없이 설정사항을 반영
- Service Discovery : MSA 기반 서비스 배포 시 서비스 검색 및 등록
- API Management : 클라이언트 접근 요청을 일원화
- Centralized Logging : 서비스별 로그의 중앙집중화
- Distributed Tracing : 마이크로서비스 간의 호출 추적
- Centralized Monitoring : 서비스별 메트릭 정보의 중앙집중화
- Resilience & Fault Tolerance : MSA 구조에서 하나의 실패한 서비스가 체인에 연결된 전체 서비스들에 파급 효과를 발생시키지 않도록 하기 위한 계단식 실패 방지 구조
- Auto-Scaling & Self-Healing : 자동 스케일링, 복구, 자동화를 통한 서비스 관리 효율화

MSA를 구현하는 기반 기술

- https://developers.redhat.com/blog/2016/12/09/spring-cloud-for-microservices-compared-to-kubernetes

모놀리틱 아키텍처와 비교

모놀리틱 아키텍처는 하나의 애플리케이션의 모든 기능이 하나의 구조에 통합되어 있는 형태로 전통적인 소프트웨어 개발 방법론에서 자주 사용되던 방법론으로 하나의 구성환경만 관리하면 되기 때문에 개발 및 테스트가 용이하다는 장점이 있지만 배포의 어려움과 프로젝트가 커지면 전체 코드를 파악하기 힘들다는 단점이 있으며 소규모 애플리케이션 개발에 적합한 구조입니다.
MSA는 하나의 애플리케이션을 여러 단위의 기능 별로 나누는 형태로 기능 별로 나누어서 배포를 가능하고 유연한 확장이 가능하다는 장점이 있지만, 연관된 여러 모듈들 간의 통합 테스트가 어렵고, 흩어진 설정들을 통합적으로 잘 관리해야 한다는 단점이 있습니다. 복잡한 대규모 어플리케이션 개발에 적합한 구조입니다.