클라우드 네이티브 아키텍처는 서비스를 개발과 운영함에 있어서 운영환경에 종속받지 않고 서비스를 호스팅할 수 있는 컴퓨팅 환경을 제공하는 아키텍처를 말합니다.
클라우드 사업자가 제공하는 클라우드 환경(AWS, MS, Google)은 다양하고, 하나의 서비스 애플리케이션 개발로 여러 클라우드 환경에 종속 되지않게 구현한다면, 서비스의 이식성, 독립성, 신속성을 크게 높일수 있습니다.
애플리케이션의 유형과 환경의 변화
인프라는 물리서버 -> 가상서버 -> 컨테이너 로 변화
서비스 앱은 Native APP -> Web APP -> Cloud Native APP 변화
구조는 Monolitic -> Multi-tier -> Mico-Service 로 변화
개발 방법론은 폭포수 -> 애자일 -> 데브옵스 로 변화
클라우드 네이티브 아키텍처의 필요성
클라우드 네이티브는 크게 이식성, 독립성, 신속성을 높일 수 있습니다.
이식성: 클라우드 환경에 종속되지 않고 어떤 환경에서도 동작될수 있어야 함.
독립성: 다른 기능에 영향을 주지 않고 독립적으로 실행할 수 있는 단위어야 함.
신속성: 어플리케이션의 기능을 추가/변경시 신속하게 반영이 되어야 함.
클라우드 네이티브를 위한 4가지 구성요소
클라우드 네이티브로 가기 위한 주요 구성요소는 API, 마이크로서비스, 컨테이너, 데브옵스 등 크게 4가지로 요약할 수 있다.
1. 마이크로서비스:
하나의 큰 어플리케이션을 작은 단위의 서비스로 분해하여 개발하고 각 서비스를 API로 통신하는 아키텍처
2. API:
마이크로서비스 간에 서로 연동할 수 있는 인터페이스
3. 컨테이너:
마이크로서비스를 컨테이너에 탑재
4. 데브옵스:
개발과 운영을 함께 할 수 있도록 지속적인 통합과 지속적인 배포를 지원하고 개발, 빌드, 배포와 같은 라이프 사이클을 제공
마이크로서비스 아키텍처 개념
하나의 큰 애플리케이션을 서비스 단위로 작게 나누어 서로 통신하는 형태의 아키텍처를 말합니다.
예를 들어 하나의 큰 Video demo platform이 Upload, Download, Streaming, Vertical, Subscriptions, Recommendations 등으로 각 서비스로 쪼개지고 각 서비스간에는 API로 통신을 하는 아키텍처를 갖습니다. 데이터베이스 또한 각각의 기능에 맞게 쪼개어 통신하는 형태의 아키텍처를 갖습니다.
마이크로서비스 아키텍처 특징 및 장단점
1. 마이크로서비스의 각 서비스는 느슨한 결합 형태를 갖습니다. 완벽한 결합으로 되어 있는 컴포넌트는 의존성이 있기 때문에 여러개의 컴포넌트로 쪼개기가 쉽지 않습니다. 반면에, 느슨한 결합은 여러개의 서비스가 결합이 되어 하나의 애플리케이션 서비스를 해 주는데 이 앱의 서비스를 각각 떨어뜨리고 서로 연동이 되는 구조를 느슨한 결합이라고 합니다.
2. 각 서비스는 독립적으로 개발/배포가 가능
3. 서비스간 API를 통해 통신
4. 각 서비스는 독립적으로 데이터 저장
장점:
- 서비스별 독립적 개발/배포/확장 가능
- 서비스별 특성에 맞는 언어, 인프라 사용 가능
- 각 서비스 장애가 전체 장애가 되지는 않음
- 유지보수 용이
단점:
- 서비스간 통신 방법이 필요하고 복잡하여 모놀리스에 비해 성능이 저하
- 데이터 중복 발생
- 문제발생시 어떤 서비스로 문제가 발생하는지에 대한 히스토리를 찾기가 쉽지 않음
- 서비스 단위의 테스트와 통합 테스트 정책 수립 필요