OpenStack 시작 전에 알아 볼 컨테이너 이야기

 

 

OpenStack을 이해하기 위해서는 컨테이너를 함께 이해해야 합니다.

 

OpenStack을 배포하는 데에는 컨테이너가 사용되고,
OpenInfra Foundation 내에서도 컨테이너와 관련된 기술이 계속 중요해지고 있습니다.

 

 

초기 컴퓨팅 환경

 

배치처리 vs 시분할처리

 

 

컨테이너의 개념은 VM이 대중화되기 이전부터 존재했습니다.

 

초창기의 컴퓨터 환경은 메인프레임 중심이었습니다.

 

이 시기에는 배치 처리를 중심으로 컴퓨팅 처리를 진행하였습니다.

 

작업 목록을 일렬로 세워두고, 하나의 작업이 끝나면 다음 작업을 실행하여,
하나의 작업이 진행되는 동안 뒤에 있는 작업들은 기다렸습니다.

 

이 시기에는 안정성을 위해 하나의 서버에서 하나의 어플리케이션만을 실행했었습니다.

이때, 대부분의 어플리케이션은 서버의 모든 자원을 사용하기 힘들어,
고가의 장비가 배치되었음에도 컴퓨터의 많은 리소스가 유휴 상태인 경우가 많았습니다.

 

이러한 흐름 속에서 시분할 처리의 개념이 도입되기 시작했습니다.

 

시분할 처리는 CPU 시간을 아주 작은 단위로 쪼개 여러 프로세스에 차례대로 할당하여,

여러 프로세스가 동시에 계속 실행되는 것처럼 느끼도록 하였습니다.

 

그럼에도 배치 처리와 시분할 처리에는 큰 문제가 있었습니다.

누군가 코드를 잘못 작성해 시스템을 망가뜨리면 전체 시스템이 함께 영향을 받는다는 점이었습니다.

 

이 문제를 해결하기 위해 최초의 가상화 기술이 만들어지기 시작했습니다.

 

1960년대 중반 IBM은 CP-40 / CP-67 계열 시스템에서,
하드웨어 전체를 가상으로 복제하는 기술을 만들었습니다.

사용자에게 완전히 독립된 형태의 가상 컴퓨터를 제공하는 최초의 VM 개념이 처음으로 등장한 것입니다.

 

다만, 이 시기의 VM은 CPU 등을 포함한 많은 요소가 소프트웨어적으로 에뮬레이션되는 방식이었습니다.

 

 

메인프레임에서 x86 서버로

 

이전까지 서버 환경은 메인프레임 시대였습니다.
( 심지어 오늘날까지도 은행권에서는 메인프레임을 사용하는 경우가 있습니다 )

 

1990년대 후반과 2000년대 초반 닷컴 버블과 인터넷 보급으로,
인터넷 서비스가 빠르게 늘어나며 기업들은 폭발적으로 증가하는 트래픽을 감당해야 했습니다.

 

메인프레임에서는 IBM이 제공하는 가상화 기술이 있었으나,
x86 기반 저비용 서버 환경에서는 같은 수준의 가상화 기술이 없었습니다.

 

x86 서버는 메인프레임과 비교하여 값이 저렴하더라도 가상화 기술의 부재로,

서버를 온전히 사용할 수 없다면 서버의 증설로 추가적인 비용 소모가 발생하게 됩니다.

 

하지만 VMware가 VMware ESXi, VMware Workstation 같은 솔루션으로,

x86 서버에서 사용 가능한 제품들을 만들며 x86 서버에서의 가상화를 이뤄냈습니다.

이로 인해, 사용자들은 물리 자원의 사용량을 극대화할 수 있게 되었습니다.

또한, 호스트의 운영체제에 상관없이 게스트 OS로 다양한 OS를 올릴 수 있게 되며,

대폭의 비용 절감으로 인한 x86 서버 시장의 확대로 이어졌습니다.

 

