Cloud Native Application
이 전 글에서 Cloud Natice Architecture에 관해 살펴보았다.
Cloud Natice Architecture에 의해 설계되고 구현되는 어플리케이션을 Cloud Native Application이라고 한다.
Cloud Native Application는,
이전에 살펴본 Cloud Natice Architecture의 특징이나 Antifragile과 같은 특징을 가지고 아래와 같은 형태로 구현된다.
1. Microservices
마이크로 서비스들로 개발된다.
2. CI/CD
이렇게 개발된 마이크로 서비스들은 CI/CD 시스템에 의해 자동으로 통합되고, 빌드 -> 테스트 -> 배포의 과정을 거친다.
- 지속적인 통합 (CI, Continuous Integration)
- 통합 서버, 소스 관리(SCM), 빌드 도구, 테스트 도구
- ex) Jenkins, Team CI, Travis CI (이러한 시스템은 git과 같은 형상 관리 시스템과 연동해서 사용) - 지속적인 배포 (CD)
- Continuous Delivery
- Continuous Deployment
- Pipe line - 카나리 배포와 블루그린 배포
지속적인 통합이란, 하나의 어플리케이션을 여러 팀이나 여러 개발자가 함께 개발하고 있는 경우 결과물을 통합하기 위한 형상 관리를 뜻 할 수도 있고,
통합된 코드를 빌드하고 테스트하는 과정 자체를 뜻 할 수도 있다.
CI 시스템에 파이프라인을 잘 연동하게 되면, 깃과 같은 형상관리 시스템에 코드를 커밋함과 동시에 [빌드 -> 테스트 -> 실행]하여 다른 쪽의 코드와 문제가 발생하는지 여부를 바로 확인할 수 있다.
지속적인 배포를 뜻하는 CD에는 두 가지 의미가 포함되어 있다.
Continuous Delivery(지속적인 전달)과 Continuous Deployment(지속적인 배포)가 그것이다.
이 둘은 git과 같은 소스 저장소에 업로드 된 코드를 가져와서,
패키지화된 결과물을 실행 환경에 어떻게 배포하는지에 따라서 달라진다고 볼 수 있다.
만약, 패키지화된 결과물을 실행 환경에 수작업으로 배포하는 과정이 필요하다면 Continuous Delivery 이고,
운영자 혹은 관리자의 개입 없이 실행 환경까지 완벽하게 자동화 되어있는 배포를 쓴다면 Continuous Deployment 이다.
이제 카나리 배포와 블루그린 배포에 대해 살펴보자.
전체 사용자의 95%는 이전 버전 서비스를 계속 사용하도록 하고 5%의 사용자만 새로운 버전의 서비스를 사용하게 하는 것을 카나리 배포라고하며,
이전 버전의 사용자 트래픽을 이전 버전과 거의 동일한 새 버전으로 점진적으로 이전시키는 방법을 블루그린 배포라고 한다.
3. DevOps
DevOps는 말그대로 Development(개발)와 Operation(운영)이 합해진 용어이며, 개발 조직과 운영 조직의 통합을 의미한다.
이러한 통합으로 고객의 요구사항을 빠르게 반영하고 만족도 높은 결과물을 제시하는 것에 그 목적을 두고 있다.
개발 회사가 개발하려고 하는 서비스 혹은 어플리케이션은, 궁극적으로 고객의 요구 사항에 맞는 에러 없는 완성물이어야 한다.
따라서 자주 테스트하고 자주 피드백을 받고 자주 업데이트 하는 과정을 거쳐, 전체 개발 일정이 완료 될 때까지 지속적으로 끊임없이 진행해 가는 것을 DevOps라고 볼 수 있다.
DevOps는 처음에 시스템이 구현되고 테스트 되고 배포되는 과정을 시스템이 종료될 때까지 무한 반복 해줌으로써, 고객이 원하는 최선의 결과물을 만드는데 목적을 두고 있다.
Cloud Native Applicaion은 이러한 DevOps 환경에 맞춰 서비스의 구조를 작은 단위로 분할할 수 있게 함으로써
더 자주 통합, 더 자주 테스트, 더 자주 배포 될 수 있다.
(마이크로 서비스에 문제가 발생했을 경우, 바로바로 수정해 다시 배포하는 과정을 반복할 수 있는 형태가 된다고 볼 수 있다.)
4. Containers
하나의 어플리케이션을 구성하는 마이크로 서비스들을 클라우드 환경에 배포하고 사용하기 위해서는 컨테이너 가상화 기술을 사용하게 된다.
컨테이너 가상화는 Cloud Native Application을 구성하는 가장 큰 특징 중 하나이다.
가상화는 Cloud Native Architecture의 핵심으로,
기존에 로컬 환경에서 운영하고 유지해야만 했던 시스템을 클라우드 환경으로 이전하여 적은 비용으로 탄력성있는 시스템을 구축하게 된 배경이 바로 컨테이너 가상화 기술이라고 볼 수 있다.
컨테이너 가상화 기술은 기존 하드웨어 가상화 또는 서버 가상화에 비해 적은 리소스를 사용하여 가상화 서비스를 구축할 수 있다.
Traditional Deployment
위 사진과 같은 전통적인 방식의 개발 시스템은 하드웨어 시스템 위에 운영체제를 설치하고 어플리케이션들을 운영하게 된다.
Virtualized Deployment
위 사진처럼 가상화를 통한 개발 시스템에서는 운영체제 위에 하이퍼바이저 기술을 통한 가상머신(Virtual Machine)을 기동하게 된다.
이러한 가상머신은 호스템 시스템이 가지고 있는 물리적인 하드웨어를 쪼개서 사용하는 개념으로,
하나의 가상머신은 독립적인 운영체제를 가지고 실행될 수 있다.
따라서 각각의 가상머신에 어플리케이션들을 운영할 수 있다.
그러나 가상머신에서 작동되는 어플리케이션은 호스트 운영체제에 많은 부하를 주게되고 시스템 확장에 한계가 있을 수 밖에 없다.
Container Deployment
마지막으로, 컨테이너 가상화 기술을 기반으로 시스템을 구축할 수 있다.
운영체제 위에 컨테이너 가상화를 기동하기 위한 소프트웨어 서비스(Container Runtime)을 작동하게 되고
컨테이너 가상화에서는 공통적인 라이브러리나 리소스를 공유해서 사용하게된다.
각자 필요한 부분에 대해서만 독립적인 영역에다 실행할 수 있는 구조인 것이다.
따라서, 기존의 하드웨어 가상화 기술 보다는 더 적은 리소스를 사용하게 될 수 있고
컨테이너 가상화 위에서 작동되는 서비스들은 가볍고 빠르게 운영할 수 있다는 특징을 가지고 있다.
💛 개인 공부 기록용 블로그입니다. 👻