도커 및 컨테이너 오케스트레이션 도구를 사용해야하는 이유 1편

"도커 런타임 환경과 도커 스웜 클러스터 , 쿠버네티스 k8s 의 컨테이너 오케스트레이션 도구를 사용해야 하는 이유" 라는 주제를 가지고 

도커 , 쿠버네티스의 원론적인 설명보다는  IT환경 변화를 통해 도커, 컨테이너,  컨테이너 오케스트레이션 도구를 왜 써야하는지에 대해 나의 생각과 자료를 정리한 글이다. 

 

"도커는 왜 써야 할까?"

"도커 스웜 클러스터 , 쿠버네티스의 k8s 등 컨테이너 오케스트레이션 도구를 왜 써야 할까? " 

 

 

 

IT 환경은 클라이언트/서버 -> 가상화 -> 클라우드 -> 컨테이너로 변화해왔다.  

비즈니스 환경에서 빠르고 혁신적인 기술을 요구하게 되고 그러면서 컨테이너 환경이 등장했다.

컨테이너는  가상머신과 유사하지만 컨테이너에는 자체 파일 시스템, CPU 공유, 메모리, 프로세스 공간 등이 있다. 기본 인프라에서 분리되기 때문에 클라우드 및 OS 배포 전반에 걸쳐 이식 가능하다 

컨테이너는 애플리게이션 (경량 리눅스 운영체제 OS) 이다. OS 레벨 가상화는 VM과 비교해봤을 때 이식성, 유연성이 뛰어나고 특정 호스트 컴퓨터에 휠씬 더 많은 컨테이너를 보유할 수 있다. 적은 수의 호스트에 더 많은 애플리케이션이 있다는 것은 구축한 데이터센터가 더 효율적이고 비용 효율적임을 의미한다. 일반적인 가상화의 경우 하이퍼바이저 위에 가상 머신을 올려 사용하지만, 컨테이너 환경에서는 도커와 같은 컨테이너 런타임 위에 사용한다.

* 도커:  컨테이너디 위에 설치되는 데몬이다. 도커는 컨테이너를 생성하고 관리하는 모든 기능을 가지고 있다. 

 

이 둘의 차이점으로는 일반적인 가상화 환경에서는 하드웨어 수준에서 가상화가 되지만, 컨테이너는 운영체제수준에서 가상화가 된다. 

자원을 더 적게 사용하고 하나의 시스템에서 더 많은 애플리케이션을 구동할 수있다. 이러한 컨테이너를 계속 생성하고 관리하기 위해 컨테이너 오케스트레이션을 사용하여 효과적으로 컨테이너를 관리한다.

 

 

"도커를 왜 사용해야 할까?"

 

이전에는 서버를 구매해서 IDC에 자바설치, 특정 모듈설치, 어플리케이션을 올려서 동작시키면 L4 스위치, 아파치, 엔진엑스등 올려서 사용하였다. 

만약 서버에 화재가 일어났을 경우 어떻게 될까?

당연히 폐기하고 다른 곳으로 옮길 것이다. 예를 들어 아파치가 다른 곳에 있어서 연결하고자 한다면 데이터베이스 접속이 안될 것이다.  

이유는 아무나 데이터베이스 접속을 하지 못하니 방화벽을 열어야 할 것이고, 동작을 확인하면 빌드 확인, 로그, 파일 커미션, 파일 위치 등 옮기는 시간은 평균 최소.. 1주일 이상 걸린다. 당연히 화재가 났으니 이중화를 해야 한다고 할 것이고 시간은 더 걸리며 이것은 was서버만 죽었을 경우이다. 

 

또 다른 문제를 예를 들어보면 ..

트랜잭션이 들어왔을때 20만건이 들어온다고 가정하면 was에서 막아도 DB에서 깨진다. 깨지는 순간 복구 불가, 서비스 다운이 된다. 

방안은 was가 버티는 상태에서 리플리카셋을 나눠놓는다는 방법이 있을 것이고, 제일 좋은 건 데이터 베이스 클러스터이다. 

구조화된 데이터베이스 mysal은 비용이 많이 비싸고, 포스트 그릴이 대안이 될 수 있으며 이것마저도 완벽한 클러스터 제공을 하기에는 문제가 있다. 

플랫한 데이터 베이스는 엘라스틱 서치가 버틸 수 있다. 

