[DevOps] 컨테이너의 이해 : 왜 컨테이너가 중요해졌을까?

Immutable Infrastructure (변경 불가능한 인프라) 탄생 배경

mutable Infrastructure (변경 가능한 인프라)

우리는 윈도우즈나 맥을 사용하면서 보안, 안정성 그리고 성능 등의 이유로 OS(운영체제)를 자주 업데이트 한다. OS는 시간이 지남에 따라 내용이나 설정이 수시로 변화가 발생하며, 새로운 애플리케이션를 설치할 때는 레지스트리도 변경한다. 지금까지 사용하던 많은 소프트웨어들은 업데이트나 설정 변경 등을 반복하면서 최신 상태로 유지하였고, 서버용 소프트웨어도 유사한 방법으로 관리했다. 

서버의 경우에는 OS 설정 변경이나 업데이트 그리고 애플리케이션 배포가 자주 발생하는 경우에

1. 서비스의 안정성에 큰 영향을 미치며, 서버 환경 자체가 파괴되는 경우도 있다. 
2. 언제 어느 부분이 변경되었는지 이력관리가 되지 않고, 변경 정보 공유가 되지 않으면 시스템 작업 시에 문제가 발생하여도 대처 방법을 알 수 없다.
3. 기존에는 서버를 교체하는 비용이 너무 많이 들었기 때문에 3년, 5년, 10년 등의 유지 보수 기간을 설정하여 장비를 자사에서 구매하고 이 기간이 끝날 때까지 사용했다.
   • 일단 구축하고 난 뒤 유지 보수하면서 최대한 오랫동안 사용하는 것이 일반적이다. 장비뿐만 아니라 OS와 미들웨어 벤더도 유지 보수 기간이 있으며 OS·미들웨어 애플리케이션과 실제 운영 모드의 트래픽에 맞춘 퍼포먼스 튜닝도 수행하는 등 인프라 관련해 여러 가지 구성 요소를 변경하면서 운영 관리 했다. 이 때문에 인프라 구축 규모가 크면 클수록 인프라 구성관리에 대한 부담도 늘어났다.

이러한 문제를 해결하기 위한 방법이 바로 서버를 구축한 이후에는 변경이나 업데이트를 할 수 없게 하는 Immutable Infrastructure (변경 불가능 한 인프라) 이다.

 

Immutable Infrastructure (변경 불가능한 인프라) 

“변경 불가능한 인프라” 란 서버를 변경 불가능한(Immutable) 것으로 취급하는 개념이다.

만약 변경이 필요한 경우에는 아예 새로운 서버를 구축하는 방법이다.

서버를 변경하지 못하도록 하여 얻을 수 있는 가장 큰 장점은 바로 “서버를 항상 깨끗(Clean)한 상태한 상태로 유지” 하는 것이다.

이 개념은 마치 DVD 로 소프트웨어를 배포할때 소프트웨어의 변경이 생기면 새로운 이미지로 DVD를 제작하는 개념이다. 즉 서비스 운영환경을 호스트OS 와 분리한 후 이미지로 생성하여 서버에 배포하여 실행한다. 서비스를 업데이트하는 경우에는 운영환경을 변경하지 않고 이미지를 새로 생성하여 배포하는 것이다.

또한 클라우드와 컨테이이너 기술, 가상화 기술들이 발전하면서 서비스 운영 환경을 이미지로 구성하여 배포하는 방법이 가능하게 되면서 “변경 불가능한 인프라” 도입이 확산되기 시작하였습니다.

Immutable Infrastructure 의 배경 기술로는 오토 스케일링(Auto Scaling)과 블루-그린 배포 방식(Blue-Green Deployment) 가 있다.

• Auto Scaling은 부하에 따라 자동으로 서버 대수를 증감시키는 기술
  • 항상 필요한 대수만 시작하기 때문에 비용 절감된다. Auto Scaling은 서버가 자동으로 확장하거나 축소되기 때문에 서버를 일회용으로 쓰고 버리는 방식으로 운영할 수 있다.
• Blue-Green Deployment 주로 클라우드 환경에서 적용되는 배포 패턴
  • 지금까지의 배포는 애플리케이션을 서버에 복사한 후 애플리케이션 서버를 재시작하는 것이다. 그러나 Blue-Green Deployment에서는 서버 그룹을 통째로 복제하여 로드 밸런서에서 전환하여 배포하는 방식이다.
  • 만약 애플리케이션 서버가 100 대 있으면 새로운 버전의 애플리케이션을 설치 한 서버를 다시 100 대 설치하고 실행한 후, 새로운 서버 그룹으로 트래픽을 전환하는 것이다. 이렇게하면  애플리케이션을 다시 시작할 때 성능 저하를 걱정할 필요가 없으며 롤백도 손쉽게 할 수 있다.
