[Docker & Kubernetes] 1. 도대체 Docker는 뭘 하는 녀석일까?

IT 관련 글을 상당히 오랜만에 쓰는 듯 하다. 기술과 연관없는 근황 관련 글(이라고 해봐야 2개 밖에 없다)을 제외하면 3월 10일이 마지막 기술 블로그 포스팅이었으니 무려 두 달 가까이 지난 시점이다. 다시 굳어져버린 손을 풀며 블로그 포스팅을 시작하려하는데, 이미 있는 주제들도 계획대로 못 끝낸 상태에서 조금 색다른 주제가 추가되었다.

Docker와 Kubernetes. IT 업종에 종사하거나, 필자처럼 보안업계에 일했던 분들이라면 관련이 없더라도 한 번 이상은 지나가면서라도 들어본 단어들일 것이다. 최근에 클라우드 환경으로 기업 서비스가 많이 이전되면서 이 Docker와 Kubernetes 또한 수요가 증가하고 있다. 필자 역시 새로 옮긴 회사가 클라우드도 관여가 되어 있어서 출근 전부터 이들에 대해 검색을 진행했다(요즘 일이 아니면 글을 쓸 생각도 안하는게 초심을 잃은 건가, 반성해야겠다).

그런데, Docker와 Kubernetes는 도대체 뭘 하는 녀석들이길래 클라우드 시대에 이렇게 각광을 받고 있는 것일까? 필자는 IT 비전공자이다보니 이들이 나타난 배경에 대해 이해는 하고 넘어가야겠다는 생각이 강했다. 왜 쓰는지 모르면 아무리 다루어도 마음에 와 닿지 않을테니 말이다.

Docker와 Kubernetes에 대해 설명한 글이 많이 있지만, 이 배경에 대해 설명을 해 놓은 포스팅은 많지 않다. 따라서 이번 포스팅에서는 필자 나름대로 Docker의 탄생 배경과 기반 기술에 대해 조금 길게 포스팅을 해보려 한다. 물론, 글 내용 중에는 맞지 않는 내용도 있을 수 있다. 다른 훌륭하신 분들의 블로그 글과 교차검증하면서 필자의 글을 봐 주시면 좋을 듯 하다.



1. OS 가상화의 등장 배경

뜬금없이 가상화라는 말이 나온 것에 대해 의아하신 분들이 있을 듯 한데, Docker 배경에 대해 이해하려면 이 가상화의 탄생 배경 역시 알고 있으면 도움이 된다. 왜냐하면 Docker도 가상화 플랫폼이기 때문이다.

기업에서 자신들의 홈페이지를 운영하기 위한 서버를 한 대 구매했다고 가정해보자. OS만 설치된 상태라면, 서버의 아키텍쳐는 간략히 아래와 같은 모양일 것이다.

홈페이지, 즉 웹 서비스를 구동하기 위해서는 웹 서비스 관련 어플리케이션(Apache, Nginx, Django 등)을 설치해야 한다. 하나 올려보자.

OS 위에 설치된 웹 서비스는 이제 Hardware의 자원(CPU, Memory, Disk 등)을 자유로이 쓸 수 있게 된다. 만약 다른 서비스를 이 서버 위에 추가로 설치한다고 해보자. 예를 들어 메일 관련 서비스(SMTP)를 설치한다고 말이다.

이제 하나의 서버에서 웹, SMTP 서비스가 동시에 구동되는 상태다. 마찬가지로 SMTP 서비스 역시 웹서비스와 마찬가지로 OS를 통해 Hardware의 자원을 사용하게 된다. 즉, 웹과 SMTP는 Hardware 자원을 공유한다고 보면 된다.

이렇게 서버를 운영하던 중, 회사가 대박이 나서 홈페이지로 사람들이 무진장 많이 몰려온다고 가정해보자. 그럼 웹 페이지는 클라이언트의 수많은 요청을 처리하느라 Hardware 자원을 과다하게 소모하게 되는데, 이로 인해 SMTP는 자신이 반드시 필요로하는 Hardware 자원을 쓰지 못해 동작에 문제가 생기게 된다.(김대리, 메일 보냈는데 못받았어??)

이러한 일을 방지하기 위해 대부분의 기업은 서버 구매 시, 그 서버의 기능을 하나 이상 추가하지 않는다. 서버 3대를 구매했다고 하면 A는 웹 서비스 용도, B는 메일 서버 용도, C는 로그 서버 용도 등으로 지정해서 사용한다. 그런데 서버 하나에 하나의 서비스만 구동하도록 만드는 것은 해당 서비스가 많이 사용된다면 큰 문제가 되지 않지만 사용되지 않을 경우 컴퓨팅 자원의 극히 일부만 소모하기 때문에 효율성은 매우 떨어지게 된다. 서버 가격이 옛날에 비해 많이 낮아졌다고 하지만 아무리 가격이 싼 제품이라고 해도 몇 백 만원은 줘야 구매할 수 있는 만큼 금전적으로도 소모가 막심할 수 밖에 없다(얼마나 비싼지 필자는 가끔 서버를 ㅅㅂ로 쓴다).