결국 고가의 메인프레임만으로는 트래픽에 대한 비용 부담이 컸기에,

기업들은 인텔 기반 CPU를 사용하는 저비용 서버를 IT 인프라로 도입하기 시작했고,

UNIX 기반의 서버에서 Linux 로 변화가 이뤄졌습니다.

 

x86의 유래

 

x86 서버는 Intel CPU 모델 명에서 비롯되었습니다.
Intel CPU 모델 명이 80386, 80486 .. 처럼 86으로 끝났기 때문에,
이 계열 CPU를 사용하는 서버를 x86 서버라고 불렀습니다.

 

 

VM의 한계와 컨테이너적 사고

 

가상 머신은 강력한 격리를 제공하지만 무겁습니다.

starting time이 오래 걸리고, OS 전체를 포함해야 합니다.

 

초기의 가상화는 하드웨어 전체를 격리된 가상 컴퓨터로 제공하는 방식이었습니다.

하지만 실제로 어플리케이션을 운영해보며, 사용자들은 그 이상의 격리를 원하게 되었습니다.
누군가 시스템 파일을 깨뜨리거나 의존성을 파괴하기에, 영향을 주는 것을 막길 원한 것입니다.

이를 위해 어플리케이션과 그 의존성, 시스템 lib, fsystem,network 등 프로세스 단위로 격리하고자,

컨테이너 기술의 흐름이 시작되었습니다.

 

 

chroot

 

 

컨테이너를 만드는 기술의 핵심은 1979년의 chroot 기술로 볼 수 있습니다.

 

chroot는 격리된 루트 파일 시스템을 제공합니다.
특정 사용자나 프로세스에게 실제가 아닌 별도의 루트 파일 시스템을 보여줘,

네트워크가 연결되고, 시스템에 원격 접속이 가능해지며,
원격 접속 사용자에게 가짜 파일 시스템을 보여주는 방식이 필요해졌습니다.

 

사용자가 shell을 얻어 접속하더라도, 사용자가 보는 환경을 제한할 수 있어졌습니다.

Docker Container 안으로 shell 접속을 하면, 해당 컨테이너 만의 파일 시스템이 보이게 됩니다.

 

이는 호스트가 완전히 격리되어 있기에 가능한 것으로, Docker 만의 격리된 파일 시스템인 것입니다.

chroot는 파일 시스템 격리에 초점이 맞춰져 있습니다.

 

다만 파일 시스템의 격리만으로는 공격자의 기업 네트워크 격리를 차단하기에 적절하지 않아,

FreeBSD는 Jail을 만들게 되었습니다.

 

이는 파일 시스템 뿐만 아니라 네트워크까지 격리하는 개념으로, 현재 컨테이너 기술에 많은 영향을 끼쳤습니다.

 

OpenStack , K8s 모두 이와 동일한 것으로 존재하는 기술들을 잘 엮어 하나의 플랫폼으로 포장한 것입니다.

 

 

cgroups , namespaces

 

 

현대 컨테이너의 근간은 cgroups와 namespaces입니다.

 

Linux의 대표적인 기술인 cgroups와 namespaces는 사실 구글에서 만든 기술로,
2006년도 구글에서 진행한 process containers 프로젝트에서 비롯되었습니다.

 

해당 프로젝트에서는 프로세스의 CPU, memory, I/O 같은 리소스 사용량을 제한하며,
여러 기존에 있던 격리 기술들을 활용하는 기술을 개발하였습니다.

이 과정에서 computerolegroup (cgroup)으로 이름을 바꿔 리눅스 커널을 통합하며, 세상에 나왔습니다.

이는 noisy neighbor 문제를 해결하기 위한 것으로,
cloud service에서 특정 서비스에 트래픽이 몰려 리소스를 못쓰게 되는 현상을 방지하기 위한 것으로,

프로세스 컨테이너를 활용해 컨테이너로 서비스를 돌렸습니다.

 

이로 인해, cgroup을 만들었고, 이를 발전시켜 실행 환경 자체를 격리하는 namespace까지 이어진 것입니다.