• Auto Scaling뿐만 아니라 Blue-Green Deployment에서 서버는 일회용으로 다루기 때문에 서버의 구축과 관리를 단순화 할 수 있다.

변경 불가능한 인프라(Immutable Infrastructure)는 서버를 일회용으로 취급하는 개념이고,
변경 가능한 인프라(mutable Infrastructure)는 항상 운영가능한 상태이고, 대체 불가능한 유일한 시스템으로 다루는 개념이다.

즉 일회용 종이컵과 고급 도자기 컵과 비유될 수 있다. 종이컵은 한번 쓰고 버리지만 컵 하나를 구매하는데 부담스러워 하지 않는다. 고급 도자기 컵은 어떨까? 깨지면 모든 것이 끝나게 된다.

 

근본적 차이점

변경 가능한 인프라와 변경 불가능한 인프라 간의 가장 근본적인 차이점은 정책에 있다.

전자는 서버 컴포넌트들을 배포한 후에도 변경되도록 설계된 반면, 후자의 경우에는 배포된 서버 환경을 변경하지 않고 궁극적으로는 기존 것은 버리고 새 것으로 대체하는 것이다.

두 가지의 인프라 관리 방법은 서버를 어떻게 처리 ( 생성, 유지, 업데이트, 제거)해야 하는지에 대한 접근 방법에서 다른 점이 있습니다.

 

Container 

컨테이너는 애플리케이션 프로세스를 말한다.

일반 애플리케이션과 컨테이너 기반 애플리케이션의 차이는 컨테이너 끼리 완전히 독립적으로 동작한다는 것이다.

컨테이너는 개별적인 cpu, memory, network, disk 등을 독립적으로 갖고 동작하기 때문에 서로 영향을 주지 않는다. 따라서 여러개의 컨테이너가 실행중일 때 일부 컨테이너만 추가 기능 개발 후 배포가 가능하다.

 

Docker

컨테이너는 어떻게 동작하느냐? 도커를 통해 동작된다.

Docker(도커) 는 Immutable Infrastructure(변경 불가능한 인프라)를 가능하게 하는 가장 중요한 기술요소이다.

OS 를 포함하여 서버의 소프트웨어 구성을 일정하게 고정 시키고 애플리케이션을 도커를 이용하여 가상 OS 환경과 함께 배포하고 운영함으로서 호스트 OS 자체에 대한 변경 없이 안정적으로 애플리케이션을 실행할 수 있는 구조이다.
애플리케이션 실행환경이 Docker 에서 제공하는 가상OS환경이 이기 때문에 언제든지 서버를 폐기/생성 할 수 있어 호스트 OS 환경의 문제로 부터 벗어 날 수 있다.

• 도커 호스트 : 도커 데몬이 동작되고 있는 시스템 
  • 도커 프로세스가 실행되어 서버로서 입력을 받을 준비가 된 상태를 도커 데몬이라고 한다.
  • 리눅스 커널을 갖고 있는 시스템(맥, 윈도우 등)에서 도커를 설치해서 데몬을 실행한다.
  • 따라서, 데몬이 실행되고 있는 리눅스 커널이 있는 시스템을 도커 호스트라고 한다.
  • 즉, 도커가 컨테이너를 실행할 수 있는 플랫폼을 만들어 놨다는 뜻
• 각 컨테이너들이 도커 데몬하에 개별적으로 동작됨
• 커널은 하나
• 호스트 입장에서 컨테이너는 단순히 동작되고 있는 프로세스이지만, 사용자 입장에서 컨테이너는 완전히 독립적인 공간에서 실행되고 있는 애플리케이션이다.

 

IMMUTABLE INFRASTRUCTURE ( 변경 불가능한 인프라 ) 장점 – DOCKER

• 모든 서버를 동일한 상태로 유지
  • 서버들을 Ansible/Puppet/Chef 와 같은 도구를 사용하여 오랜시간 동안 업데이트와 패치를 거듭하면서 관리되었다고 가정한다. 그렇다면 그 서버들의 상태가 모두 동일하게 유지되고 있다고 자신있게 말할 수 있을까? 서버를 수동이 아닌 자동화된 방식으로 관리한다는 것은 관리의 효율성은 보장하지만 모든 서버들의 상태를 동일하게 유지 한다고 할 수 없다.
  • “변경 불가능한 인프라”에서는 서버의 변경이 필요하게 되면 모든 서버의 이미지를 새로 만들기 때문에 모든 서버가 동일한 상태임을 보장한다.
• 언제든지 즉시 운영 가능한 서버 구축
  • 언제든지 즉시 운영 가능한 서버 환경을 구축할 수 있다면 서비스의 가용성을 확실하게 보장 할 수 있다.
  • 아무리 클라우드환경에서 시스템을 운영 중이라고 하더라도 하드웨어를 사용하는 것이므로 반드시 물리적인 고장이 발생할 수 있다.
  • 만약 만약 장애 상황에서 서버를 처음부터 설치해야 한다면, 시간의 문제 뿐만이 아니라 비즈니스에도 큰 문제가 발생한다.