검은 테두리가 Hardware 자원의 총 사용 가능 범위라고 생각해보자.

사용되지 않는 저 서버 자원들을 사용하여 다른 서비스를 제공할 수는 없는 것일까? 그리고 각각의 서비스가 사용할 수 있는 Hardware의 자원을 제한할 수 있는 방법은 없는 것일까? 이것이 가상화가 나타난 배경 중 첫 번째이다.



2. Hyperviser 기술(Hyper-V)

조선어로 하이퍼바이저라고 쓰는 이 기술은 하나의 Hardware 자원을 논리적으로 분할하여 여러 OS를 구동할 수 있도록 한 기술이다. 무슨 말인지 와 닿지 않을텐데, 아래의 아키텍쳐를 보자.

Hyper-V는 두 가지 타입이 존재한다. H/W 위에서 작동하는 타입1과 HostOS 위에서 작동하는 Type2로 말이다.

Hyperviser는 Hardware 또는 Host OS위에서 동작한다. VMware 프로그램이 설치되어 있는 분들이라면 새 OS를 설치하기 전 Memory, Disk, 네트워크 어뎁터 등을 설정하는 부분을 기억할 것이다. 이 값에 따라 Hyper-V는 Hardware 자원을 논리적으로 분리/격리(Isolation)하여 특정 OS가 격리된 자원을 사용할 수 있도록 한다.

VMware에서의 자원 할당 설정. OS 설치 전 진행한다.

참고로 Hyper-V는 두 가지 타입이 존재한다. Type1 또는 Native 또는 Bare Metal라고 불리는 타입은 Hyper-V가 Hardware 위에서 직접 논리적인 자원 분할과 격리를 진행한다. 따라서 Type1 Hyper-V는 하나의 OS에 문제가 발생하더라도 다른 OS의 동작에는 영향이 가지 않는다는 장점이 있다. 단점은 올리고자 하는 OS 수 만큼 라이센스를 구매해야 한다는 점이다. EXSI가 대표적인 Type 1 Hyper-V 제품이다. 사용해보신 분들이라면 위의 내용이 조금 더 쉽게 이해되실것이다.

다른 타입은 Type 2 또는 Host방식이라고 불리는 Hyper-V다. 이 Hyper-V는 기존의 OS(Host OS라고 한다) 위에서 동작하기 때문에 설치한 OS(Guest OS라고 한다)들이 하나의 프로세스처럼 동작한다. 따라서 하나의 OS에 문제가 발생하는 경우 다른 OS도 그 영향이 미치게 된다는 단점이 있다. 장점이라면 Type1과 달리 별도의 라이센스 구매 없이도 자유롭게 사용할 수 있는 제품이 많다는 것이다. Virtual Machine, VMware 등의 제품이 이 타입에 속한다.

이 Hyper-V를 사용하면 자원이 남는 경우 OS를 여러 대 올려 사용하는 것도 가능하다. 하지만 자원 분할/격리 후 OS는 사용자가 별도의 설치 과정을 거쳐야하며, OS 자체의 용량이 꽤 나가는 편이다보니 하나의 서버에 많은 OS를 올릴 수 없다는 문제가 있다. 또한 Type2는 Guest OS에 많은 자원이 할당되는 경우 Host OS의 동작 자체가 눈에 띄게 느려진다는 문제도 있다. 만약 4GB 메모리 노트북을 가지고 있으신 분들이라면 VMware 하나 설치해서 돌려보자. HostOS의 속도가 현저하게 느려지는 것을 확인할 수 있다.



3. LXC(Linux Container)

위의 가상화 배경보다 조금 앞선 시대의 이야기로 잠깐 넘어가보려 한다. 바로 LXC라는 UNIX에 포함되어 있던 기술이다.

LXC는 LinuX Container의 약어다. 이 Linux Container는 Linux OS 위에서 동작하는 프로세스를 격리함으로써 각 프로세스가 독자적인 환경을 가지도록 만드는 기술이다. 다른 말로는 "OS 수준의 가상화"라고도 한다. 앞에서 보았던 Hyper-V는 하드웨어 수준에서 가상화가 일어난 것과 대치된다.

그럼 여기서 의문점이 든다.

