☁ Cloud Native란?
☁ 클라우드 네이티브의 정의
- 클라우드의 이점을 백퍼센트 활용하지 못하는 기존 시스템에서의 애플리케이션과 달리
클라우드의 이점을 최대로 활용할 수 있도록 애플리케이션을 구축하고 실행하는 방식 - 클라우드 네이티브라는 이름만 보게 되더라도
클라우드 네이티브는 클라우드의 규모와 크기 조정 및 성능에 최적화되어 있는
애플리케이션을 개발하기 위한 접근 방식과 기술을 이야기한다는 것을 알 수 있음
- 2015년 처음 클라우드 네이티브라는 용어를 사용한 리눅스는 CNCF 재단을 만들어
클라우드 네이티브로 전환할 수 있는 오픈 소스 기술들을 추진하고 관리하고 있음 - 또한 CNCF 재단에서는
'클라우드 네이티브 기술은 조직이 퍼블릭, 프라이빗, 그리고 하이브리드 클라우드와 같은
현대적이고 동적인 환경에서 확장 가능한 애플리케이션을 개발하고 실행할 수 있게 해주는 기술.
컨테이너, 서비스 메쉬, 마이크로서비스, 불변 인프라, 그리고 선언형 API가
클라우드 네이티브 접근 방식의 예시들이며 이 기술은 회복성, 관리 편의성, 가시성을 갖춘
느슨하게 결합된 시스템을 가능하게 하며 견고한 자동화 기능을 함께 사용하면
엔지니어는 영향이 큰 변경을 최소한의 노력으로 자주, 예측 가능하게 수행할 수 있다.'
라고 클라우드 네이티브를 정의했음
☁ 클라우드 네이티브를 위한 주요 4가지 요소
- 클라우드를 실현하기 위한 주요 4가지 요소에는
데브옵스, 지속적인 통합/배포, 마이크로서비스, 컨테이너 기반 인프라가 존재
- 데브옵스란 애플리케이션 개발, 운영 간의 협업 프로세스를 자동화하는 것을 말하며
이를 통해 결과적으로 애플리케이션의 개발과 개선 속도를 빠르게 함 - 서비스 출시 속도가 빠르고 업데이트 주기가 빈번해진 현재를 따라가기 위해서는
개발된 소프트웨어가 시스템의 안정성을 유지하면서 사용자에게 빠르게 제공될 수 있도록
개발, 테스트, 배포, 운영의 사이클이 자동화된 단일 워크플로우로의 통합 필요성이 생기게 됨
이로 인해 개발과 운영의 업무가 통합된 데브옵스 개발론이 나타나게 되었음 - 그러므로 조직 내 인력과 이들의 협업 프로세스를 자동화하는 데브옵스 속에서부터
클라우드 네이티브 애플리케이션이 시작된다고 할 수 있음
- 컨테이너 기반 인프라란 가상화 기술 중 하나로, 시스템을 가상화하는 것이 아니라
애플리케이션을 구동할 수 있는 컴퓨팅 작업을 패키징하여 가상화하는 것 - IT 기술의 컨테이너도 물류 분야의 컨테이너처럼 이동성을 실현하기 위한 기술
즉, 컨테이너를 통해 어느 환경이나 어느 인프라로든 쉽게 이동할 수 있음을 뜻하며
컨테이너는 애플리케이션을 실행하기 위한 컴퓨팅 작업을 패키징하여 이미지로 만드므로
경량화되어 있고, 서버나 OS 환경에 종속되지 않아 진정한 애플리케이션 이식성이 실현됨 - 애플리케이션이 돌아갈 수 있는 OS 환경이 포함되어 있어 VM을 띄워 자원을 할당한 후
OS를 부팅하고 나서야 애플리케이션을 구동할 수 있는 하이퍼바이저 기반의 VM 방식과 달리,
컨테이너 기반의 가상화 방식은 프로세스 간 벽을 만들어 애플리케이션이 구동되는 환경이
컨테이너화되어 있기 때문에 하나의 OS 커널을 공유하여 사용하며
각각의 OS가 필요하지 않기 때문에 더 가볍고 크기도 작아 복제와 배포가 간편해짐
또한 모든 것이 패키지로 묶어 이미지로 만들어지기 때문에
컨테이너가 작동하는 환경이라면 어디서든 실행시킬 수 있는 장점이 있음
- 마이크로서비스란 애플리케이션을 구성하는 서비스들을 독립적인 작은 단위로 분해해
구축하고 각 구성 요소들은 네트워크를 통해 통신하는 아키텍처 - 이들은 서비스 안정성과 확장성을 지원하며
서비스끼리는 프로그래밍 언어에 구속받지 않는 API를 통해서 통신하며
각 서비스는 각각 자체 DB를 가지게 됨 - 모놀리식은 전체 애플리케이션이 하나의 통합된 패키지 형태로 구성되어 있고
구성 모듈들이 의존적으로 연결되어 있기 때문에 기능 하나를 변경하려면
전체 애플리케이션을 재배포해야 하여 번거로움
이러한 이유로 확장하기 어려운 문제가 존재하며
개발 초기에 사용한 기술 스택에 고정되어 사용해야 한다는 제약이 존재
이와 달리 마이크로 서비스는 애플리케이션을 작은 기능으로 나누어
해당 기능에만 집중하여 구축하므로 개별 서비스들을 더 쉽게 변경하거나 확장할 수 있으며,
서비스마다 다른 언어, 프레임워크, 라이브러리를 사용할 수 있다는 장점이 있음
이외에도 서비스들이 분리된 독립적인 구조이므로 장애가 발생 시 한정적 격리 가능
- 지속적인 통합이란 개발자가 작업한 코드를 자동으로 테스트하고
테스트에 통과하면 코드를 통합하여 저장함 - 지속적인 배포는 작업한 코드 및 변경사항들이 테스트를 거쳐 리포지토리에 업로드되고
실서비스 배포로 릴리즈까지 자동화하는 것을 말함 - 오른쪽 사진과 같은 과정을 거치는 통합과 배포를 합쳐 자동화하여
애플리케이션을 보다 짧은 주기로 고객에게 제공할 수 있음
- 레드헷에서는 이와 같이 이러한 주요 요소들을 가지고 클라우드 네이티브의 실현을 비유함
이러한 기술들을 통해 사용자 피드백을 신속하게 통합하여
지속적으로 개선할 수 있는 비즈니스 가치를 제공할 수 있도록 클라우드 네이티브는 설계됨
☁ 클라우드 네이티브 이점 사례
- 클라우드 네이티브 이점 사례로는 넷플릭스, 위챗, 우버 등이 있음
- 넷플릭스는 프로덕션에 600개 이상의 서비스가 있고 하루에 100번 배포를 함
넷플릭스는 클라우드로 이전을 하면서 인프라만 클라우드로 옮기게 된다면
기존에 지닌 모놀리식 구조와 데이터베이스에 대한 의존, 데이터센터의 비대화로 인한
모든 문제와 한계점을 그래도 옮기는 것 밖에 되지 않음을 알게 되어
애플리케이션 중심의 클라우드 네이티브로 전면 재설계하였음 - 우버는 프로덕션에 1000개 이상의 서비스가 있고 하루에 수천번 배포를 함
또한 위챗은 프로덕션에 3000개 이상의 서비스가 있고 하루에 1000번 배포를 함
그렇기 때문에 이들은 독립 마이크로 서비스로 구성된 클라우드 네이티브 시스템을 선택해
시장 상황에 신속하게 대응하고 있음
☁ 클라우드 네이티브 문제점과 고찰
- 하지만 클라우드 네이티브는 이렇게 단순히 좋기만 할까요?
- 이렇게 다양한 기술을 사용하는 만큼, 다양한 기술의 장점이 모이기도 하지만, 단점도 모이게 됨
데브옵스 안에서 이루어지는 클라우드 네이티브인 만큼, 구축된 데브옵스 파이프라인이 없으면
팀이 마이크로 서비스와 관련된 분산 워크 플로우 및 책임을 관리하는데 어려움을 겪을 수 있음
컨테이너의 경우 빠른 확장을 적절하게 모니터링하지 않으면 보안 위험을 초래할 수 있음
마이크로서비스의 경우 여러 서비스가 분산되어 얽혀있기 때문에
이로 인한 복잡성이 높고 분산시스템을 어떻게 구성할 것인지에 대한 어려움이 존재함
또한 이렇게 인프라 뿐만 아니라 이러한 기술에 맞춰 조직이 변화되어야 하는 조직 재설계도 필요 - 세상에 나쁜 기술은 없다라는 말처럼 다양한 상황 속에서 이점과 단점을 따져
어떤 기술이 필요할지, 클라우드 네이티브가 나에게 적합한 기술일지
생각해보는 개발자가 되는 것이 필요하다는 고찰을 하게 됨
☁ 참고 문헌
'GDSC Sookmyung 활동 > 10 min Seminar' 카테고리의 다른 글
| ☁️ Cloud CLI (0) | 2022.06.14 |
|---|---|
| MLops와 Vertex AI 맛보기 (0) | 2022.06.06 |
| 디지털 소유권 - NFT와 메타버스 (0) | 2022.05.16 |
| CORS란? (0) | 2022.05.12 |
| 쿠키 vs 세션 vs 토큰 (0) | 2022.05.02 |