Cloud Native란?

회사내에서 사내에서 자체 구축하고 운영하는 방식을 ‘온프레미스’, 인터넷을 통해 가상화 된 컴퓨터의 리소스를 제공 받아 운영하는 방식을 ‘클라우드’ 라고 불러요.

Cloud종류

Cloud는 간단하게 3가지 방식으로 운용이 돼요.

한 조직에서 만 사용하여 해당 조직 내에서 완벽하게 제어 가능한 ‘사설 클라우드’(보안이 중요한 은행과 의료 서비스), 공급자가 소유한 Cloud를 공공에게 제공되는 ‘공공 클라우드’, 앞서 두 유형을 묶은 ‘하이브리드 클라우드’ 방식을 예로 들 수 있어요.

애플리케이션의 주요 속성

확장성

클라우드 네이티브는 확장성을 고려하며 설계해야해요.

우선, 전통시스템에서 주로 사용하는 수직적 확장은 서버 한 대에 성을을 높이지만 한계가 명확해요.

그에 반해 수평적 확장은 서버 대 수를 늘려 처리해 클라우드 환경에 적합하고 필요에 따라 탄력적으로 증감이 가능해요.

느슨한 결합

시스템을 모듈로 분리하고 의존성을 최소화해요.

이를 통해 서비스를 독립적으로 운용하고 유연한 시스템 설계를 만들어요.

복원력

한 부분에서 장애가 발생해도 시스템의 다른 구성 요소에 영향이 끼치지 않아야 해요.

몇 가지 기법으로 서킷 브레이커, 재시도, 타임아웃, 사용률 제한 패턴이 있어요.

관측 가능성

시스템 내부 상태를 외부에서 파악할 수 있어야해요.

이경우, 모니터링을 통해 애플리케이션에 대한 측정값을 외부로 제공해요.

경고/시각화를 통해 수집된 데이터를 시각화 하고 해당 데이터를 그래프로 표시하게 되면 시스템 동작을 파악할 수 있죠.

로그 집계/분석을 통해 로그를 집계하고 수집해 시스템 작동에 대한 더 나은 데이터를 제공하고, 데이터 내에서 정보를 찾기 위해 분석을 수행할 수 있어야 해요.

관리 용이성

클라우드 네이티브의 경우 간단하게 관리할 수 있어야해요. 예를 들어 설정 파일 하나로 환경을 변경하거나 명령어 하나로 서버를 추가/제거가 가능하죠.

문화 및 관행

자동화

클라우드 네이티브의 핵심이에요. 단순 반복적인 수동 작업을 자동화 하여 클라우드 네이티브 애플리케이션을 빠르게 배포하는 아이디어를 기반으로 해요.

이전 시스템의 경우 서버를 생성하고 설정하는 작업을 수동으로 작업 할경우 일관성이 없을 수 있으며 실수 할 수 있었어요. 하지만 이를 자동화를 통해 컴퓨터 리소스 동적으로 할당받으며 일관성 있는 설정을 통해 반복적인 업무를 줄임과 동시에 인간이 하는 실수를 줄일 수 있게 되었죠.

지속적 전달(CI)

지속적 전달의 경우 기본 브랜치가 문제없이 배포 가능한 상태를 유지하도록 하는데 초점을 맞춰요.

지속적 배포는 변경 된 사항을 프로덕션에 자동으로 배포하는 경우를 말해요.

데브옵스

지위, 배경에 관계없이 사람들이 시스템을 구상, 개발, 배포 및 운영하기 위해 함계 협력하는 문화를 말해요.

목표

속도

클라우드 네이티브 환경처럼 유연한 환경에서 개발하게 될 경우 출시 시간을 단축 시켜 조금 더 시장에 유연하고 빠른 속도로 배포가 가능해져요. 기존 전통방식의 경우 강한 결합으로 유연성이 부족해 출시기간 지연이 되고 지연이 된다면 경쟁력이 떨어질 수 밖에 없죠.

복원력

예전 전통시스템의 경우 실패할 경우 예외처리를 하였죠. 하지만 이제 실패의 경우 기본이고 어떻게 능동적으로 복원이 가능하며 서비스에 영향이 없어야하는지

확장성

상황에 따라 동적으로 확장할 수 있어야해요. 예를 들어 오전 7시에 쇼핑몰 핫딜이 일어날 경우 특정 서비스에서 비약적으로 트래픽이 늘어날 경우 해당 서비스에 대한 트래픽을 동적으로 수정이 가능하게 설계해야 하죠.

클라우드 네이티브를 애플리케이션과 결합하게 되면 필요한 탄력성을 확보 할 수 있어요.

비용

클라우드 네이티브 방식을 채택하게 되면 비용 최적화가 가능해요.

24시간 내내 실행할 필요 없이 필요한 자원만 생성해서 실제 사용한 만큼만 지불하고, 필요 없는 자원은 회수가 가능해요.

클라우드 네이티브 구성

컨테이너

전통적인 방식으로 애플리케이션 실행 시 자바 런타임 환경과 미들웨어를 설치하고 유지 관리해야해요. 하지만 컨테이너의 경우 다양한 환경에서 이식성과 배포 반복성이 매우 뛰어나며 리소스를 덜 사용하죠. 즉, 컨테이너를 사용하게 되면 동적으로 리소스를 관리하기 때문에 비용 측면에서도 이득을 많이 보게 돼요.

오케스트레이션

위와 같은 컨테이너를 사용하게 되면 결국 수십, 수백 개의 컨테이너를 관리, 배포해야해요.

컨테이너 관리를 오케스트레이션을 통해 다양한 작업을 자동화 하는데 도움이 돼요.

컨테이너의 배포 대상은 서버지만 오케스트레이션의 배포 대상은 클러스터에요.

💡

컨테이너를 오케스트레이션 작업을 YAML 파일을 통해 아래 해당하는 작업을 제어가 가능하죠.

서버리스

서버리스 컴퓨팅은 개발자가 애플리케이션 비즈니스 로직을 구현하는데 집중할수 있게 만들어줘요. 말 그대로 서버를 리스한다라고 생각하면 돼요. 장점으로 트래픽 예측이 어려운 API의 경구 사용에 용이하지만 단점으론 속도와 장시간 실행되는 작업에는 적합하지 않죠.