클라우드 네이티브란?
클라우드의 이점을 최대한 활용할 수 있도록 애플리케이션을 구축하고 실행, 배포하는 방식
클라우드 네이티브의 목표 : 변화하는 비즈니스 요구 사항에 빠르게 적응할 수 있는 유연하고 가용성이 높으며 확장 가능한 소프트웨어 제공
클라우드 네이티브는 소프트웨어 아키텍처, 개발 방식, 조직 문화, 인프라 등 모든 것을 클라우드에 적합한 방식으로 설계하고 실행하는 것을 의미한다. 이러한 클라우드 네이티브로의 전환을 통해 IT 조직은 빠르게 변화하는 비즈니스 요구사항에 유연하게 대응할 수 있고 가용성이 높으며 확장 가능한 소프트웨어를 적시에 제공할 수 있다.
클라우드의 4가지 특성
일반적으로 클라우드는 다음 4가지 특성을 가지고 있다.
- CI/CD : 자동화된 빌드와 배포 과정
- DevOps : 개발과 운영 조직의 유기적인 협업을 의미하는 데브옵스
- MicroServices : 분산 소프트웨어 아키텍처
- Container : 경량 가상화 기술
각 요소들에 대해서 하나씩 살펴보도록 하자.
CI/CD
CI/CD = 지속적 통합(Continuous Integration, CI) + 지속적 배포(Continuous Deployment, CD)
개발자가 개발한 코드 변경사항이 자동으로 빌드, 테스트, 통합되어 서비스 환경에 배포되는 과정이 자동화된 개발 방식이다. 실무에서는 각 단계의 연이은 동작이 Jenkins나 GitHub Actions과 같은 도구를 사용해 파이프라인 형태로 자동화된다.
CI
빌드/테스트/통합의 자동화
개발자가 새로운 변경사항을 commit으로 만들어 깃헙에 push 하고 코드 저장소에 pull request라는 병합요청을 보낸다. 그럼 깃헙은 새로운 코드 병합 요청 이벤트를 감지하고 사전에 연동된 단위 테스트와 통합테스트를 실행시켜 기능에 문제없음을 자동으로 확인한다. 이러한 이벤트 수신과 빌드테스트의 자동화는 보통 Jenkins나 GitHub Actions를 통해서 연동으로 이루어진다.
코드 변경에도 다른 기능에도 문제가 없으니 기계적으로 확인되었으므로 다음으로는 pull request에 담긴 변경에 대한 코드 리뷰를 동료들과 함께 진행한다. 코드 리뷰 후 최종적으로 코드 병합이 완료되면 자동으로 컨테이너 이미지로 빌드되게 되고, CI 과정이 완료되게 된다.
CI과정이 자동화되어 있다면, 애플리케이션에 대한 코드 변경 사항이 항상 자동으로 빌드 테스트 되어 공유 레포지토리에 통합되므로 여러 명의 개발자가 동시에 작업하더라도 품질을 보장할 수 있고 코드 변경에 따른 빌드 여부나 영향도가 기계적으로 보장되기 때문에 더더욱 코드 리뷰에 부담이 없어지는 장점이 있다.
CD
배포의 자동화
CD는 간단히 말하면 배포 자동화의 과정이다.
이전 CI 단계를 통해 새로운 코드의 병합이 모두 성공적으로 이루어지면 사람의 개입 없이 해당 변경 사항이 사전 실 서비스 환경에 자동으로 배포되어 즉시 개별 결과를 공유할 수 있다. 사전 실 서비스 환경이란 개발 환경이나 오픈 베타 환경과 같은 개발 서버의 환경을 의미한다. 그리고 최종적으로 비즈니스 수요에 따라 승인을 통해 실 서비스 환경에 배포된다.
이러한 CI/CD 파이프라인이 자동화되어있다면, 작은 코드 변경 사항이 빈번하게 소스코드 저장소에 commit 되고, 하루에도 여러 번 이루어지는 코드 변경과 릴리즈가 특별하지 않은 일상이 된다.
DevOps
DevOps는 소프트웨어 개발(Dev)과 운영(Ops)을 유기적으로 통합하여 개발 라이프 사이클을 단축하는 동시에 비즈니스의 목표를 달성할 수 있도록 빈번한 업데이트를 제공하는 것을 목표로 하는 소프트웨어 엔지니어링 문화이다.
DevOps는 소프트웨어 개발자와 IT 운영 전문가 간의 협업, 커뮤니케이션 및 통합을 강조하여 소프트웨어 제공의 속도와 품질을 개선하고 안정성을 높여서 조직이 변화하는 비즈니스 요구 사항을 신속하게 대응할 수 있도록 한다.
DevOps의 형태는 다양하지만, 가장 중요한 핵심 원칙은 다음과 같다.
DevOps의 핵심 원칙
- 협업 및 커뮤니케이션 : 개발자, 테스터, 운영 팀 간의 정기적인 커뮤니케이션과 조정을 통해 모든 사람이 변경 사항, 위험 및 개선 기회를 인지, 부서 간의 사일로를 허물고 응집력 있는 팀으로 협력하여 소프트웨어 업데이트를 더 빠르고 효율적으로 제공한다.
- 자동화 : 예를 들어 코드 빌드 및 테스트, 애플리케이션 배포, 인프라 관리와 같은 작업 자동화이다. 자동화를 통해 소프트웨어 업데이트를 더 빠르고 더 높은 품질로 제공한다. 가능한 한 많은 작업을 자동화하여 인적 오류를 줄이고 효율성을 개선하며 일관되고 반복 가능한 결과를 보장하여 프로세스 속도를 높이는 것이다.
- 지속적인 개선 및 낭비 최소화 : 데이터와 피드백을 사용하여 프로세스와 시스템을 지속적으로 평가하고 효율성을 개선하고 낭비를 최소화한다. 이러한 활동은 실험, 데이터 분석 및 피드백을 통해 이루어지며, 이를 통해 개선이 필요한 영역과 프로세스와 시스템을 최적화할 수 있는 기회를 파악한다.
- 짧은 피드백 루프를 통해 사용자 요구 사항에 집중 : 정기적으로 사용자와 함께 변경 사항을 테스트 및 검증하고 사용자의 피드백을 개발 프로세스에 통합하여 고객의 요구를 충족하는 소프트웨어를 만들고 사용자 피드백을 기반으로 지속적으로 개선한다.
마이크로서비스 아키텍처(MSA)
대규모 애플리케이션이 API를 통해 서로 통신하는 작고 독립적인 서비스 모음으로 구성되는 소프트웨어 아키텍처
이러한 방식을 사용하면 기존 모놀리틱 아키텍처에 비해 더 빠른 개발 및 배포, 더 빠른 확장성과 복원력을 얻을 수 있다.
- 모놀리틱 아키텍처 : 전체 시스템이 단일 모듈로 구성되어 있어 시스템이 복잡해질수록 유지 보수성과 확장성이 낮아지는 문제가 있다.
- 마이크로 서비스 아키텍처 : 작은 단위로 서비스를 나누어 각각을 독립적으로 개발하고 배포하며 서로 다른 서비스들은 API를 통해 통신한다. 이를 통해 기능 단위 별로 빠르고 유연한 개발과 배포가 가능하며 문제 발생 시 해당 기능만 보관하거나 교체하여 복원력을 높일 수 있다. 또한, 각각의 서비스는 독립적으로 확장할 수 있기 때문에 대규모 시스템에서의 확장성이 높아진다.
마이크로 서비스 아키텍처의 예시로는 대규모 온라인 쇼핑몰 시스템이 있다. 기존의 모놀리틱 아키텍처에서는 모든 기능이 하나의 애플리케이션에 내장되어 있어 쇼핑몰 시스템에서 일어나는 모든 기능의 변경이 시스템 전체에 영향을 미치게 된다. 따라서 이를 수정하기 위해서는 전체 애플리케이션을 다시 빌드하고 배포해야 할 수 있다. 하지만 마이크로 서비스 아키텍처에서는 쇼핑몰 시스템에서 주문, 결제, 상품 등 각각의 기능들을 독립적으로 개발하고 배포할 수 있다.
이렇게 기능들을 작은 단위로 나누어서 개발하면 하나의 서비스에 문제가 생겼을 때 해당 서비스만 복구하면 되므로, 장애 복구 시간을 최소한으로 줄일 수 있다. 또한, 서비스 단위로 확장할 수 있기 때문에 대규모 트래픽 처리에 유리하다. 그리고 각각의 서비스는 API를 통해 통신하기 때문에 언어나 기술 스택을 서비스 별로 자유롭게 선택할 수 있으며, 특정 기술에 종속되지 않는다. 따라서 비즈니스 요구 사항이나 개발자가 가진 기술 스택에 따라 서비스를 독립적으로 개발할 수 있다.
MSA의 단점
- 분산된 수 백, 수 천 개의 작은 앱을 관리해야 하므로 전체 시스템 구조가 복잡해질 수 있음
- 앱별 다양한 런타임 환경, 성능 간섭
- 잦은 빌드/배포, 설정 관리 복잡
- 트래픽 분산 관리, 서비스 디스커버리 등
Container
컨테이너는 실행 환경과 성능을 격리, 표준화한다.
애플리케이션을 OS 환경까지 가상화해서 패키징
컨테이너는 OS 환경까지 패키징되었기 때문에 Linux, Windows, Mac, 가상 머신, 베어메탈, 개발자의 컴퓨터, 데이터 센터, 온프레미스 환경, 퍼블릭 클라우드 등 사실상 어느 환경에서나 구동되므로 개발 및 배포가 쉬워진다.
애플리케이션의 성능 격리
컨테이너는 CPU, 메모리, 스토리지, 네트워크 리소스를 OS 수준에서 가상화하여 개발자에게 기타 애플리케이션으로부터 논리적으로 격리된 OS 샌드박스 환경을 제공한다. 컨테이너 이미지만 실행하면, 격리된 프로세스로 동작하며 마치 별도의 서버인 것처럼 사용할 수 있는 가벼운 가상 환경이다. 이를 통해 어플리케이션의 확장성과 이식성이 높아지며 마이크로 서비스들을 효과적으로 관리할 수 있다.
Docker
컨테이너를 실행시키거나 컨테이너 이미지로 빌드하는 과정에서 가장 많이 사용하는 컨테이너 관리 도구
마이크로 서비스의 단점을 극복하는 기술 : 컨테이너와 쿠버네티스
- Container : 다양한 App 환경을 OS까지 Image화 배포, 성능 격리
- Container Orchestration : 사실상의 표준 kubernetes, 대규모 컨테이너의 관리를 위해 Container Orchestrator를 사용한다.
- Container Orchestrator : 분산 환경에서 컨테이너를 쉽게 배포, 관리, 확장할 수 있게 해주는 도구로 대표적인 예가 Kubernetes이다. Kubernetes는 오픈 소스로 제공되는 컨테이너 Orchestrator로 대부분의 public cloud에서 공통적으로 지원하며, container 관리와 운영에 매우 효과적이다.
Kubernetes가 컨테이너 단위의 어플리케이션과 로드밸런서 연결을 자동으로 제어하며, 서비스 중단 없는 배포를 자동화
클라우드 네이티브는 현대 비즈니스 환경에서 살아남기 위한 경쟁력을 확보하기 위한 중요한 요소 중 하나이다.
클라우드 네이티브의 목표 : 변화하는 비즈니스 요구 사항에 빠르게 적응할 수 있는 유연하고 가용성이 높으며, 확장 가능한 소프트 웨어 제공
2023 KAKAO Tech Campus_BackEnd 2단계
"카카오 클라우드 필수 강의"를 정리한 글입니다.
'개발 > 클라우드' 카테고리의 다른 글
| 클라우드 보안 - Zero Trust 모델 (0) | 2023.07.09 |
|---|---|
| 도커와 쿠버네티스 (0) | 2023.07.07 |
| IT 서비스와 클라우드 (0) | 2023.07.06 |
| 클라우드 서비스 AWS (1) (0) | 2023.05.29 |
| 클라우드 인프라 구축 - 이론 (0) | 2023.05.27 |
