컨테이너는 VM과 뭐가 다르지? 장단점은 또 뭐지?

학습 차원에서 틈틈이 해외 전문가들이 블로그나 미디어 그리고 책에서 쓴 글을 정리하고 있습니다. 이번 포스팅도 그중 하나고요. 거칠고 오역된 부분이 있을 수 있습니다. 제대로 번역되지 않은 부분은 확인주시면 반영토록 하겠습니다. 이번 글은 해외 블로거인 파해드 밀릭이 자신의 개인 미디엄 블로그에 올린 글을 정리한 것입니다.

최근 나는 컨테이너에 대해 쓸 것인지를 묻는 독자들로부터 많은 메시지를 받았다. 컨테이너에 대해 매우 제한된 지식만 갖고 있던 터라, 나는 컨테이너에 대해 배웠다.

이 기사는 따라서 컨테이너에 초점이 맞춰져 있다.

결론: 컨테이너를  알아라. 곧, 기술 분야 모든 사람들은 컨테이너에 대해 말할 것이다.

우리는 클라우드 시대에 있다. 컨테이너는 이 시대 핵심 컴포넌트들 중 하나다.

기사 구조

이 기사는 아래와 세부 섹션으로 구성돼 있다.

  • 어떻게 OS와 커널이 작동하는지 이해하기: 이 지식은 기본을 형성하기 위해 필요로 한다.
  • 어떻게 버추얼 머신이 작동하는지
  • 컨테이너란 무엇인지
  • 컨테이너의 혜택과 단점
  • 소프트웨어 컨테이너 애플리케이션들

컨테이너는 경량 소프트웨어 애플리케이션으로 많은 혜택을 제공한다. 애플리케이션을 전달하기 위한 시간 절약, 확장성, 애플리케이션 관리 편의성, 지원과 나은 사용자 경험을 제공한다.

우리가 컨테이너에 대해 살펴보기 전에 어떻게 운영체제가 돌아가는지 이해하자. 특히 우리 스스로 OS의 심장에 위치하는 커널의 역할에 대해 친숙해 지도록 하자.

첫 번째, 기본을 구축하자. 운영체제가 어떻게 돌아가는지 이해하자.

운영체제는 컴퓨터 시스템에서 가장 중요한 소프트웨어다. 운영체제는 컴퓨터 하드웨어를 관리한다. 이와 함께 운영체제는 엔드유저 및 다른 애플리케이션들과 상호 작용하는 소프트웨어 애플리케이션을 관리하는 책임도 있다.

운영체제는 소프트웨어 애플리케이션들의 번들이다.

운영체제는 많은 책임들을 갖고 있다. 애플리케이션이 고립되어 운영될 수 있도록 업무 스케줄링, 처리, 메모리 할당 등을 책임진다. 이와 함께 운영체제는 애플리케이션이 하드웨어와 커뮤니케이션할 수 있도록  추상 레이어를 제공한다.

시장에서 이용할 수 있는 많은 운영체제들이 있다. 마이크로소프트 윈도, 맥 OS, 구글 안드로이드, 리눅스 우분투 등도 운영체제들이다.

운영체제는 아래 이미지에서 보는 것처럼 소프트웨어 애플리케이션과 하드웨어 사이에서 위치한다.

한 운영시스템은 많은 내부 프로그램들로 이뤄진다. 프로그램들 자체는 단지 명령이다. OS 코어를 형성하는 프로그램이 있고, 이것은 커널로 알려져 있다.

기사 두 번째 섹션으로 넘어가 보자. 커널은 운영체제에서 핵심적인 역할이다. 커널의 역할에 대해 분명하게 이해하자.

커널이란 무엇인가?

커널은 OS에서 가장 중요한 프로그램이다. 컴퓨터 시스템에서 최우선 OS는 호스트 OS로 알려져 있다. 호스트 OS 위에서 많은 OS를 추가로 런칭할 수 있다. 나는 이것에 대해 기사 후반부에서 설명할 것이다. 이들 추가되는 OS들은 게스트OS로 알려져 있다.