• Provisioning 은 단순하게 
  • “변경 할수 없다”는 것은 “Ansible을 최초 한 번만 실행하는 것‘이다.
  • Ansible은 오픈 소스 소프트웨어 프로비저닝, 구성 관리, 애플리케이션 전개 도구이다. 
  • Ansible은 '멱등성'이라는 중요한 특징을 가지고 있다. 이것은 동일한 서버에 Ansible을 여러 번 반복해서 실행해도 동일한 결과를 얻는 것이다.
  • Immutable Infrastructure 환경에서는 최초의 상태에서 변화가 필요없기 때문에 멱등성이 불필요하다.
• 테스트의 편이성 
  • Immutable Infrastructure에서는 개발/스테이징/운영 단계에서 모든 서버 상태가 동일하게 보장되어 있기 때문에, CI를 통한 테스트에 대한 신뢰도가 높아진다.
  • 애플리케이션 이식성 향상 Docker Hub를 통해 컨테이너 이미지를 공유 할 수 있기 때문에 전세계 누구나 ​​동일한 시스템 사양이면 같은 환경의 서버를 구축 할 수 있다.
  • 글로벌한 개발 커뮤니티에서는 머신 이미지와 간단한 스크립트를 공유하면 손쉽게 개발환경을 공유할 수 있습니다.
• 모듈성
  • Docker의 컨테이너화 접근 방식은 전체 애플리케이션을 분해할 필요 없이 애플리케이션의 일부를 분해하고, 업데이트 또는 복구하는 능력에 집중되어 있다.
  • 사용자는 이 마이크로서비스 기반 접근 방식 외에도 SOA(service-oriented architecture)의 작동 방식과 동일하게 멀티플 애플리케이션 사이에서 프로세스를 공유할 수 있다.
• 계층 및 이미지 버전 제어
  • 각 Docker 이미지 파일은 일련의 계층으로 이루어져 있으며 이 계층들은 단일 이미지로 결합된다.
  • 이미지가 변경될 때 계층이 생성되고, 사용자가 실행 또는 복사와 같은 명령을 지정할 때마다 새 계층이 생성된다.
  • Docker는 새로운 컨테이너를 구축할 때 이러한 계층을 재사용하므로 구축 프로세스가 훨씬 더 빨라진다.
  • 중간 변경 사항이 이미지 사이에서 공유되므로 속도, 규모, 효율성이 더 개선됩니다.
  • 계층화에는 버전 관리가 내재되어 있으며 새로운 변경 사항이 발생할 때마다 내장 변경 로그가 기본적으로 적용되므로 컨테이너 이미지를 완전히 제어할 수 있습니다.
• 롤백
  • 계층화에서 가장 유용한 부분은 아마도 롤백 기능일 것이다.
  • 모든 이미지에는 계층이 있으며, 현재의 이미지 반복이 적절하지 않은 경우 이전 버전으로 롤백하면 됩니다.
  • 이 기능은 애자일(agile) 개발 접근 방식을 지원하며 툴 관점에서 실제로 지속적인 통합 및 연속 배포(Continuous Integration and Deployment, CI/CD)를 수행하는 데 도움을 준다.
• 신속한 배포
  • 새로운 하드웨어를 준비하고, 실행하고, 프로비저닝하고, 사용할 수 있게 하려면 일반적으로 며칠이 소요되었고, 많은 노력과 부가적인 업무가 필요하므로 부담도 상당했다.
  • Docker 기반 컨테이너는 배포 시간을 몇 초로 단축할 수 있다. 각 프로세스에 대한 컨테이너를 생성함으로써 사용자는 유사한 프로세스를 새 앱과 빠르게 공유할 수 있다.
  • 또한, 컨테이너를 추가하거나 이동하기 위해 OS를 부팅할 필요가 없으므로 배포 시간이 크게 단축된다.
  • 이뿐만 아니라 배포 속도가 빨라 컨테이너에서 생성된 데이터를 비용 효율적으로 쉽게 생성하고 삭제할 수 있고 사용자는 우려를 할 필요가 없다.
  • 즉, Docker 기술은 효율성을 중시하며 더 세분화되고 제어 가능한 마이크로서비스 기반 접근 방식이다.

 

참고

• http://www.opennaru.com/openshift/immutable-infrastructure-with-docker-and-containers/
• https://www.youtube.com/watch?v=m454YTyPWSk 
• http://www.opennaru.com/openshift/immutable-infrastructure-vs-old-infra/
• https://www.redhat.com/ko/topics/containers/what-is-docker