Antifragile의 특징
1. Auto scaling
자동확장성을 의미, 시스템을 구성하는 인스턴스를 하나의 오토스케일링 그룹으로 묶은 다음 그룹에서 유지되어야하는 최소 인스턴스를 지정할 수 있고, 사용량에 따라 인스턴스를 증가시킬 수 있다. 이러한 작업을 관리자가 수작업으로 하는 것이 아니라 CPU 또는 메모리, 데이터베이스 사용량이나 조건에 따라 자동으로 확장된다.
2. MicroService

클라우드 네이티브 아키텍처,어플리케이션의 핵심. 전체 서비스를 구축하고 있는 개별적인 모듈이나 기능을 독립적으로 개발하고 배포하고 운용할 수 있도록 세분화 된 서비스.
3. Chaos engineering
시스템이 어떤 변동이나 예견된 불확실성이나 예견되지 않은 불확실성에 대해서도 안정적인 서비스를 제공할 수 있도록 구축되어야 한다는 것을 의미.
4. continuous deployment
CI/CD : 지속적인 통합, 지속적인 배포를 의미. 클라우드 네이티브 어플리케이션의 경우 많게는 수백개의 마이크로 서비스로 도메인이 분리되어 개발되는 경우가 일반적이다. 수십 수백개의 서비스를 일일이 빌드하고 테스트하고 배포하는 작업을 수작업으로 하는 것은 시간적으로 매우 비효율적이다. 이러한 서비스들을 빌드하고 배포함에 있어 자동화 시스템을 구축하고 하나의 작업에서 다른 작업으로 연계되는 과정을 파이프라인으로 구축하게 되면 매우 효율적으로 관리할 수 있다.
Cloud Native Architecture의 특징
1. 확장 가능한 아키텍처
- 시스템의 수평적 확장으로 인해 더 많은 사용자 요청을 처리할 수 있게 됨
- 확장된 서버로 시스템의 부하가 분산됨과 동시에 가용성을 보장할 수 있게 됨
- 서버 가상화. 시스템 또는 서비스 애플리케이션 단위의 패키지( 컨테이너 기반 패키지 )
- 클라우드 네이티브에 구축된 가상 서버와 리소스들은 다양한 모니터링 도구를 이용해 시스템의 상황 및 리소스 사용량 등을 확인할 수 있다.
2. 탄력적 아키텍처
- 서비스 생성-통합-배포, 비지니스 환경 변화에 대응시간 단축 ( CI/CD 파이프라인 구축 )
- 분할 된 서비스 구조. 분리된 서비스 간에 원활한 통신을 위해 각각의 서비스들은 종속성을 최소화 시켜야 한다. 그리고 stateless한 서비스를 제공하려고 노력해야 한다.
- 서비스 추가, 삭제 자동으로 감지
- 변경된 서비스 요청에 따라 사용자 요청 처리( 동적 처리 )
3. 장애 격리
- 특정 마이크로 서비스에 오류가 발생해도 다른 서비스에 영향을 최소화 할 수 있다.
Cloud Native Application 특징

- 마이크로 서비스로 개발된다
- CI/CD : 개발된 마이크로 서비스들은 CI/CD 시스템에 의해 자동으로 빌드,테스트,배포 된다
- DevOps : 마이크로 서비스에 문제가 발생하면 바로 수정해서 다시 배포하는 과정을 반복하는 형태가 된다. 이러한 특징을 DevOps라고 한다. 위 과정은 시스템이 종료될 때 까지 무한 반복해줌으로써 고객이 원하는 최선의 결과물을 만드는데 그 목적을 둔다.
- Container : 하나의 어플리케이션을 구성하는 마이크로 서비스들을 클라우드 환경에 배포하고 사용하기 위해서는 컨테이너 가상화 기술을 사용하게 된다.
지속적 통합, CI( countinuous Integration )
- 통합 서버, 소스 관리( SCM ), 빌드 도구, 테스트 도구
- ex ) Jenkins, Team CI, Travis CI
DevOps

- 개발조직( Development ) 와 운영조직( Operation )의 통합
- 고객의 요구사항을 빠르게 반영하고 만족도 높은 결과물을 제시하는 것에 그 목적을 두고 있다.
- 잦은 서비스 수정은 전체 개발일정을 더디게 하는 요인이 될 수도 있다.
- 하지만 개발회사가 개발하려는 서비스라던가 어플리케이션은 궁극적으로 고객의 요구사항에 맞는 에러 없는 완성물이여야 한다.
- 자주 테스트하고 자주 피드백 하고 업데이트하는 과정을 거쳐 개발일정이 완료될 때 까지 지속적으로 진행하는 과정을 DevOps라고 할 수 있다.
Container 가상화

- 가상화는 클라우드 네이티브 아키텍처의 핵심이다.
- 운영체제 위에 컨테이너 가상화를 기동하기 위한 소프트웨어 서비스를 작동하게 되고 컨테이너 가상화에서는 공통적인 라이브러리나 리소스들을 공유해서 사용하게 된다. 각자 필요한 부분에 대해서만 독립적인 영역에서 실행할 수 있는 구조이다
- 기존의 하드웨어 가상화 기술보다 더 적은 리소스를 사용할 수 있고, 컨테이너 가상화 위에서 작동하는 서비스들은 훨씬 더 가볍고 빠르게 운용할 수 있다는 장점이 있다.
[ 참고 ]
MSA vs SOA 차이점
1. 서비스 공유 지향점
- SOA - 재사용을 통한 비용 절감을 주목적으로 하고 있다.
- MSA - 서비스 간의 결합도를 낮추어 변화를 능동적으로 대응하는 데에 그 목적을 두고 있다.

2. 기술 방식
- SOA - 공통의 서비스를 ESB( 엔터프라이즈 서비스 버스 )에 모아 사어 측면에서 공통 서비스 형식으로 서비스 제공
- MSA - 각 독립된 서비스가 노출된 REST API 사용.
!! 위 내용은 Dowon Lee 님의 "Spring Cloud로 개발하는 마이크로서비스 애플리케이션(MSA)" 강의를 참고하여 정리한 글입니다
Spring Cloud로 개발하는 마이크로서비스 애플리케이션(MSA) - 인프런 | 강의
Spring framework의 Spring Cloud 제품군을 이용하여 마이크로서비스 애플리케이션을 개발해 보는 과정입니다. Cloud Native Application으로써의 Spring Cloud를 어떻게 사용하는지, 구성을 어떻게 하는지에 대해
www.inflearn.com
'MSA' 카테고리의 다른 글
| Spring Cloud Config & Spring Cloud Bus 간단정리 (0) | 2022.10.20 |
|---|---|
| API Gateway 간단 정리 (0) | 2022.10.19 |
| Spring Cloud Netflix Eureka 간단 정리 (0) | 2022.10.14 |
| Spring Cloud 간단정리 (0) | 2022.10.14 |