커널은 운영체제의 심장이다.

커널을 브리지로 생각하라. 컴퓨터 시스템에서 소프트웨어 애플리케이션을 데이터를 처리하는 하드웨어를 연결하는 역할이다.

커널의 중요성은 커널이 메모리 독자 영역에 위치 한다는 사실에서 입증된다. 따라서 커널은 컴퓨터 RAM 메모리에서 전용 영역을 갖는다. 이 영역은 다른 애플리케이션들과는 고립돼 있다.

이같은 디자인의 본질은, 사용자 애플리케이션이 운영체제 커널을 오염시키거나 방해하는 것을 막아준다. 사용자 애플리케이션들은 사용자 공간에서 돌아간다. 커널은 커널 공간에서 실행된다.

컴퓨터가 부팅될 때, 커널은, 컴퓨터 시스템에 올려지는 첫 컴퓨터 프로그램 들 중 하나다. 추가적으로 커널은 컴퓨터 시스템 스위치가 꺼질 때까지 메모리에 남는다.

커널은, 컴퓨터 시스템의 중심에 있다. CPU와 메모리, 하드웨어와 사용자 애플리케이션들 사이에 있다.

커널은 마우스, 키보드, 모니터, 디스크, 프린터 같은 하드웨어 기기들과의 커뮤니케이션도 관리한다. 커널은 또 CPU 명령을 바꿔준다. 이것은 효과적으로 저수준 작업들을 관리한다.

강조: CPU는 명령을 실행한다. 그것들을 서브 명령으로 해체함으로써 말이다. 누군가는 CPU를 컴퓨터 시스템의 브레인으로 생각할 수 있다.

위의 다이어그램에서 핵심은, 커널은 애플리케이션 메모리 관리에 책임을 진다는 것이다. 커널은 애플리케이션을 설정하고, 애플리케이션을 메모리에 올린다. 결과적으로 프로세스들을 관리하는 책임이 있다.

하이퍼바이저에 대한 빠른 소개

사용자 애플리케이션들은 다른 프로세스들을 통해 하드웨어에 접근하는 반면 커널은 무제한으로 접근할 수 있다. 핵심 프로세스들 중 하나는 하이퍼바이저로 알려져 있다. 하이퍼바이저는 컴퓨터 시스템 애플리케이션들과 물리적인 하드웨어 사이에 위치한다. 결과적으로 한 애플리케이션이 CPU와 상호 작용하고 싶다면, 운영체제 시스템과 하이버바이저를 거쳐야 할 것이다.

이 디자인은 우리의 주의를 요구하는 많은 문제를 가져온다.

이 다계층 디자인은 사용자 경험에 영향을 준다. 우리는 두 개 호스트 OS를 동시에 한 물리적인 컴퓨터 시스템에서 돌릴 수 없다. 게다가 한 애플리케이션은 다른 애플리케이션을 오염시키거나 방해할 수 있다. 하드웨어 시스템 인프라를 세팅하는 것은 시간을 많이 잡아 먹고 비용도 많이 들어가는 일이다.

따라서 컨테이너들은 그때 비용을 절약하고, 유지관리성 및 확장성을 향상하고 사용자 경험을 강화하고, 애플리케이션 전달 시간을 줄이기 위해 소개됐다. 지금까지 우리는 컨테이너가 어떻게 작동하고 어떤 혜택을 주는지 이해하기 위해 기본 블록들을 구축해왔다.

우리가 컨테이너에 대해 깊이 들어가기 전에, 퍼즐의 또 다른 조각을 먼저 이해하자. 버추얼 머신이다. 이 기사의 세 번째 섹션으로 이동하자. 버추얼머신이다.

버추얼 머신(VM)

버추얼 머신은 컴퓨터 시스템 하드웨어와 소프트웨어 애플리케이션을 분리한다. 우리는 버추얼 머신을 생성함으로써 컴퓨터 시스템을 복제할 수 있다. VM은 추상화 레이어를 제공하고, 기반 하드웨어 컴포넌트들의 복잡성을 숨겨준다. VM은 물리적인 하드웨어 시스템을 운영하는데 사용될 수 있다. VM은 지난 10여 년간 많이 사용돼왔다. 한 하이퍼바이저 프로세스는 버추얼 머신들을 런칭한다.

