블로그 주소 : https://blog.naver.com/gomets_journey

시작 시간 - Containers vs VMs

• 하드웨어 가상화는 CPU, 메모리, 하드 디스크 등의 하드웨어를 가상화하고 있기 때문에 하드웨어나 OS 부팅해야해서 부팅에 분 단위 시간 소요

• 컨테이너형 가상화에서는 컨테이너 부팅 시 OS는 이미 시작하고 프로세스의 시작만 할 초 단위 시간 소요

​

오버 헤드 - Containers vs VMs

• OS에서 응용 프로그램을 작동하는 경우, 하드웨어 가상화에서는 가상화 된 하드웨어 및 하이퍼바이저를 통해 처리하기 때문에 물리적 시스템보다 처리에 부가적인 시간(오버 헤드)가 필요

• 컨테이너형 가상화에서는 커널을 공유하고 개별 프로세스가 작업을 하는 것과 같은 정도의 시간 밖에 걸리지 않기 때문에 대부분 오버 헤드가 없음

​

VM의 고질적인 문제점

1, 거대한 이미지 사이즈

• VM을 템플릿 관리는 하지만 사이즈가 커서 재사용성을 높이기 어려움

​

2. 느린 시작 시간

• 부팅시 Hypervisor - OS - 미들웨어 - 애플리케이션까지 실행되어야 함

​

3. VM 간의 환경 불일치

• VM 생성 후 개별로 변경 사항을 관리하기 때문에 VM 간 구성이나 환경이 불일치

​

컨테이너를 통한 VM 문제 해결

1, 작은 이미지 사이즈

• 컨테이너는 레이어 개념으로 이미지에 파일을 추가/삭제하여 관리함

• 레이어 사이즈를 최적화하여 이미지 사이즈를 최소화

​

2. 빠른 시작 시간

• 컨테이너는 분리된 프로세스 형식으로 OS 부팅이 필요 없기 때문에 부팅 시간을 최소화 할 수 있음

​

3. 높은 이동성

• 애플리케이션에 필요한 라이브러리나 의존 파일들을 이미지에 포함하기 때문에 환경에 의한 발행되는 문제가 거의 없음

​

Container Image

1. 컨테이너를 실행할 때 필요한 파일시스템

• 이미지 레이어의 집합체 (파일 내용과 메타 정보를 포함)

• 레이어는 부모와 자식 관계

• 변경분만 기록

• Read Only (읽기 전용)으로 쓸 수 없음

2. 공통 레이어를 이미지 간에 공유

• 디스크 용량을 줄이고 높은 이동성 실현

​

Container - 애플리케이션 지향 인프라

1. 컨테이너화는 데이터 센터를 머신 지향에서 애플리케이션 지향으로 전환

• 애플리케이션 개발자와 운영팀에게 서버와 운영 체제에 대한 세부 사항을 추상화

• 실행중인 애플리케이션과 개발자에 미치는 영향을 최소화하면서 새로운 하드웨어 지원과 운영 치제를 업그레이드하여 인프라 팀의 유연성 제공

• 서버 CPU와 메모리 사용량과 같은 메트릭 정보 뿐만 아니라 애플리케이션에 연결하여 스케일 업, 머신 장애 또는 유지 보수 시에 애플리케이션 모니터링

​

cf)Goole의 업무 방식

• Gmail에서 YouTube, 검색에 이르기까지 Google의 모든 제품은 컨테이너에서 실행된다. 개발팀은 컨테이너화를 통해 더욱 신속하게 움직이고, 효율적으로 소프트웨어를 배포하며 전례 없는 수준의 확장성을 확보할 수 있게 되었다. Google은 매주 수십억 개가 넘는 컨테이너를 생성한다. 지난 10여 년간 프로덕션 환경에서 컨테이너화된 워크로드를 실행하는 방법에 관해 많은 경험을 쌓으면서 Google은 커뮤니티에 계속 이 지식을 공유해 왔다. 초창기에 cgroup 기능을 Linux 커널에 제공한 것부터 내부 도구의 설계 소스를 Kubernetes 프로젝트 공개한 것까지 공유의 사례는 다양하다. 그리고 이 전문 지식을 Google Cloud Platform으로 구현하여 개발자와 크고 작은 규모의 회사가 최신의 컨테이너 혁신 기술을 쉽게 활용할 수 있도록 하였다.