cgroup과 namespace를 기반으로 사용자들은,
PID, 네트워크 스펙, 마운트 지점 등 시스템의 주요 포인트들을 프로세스마다 격리된 시각으로 볼 수 있게 되었습니다.

이렇게 만들어진 cgroups 와 namespace가 리눅스 커널에 들어오게 되며 리눅스가 발전하게 됩니다.

 

 

LXC의 등장

 

LXC는 LinuX Containers의 약자로,

 

cgroups와 namespaces를 통합해 커널 패치 없이 컨테이너를 관리할 수 있게 한 최초의 사용자 도구입니다.

하지만 이때까지만 해도 컨테이너는 Linux 시스템을 매우 잘 아는 사람들의 전유물로,
SW 개발자나 이에 관심없는 개발자들은 컨테이너에 대해 알지 못했습니다.

 

설령 이에 대해 알고 있더라도,
namespaces를 만들고, cgroups 설정 및 파일 시스템 준비 후 네트워크를 붙여 어플리케이션을 배포하는 일은
일반 개발자가 쉽게할 수 있는 일이 아니었습니다.

 

 

Docker의 등장

 

 

2013년 3월 13일, Docker가 처음 등장하였습니다.

 

Docker는 기존의 Linux 엔지니어만 활용 가능했던 컨테이너 기술을,
추상화하여 개발자가 사용가능한 쉬운 인터페이스로 개선하였습니다.

 

개발자는 컨테이너 내부에서 cgroups와 namespaces가 어떻게 동작하는지 몰라도,
docker start, docker run 같은 명령으로 컨테이너를 실행시킬 수 있게 되었습니다.

 

몇 줄의 짧은 파일 작성을 통해, 어플리케이션을 컨테이너 이미지로 만들 수 있었습니다.

 

특히나, 2010년대 초반 개발자들 사이에서 Agile 방법론이 매우 중요한 키워드로 떠오르던 환경에서,
MSA가 주목받으며 Docker도 함께 주목받게 되었습니다.

 

Docker를 활용하면 서비스를 작게 나눠 각각을 빠르게 배포하고, 교체함에 있어 훨씬 수월해지는 것입니다.

컨테이너를 빠르게 만들고 실행할 수 있기에 MSA와 Agile 흐름 속에서 더욱 각광받았습니다.

 

DockerFile

 

특히나 Docker가 성공할 수 있었던 가장 큰 이유 중 하나는 Dockerfile 이었습니다.

 

Docker의 이미지는 Layer 구조를 가져,

어플리케이션을 새로 배포할 때, 전체 환경을 매번 다시 만드는 것이 아니라, 변경된 레이어만 새로 만들 수 있습니다.

 

예를 들어, OS와 런타임, 라이브러리 레이어는 그대로 재사용하고,
어플리케이션 코드가 바뀐 마지막 레이어만 교체해 저장공간을 줄이고, 빠른 배포를 가능케합니다.

 

Dockerfile은 실행 환경을 파일로 정의하게 해주었습니다.
이를 통해, 개발자는 어플리케이션이 어떤 환경에서 실행되어야 하는지,
코드처럼 관리할 수 있게 되었습니다.

 

Registry

 

또한, Docker가 대중화될 수 있었던 또 다른 이유는 Registry에 있습니다.

Registry란 원격 저장소로 GitHub, PyPI, npm과 같은 역할을 수행합니다.

 

과거에는 개발자가 매번 웹 서버, DB , runtime 구성들을 반복해야 했습니다.
오픈소스 라이브러리를 가져다 쓸 수 있었으나, 실행 환경 전체를 재사용하는 것은 쉽지 않았습니다.

 

Registry가 등장하며 다른 사람이 만들어놓은 이미지를 가져와 이를 사용할 수 있게 되었습니다.

Registry는 이미지를 공유하고, 재사용하게 만들었고, 컨테이너 생태계 확장에 결정적 역할을 했습니다.

 