한 버추얼 머신은 한 버추얼 하드웨어 시스템을 생성한다. 우리는 마이크로소프트 윈도 운영체제에서 버추얼 머신을 생성하고 그것 위에 리눅스 운영체제를 설치할 수 있다. 이것은 IT 사용자들에게 대단한 유연성을 제공한다.

버추얼 머신을 당신의 컴퓨터 시스템의 한 버전으로 생각해보라.

게스트OS는 모두 호스트OS를 공유한다. 각각의 게스트 OS는 별도 버추얼 머신 내에서 공개된다.

VM을 설치하고 배치하고 복제하는 것은 완전한 세트의 인프라를 사는 것보다는 저렴하다. 우리는 버추얼 머신에서 커스텀 애플리케이션을 배치하고 설치할 수 있다.  VM에서 애플리케이션을 돌리려면 별도 OS(게스트 OS로 알려진)를 필요로 한다.

결과적으로 VM은 자체적으로 그들의 게스트OS를 갖고 있다. 이것은 그것들의 자체 커널, 드라이버, 애플리케이션 바이너리들을 포함한다. 나중에 VM은 호스트 OS에서 돌아가는 한 하이퍼바이저를 운영한다. 그 결과 한 애플리케이션이 CPU와 상호 작용하고 싶다면, 그것은 운영체제와 하이퍼바이저를 거쳐야 할 것이다.

하이퍼 바이저와 호스트OS를 통하는 것은 사용자 경험에 영향을 줄 수 있다.

VM은 문제를 가져온다. VM은 메모리를 많이 잡아 먹는 프로그램일 뿐만 아니라 양한 버추얼 머신들 사이에서 애플리케이션 바이너리 중복을 추가한다. 게다가 그것은 VM을 부팅하는데 오랜 시간이 걸린다.

시나리오

당신이 2개 VM을 한 윈도OS에서 공개한다고 싶어 한다고 하자. 이와 함께 당신은 당신의 서버 코드를 한 VM에서 호스팅하고 다른 VM에선 클라이언트 코드(UI)를 호스팅하고 싶어 한다고 하자.

당신은 윈도 OS로 VM을 준비하기로 하고 그것을 복제할 수 있다. 당신이 지금 한 VM을 복제했다는 사실은 OS과 라이브러리 중복을 가져온다. 이것은 또한 드라이버들이 두 OS에서 모두 존재할 필요가 있다는 것을 의미한다. 따라서 두 VM은 많은 메모리 공간을 잡아먹을 것이다. 결과적으로 당신은 물리적 서버에서 소수 VM만 선보일 수 있다.

버추얼 머신은, 무거운 컴퓨터 프로그램이다. 버추얼 머신은 서버 메모리를 필요로한다. 이와 함께 컴퓨터 시스템에서 다수의 VM 만 동시에 실행할 수 있다.

VM 부팅 시간 설치, 성능, 유지, 복제 저하는 컨테이너화로 알려진 새로운 기술의 탄생을 가져왔다.

컨테이너는 어떻게 돌아가나?

버추얼 머신은 운영체제를 복제한다. 반면 컨테이너는 한 운영체제를 공유한다.

우선 컨테이너는 게스트 OS를 필요로 하지 않는다. 컨테이너는 소프트웨어 프로그램이다. 컨테이너내에 있는 모든 애플리케이션들은  OS의 사용자 공간에서 돌아간다. 컨테이너 내 모든 응용 프로그램은 OS의 사용자 공간에서 실행되며 호스트 OS의 디자인과 일치, 커널에만 전용 공간이 제공된다. 이것은 애플리케이션들이 게스트 OS와 이후 하이퍼 바이저를 거치지 않고 CPU와 커뮤니케이션할 수 있도록 한다 그 결과 컨테이너는 보다 나은 성능을 제공한다.