"리눅스에는 도대체 무슨 기능이 있길래 Hyper-V 등을 사용하지 않고도 프로세스만을 격리하는 것이 가능한가요?"

아시는 분들은 아시겠지만, Linux는 하드웨어와 사람 사이에서 중재자 역할을 하는 Kernel(커널)이라는 녀석이 존재한다. 이 커널에는 다른 OS에 없는 몇 가지 기술이 있는데, 이 기술로 인해 Linux의 Container 가상화가 가능하게 되었다. 그 배경 기술은 아래와 같다.

- chroot
- namespace
- cgroup


(1) chroot
chroot는 change root의 줄임말이다. 즉 root 디렉토리를 바꾸는 기능이라고 보면 된다. Linux는 chroot라는 이름으로 root 디렉토리를 변경할 수 있도록 명령어를 제공하고 있다.

도대체 무슨 이유 때문에 이 root 디렉토리를 바꾸는 것일까? 여러 이유가 있지만 이 이유를 알아보기 전에 Linux의 파일 시스템을 간략하게 보고 넘어가자.

리눅스에서 pwd 명령어를 쳤다고 가정해보자. 그럼 pwd 명령어 실행을 위해 리눅스의 최상단 폴더인 root(/)를 기준으로 명령어 파일을 찾아 내려오게 된다.

최상위 폴더를 변경한다는 말은, 결국 파일을 찾는 기준 폴더를 변경한다는 말이다. 만약 필자가 /chroot라는 폴더를 만들고 그 폴더를 최상위 폴더로 변경하게 되는 경우, 파일 검색 기준점이 root(/)가 아닌 /chroot가 된다는 말이다.

이제 chroot를 사용하는 경우에 대해 알아보자. 만약 Linux 내에서 개발을 진행할 때, 개발 환경을 새로 구성해야 하는 경우가 있을 수 있다. 이 때문에 OS를 다시 설치하고 환경 설정을 진행하는 것은 시간적으로 매우 비효율적이다. 대신 chroot를 사용하여 개발 환경을 chroot 구역 내에 구성할 수 있다.

혹은 보안의 이유로 chroot를 사용하기도 한다. 만약 일반 사용자가 실수로 root(/) 디렉토리로 접근하여 시스템 구성을 확인하거나 변경할 수도 있는데, 일반 사용자 계정에 대하여 그들의 홈 디렉토리를 최상위 디렉토리로 지정함으로써 인가되지 않은 시스템 접근을 막을 수 있다.

직접 chroot를 사용하여 이해하고 싶으신 분들은 chroot 실습 내용이 포함된 이 포스팅을 참고하자.

chroot는 특정 프로세스를 격리한다는 점에서 가상화와 큰 차이점이 없어보인다. 하지만 chroot의 경우 Hyper-V나 뒤에 설명할 LXC와 달리 하드웨어 자원에 대한 논리적 분배와 격리 기능은 지원하지 않는다. 단순히 파일과 폴더에 대한 접근만 관리할 뿐이다.


(2) namespace
namespace, 축약어로 ns로도 표현하는 이 기능은 하나의 시스템 위에서 프로세스를 격리하고 자원을 프로세스에 분배하는 경량 가상화(lightweight virtualization) 기술이다. Hyper-V 가상화와의 차이점이라면 Hyper-V가 Hardware 자원을 논리적 분리 및 가상화 하는 것과 달리, namespace는 Linux 시스템(커널) 자원을 분리하여 프로세스에 할당한다.

리눅스에서 각 process에 할당된 namespace를 확인할 수 있다. 가장 확인하기 쉬운 1번 프로세스(init, systemd)에 존재하는 namespace에 대해 아래와 같이 확인할 수 있다.

# 명령어: ls -lh /proce/{PID}/ns -> {PID}를 1로 변경하면 1번 프로세스의 namespace를 확인할 수 있다.

ipc, mnt, net 등의 namespace가 프로세스에 필요한 자원을 묶어 격리된 1번 프로세스에 할당하는 것으로 위 결과를 해석할 수 있다.


(3) cgroup

cgroup은 control group의 약자로, 리눅스 kernel의 특징 중 하나다. cgroup은 리눅스의 프로세스에 자원 할당을 제어하는 기능이다. 어떻게보면 namespace와 비슷한데, namespace와 달리 Hardware 자원을 할당한다.


자, 이제 위의 세 가지 기술을 하나로 합쳐보자. 프로세스 격리가 되어 독립적인 환경 구성이 가능하고(chroot), 각 프로세스에 분할된 시스템(커널) 자원 및 Hardware 자원을 제공(namespace, cgroup)한다. 마치 OS 위에서 독립적인 격리 공간에 자원을 배분하는 형태로 일종의 가상화다. 이 세 가지 기술이 합쳐져 나온 것이 바로 LXC, OS 수준의 경량 가상화다.

