이것은 실제로 사용되는 데이터 엔지니어링 기술의 요약입니다.
개인 기록용으로 작성되었습니다.
https://github.com/mjs1995/muse-data-engineer/blob/main/doc/Back-End%20Development/msa.md
GitHub – mjs1995/muse-data-engineer: 데이터 엔지니어로 성장하기
데이터 엔지니어가 되십시오. GitHub에서 계정을 생성하여 mjs1995/muse-data-engineer 개발에 기여하십시오.
github.com
모놀리식 아키텍처
- 애플리케이션의 모든 비즈니스 로직을 포함하는 구조
- 전통적인 IT 프로젝트의 기반이 되는 단일 구조 형태
- 특성
- 통합된 통합 데이터베이스 사용
- 서비스를 구성하는 모든 기능을 하나의 코드 베이스로 개발(Unified Code System)
- 장점
- 모든 것이 하나의 프로젝트에 있으므로 개발, 빌드, 배포 및 테스트가 쉽습니다.
- 기존 IDE 및 도구를 사용하여 쉽게 개발할 수 있습니다.
- 로드 밸런서 앞에 동일한 애플리케이션을 여러 개 배치하여 간단히 확장할 수 있습니다.
- 불리
- 끊임없이 변화하는 기술 환경에서는 기존 프레임워크에 대한 종속성과 잠재적인 문제가 있습니다.
- 기능이 풍부해지고 더 커지고 복잡해짐에 따라 CI/CD(지속적인 통합/배포) 및 유지 관리가 더 어려워졌습니다.
- SPOF(Single Point of Failure): 기능 장애 시 전체 서비스가 중단되어 사용할 수 없음
- 많은 모듈이 공존하기 때문에 각 모듈의 특성에 따라 하드웨어를 확장하기가 어렵습니다.
- 전체 프로세스가 하나의 프로세스에서 이루어지기 때문에 안정성도 문제입니다. 프로세스가 메모리를 누수할 때, 프로세스가 종료될 때, 오류가 발생할 때 등 모두 동시에 영향을 받습니다.
- 새로운 기술, 언어, 프레임워크 등을 적용하기 어렵다. 부품을 선별하기가 어려우니 기술이 노후화될 때까지 놔두고 머지않아 차세대 프로젝트로 통째로 교체할 예정입니다.
MSA(마이크로서비스 아키텍처)
-
https://www.nginx.com/blog/introduction-to-microservices/ - 마이크로서비스는 애플리케이션을 느슨하게 결합된 서비스 모음으로 구성하는 일종의 서비스 지향 아키텍처(SOA)인 소프트웨어 개발 기술입니다.
- 애플리케이션을 더 작은 서비스로 분해하는 이점은 모듈성을 개선하고 애플리케이션을 이해, 개발 및 테스트하기 쉽게 만들고 애플리케이션 침식에 대한 탄력성을 높인다는 것입니다.
- 민첩한 개발 환경과 점점 더 복잡해지는 애플리케이션에서 마이크로서비스를 사용하면 서비스의 미세한 분리로 인해 분명한 이점이 있지만 서비스의 분리에는 단점도 있습니다.
- 소규모 자율 팀이 팀별 서비스를 독립적으로 개발, 배포 및 확장할 수 있도록 하여 병렬 개발을 지원합니다. 지속적인 리팩토링을 통해 개별 서비스 아키텍처를 하나로 병합할 수 있습니다.
- 통화관리, 고객관리 등 서비스 단위로 구분되며 각 서비스는 API 형태로 제공된다. 각 서비스는 하나의 작은 애플리케이션으로 배포할 수 있습니다. 따라서 부분적으로 새로운 기능을 추가하거나 새로운 기술을 적용할 수 있습니다. 부분적인 장애가 발생하더라도 이 서비스와 관련 없는 다른 서비스는 복구 중에 정상적으로 작동합니다.
- 마이크로서비스 기반 아키텍처는 지속적인 제공 및 배포를 가능하게 합니다.
- 특성
- MSA의 서비스는 종종 HTTP와 같은 기술 독립적인 프로토콜을 사용하여 목표를 달성하기 위해 네트워크를 통해 통신하는 프로세스입니다.
- 마이크로서비스 아키텍처의 서비스는 독립적으로 배포할 수 있습니다.
- 서비스 교체가 쉽습니다.
- 서비스는 기능별로 분류됩니다.
- 필요에 따라 다양한 프로그래밍 언어, 데이터베이스, 하드웨어 및 소프트웨어 환경을 사용하여 서비스를 구현할 수 있습니다.
- 서비스는 자동화된 프로세스에서 작고, 메시지 가능하고, 컨텍스트 바인딩되고, 자율적으로 개발되고, 독립적으로 배포 가능하고, 배포되고, 빌드되고, 릴리스됩니다.
- 장점
- 서비스별 독립 배포가 가능합니다.
- 스케일링: 특정 서비스 부하에 스케일링이 필요한 경우 해당 서비스만 스케일링
- 장애 대응 : 서비스 제공 전반에 미치는 영향 최소화
- Polyglot : 서비스별로 다른 언어/환경 구성 가능
- 불리
- 마이크로서비스 애플리케이션이 분산 시스템이라는 사실에서 발생하는 복잡성.
- 마이크로서비스 기반 애플리케이션을 테스트하고 배포하는 것 또한 훨씬 더 복잡합니다.
- 건축학
- 물론 모듈식 구조가 우세하다.
- 지속적인 제공 소프트웨어 개발 프로세스에서 자신을 포지셔닝하십시오. 애플리케이션에 대한 사소한 변경은 하나 또는 적은 수의 서비스를 다시 빌드하고 재배포하기만 하면 됩니다.
- 정교한 인터페이스(서비스는 독립적으로 배포 가능), 비즈니스 중심 개발(도메인 중심 설계), 클라우드 애플리케이션 아키텍처, 폴리곳 프로그래밍, 지속성, 경량 컨테이너 배포, 분산형 연속 배포 및 전체론적 서비스 모니터링. DevOps와 동일한 원칙을 고수하십시오.
- 확장성에 도움이 되는 기능을 제공합니다.
- 각 서비스는 API를 서로 제공하고 이를 이용하여 서로 호출합니다. 각 서비스는 비동기식으로 작동하며 메시지를 기반으로 통신합니다.
- 마이크로서비스 아키텍처는 시스템과 소프트웨어의 구성과 구성 요소 간의 관계를 정의하여 서비스가 매우 작은 단위로 작동할 수 있도록 하는 아키텍처입니다.
- 모든 것을 단일 애플리케이션으로 통합하는 기존의 모놀리식 접근 방식 대신 마이크로서비스를 사용하면 모든 것이 독립적이며 동일한 작업을 수행하기 위해 함께 작동합니다.
- 구성 원리
- 개별 책임: 각 서비스에는 하나의 책임만 있습니다.
- 독립적으로 배포 가능: 각 서비스를 독립적으로 배포
- 느슨하게 결합됨: 서비스 간 종속성 최소화
- 유지보수 및 테스트 용이성 : 별도의 서비스별로 관리 및 유지보수가 용이하며 독립적인 테스트가 가능
- 팀별 구성 가능(소규모 팀 소유) : 서비스 단위로 팀 구성하여 개발/운영 가능
- 비즈니스 단위(서비스 단위)의 조직(비즈니스 기능을 중심으로 구성): 각 서비스 단위는 비즈니스 단위로 평가될 수 있습니다.
- 요소
-
https://developers.redhat.com/blog/2016/12/09/spring-cloud-for-microservices-compared-to-kubernetes - 구성 관리: 서비스 재구축 또는 재시작 없이 설정 반영
- 서비스 디스커버리: MSA 기반 서비스 제공 시 서비스 디스커버리 및 등록
- API Management: 클라이언트 액세스 요청 통합
- 중앙 집중식 로깅: 서비스별 로그 중앙 집중화
- 분산 추적: 마이크로서비스 간 호출 추적
- Centralized Monitoring: 서비스별 지표 정보를 중앙 집중화
- 복원력 및 내결함성: 하나의 실패한 서비스가 MSA 패브릭의 체인에 연결된 모든 서비스에 도미노 효과를 일으키는 것을 방지하는 계단식 오류 방지 패브릭
- Auto-Scaling & Self-Healing: 자동 확장, 복구 및 자동화를 통한 효율적인 서비스 관리
-
- MSA가 구현하는 기본 기술
-
https://developers.redhat.com/blog/2016/12/09/spring-cloud-for-microservices-compared-to-kubernetes
-
- 모놀리식 아키텍처와의 비교
- 모놀리식 아키텍처(Monolithic Architecture)는 기존의 소프트웨어 개발 방식에서 흔히 사용되는 방식으로 애플리케이션의 모든 기능을 하나의 구조로 통합하는 방식으로 하나의 구성 환경만 관리하기 때문에 개발 및 테스트가 용이하다는 장점이 있다. 프로젝트가 커질수록 모든 코드를 이해하기 어렵고 소규모 어플리케이션 개발에 적합하다는 단점이 있습니다.
- MSA는 어플리케이션을 여러 기능 단위로 나누는 형태로 어플리케이션을 기능별로 나누어 유연한 배포 및 확장이 가능한 장점이 있지만, 여러 관련 모듈 간의 테스트 통합이 어렵고 산재된 설정을 통합적으로 관리하는 단점이 있음 이 구조는 대규모의 복잡한 애플리케이션 개발에 적합합니다.
참조