VM이 가져온 문제들은 다소 해결됐다. 단일 호스트 OS와 그것의 애플리케이션 바이너리들을 포함하는 드라이버들은 공유되기 때문이다. 이것은 관련 바이너리와 자원들이 컨테이너에서 제공된다는 것을 의미한다.

컨테이너들은 파일 시스템을 복제하고, 우리가 애플리케이션을 안전한 환경에서 돌리도록 해준다. 모든 리소스와 파일들은 컨테이너 파일 시스템 내에서 돌아간다. 라이브러리와 함께 환경 변수들은 컨테이너들 내에서 저장된다. 이것은 컨테이너에서 인스턴스 기반 하이퍼바이저와 비교해 빠른 명령 실행을 촉진한다.

컨테이너들은 샌드 박스 환경을 제공한다. 그것들은 OS에 추상화를 가져온다.

컨테이너들은 컨테이너 엔진에서 공개된다. 나중에 한 컨테이너 엔진은, 많은 컨테이너들을 런칭할 수 있다. 이 컨테이너들은 파일 기반 설정 시스템을 갖고 있다. 이들 파일은 버전화, 백업, 모니터링될 수 있다. 따라서 두 컨테이너를 비교하기는 매우 쉽다.

컨테이너들은 컨테이너들이 실행할 필요가 있는 전체 정보를 갖고 있는 이미지를 포함하고 있다. 컨테이너들은 모노리식 애플리케이션을 마이크로 애플리케이션으로 분리하고 이들 간 커뮤니케이션을 설정하도록 고취시킨다. 마이크로서비스의 근본은 IT팀이 요구되는 애플리케이션 부분들을 단지 강화하고, 수행하고 배치할 수 있게 한다.

마이크로서비스들은 컨테이너와 함께 한다. 분산돼 있는 마이크로서비스들이 컨테이너를 사용해 호스트되고, 확장된다. 마이크로서비스에 대해 보다 많은 것을 알고 싶다면 이 기사를 보라. 

마이크로서비스 아키텍처란 무엇인가?

하드웨어 시스템 가상화 대신 컨테이너는 OS를 가상화한다.

모든 컨테이너들은 같은 OS를 공유한다. 따라서, 컨테이너들은 모두 같은 커널을 공유한다. 결과적으로 부팅 시간이 빠르다. 기억하라. 우리는 게스트OS에서 컨테이너를 런칭할 필요가 없다. 이 디자인은 컨테이너 기반 아키텍처에서 효율성을 증가시킨다.

컨테이너들은 경량 컴퓨터 프로그램들이다.

컨테이너와 vs 버추얼 머신-수직적 비교

VM에서 하드웨어와 커뮤니케이션하는 호스트 OS가 설치된다. 그때 바이너리가 게스트 VM에 설치된다. 웹애플리케이션, 데이터베이스 서버 같은 추가 애플리케이션들은 그때  이 VM에서 설치된다. 반면 컨테이너 애플리케이션에서 복수의 게스트 OS가 한 호스트 OS에서 설치될 수 있다. 각각의 게스트OS는 별도의 애플리케이션을 돌릴 수 있다. 예를 들어 웹 애플리케이션은 데이터베이스 서버와는 다른 게스트OS에 배치될 수 있다. 모든 게스트OS는 같은 기반 하드웨어와 커뮤니케이션한다.

그 결과 컨테이너들은, 마이그레이션 및 복제가 쉽다. 컨테이너들은 메모리를 덜 필요로 한다. 많은 컨테이너들은, 물리적 서버에서 호스팅 될 수 있다.

컨테이너들은 애플리케이션들 대한 한 래퍼(wrapper: 포장지)를 만들 수 있다. 이들은 모두 같은 하드웨어 자원에 접근한다. 결과적으로 유지성( maintainability)과 애플리케이션 가용성을 향상시킨다.