이 이야기를 하는 이유는 이 모든 것을 도커가 없으면 할 수 없다. radius 설치할때 radius를 만든 사람이 제공하는 것을 적절하게 가져와서 워커 노드에 적재시켜서 사용할 수 있는 구조를 가지고 있으면 되는것 아닌가?  도커 허브에서 오피셜로 되있는것은 문제가 생겼을때 제공을 해준다. 도커를 사용하게 되면 그 기능을 만든 사람 것을 가져와서 구조에 알맞게 사용을 하면 된다.

 

두 가지의 간접적인 예시를 들면서 도커를 왜 사용해야하는지에 대해 충분한 설명이 되었을 거라 생각한다. 

 

 

"왜 도커 스웜, 쿠버네티스를 사용해야 할까 ?"

 컨테이너를 사용하여 런타임 도구로 도커를 결정하였다고 하면, 오케스트레이션 도구로 어떤 것을 사용할 필요가 있을까?

실제 도커스웜과 쿠버네티스를 직접 구축과 사용을 하고 있기 때문에 이 문제에 대해 왜 써야하는지에 대한 고찰을 할 필요성이 있다고 생각이 들었다. 

컨테이너 오케스트레이션 도구가 필요한 이유는 컨테이너의 수가 많아지게 되면 관리와 운영에 어려움이 따르게 된다.

각각 독립적으로 배치된 컨테이너를 연결하고 관리하고 확장하면서 이 요소들 전체가 하나로 실행되도록 할 수 있어야 한다. 이렇게 다수의 컨테이너 실행을 관리하고 조율하는 것을 컨테이너 오케스트레이션이라고 부른다.

 

컨테이너 오케스트레이션 도구로는  쿠버네티스 ,  도커 스웜클러스터, 아파치 메소스가 있다.

IBM이 레드햇을 인수하고, 가상화 시대를 주도한 VM웨어가 계열사인 피보탈 인수에 나선 것도 쿠버네티스 주도권 확보 목적이였다. 현재 주요 클라우드 업체들도 쿠버네티스를 서비스 형태로 제공하고 있다.

쿠버네티스와 도커 스웜클러스터에서 우위 싸움에서 쿠버네티스가 승자가 되었으며,  도커 스웜은 쿠버네티스에 합쳐지게 되었다. 도커 스웜 마스터노드는 최종 인수되었다고 알고 있다. 또한 버전도 더 이상 나오지 않으며 현재 버전이 최종버전이다. ( 최종 버전 = 안정적인 버전 )  그래서 현재 문서만 보아도 쿠버네티스에 대한 문서들은 굉장히 많지만 도커 스웜에 대한 문서들은 거의 없다. 그렇지만 도커 스웜 클러스터는 중견기업, 대기업까지도 충분히 사용할 수 있는 오케스트레이션 도구이다. 

 

 

 

Docker Swarm은 자체 인프라를 구축하고 실행하는 경우 일반적으로 Kubernetes보다 더 적은 설정 및 구성이 필요하다. 또 한번 구축을 해놓으면 별다른 관리를 필요로 하지 않는다. 개인적으로 쿠버네티스와 비교했을 때 가장 장점이라 생각한다. 선언적 YAML 파일을 통한 애플리케이션 배포, 원하는 상태로 서비스 자동 확장, 클러스터 내 컨테이너 간 부하 분산, 서비스 전반에 걸친 보안 및 액세스 제어와 같이 Kubernetes와 동일한 장점을 제공한다. 실행 중인 워크로드가 적거나, 자체 인프라를 관리해야 해도 괜찮거나 Kubernetes가 제공하는 특정 기능이 필요하지 않은 경우 Docker Swarm을 선택하는 것이 좋을 수 있다.

 

Kubernetes는 처음에는 설정이 더 복잡하지만 보다 뛰어난 유연성과 기능을 제공한다. 또한 활발한 오픈 소스 커뮤니티의 광범위한 지원을 받고 있다. Kubernetes는 즉시 사용 가능한 여러 배포 전략을 지원하고, 네트워크 수신을 관리할 수 있으며, 컨테이너에 대한 관찰 기능을 바로 제공한다. 모든 주요 클라우드 공급업체는 자동 확장과 같은 클라우드 네이티브 기능을 훨씬 쉽게 시작하고 활용할 수 있는 관리형 Kubernetes 서비스를 제공한다. 많은 워크로드를 실행 중이고 클라우드 네이티브 상호 운용성이 필요하며 조직에 많은 팀이 있어 서비스 격리가 더 많이 필요한 경우 Kubernetes를 플랫폼으로 고려하는 것이 좋다.

 

 

 

* 2편에서 swarm 과 k8s 의 장단점을 좀 더 깊이 다루도록 하겠다.