Part 1. 개발자를 위한 Kubernetes 입문
Part 1. Ch 1. Kubernetes의 등장 배경
Ch 1. Kubernetes의 등장 배경
- Ch 1. Kubernetes의 등장 배경
애플리케이션 개발환경의 변화와 Kubernetes의 등장
애플리케이션 개발환경의 변화와 Kubernetes의 등장
오늘날 우리가 사용하는 대부분의 소프트웨어는 하나의 애플리케이션 형태로 동작한다. 모바일 앱부터 웹 서비스, 백엔드 서버까지 모두 특정 목적을 수행하기 위해 실행되는 프로그램이다.
최근 몇 년 동안 애플리케이션을 개발하고 운영하는 환경은 매우 빠르게 변화해왔다. 물리 서버에서 직접 실행되던 시대를 지나 가상화와 클라우드를 거쳐 현재는 컨테이너와 Kubernetes가 사실상의 표준 환경으로 자리 잡게 되었다.
이번 글에서는 이러한 변화 과정을 살펴보고 Kubernetes가 등장하게 된 배경을 정리해본다.
애플리케이션이란?
애플리케이션(Application)은 특정 목적을 수행하기 위해 실행되는 컴퓨터 프로그램을 의미한다.
대표적인 예시는 다음과 같다.
- 모바일 애플리케이션
- 프론트엔드 애플리케이션
- 백엔드 애플리케이션
- 데스크톱 프로그램
- 배치 프로그램
최근에는 하나의 거대한 애플리케이션보다는 여러 개의 애플리케이션이 서로 통신하면서 서비스를 구성하는 방식이 일반적이다.
애플리케이션의 개발 및 배포 과정
애플리케이션은 일반적으로 다음 과정을 거쳐 사용자에게 서비스된다.
1. 개발(Development)
개발자는 요구사항을 분석하고 애플리케이션의 동작에 필요한 소스코드를 작성한다.
- Java
- Kotlin
- Python
- JavaScript
- Go
등의 언어를 이용해 비즈니스 로직을 구현한다.
2. 빌드(Build)
작성한 소스코드와 라이브러리를 하나의 실행 가능한 형태로 만든다.
예를 들어 Spring Boot에서는 다음과 같은 결과물이 생성된다.
my-app.jar
빌드 과정에서는 다음 작업들이 수행된다.
- 소스코드 컴파일
- 라이브러리 의존성 포함
- 실행 파일 생성
- 테스트 수행
3. 배포(Deploy)
빌드된 결과물을 실제 실행 환경으로 전달한다.
과거에는 직접 서버에 파일을 복사했지만 현재는 주로 다음 방식을 사용한다.
- Docker Registry
- Artifact Repository
- CI/CD Pipeline
4. 실행(Run)
배포된 애플리케이션이 실제 서버에서 실행된다.
실행 중에는 다음 요소들이 함께 동작한다.
- 운영체제
- 네트워크
- 데이터베이스
- 로그 시스템
- 모니터링 시스템
애플리케이션 환경
애플리케이션 환경은 크게 두 가지로 구분할 수 있다.
개발 환경
개발자가 애플리케이션을 작성하고 테스트하는 환경이다.
포함되는 요소는 다음과 같다.
- 개발자 PC
- IntelliJ
- VSCode
- Gradle
- Maven
- 디버깅 도구
- 테스트 도구
실행 환경
실제 서비스가 동작하는 환경이다.
포함되는 요소는 다음과 같다.
- Linux 서버
- 가상 머신
- 클라우드 인프라
- 데이터베이스
- 로그 시스템
- 모니터링 시스템
개발 환경과 실행 환경이 다를수록 “내 컴퓨터에서는 되는데요?” 문제가 발생할 가능성이 높아진다.
백엔드 실행 환경의 변화
백엔드 애플리케이션의 실행 환경은 크게 네 단계로 발전해왔다.
1. 로컬 애플리케이션 시대
초기의 프로그램은 네트워크 연결 없이 로컬 PC에서 실행되었다.
프로그램
↓
파일
↓
로컬 PC
대부분의 데이터는 파일 형태로 저장되었다.
2. 물리 서버 시대
인터넷 서비스가 등장하면서 별도의 서버가 필요해졌다.
개발 PC
↓
FTP
↓
물리 서버
특징
- 서버 구매 필요
- 직접 운영
- 확장 어려움
- 장애 대응 어려움
3. 가상화와 클라우드
VM 기술과 퍼블릭 클라우드가 등장했다.
물리 서버
↓
가상 머신
↓
애플리케이션
대표적인 서비스
- AWS EC2
- Azure VM
- Google Compute Engine
장점
- 빠른 서버 생성
- 자원 확장 가능
- 비용 절감
하지만 운영체제까지 포함된 VM은 여전히 무겁다는 문제가 있었다.
컨테이너의 등장
컨테이너는 운영체제 레벨의 가상화를 제공한다.
Application
↓
Container
↓
Host OS
VM과 비교하면 다음과 같은 차이가 있다.
| VM | Container |
|---|---|
| OS 포함 | OS 공유 |
| 무거움 | 가벼움 |
| 부팅 수분 | 실행 수초 |
| 자원 사용 많음 | 자원 효율 높음 |
컨테이너의 장점
빠른 실행
운영체제를 새로 부팅하지 않는다.
자원 효율
CPU와 메모리를 효율적으로 사용할 수 있다.
환경 일관성
개발 환경과 운영 환경을 동일하게 만들 수 있다.
쉬운 배포
이미지 하나만 전달하면 된다.
Docker의 등장
리눅스 컨테이너 기술 자체는 오래전부터 존재했다.
하지만 이를 대중화한 것이 Docker이다.
Docker는 다음 기능을 제공했다.
- 이미지 빌드
- 이미지 배포
- 컨테이너 실행
- 컨테이너 관리
Application
↓
Docker Image
↓
Docker Container
이후 대부분의 서버 애플리케이션은 컨테이너 형태로 배포되기 시작했다.
컨테이너의 한계
컨테이너가 많아지면서 새로운 문제가 발생했다.
예를 들어 서버가 100대라면 다음 문제들이 생긴다.
- 어느 서버에 배포할 것인가?
- 장애가 발생하면 누가 재시작할 것인가?
- 서버가 부족하면 어떻게 확장할 것인가?
- 업데이트는 어떻게 할 것인가?
- 트래픽은 어떻게 분산할 것인가?
수십, 수백 개의 컨테이너를 사람이 직접 관리하는 것은 불가능했다.
Kubernetes의 등장
구글은 오래전부터 Borg라는 내부 오케스트레이션 시스템을 사용하고 있었다.
Container
↓
Borg
↓
Google Datacenter
구글은 이 경험을 바탕으로 Kubernetes를 공개했다.
Kubernetes의 역사
- 2014년 공개
- 2015년 정식 출시
- CNCF 프로젝트 채택
- 현재 사실상의 표준 플랫폼
Kubernetes가 해결하는 문제
Kubernetes는 컨테이너 운영을 자동화한다.
대표적인 기능은 다음과 같다.
- 자동 배포
- 자동 복구
- 자동 스케일링
- 서비스 디스커버리
- 로드밸런싱
- 롤링 업데이트
- 설정 관리
- 스토리지 관리
Kubernetes의 역할
사용자
↓
Kubernetes
↓
Container
↓
Server
개발자는 애플리케이션만 작성한다.
Kubernetes가 다음 작업을 자동으로 수행한다.
- 어떤 서버에 배치할지 결정
- 장애 발생 시 재시작
- 트래픽 분산
- 버전 업데이트
- 스케일링
왜 Kubernetes가 표준이 되었을까?
Kubernetes가 빠르게 확산된 이유는 다음과 같다.
클라우드 독립성
- AWS
- Azure
- GCP
- 온프레미스
모두 동일하게 사용할 수 있다.
컨테이너 중심 설계
Docker와 매우 잘 결합된다.
자동화
운영 작업의 상당 부분을 자동화할 수 있다.
확장성
수십 개부터 수천 개의 서버까지 관리 가능하다.
정리
- 애플리케이션은 개발 → 빌드 → 배포 → 실행 과정을 거친다.
- 실행 환경은 물리 서버 → 가상 머신 → 컨테이너로 발전해왔다.
- Docker는 컨테이너 기술을 대중화했다.
- 컨테이너 운영 문제가 등장하면서 Kubernetes가 탄생했다.
- Kubernetes는 컨테이너의 배포와 운영을 자동화하는 플랫폼이다.
- 현재 Kubernetes는 클라우드 네이티브 환경의 사실상 표준으로 자리잡고 있다.
물리 서버
↓
가상 머신
↓
컨테이너
↓
Kubernetes
Kubernetes는 단순한 배포 도구가 아니라 현대적인 애플리케이션 실행 환경 그 자체라고 볼 수 있다.