컨테이너들은 각각 고립될 수 있다. 이것은 애플리케이션을 좀 더 보호하고 애플리케이션들 간 보안을 고취시킨다. 나아가 한 애플리케이션용으로 모두 같은 OS커널에 접근하는 새 컨테이너들이 만들어지고 런칭될 수 있다. 컨테이너들은 클라우드에서 호스팅될 수 있는 VM에서 호스트될 수 있다. 한 컨테이너는 다른 OS에서 역시 돌아갈 수 있다.

시나리오

당신이 한 애플리케이션을 컨테이너에 배치하고 싶다고 가정해보자. 당신은 그때 당신의 애플리케이션 레벨 업데이트를 하고, 바로 결과물을 컨테이너 이미지로 배치할 수 있다. 이 컨테이너 이미지는 그때 호스트OS에 배치될 수 있다. 나아가, 당신은, 이미지를 개발하고 그것을 개발 테스트부터 프로덕션 환경으로까지 배치할 수 있다.

이미지들에서 일관성은 안정성을 고취시킨다. 시스템들에 걸쳐 애플리케이션에서, 각각의 이미지는 버전화될 수 있다. 시간이 가면서 진전되는 상황을 추적될 수 있다. 나아가, 컨테이너 이미지의 최소 크기는 엔터프라이즈급 애플리케이션을 전달하기 위해 요구되는 시간을 줄인다.

컨테이너의 개념은 모두 자원을 적절한 곳에 공유하는 것에 대한 것이다.

컨테이너의 혜택은 무엇인가? 컨테이너는 다음 혜택들을 제공한다.

  • 애플리케이션 레벨 고립
  • VM보다 빠른 셋업
  • VM보다 메모리 덜 소모
  • 마이그레이션, 백업, 전송이 쉬움. VM과 비교해 크기가 작기 때문이다.
  • 하드웨어와의 빠른 커뮤니케이션은 따라, 성능에 효과적일 수 있다.
  • 애플리케이션 배치와 유지보수를 향상시킨다. 전체 컨테이너 이미지 때문이다.
  • 애플리케이션 전달 시간 감소
  • 마이크로아키텍처와 디자인 고취

컨테이너의 일반적인 단점들은 무엇인가? 향후 향상들이 컨테이너들에서 만들어질 수 있다.

  • 컨테이너는 VM만큼 성숙하지 않았다. 성능은 여전히 대규모로 테스트되고 있다.
  • 컨테이너 기술에 경험이 있는 IT관리 컨설턴트들이 많지 않다. 따라서, 장기적으로 애플리케이션을 지원하는 것을 어렵게 한다.
  • 이와 함께 컨테이너는 버즈워드가 됐다. 클라우드 시대 때문이다. 그러나 미래에 그것이 비상할지는 여전히 논쟁거리다.
  • 컨테이너는 IT인프라에서 관리해야 할 또 다른 툴을 추가한다.
  • 애플리케이션이 완전이 고립돼 있지 않을 때 컨테니어들은 VM에 있는 것 만큼 안전하지 않는다. 보안은 향후 좀 더 향상될 수 있다.

어떤 소프트웨어 회사들이 컨테이너를 제공하나

도커: 많은 유명세를 최근 얻었다. 도커는 OS를 갖고 있는 베이스 이미지들을 포함해 많은 레이어들을 갖고 있다. 애플리케이션들은 적절한 레이어들에서만 설치될 수 있다.

코어 OS: 또 다른 유명 컨테이너 기술이다. 도커 컨테이너를 실행할 수 있다.

로켓: 인기를 얻어가는 중이다.

테크잇 뉴스레터를 전해드립니다!

오피니언 기반 테크 블로그 'TechIt'
테크 비즈니스를 보는 다양한 통찰들을 이메일로 간편하게 받아 볼 수 있습니다.

About the author

endgame
endgame

테크 블로거 / 공유할만한 글로벌 테크 소식들 틈틈히 전달하겠습니다

No more pages to load


TechIT

테크 비즈니스를 보는 다양한 통찰 '테크잇'

독자 여러분들께서 좋은 의견이나 문의 사항이 있으시면 아래 양식에 따라 문의 주시기 바랍니다.

Contact