컨테이너 오케스트레이션의 등장은 서버의 상태를 관리하기 위한 노력이다.여기서 서버(Server)는 서비스를 제공하는 컴퓨터나, 소프트웨어이다.
만약에, 본인의 컴퓨터 환경이 바뀌거나, OS가 변경이 되면 아무리 문서화를 잘 하여도 서버를 관리하는 것이 어렵다.
예를 들어서, 기존 설치 프로그램과 충돌이 난다던가, 하나의 서버에서 다른 프로그램 버전을 이용해야 한다면? 매우 큰 문제가 발생할 수 있다.
따라서, 예전에는 CHEF, Puppt과 같은 관리 도구로, 서버의 상태를 확인하고 설치되지 않은 프로그램 혹은 설정이 있으면 서버에 설치를 도와주는 도구가 존재하였다.
또 초기의 해결 방법은 가상 머신(Virtual Machine, VM)이다. 가상 머신 지금도 여전히 OS에 리눅스나 다른 운영체제를 설치할 때 많이 활용한다. 이 가상 머신에는 하나의 프로그램만 설치되어 있기 때문에 관리하기도 쉽다.
하지만 이러한 VM의 문제는 요즘의 클라우드 환경과 맞지 않는 경우도 있고, 특정 가상 머신 제공 벤더에(Oracle etc)에 종속이 될 수 있다.
이때, 도커(Docker)가 등장하게 된다. 도커를 통해 모든 실행환경을 컨테이너로 변경하게 되고, 도커만 설치가 되어 있으면 어디서든 작동하고 ,VM처럼 느리거나 그러지 않고 효율적이다. 즉, 서버 관리자의 복잡함을 해결해주는 좋은 기술이다.
컨테이너의 특징
- 가상머신과 비교하여 컨테이너 생성이 쉽고 효율적
- 컨테이너 이미지를 이용한 배포와 롤백이 간단
- 언어나 프레임워크에 상관없이 애플리케이션을 동일한 방식으로 관리
- 개발, 테스팅, 운영 환경은 물론 로컬 피시와 클라우드까지 동일환 환경을 구축
(전체 서버 환경을 컨테이너가 가지고 있기 때문에, 특정 운영이나 Staging에서만 작동하거나 그러한 문제점이 존재하지 않는다)
- 컨테이너는 오픈소스고, 특정 클라우드 벤더에 종속적이지 않음
이러한 컨테이너의 특징에 따라 모든 소프트웨어가 컨테이너화되기 시작한다. 예를 들어, MySQL도 기존에 설치해서 썼다고 한다면, MySQL 컨테이너를 활용하고, redis, jenkins 등 심지어 WordPress까지...
개발자는 모든 것을 Docker의 컨테이너로 관리하고 싶은 욕구가 생긴다. 따라서, 아래와 같은 프로세스로 개발이 수행되기 시작한다.
Develop - Build - Ship - Run!
개발자가 코드를 작성하면 빌드, 여기서 빌드는 도커 이미지를 만드는 거고, 쉽은 만든 이미지를 도커 허브나 저장소에 저장하고 Run은 도커 이미지를 실행하는 것이다.
이렇게 개발이 정형화되기 시작하고 이전에는 어떤 언어를 쓰는지, 어떤 프레임워크를 쓰지는지에 따라서 방법이 달랐고 관리하기가 힘들었다면, 도커를 도입하고나서 도커 이미지로 만들기만 하면 저장하면서 사용하는 방식이 표준화가 되었다.
하지만 도커의 컨테이너가 수십개, 혹은 수백개가 되면 어떻게 될까? 많은 컨테이너를 관리하는 것은 여전히 어렵다. 따라서, 편안한 관리 방안을 찾기 위해 노력해왔다. 아래의 예시를 보자.
1. Docker에서 배포는 어떻게 할까?
docker stop app && docker run ...docker-server-1
docker stop app && docker run ...docker-server-2
docker stop app && docker run ...docker-server-3
이렇게 docker server 1,2,3에 접속해서 IP도 관리해야하고, 실행할때 하나하나 접속해서 실행해야 한다.
또한, 이러한 많은 서버들을 모니터링해야 할 수도 있으며, 버전업을 하고 싶은데 docker server에 하나하나 접속해서 버전업을 시켜야 한다. 심지어, 롤백을 한다면 다시 하나하나 들어가서 해야 한다. == 귀찮다.
2. 서비스 검색
프로그램이(PROXY, WEB, WEB2)이 있다. 초기에는 PROXY에서 192.168.0.100을 바라보라고 하지만, WEB2로 분산하고 싶다.. 이때, 단순하게 중앙에 LoadBalancer를 통해서 부하분산을 해주어, WEB을 분산하여 검색을 할 수 있다.
하지만 관리하는 서비스가 굉장히 많아 지고, App 끼리의 통신이 중요한 요즘 그럴 때마다 Loadbalancer를 설치해주고, IP가 바뀔 때마다 업데이트 해주고 하는 것이 귀찮다.
3. 서비스 노출
Public 영역에서 프록시 서버를 두고 들어오는 host에 따라서, Private 내부 서버를 연결하는 경우가 있다. 예를 들어, 위 그림 처럼 blog 서버면 2번으로, test 서버면 1번으로 연결하면 된다.
하지만 내부적으로 도메인 하나 새로 등록했으니, 저 콘테이너로 연결해주면 되는데.. nginx conf 파일 들어가서 추가해주는게 귀찮다.
4. 서비스 이상, 부하 모니터링은?
12개의 콘테이너를 관리하다가, 5개의 콘테이너가 죽으면 어떻게 할까?
컨테이너 접속해서 log보고, 해결하는데 너무 귀찮다.
즉, 개발자의 귀찮음을 해결하는 자동화하는 방법이 필요한 것이다. 컨테이너 기술 자체는 좋은데, 이 많은 콘테이너를 관리한느 기술이 필요한 것이고 이러한 기술이 등장했는데, 이것이 바로 "콘테이너 오케스트레이션"이라는 기술이다.
Container Orchestration
서버 관리자가 하는 일들을 대신해주는 프로그램을 만드는 것이다. 기존에 서버 관리자가 하나하나 하는 일들을 Orchestration이 대신 처리해주시는 것이다.
Contatiner Orchestration의 특징
중앙제어(master-node)
노드가 매우 많아 지면, 각 노드에 리소스를 사람이 알고 있기에는 한계가 있다.
따라서, node 들을 cluster 라는 단위로 묶어서 관리한다. 클러스터 하나에 접속해서 명령어를 하나씩 주기가 어렵기 때문에 Master Node를 두고, 각 node에 명령어를 주게 된다.
또한, 각 Node 사이에서 네트워킹이 잘 되어야 하며, Node의 개수가 아무리 많아도 이를 쉽게 관리할 수 있어야 한다.
상태관리(State)
App1, App2, App3 처럼 이미지가 3개인 상황에서 하나가 문제가 생기면, 죽이고 하나를 새로 띄워주는 것
배포관리(Scheduling)
App1은 무거운 서버이고, App2는 여유로운 서버이다. 이것을 자동으로 체크해서, 새로운 앱을 띄울 때 그 서버에 띄워주거나, 혹은 여유 있는 서버가 없으면 서버 하나 새로 띄워주는 것.
배포 버전관리(Rollout-Rollback)
version : "v2" 로 하면 v2 로 모두 바뀌고, v1 으로 하면 모두 바뀌게 중앙에서 관리
서비스 등록 및 조회(Service Discovery)
Web이 x.x.x.100 에 뜨면 master node 에 등록되고, 101에 하나 더 서비스가 뜨면, 저장소에 저장이 됨. 여기서 Proxy 서버가 해당 저장소를 계속해서 관찰하다가, 설정이 변경되거나 프로세스를 재시작 해준다. 이렇게 되면 관리자가 하나하나 IP를 바꿀 필요 없이 프로그램이 관리할 수 있음
볼륨 스토리지(Volume)
1번 노드는 NFS 에 연결, 2번 노드는 AWS EBS 에 연결, 3번 노드는 GCE PD를 연결 할 수 있는데, 이러한 연결 방식을 설정으로 관리해줄 수 있음
이러한 컨테이너 오케스트레이션은 하나의 개념이지, 어떤 도구를 말하는 것이 아님. 현재는 다양한 컨테이너 관리 도구에서 중에서 k8s를 표준처럼 활용함
출처 : https://sretips.com.br/docker/docker-on-practice/
'블로그 > 데이터 엔지니어링' 카테고리의 다른 글
| [K8s] Pod & ReplicaSet & Deployment (0) | 2024.01.18 |
|---|---|
| [K8s] 쿠버네티스 알아보기 (0) | 2024.01.17 |
| [K8s] 왜 쿠버네티스일까? (0) | 2024.01.17 |
| GA4와 Bigquery로 행동 로그 쌓기 삽질하며 배운 점 (0) | 2022.05.22 |