Docker의 한계

 

Docker Engine은 croups와 namespaces 같은 Linux 커널 기능을 이용해 컨테이너를 만들고 실행합니다.

 

하지만 Docker는 기본적으로 한 서버 내에서 컨테이너를 실행하고 관리하는 도구입니다.

 

엔터프라이즈 환경에서는 멀티 서버에서 컨테이너를 실행해야 하기에,
Dokcer만으로는 여러 서버의 컨테이너를 중앙에서 파악하고, 제어하기에 어려움이 있습니다.

 

이를 극복하기 위해 Docker Compose 같은 도구가 등장했지만,
이는 여전히 대규모 클러스터 운영 문제를 해결하는 도구는 아닙니다.

 

서비스가 커지고 컨테이너 개수가 많아지며 이를 해결하기 위한 오케스트레이션 도구의 전쟁이 벌어지게 되었습니다.

 

이런 컨테이너가 많아지자 오케스트레이션이 필요해졌고,
Apache Mesos, Docker Swarm, Kubernetes가 경쟁했습니다.

 

Google에서 Go를 기반으로 만든 K8s가 오늘날 산업의 표준으로 자리 잡았고,
CNCF로 기부되며 오픈소스 생태계 전략도 K8s 확산에 중요한 역할을 하였습니다.

 

오늘날 OpenStack과 K8s는 분리된 개념이 아닙니다.

OpenStack은 프라이빗 클라우드의 컴퓨트, 네트워크, 스토리지 기반을 제공하고,
Kubernetes는 그 위에서 컨테이너와 AI 워크로드를 운영합니다.

 

OpenStack 관점에서의 컨테이너

 

컨테이너는 어플리케이션을 가볍게 실행하는 기술만은 아닙니다.

 

운영 관점에서 보면 컨테이너는 아래의 기술이 OpenStack과 연결됩니다.

• 실행 환경 표준화
• 배포 단위 최소화
• 서비스의 일관된 운영 방식 기술

OpenStack은 하나의 거대한 프로그램이 아닌,

Nova, Neutron, Cinder, Glance, Keystone 같은 여러 서비스가 함께 동작하는 분산 시스템입니다.

 

각 서비스는 API 서버, 스케줄러, 에이전트, 데이터베이스, 메시지 큐 등 다양한 컴포넌트와 함께 운영됩니다.

 

이런 시스템을 직접 설치하고 관리하기 위해서는 의존성 충돌, 버전 관리, 배포 순서, 장애 복구 같은 문제가 복잡해집니다.

 

컨테이너는 이 복잡성을 줄이는 데 도움을 줍니다.

각 OpenStack 서비스를 컨테이너 이미지로 패키징해,

실행 환경을 더 일관되게 유지할 수 있고,

배포와 업그레이드도 더 예측 가능해집니다.

 

컨테이너는 OpenStack 위에서 실행되는 워크로드이기도 하지만,

동시에 OpenStack 자체를 배포하고 운영하는 방식에도 깊게 들어와 있습니다.

 

파이팅

 

컨테이너는 어느 날 갑자기 등장한 기술이 아닙니다.

 

이 흐름을 이해하면 OpenStack과 Kubernetes의 관계도 더 선명해집니다.

 

OpenStack은 컴퓨트, 네트워크, 스토리지 같은 하부 인프라를 제공합니다.

Kubernetes는 그 위에서 컨테이너화된 애플리케이션과 AI 워크로드를 운영합니다.

컨테이너는 OpenStack 위에서 실행되는 대상일 뿐 아니라, OpenStack 자체를 배포하고 운영하는 방식에도 사용됩니다.

 

OpenStack을 이해하기 위해서는 Nova, Neutron, Cinder 같은 컴포넌트와 더불어,

현대 인프라가 어떤 문제를 해결하기 위해 가상화로 발전했고,

다시 컨테이너와 오케스트레이션으로 확장되었는지를 이해해야합니다.