처음 IT에 입문하는 사람, 비 전공자, 비 개발자들은 IT 용어가 낯설 수밖에 없습니다. 특히 일상에서 쓰이는 용어인데, IT 업계에서 다른 의미로 쓰이고 있다면 혼란은 더욱 가중되죠. 모르는 내용이 있을 때 모두가 친절하고 자세히 그리고 쉽게 알려주려고 노력하시지만, 비개발자 입장에서 이해하기는 쉽지 않았습니다. 그럼에도 IT 회사에서 근무한다면 개발자와의 협업과 소통을 위해, 높은 이해도를 바탕으로 한 본인의 업무 수행을 위해 IT 기초 지식을 알고 있어야 함은 당연했습니다.
여기저기 흩어져 있는 용어의 정의, 개념, 생태계 등을 정리하고 비 개발자가 이해할 수 있는 수준. 하지만 비 개발자가 알고 있기에 충분한 깊이의 지식을 공유하는 것이 [비개발자의 눈] 시리즈입니다.
시리즈의 첫 번째 주제는 컨테이너 입니다. 처음 IT 회사에 입사해서 '컨테이너'라는 단어를 들었을 때는 위와 같은 화물 컨테이너가 떠올랐어요. 처음에는 구글에 컨테이너를 검색해 보고 나오는 정의를 그대로 외운 뒤 겉 핥기 식으로만 이해하고 업무에 임했지만, 지금 [비개발자의 눈]이라는 컨텐츠를 생산하면서 컨테이너는 정확히 무엇이고, 어떤 장점들이 있는지 자세히 알아봤어요! 앞으로 [비개발자의 눈] 시리즈는 이런 식으로 제작되고 공유될 예정입니다.
1. 컨테이너의 개념
A. 컨테이너란?
컨테이너의 정의를 검색하면 아래와 같은 내용이 나옵니다.
컨테이너는 소프트웨어 서비스를 실행하는 데 필요한 특정 버전의 프로그래밍 언어 런타임 및 라이브러리와 같은 종속 항목과 애플리케이션 코드를 함께 포함하는 경량 패키지입니다.
어떤 말인지는 알겠는데, 사실 와닿는 설명은 아닙니다.그래서 정리해 보면,컨테이너란 운영체제를 가상화하여 어떤 환경에서나, 즉 프라이빗 데이터 센터, 퍼블릭 클라우드 혹은 개발자의 개인 노트북에서까지도 실행하기 위해 필요한 모든 요소들을 포함하는 소프트웨어 패키지입니다. 환경에 구애받지 않고 애플리케이션을 실행할 수 있도록 하는 기술인 거죠.그래서 CPU, 메모리, 스토리지, 네트워크 리소스를 쉽게 공유할 수 있게 되고 실제 실행 환경에서 애플리케이션을 추상화할 수 있습니다.
B. 컨테이너가 필요한 이유
실제로 개발을 위한 환경을 구축할 때는 정말 많은 과정이 필요하다고 합니다. 서버가 있어야 하고, OS를 구축하고, 네트워크 통신 포트 구성, 개발 툴 설치 등 많은 설정이 필요하고 호환성을 고려한다면 툴의 버전, OS버전 등을 모두 맞춰서 설치해야 한다고 해요. 이런 환경을 또 각 서버, 개발자의 PC마다 모두 한 번씩 설치하기엔 너무 반복적인 일인 데다가 구성이 잘못되거나 에러가 발생하면 다시 처음부터 해야겠죠. 그렇기 때문에 세팅을 한 번만 할 수 있고 또 배포할 수 있다면 개발 과정의 수고로움이 훨씬 줄어들 것이 당연해요! 이게 바로 컨테이너를 사용하는 이유입니다. 특히나 컨테이너는 배포에 최적화 되어있고 호스트의 OS가 달라도 어디서든 구동시킬 수 있어요. 덕분에 개발팀은 컨테이너화를 통해서 빠르게, 효율적으로 소프트웨어를 배포할 수 있게 되고, 전례 없는 수준의 확장성을 확보할 수 있게 되었답니다.
2. 컨테이너 기술의 역사
A. 2000년 이전
1979년, chroot를 발표한 것으로 역사가 시작됩니다. Chroot는 파일이나 디렉토리에 대한 액세스 권한을 제어할 수 있었지만 네트워크 및 프로세스 등을 컨트롤할 수 있는 기능은 없었습니다. 그리고 2000년에 제공된 Jail의 획기적인 기술로 컨테이너가 시작되었다고 할 수 있습니다.
B. 2000년 ~ 2010년
2000년, Unix OS인 FreeBSD에서 OS 가상화 기능, FreeBSD Jail를 발표합니다. FreeBSD Jail는 호스트 OS와 Jail이라는 OS 가상화 환경에서 프로세스, 네트워크, 파일 시스템을 분리할 수 있는 기술을 제공했습니다. 사용자별로 환경을 분리해서 안전성을 확보할 수 있었고 임대 서버, 호스팅 등의 서비스에 활용할 수 있었습니다.
Google은 2006년에 프로세스 자원 이용량을 제어하는 기능을 발표하는데 이 기능 이름은 cgroup입니다. 그리고 2008년에는 Rea Hat에서 논리적으로 시스템 자원을 분할하는 Namespace를 발표하고 IBM에서는 LXC (Linux Containers)를 발표합니다. LXC는 현재 컨테이너 기술의 시초라고 할 수 있는데, cgroup과 Namespace를 사용해 구현한 최초의 Linux 컨테이너 엔진입니다.
C. 2010년 이후
2013년 3월 26일, 컨테이너 기술이 확산되는 데에 기폭제 역할을 하는 도커(Docker)가 등장합니다. RHEL, SUSE, Debian 등 모든 Linux 배포판을 지원하는 오픈소스 소프트웨어로 공개되었죠, 2015년 7월 21일에는 Kubernetes 버전 1.0이 출시되고 이후 2016년 1월, Cloud Native Computing Foundation (이하 CNCF)이 컨테이너와 관련된 다양한 기술 문제들을 오픈소스로 해결하는 것을 목표로 정식 출범했습니다. 2017년 7월, OCI(Open Container Initiative)라고라고 하는 컨테이너 관련 표준 v1.0이 발표되고, Kubernetes 표준인 CRI (Container Runtime Interface)와 OCI(Open Container Initiative)에 최적화된 표준 컨테이너 런타임인 CRI-O가 발표됩니다.
3. 컨테이너의 장점
A. 민첩성
컨테이너를 사용하면 개발자가 항목과 환경에 미치는 영향에 대해 덜 스트레스받으면서 훨씬 더 빠른 작업이 가능해집니다. 애플리케이션을 배포하기 위한 전체적인 노력이 줄고, 테스트 주기를 간소화할 수 있죠. 결국 개발팀과 운영팀 간의 협업 또는 효율성이 향상되면서 더 빠른 결과물을 만들어낼 수 있습니다.
B. 이식성
컨테이너는 기본적으로 애플리케이션을 실행할 때 필요한 모든 구성 요소를 패키지하고 보관하는 표준화된 형식을 제공합니다. 따라서, ‘어떤 환경에서는 작동하고, 또 다른 어떤 환경에서는 작동하지 않는다’와 같은 문제를 해결할 수 있으며 OS 플랫폼 간 혹은 클라우드 간 이식이 가능합니다. 즉, 컨테이너가 배포될 때는 항상 변경되지 않은 상태로 일관된 환경에서 실행됩니다. 덕분에 개발 시스템부터 프로덕션 환경까지 일관된 형식을 사용할 수 있습니다.
C. 확장성
애플리케이션 컨테이너 기술은 고도의 확장성을 제공합니다. 별도의 OS 인스턴스를 비롯해 VM에서와 같은 일반적인 오버헤드가 없기 때문에 같은 인프라에서 더 많은 컨테이너를 지원할 수 있습니다. 컨테이너의 경량 특성 덕분에 컨테이너는 빠른 시작과 중지가 가능하며 덕분에 신속한 스케일 업 앤 다운 시나리오를 구현할 수 있습니다.
D. 효율성
컨테이너화 된 환경에서 실행되는 소프트웨어는 호스트 시스템의 OS 커널을 공유하기 때문에 개발자는 컨테이너 전반에 걸쳐 애플리케이션 계층을 공유할 수 있습니다. 또한 본질적으로 VM보다 용량이 작고 시작 시간도 짧기 때문에 결과적으로 서버 효율성이 향상되고 관련 서버 및 라이선스 비용은 절감할 수 있습니다.
이 외에도 구동 환경이 폭넓어 거의 모든 곳에서 구동할 수 있다는 점, 개발자 친화적으로 개발팀의 생산성과 효율성이 향상되는 등 다양한 장점이 있습니다.
4. 컨테이너의 단점
A. 보안 측면
컨테이너 기술의 보안 측면에서는 기존 VM과 비교했을 때 컨테이너는 잠재적인 보안 리스크가 훨씬 더 많기 때문에 계속해서 화두 되는 주제이기도 합니다. 컨테이너는 다중 레이어로 구성됩니다. 따라서 컨테이너화된 애플리케이션, 레지스트리, 호스트 OS에 대한 보안을 확보해야만 합니다.
B. 오케스트레이션
컨테이너 오케스트레이션은 컨테이너의 배포와 확장, 네트워킹을 자동화합니다. 만약 한정된 적은 양의 컨테이너일 경우에는 개별 관리자가 손수 관리할 수 있겠지만 대규모의 상용 프로젝트 환경에서 수많은 컨테이너를 개별적으로 제어하는 것은 현실적으로 불가능할 수밖에 없습니다. 따라서 어떤 컨테이너를 어느 호스트에 배치해 구동시킬 것인지, 한정된 리소스에 맞춘 최적의 스케줄링을 어떻게 구현할 것인지, 구동 중인 컨테이너들의 상태는 어떻게 추적하고 관리할 것인지, 운영되는 인스턴스 및 컨테이너들을 어떻게 상호 연결할 것인지에 대한 해답을 찾아야 합니다. 이에 쿠버네티스, Docker Swarm, Apache Mesos와 같은 오케스트레이션 툴을 선택해야 합니다.
C. 모니터링 측면
컨테이너의 성능이나 보안 문제의 발생을 예방하기 위해서 컨테이너를 모니터링하는 것도 매우 중요합니다. 지속적인 모니터링을 통해 수행하는 작업 그리고 모든 환경에서의 성능에 대한 통찰력을 얻을 수 있습니다.
5. 가상머신(VM)과의 비교
위에 서술된 내용 중, VM과 컨테이너를 비교하는 문장이 심심치 않게 등장했습니다. VM과 컨테이너는 프로세스와 네트워크, 파일 시스템을 격리할 수 있다는 장점을 공유하고 있지만, 눈에 띄는 차이점도 존재합니다.
컨테이너의 경우 대부분 크기가 메가바이트 단위입니다. 애플리케이션보다 크거나, 특정한 작업을 수행하는 단일 기능이 컨테이너에 패키징 되는 경우가 많습니다. 실행할 때 필요한 ‘모든’ 파일이 컨테이너에 패키징되는 것은 아닌 것입니다. 반면 VM은 크기가 기가바이트 단위인 것이 일반적입니다. VM은 자체 OS를 포함하고 있어서 리소스 집약적인 여러 가능을 동시에 수행할 수 있다는 장점이 있습니다. 사용할 수 있는 리소스가 늘어나면서 전제 서버, OS, 데이터 베이스, 네트워크 추상화, 분할, 복제, 에뮬레이션할 수 있습니다. VM 서비스를 관리하고 최종 사용자에게 제공하기 위해서는 하이퍼바이저가 필요합니다. 컨테이너와 VM의 주요한 차이점은 시작시간, 디스크 공간, 범위 등입니다. VM은 전체 운영 체제를 처리하기 때문에 컨테이너의 시작 시간이 VM을 시작하는 것보다 훨씬 빠릅니다. 또, 컨테이너는 필요한 구성 요소만 로드되기 때문에 많은 디스크 공간을 절약합니다.
DevOps를 실현할 때의 주요 기술 중 하나는 ‘컨테이너’입니다. 소프트웨어 개발의 최신 동향에 해당하는 기술로, 더 적은 비용으로 애플리케이션을 보다 효율적으로 개발하면서 테스트와 환경 구성 그리고 트러블슈팅과 같은 고질적인 IT 문제에 발 묶이지 않고 DevOps에 더 집중할 수 있습니다.
[비개발자의 눈] 시리즈 첫 번째로 컨테이너의 개념부터 역사 그리고 장단점에 대해 알아봤습니다! 컨테이너라는 기술에 대해 이해하고 나니 개발자들이 어떤 방식으로 일을 하고 있고 그 생태계가 어떻게 변해왔는지에 대해 알 수 있게 되어 이해도가 훨씬 높아졌음을 스스로 느낄 수 있었습니다. 시리즈의 두 번째 포스트에서는 컨테이너 런타임, 오케스트레이션 등에 대해 알아보겠습니다.
참고
Aqua Blog - A Brief History of Containers: From the 1970s Till Now
Redhat - Evolution of Containers
Medium by Martin Kaschke - What Is Containers Architecture?
VMWare - 하이퍼바이저란?