경량 가상화는 OS 위에서 서비스(어플리케이션) 구동에 필요한 자원만 별도로 격리하여 동작하기 때문에 Hyper-V와 달리 OS를 설치할 필요도 없고, 실행을 함에 있어서도 Hyper-V에 비해 매우 가볍다. 따라서 LXC를 사용하면 하나의 서버에서 여러 서비스를 제공하는 것도 가능해진다.



4. Docker는 왜 등장했는가.

이제 오늘 포스팅의 목적지인 Docker에 대해 이야기 할 차례다.

LXC를 사용하는 이유는 무엇일까? 전통적인 방식으로 소프트웨어를 배포하는 경우를 생각해보자. 서버 A와 B에 동일한 소프트웨어를 설치하려는데, A 서버는 1년 전에 리눅스 설치가 완료되었고, B 서버는 최근에 리눅스 설치가 완료되었다. 단순히 두 서버의 리눅스가 가지는 패키지만 하더라도 버전이 완전히 동일하지는 않을 것이다. 문제는 이렇게 사소하게 다른 환경으로 인해 A 서버에서는 아무 문제 없이 구동되는 소프트웨어가 B에서는 이슈를 일으킬 수 있다는 것이다. 따라서 동일한 소프트웨어를 여러 군데에 설치해야 할 경우, 설치되는 서버의 환경을 모두 동일하게 맞춰 주어야 한다. 가능할까? 최소한의 기능으로 리눅스를 설치하더라도 내부에 설치되는 패키지의 수가 무려 200 개가 넘어간다. 언제 다 비교하고 있을까? 물론, Hyper-V를 사용하여 동일한 OS를 구성하는 방법도 있지만 설치와 구성 자체도 새로 해야할 뿐더러 너무 무겁다. 이러한 이유로 소프트웨어 배포 시 소프트웨어가 최적으로 동작할 수 있는 환경을 별도로 제공해주는 컨테이너가 사용되기 시작한 것이다.

LXC의 내용을 봤으면 알겠지만 격리 환경을 구성하기 위한 과정이 난이도가 높고 복잡해서 사용하기가 꽤 까다로웠다. 물론 불굴의 의지를 가지는 일부 사람들은 이 높은 난이도를 극복하고 컨테이너를 쓰기 시작했지만, 점차 늘어나는 컨테이너의 관리에 어려움을 느끼게 된다. 예를 들면 하나의 컨테이너에서 테스트를 위해 환경을 구축했다고 가정해보자. 그런데 모종의 사건으로 인해 해당 컨테이너가 손상되어 다시 생성을 해야 되는 상황이라고 가정해보자. 할 수 있을까?

Docker는 컨테이너를 실행하는데 필요한 설정과 파일 내용을 정의하는 Image라는 것을 가진다. 마치 VMware의 스냅샷과 유사한데, 이 Image 파일만 있다면 docker를 사용하여 특정 시점의 환경 구성을 가지는 하나 이상의 컨테이너를 언제든지 생성할 수 있게 된다. 어떻게 보면 Docker의 등장으로 인해 LXC 기술이 조금 더 활발히 사용되게 된 것인데, 최근 각광받는 클라우드 환경의 경우 LXC 기반 기술로 소프트웨어를 배포하는 경우가 늘어나면서 Docker의 수요도 급증하게 되었다.

즉, 도커는 완전히 새로운 기술이 아니라 기존에 존재하던 기술들을 적절히 배합함으로써 경량 가상화를 이끌어낸 플랫폼이라보면 된다.


참고 자료: https://dololak.tistory.com/category/%EC%8B%9C%EC%8A%A4%ED%85%9C%20%EC%9D%B8%ED%94%84%EB%9D%BC

'시스템 인프라' 카테고리의 글 목록

https://limm-jk.tistory.com/3

[Dev-Ops] Docker? 도커가 뭐에요..?

https://ooeunz.tistory.com/61

[Docker] Docker의 개요

---

Docker가 완전히 새로운 기술이 아니다보니 등장 배경을 파악하기 위한 기반 기술에 대해 꽤나 많은 공부가 필요했다(이제 수박 겉핥기로 본 것 같은데 큰일이다). 물론 필자가 나름대로 정리한 내용이기 때문에 필자처럼 처음 해메시는 분들은 어느정도 걸러서 참고하시면 좋을 듯 하다.

다음 포스팅에서는 Kubernetes라는 녀석에 대해 알아보려 한다.



Fin.