​

Containers vs VMs

구분

하이퍼 바이저형 가상화

컨테이너형 가상화

시작 시간

몇 분

몇 초

이미지 크기

수GB ~ 수백GB

OS를 포함하여 애플리케이션과 필요한 런타임 소프트웨어

~ 수백MB

애플리케이션과 런타임 소프트웨어만

Guest OS

Windows/Linux 등 다양한 선택 가능

호스트OS와 동일한 OS

이식성

대부분 가상 이미지에 대한 변환이 필요함

컨테이너 이미지 그대로 사용 가능

데이터 관리

VM 내부 또는 연결된 스토리지에 저장

컨테이너 내부에 있는 데이터는 종료시 소멸되며, 필요에 따라 스토리지를 이용하여 저장

Guest OS와의 관계

Guest OS는 하드웨어(가상)로 인식

Host OS를 커널수준으로 분리하여 OS를 가상화 형태로 사용하여 필요에 따라 호스트와 리소스 공유 가능

​

Containers의 장점

​

개발자 측면의 장점

특징

설명

효율적인 개발 환경 구축

개발 환경 구축 기간 단축 / OS가상화로 격리된 테스트 환경 구축

기존 가상화대비 작은 시스템 리소스로 개발 환경 구축

배포 편이성

이미지를 통한 빌드, 배포 자동화

개발자 환경 / 테스트 환경 / 스테이징 환경 / 운영 환경에 대한 일관성 보장으로 장애 요인 제거와 장애 원인 파악 시간 단축

민첩한 개발

컨테이너를 통한 짧은 주기로 요구사항 정의와 릴리즈를 반복하는 AGILE DEVELOPMENT 지원

서비스 무정지 환경 제공

서비스 정지 없이 시스템 운영이 가능하여 배포시간과 횟수에 대한 제약이 없음

마이크로 서비스 아키텍처

마이크로 서비스는 컨테이너로 구성하고 배포, 운영하는 것이 매우 유리

DevOps 기반

컨테이너는 DevOps 빌드 / 테스트 / 배포 파이프라인을 간소화

​

운영자 측면의 장점

특징

설명

낮은 오버헤드와 빠른 시작

최소한의 CPU와 메모리만 사용하여 비용 절감과 부하가 작아 고성능 제공

Guest OS가 없기 때문에 OS 부팅없이 애플리케이션을 실행하여 빠른 시작

(호스트OS에서 프로세스로 실행)

높은 이동성

(Portability)

Public Cloud (AWS, Azure, Google)와 기업내에서 Linux 운영체제라면

어디서나 운영 및 이식이 용이함

구축 기간 단축

컨테이너 환경은 개발, 스테이징, 운영 환경을 단순한 복사로 구축하여 작업 시간을 단축하고 일관성을 제공하여 환경에 의한 문제 원인 제거

장애 대응

배포, 시스템 유지 보수, 장애 발생시 무정지 작업이 가능

컨테이너 이미지 단위로 배포하고 운영하기 때문에 장애시 전환 시간을 단축

이미지 형태의 배포로 환경 차이에 의한 장애원인 제거

클라우드 네이티브 운영

환경 실현

스케줄링(Scheduling), 컨트롤링(Controlling), 자가 복구(Self Healing),

오토 스케일링(Auto Scailing), 롤링 업데이트(Rolling Update)

도커(Docker)

• 컨테이너 기반의 오픈소스 가상화 플랫폼

​

도커의 특징

• 레이어 저장방식

• 이미지 경로 표현

• Dockerfile

• DockerHub

• Command와 API

• 훌륭한 생태계 및 커뮤니티

• 지속적인 성능 / 기능 업데이트

​

비유하자면, image=실행파일, container=프로세스

정리하자면, image=컨테이너 실행에 필요한 파일, 설정 값 등을 포함하고 있는 덩어리

​

이미지의 레이어 저장방식

이미지간의 의존관계를 이용하여, 각각의 이미지들의 용량을 최소화 한다.

​

손쉬운 이미지 공유