개요
- **클라우드 네이티브 컴퓨팅**
- 클라우드 네이티브 핵심요소 4가지 : DevOps, CI/CD, Micro Service, Container
- DevOps
- CI/CD (ex. GitOps)
- 모놀리식 vs MSA
- VM vs Container
- k8s클라우드 네이티브 컴퓨팅
기존의 클라우드 방식보다 더 효율적인 방법을 고민하다가 등장한 클라우드 네이티브에 대해 정리해보자.
클라우드 네이티브란?
- 클라우드 탄력성(Elasticity) 극대화: 필요에 따라 자원을 빠르게 확장 또는 축소할 수 있도록 설계됨.
- 자동화된 개발 및 배포: 개발, 통합, 배포 과정을 자동화하여 운영 효율성을 높임.
- 클라우드 네이티브의 핵심 요소 4가지
- DevOps: 개발과 운영의 협업을 강화하는 방식
- CI/CD: 지속적인 통합(Continuous Integration)과 지속적인 배포(Continuous Deployment)
- 마이크로서비스 아키텍처: 하나의 애플리케이션을 여러 개의 독립적인 서비스로 분리
- 컨테이너 기술: 애플리케이션과 실행에 필요한 요소들을 하나의 패키지로 관리
1. DevOps
DevOps(Development + Operations)는 개발과 운영을 결합하여 소프트웨어 개발, 테스트, 배포, 운영을 자동화하고 최적화하는 접근 방식이다.
기존에는 개발팀과 운영팀이 분리되어 있어서 새로운 기능을 배포할 때 마다 협업 문제나 운영상의 장애가 많았다. 이를 해결하기 위해 자동화된 프로세스와 협업도구를 사용하여 개발부터 배포까지 빠르게 진행할 수 있도록 도와주는게 데브옵스 이다.
데브옵스의 핵심 목표
- 소프트웨어 배포 속도 향상 - 개발한 기능을 빠르게 배포
- 안정적인 운영 유지 - 장애 발생 시 신속한 복구
- 자동화된 테스트 및 배포 - 사람의 개입 최소화
- 팀 간 협업 강화 - 개발팀과 운영팀이 같은 목표를 공유
2. CI / CD
CI/CD를 활용하면 코드를 빠르고 안정적으로 배포할 수 있다. (데브옵스 실현할 기술)
- 버그를 조기에 발견 → 코드 병합할 때마다 자동 테스트
- 배포 자동화 → 개발자가 실수할 확률 줄임
- 빠른 피드백 → 새로운 기능을 더 빠르게 사용자에게 제공
- 효율적인 협업 → 개발팀과 운영팀 간의 의사소통 문제 해결
CI(Continuous Integration, 지속적 통합)
- 코드 변경 사항을 공유 저장소(Git 등) 자주 병합하여 자동으로 빌드 및 테스트 수행
- 충돌(Conflict) 방지 및 코드 품질 유지
- ex )
1. 개발자가 새로운 기능을 개발하고 코드를 Git에 Push
2. CI 서버(GitHub Actions, Jenkins 등)가 자동으로 코드 빌드 및 테스트 실행
3. 테스트가 통과하면 코드가 저장소에 반영됨 (실패하면 개발자가 수정)
CD(Continuous Delivery vs. Continuous Deployment)
| 개념 | 배포 자동화 수준 | 사람의 개입 여부 |
|---|---|---|
| Continuous Delivery | 테스트 환경까지 자동 배포 | 운영 서버 배포는 사람이 결정 |
| Continuous Deployment | 운영 서버까지 자동 배포 | 사람이 개입하지 않음 |
-
GitOps
GitOps는 애플리케이션 코드뿐만 아니라 인프라, 네트워크 설정, 그리고 CI/CD 파이프라인까지 모든 구성 요소를 Git에서 관리하는 방식이다. 일반적으로 개발자들은 애플리케이션 코드를 Git으로 관리하지만, 인프라 환경과 네트워크 설정, 배포 과정까지 Git에서 관리할 수 있는 이유는 쿠버네티스(Kubernetes) 덕분이다. -
왜 GitOps에서 Git이 중요한가?
GitOps에서는 Git을 단순한 코드 저장소가 아니라, 시스템의 모든 상태를 정의하는 중앙 관리 도구로 사용한다. 즉, Git에 저장된 파일(코드, 설정 파일 등)이 곧 운영 환경의 기준(state) 이 된다. 운영 환경에서 변경이 필요하면, 직접 서버를 수정하는 것이 아니라 Git에 변경 사항을 반영하고 이를 자동으로 적용한다.
-
GitOps가 가능한 이유
쿠버네티스에서는 모든 환경(애플리케이션, 인프라, 네트워크 설정 등)을 YAML 파일로 선언할 수 있다. 이 파일을 Git에 저장하면, 쿠버네티스가 자동으로 이를 반영하여 배포하고 인프라를 구성한다.
-
GitOps를 사용하려면?
GitOps를 구현하려면 두 가지 조건이 필요하다.
1. Git을 활용한 형상 관리: 모든 설정을 Git에 저장하고 변경 사항을 Git에서 추적해야 한다.
2. 선언형(Declarative) 구성 방식: 시스템의 상태를 직접 명령하는 것이 아니라, "이렇게 되어 있어야 한다"는 형태로 선언해야 한다. (예: "서버 3대를 유지해라"라고 선언하면, 쿠버네티스가 자동으로 이를 맞춘다.쿠버네티스는 이러한 선언형 방식을 지원하므로 GitOps를 쉽게 적용할 수 있다. 그러나 쿠버네티스 환경이 아니라면 GitOps를 구현하기 어려운 이유도 바로 선언형 방식이 필수적이기 때문이다.
GitOps를 활용하면 운영 자동화, 일관성 유지, 변경 추적이 가능해진다.
3. 마이크로서비스 아키텍처 (MSA)
모놀리식 vs. 마이크로서비스
| 항목 | 모놀리식 아키텍처 | 마이크로서비스 아키텍처 |
|---|---|---|
| 구조 | 하나의 거대한 애플리케이션 | 독립적인 서비스들의 집합 |
| 배포 방식 | 전체 코드 재배포 | 개별 서비스(MSA)만 배포 가능 |
| 유지보수 | 코드 수정 시 전체 시스템 영향 | 독립적인 서비스 수정 가능 |
- 컴퓨팅 파워를 많이 필요로 하는 것들은 MS로 안가는 경우도 있다. MS는 지속적으로 동작하는 거지만 모놀리식은 한번 동작하는거니깐 계속 동작 안해도 되는 것들은 굳이 MS할 필요 없다고 한다.
4. 컨테이너 기술
컨테이너는 애플리케이션 실행에 필요한 모든 요소를 패키징하여 어디서든 실행할 수 있도록 만들어 준다.
가상 머신(VM) vs. 컨테이너
| 항목 | 가상 머신(VM) | 컨테이너 |
|---|---|---|
| 운영체제 | 각 VM마다 개별 OS 포함 | 컨테이너는 호스트 OS 공유 |
| 자원 효율성 | 무겁고 자원 소비 많음 | 가볍고 빠른 실행 가능 |
| 배포 속도 | 느림 | 빠름 |
⇒ 즉, 가상머신은 하나하나가 독립된 서버라면, 컨테이너는 애플리케이션이 중심인데 이 app을 실행시키기 위해 필요한 모든 요소들을 패키징 해놓은 것이다.
Dockerk Engine에서 호환되는 컨테이너로 만든 거면 아무데나 꽂아도 다 돌아간다.
5. 쿠버네티스(Kubernetes)
쿠버네티스는 컨테이너 기반 애플리케이션의 배포, 확장, 관리를 자동화하는 컨테이너 오케스트레이션 도구이다.
늘어나는 컨테이너를 효과적으로 운영하려면 여러 서버에서 실행(호환 관리), 배포, 회수 등을 자동화로 관리하는 과정이 필요하다. 이를 쿠버네티스가 해주는 것이다.
쿠버네티스의 주요 기능
- 자동 배포 및 스케일링
- 장애 발생 시 자동 복구
- 로드 밸런싱 지원 및 자원 사용 최적화
⇒ 컨테이너를 실행 한다는게 어떤 의미? : 컨테이너를 여러 서버에 보내서 실행시키는 것
⇒ 컨테이너를 어디에 누가 보내고, 회수하고, … 누가 관리? → 컨테이너 오케스트레이션 : 컨테이너를 관리하는 것
⇒ 컨테이너 오케스트레이션을 해주는 가장 대표적인 것이 “쿠버네티스”이다.
