컨테이너 기반의 클라우드 네이티브 컴퓨팅 시대 도래(3/3)

클라우드 네이티브 컴퓨팅에 대한 내용을 요약하여 공유 합니다. 길이가 길어 총 3편으로 나누 었습니다

도움이 되었으면 합니다


클라우드 네이티브 컴퓨팅의 구성

앞서 살펴 보았듯이 컨테이너와 DevOps 환경의 자동화, 마이크로 서비스는 기본 클라우드 컴퓨팅 환경을 진화 시키고 있다.  이 진화된 컴퓨팅 환경을 클라우드 네이티브 컴퓨팅(Cloud Native Computing)이라 한다.

클라우드 네이티브 컴퓨팅은 인프라에서 어플리케이션 까지 필요한 구성 요소를 결합하여 구성 한다. 각각의 구성 요소를 살펴 보면 다음 과 같다.

1_PvQh6lzs-GKKai7ZFwrMdA

출처 : https://blog.devnetcreate.io/developing-cloud-native-applications-94179c53e486

인프라스트럭처, 프로비져닝(Infrastructure, Provisioing)

클라우드 네이티브 컴퓨팅의 대상 인프라는 컨테이너 이동성에 힘입어 거의 제약 없이 구성 할 수 있다는 장점이 있다. 다음은 클라우드 네이티브 컴퓨팅이 지원 하는 인프라 종류 이다.

  • BareMetal : 물리적인 인프라. 내부 또는 데이터 센터에 구성
  • 가상화 인프라(Private Cloud) : Openstack, Cloudstack, VMWare등 플랫폼 기반이 가상 인프라
  • 퍼블릭 클라우드(Public Cloud) : AWS, Google GCP, MS Azure 등 대부분의 퍼블릭 클라우드

클라우드 네이티브 컴퓨팅 인프라는 기존과 달리 클러스터로 구성 하여야 한다. 즉 하나 이상의 노드(물리, 가상화)를 네트워크로 구성하고 그 위에 오케스트레이션 플랫폼을 설치 하여 구성 한다. 이 클러스터 구성은 오케스트레이션 플랫폼에 따라 차이가 있어 구성 전 오케스트레이션 플랫폼의 요건을 확인 하여야 한다

프로비져닝은 가상화(프라이빗, 퍼블릭) 인프라에 해당한다. 인프라 프로비져닝은 가상화 플랫폼이 제공하는 API를 이용하여 클러스터 구성을 자동화 한 것으로, 초기 구성 뿐아니라 운영 중 자원 사용량에 다른 노드의 스케일링, 교체 등이 포함 된다. 인프라 프로비져닝의 자동화는 구성의 오류와 작업을 효율화 할 수 있는 장점을 제공한다

현재 컨테이너 오케스트레이션이 지원 되는 OS는 Linux와 Windows(2016 서버 버젼 이상)이다. 인프라 프로비져닝 시 해당 OS를 같이 설정하는 것이 필요하다

컨테이너 오케스트레이션, 런타임(Orchestration, Runtime)

컨테이너 오케스트레이션은 동적 관리를 위한 핵심 엔진이다. 앞서 구성된 클러스터 인프라에 설치 되며 이 후로는 오케스트레이션 엔진에서 인프라 정보와 상태에 따라 관리를 수행 한다.

컨테이너 런타임은 컨테이너를 생성, 실행, 관리한다. 오케스트레이션 엔진은 컨테이너 런타임을 통해 컨테이너의 실행을 관리 한다. 현재는 리눅스 재단에서 표준화한 Containerd라는 엔진을 사용하지만 이전에는 Docker의 런타임을 사용하였다. 시스템의 요구에 따라 적절한 런타임을 선택 적으로 사용 할 수 있다   

어플리케이션 개발(Application Development)

앞서 설명한 DevOps 파이프라인이 구현된 영역이다. 컨테이너의 빌드 부터 배포, 업데이트, 운영, 모니터링을 담당하며 직접 개발 또는 오픈소스, 상업용 제품등을 선택 할 수 있다.

마이크로 서비스 아키텍처를 적용 할 것이라면 통합 로깅, 메시징 등 마이크로 서비스 아키텍처에 필요한 요소를 추가로 구성하여야 한다.

구성 시 고려 사항

현재 클라우드 네이티브 컴퓨팅은 오픈소스가 주도 하고 있다.(이후에 살펴 볼 것이다) 제품화된 플랫폼들도 핵심 요소는 오픈소스를 기반으로 하고 있다.

따라서 클라우드 네이티브 컴퓨팅 환경을 구축 하려면 해당 오픈소스에 대한 지식 습득과 통합, 최적화를 수행 하여야 한다. 대부분의 기업은 이를 위한 별도 조직과 전문가를 통해 환경 구축 및 관리/운영을 하고 있다. 기존 클라우드 컴퓨팅과 달리 변화된 환경을 구축 하여야 함으로 조직의 변화 관리도 중요한 포인트 이다.

퍼블릭 클라우드, 클라우드 솔루션 기업을 중심으로 클라우드 네이티브 컴퓨팅 환경을 쉽게 구축하고 운영 및 관리 할 수 있는 서비스 또는 플랫폼을 제공한다. 자체 조직이나 관리가 어려울 경우 해당 솔루션을 사용하는 것을 권장한다. 클라우드 네이티브 컴퓨팅 자체 보다는 어플리케이션의 운영이 기업에 있어서는 저 중요하고 가치 있는 일임으로 비용 대시 성과를 볼 때 적절 한 솔루션을 활용하는 것이 효과적이다

오픈소스가 주도하는 클라우드 네이티브 생태계

앞서 언급 하였듯이 클라우드 네이티브 컴퓨팅은 시작 부터 오픈 소스가 주도 해 오고 있다. 초기에 비해 신규 및 기존 오픈소스의 업데이트가 이루어져 거대한 생태계를 형성 하고 있다.

다음은 클라우드 네이티브 컴퓨팅의 오픈 소스 생태계를 정리한 것이다.

CloudNativeLandscape_latest

출처 : https://github.com/cncf/landscape

이 중 핵심 적인 오픈 소스는 컨테이너 런타임과 오케스트레이션이라 할 수 있다

컨테이너 런타임은 Docker가 주도 하고 있다. 리눅스 재단에서 컨테이너 표준화를 진행 하면서 Docker는 자사 런타임을 제공 하였고 현재는 표준화 돤 Containerd 엔진을 기반으로 Docker 뿐아니라 타 런타임도 기능을 확장한 버젼을 내놓고 있다. 예를 들면 rkt(로켓이라 읽는다)의 경우 보안을 강화한 컨테이너 런타임이다.

컨테이너 오케스트레이션 엔진의 경우 대표적으로 구글의 Kubernetes, Docker의 Swarm, MESOS등이 있다. 각각 기능과 목적의 차이가 있으나 현재는 Kubernetes를 가장 많이 사용하고 있고 증가 하는 추세이다.

Kubernetes는 구글이 내부적으로 사용하던 Borg를 기반으로 오픈소스화 한 엔진으로 기업 규모의 어플리케이션과 마이크로서비스 관리를 위한 방대한 기능을 제공한다. 그 규모 만큼 이해와 사용에 있어 어려움이 있긴 하지만 다수의 글로벌 기업이 채택하고 있어 앞으로 계속 성장할 것으로 전망한다.

다음은 클라우드 네이티브 컴퓨팅 재단이 조사한 오케스트레이션 엔진에 대한 결과 이다. 2017년 기준으로 Kubernetes가 77%의 사용율을 보이고 있다

chart1

출처 : Cloud Native Technologies Are Scaling Production Applications – Cloud Native Computing Foundation(https://www.cncf.io/blog/2017/12/06/cloud-native-technologies-scaling-production-applications/)

런타임과 오케스트레이션 외에도 인프라, 프로비져닝, 어플리케이션 개발 등의 영역에 상당 수의 오픈소스가 있으며, 지속적으로 확장 중에 있다.

마치며…

총 3편의 글에 걸쳐 클라우드 네이티브 컴퓨팅에 대해 정리하여 보았다. 컴퓨팅 환경은 클라우드의 도입으로 부터 컨테이너까지 빠르게 변화하고 있다. 그 배경에는 디지털로 비즈니스 기반을 전환하려는 기업들의 요구가 있다.

클라우드 컴퓨팅은 기업이 디지털 환경으로 전환 할 때 필요한 기반을 제공하며, 관련 기술의 발전으로 비즈니스 요구에 민첩한 대응과 높은 효율화를 제공하고 있다.

이제 클라우드 컴퓨팅은 선택이아니라 필수가 되어가고 있는 것이다.


이전 글 : DevOps 컨테이너로 날개를 달다

Advertisements
컨테이너 기반의 클라우드 네이티브 컴퓨팅 시대 도래(3/3)

컨테이너 기반의 클라우드 네이티브 컴퓨팅 시대 도래(2/3)

클라우드 네이티브 컴퓨팅에 대한 내용을 요약하여 공유 합니다. 길이가 길어 총 3편으로 나누 었습니다

도움이 되었으면 합니다


DevOps 컨테이너로 날개를 달다

DevOps대 대한 정의는 다양해 한 마디로 정의 할 수는 없지만 주요 키워드를 살펴 보면 무엇을 이야기 하는지 알 수 있다.

  • 개발과 운영의 경계가 모호 해지는 추세 : 클라우드 이 후 코드 기반으로 업무를 수행하는 환경으로 변화
  • 개발과 운영의 커뮤니케이션 강화 : 분리된 조직이 아닌 팀 단위로 문제를 협력 하여 해결
  • 자동화 : 개발에서 운영 까지의 업무 파이프라인 전체를 자동화 하여 효율성을 높임

즉 DevOps는 개발과 운영 업무의 효율화에 초점이 맞추어져 있고, 컨테이너는 효율화를 구현 하는데 핵심 기술을 제공한다.

DevOps의 주요 업무 흐름(Pipeline)은 다음과 같이 구성된다.(여러 문서가 있지만 가장 쉽게 이해 할 수 있는 이미지를 구글링을 통해 발췌 하였다)

03b08de

출처 : DevOps is a culture not a job description | LinkedIn (https://www.linkedin.com/pulse/20140419203541-7504519-devops-is-a-culture-not-a-job-description)

위 그림을 요약해 보면 다음과 같다

  • 계획 – 개발 – 배포(릴리즈) – 운영 까지의 전 업무 흐름을 하나로 연결
  • 반복과 피드백을 통해 개선(데이터 화)
  • 민첩성을 높이기 위한 자동화 기술 적용(반복적인 업무 대상)

컨테이너는 위 DevOps 파이프라인의 모든 과정에 자동화/효율화 기반을 제공한다

코드로 부터 빌드, 테스트 : Container Build

컨테이너 빌드(Container Build)는 간단히 말하면 컨테이너를 이미지(Container Image)화 하는 과정이다. 앞서 이야기 하였듯이 컨테이너는 그 자체로 OS상에 배포 되어 마치 가상 머신 처럼 독립 실행 가능한 단위이다. 이 실행에 필요한 구성은 이미지 형태로 저장 되는데, OS에서 프로세스를 실행 하는 데 필요한 정보를 파일 시스템으로 저장, 패키지화 한다고 생각 하면 된다.

컨테이너 빌드는 일종의 OS Shell script를 작성하는 것과 유사 하다. 일반적으로 빌드 파일(예 : 도커파일, Dockerfile)로 작성 되는데 다음과 같은 구성을 갖는다

  • 베이스 이미지 : 컨테이너를 구성 하는데 기본이 되는 이미지. 보통 OS나 서버(웹, 어플리케이션, DB 등) 이미지 이다. 매번 공통 이미지를 다시 만들지 않고 재 사용하는 잇점을 제공 한다
  • 코드의 컴파일 또는 빌드 : 저장소(git과 같은)에서 코드를 다운로드하여 단위 테스트 후 어플리케이션을 빌드 한다
  • 서버에 필요한 설정 파일을 설정 한다
  • 서버가 사용하는 기본 포트, 볼륨을 정의 한다
  • 서버가 기동할 실행 스크립트를 정의 한다

이렇게 작성된 빌드 파일을 빌드 명령어로 (예 : docker build) 수행하면 컨테이너의 이미지가 생성되며 다른 환경에서 이 이미지를 사용 할 수 있도록 이미지 저장소에 등록 한다(예: docker push). 이미지 저장소는 빌드 버젼에 따라 이미지를 관리 한다.

이렇게 빌드된 컨테이너 이미지는 로컬 개발 환경, 서버 환경 등 어디든 배포 되어 실행 되며, 운영과 동일 한 환경으로 테스트를 수행 할 수 있다.

컨테이너 기반의 DevOps는 컨테이너 빌드의 전 과정을 자동화 할 수 있다. 예를 들어 Docker의 경우 API(프로그래밍 인터페이스)를 제공하여 사용자가 코드를 통해 원하는 형태로 컨테이너 빌드 과정을 자동화 할 수 있도록 지원한다. 또한 한번 작성된 빌드 파일은 변경 시 코드 처럼 변경 추적 및 버젼 관리가 가능하고, 유사한 형태에 재사용 될 수 있도록 베이스 이미지화 할 수 있어  공유 및 재 사용이 가능 하다.(개발 코드와 관리 하는 방식이 동일 하다)

다음은 오픈 소스인 도커(Docker)를 기준으로 한 컨테이너 빌드 흐름을 도식 화 한 것이다.

docker-build-process

출처 : Automating Docker Image Builds With Continuous Integration (https://blog.newrelic.com/2016/09/21/docker-images-continuous-integration/)

릴리즈, 배포 그리고 운영 : Container Orchestration

운영을 위한 컨테이너 배포는 데이터 센터 또는 클라우드 인프라 상에서 수행 한다. 실 운영 환경은 컨테이너(어플리케이션) 실행에 필요한 CPU, Memory등 리소스를 할당하고 컨테이너 간 통신을 위한 네트워크, 데이터 저장을 위한 스토리지 등 인프라의 제공 하는데,  컨테이너 오케스트레이션(Container Orchestration) 플랫폼이 이 역할을 담당한다.

컨테이너 오케스트레이션 플랫폼은 컨테이너 배포 및 운영에 있어 자동화된 “동적 관리(Dynamic Management)”를 수행하는 핵심 요소이다. 앞서 이야기한 동적 인프라와 같이 컨테이너를 단위로 사람의 개입 없이 운영 환경을 제어 한다.

컨테이너 오케스트레이션이 수행 하는 주요 역할은 다음과 같다

  • 스케쥴링(Scheduling) : 컨테이너 실행에 필요한 운영 인프라 자원을 할당. 여러대의 서버 하드웨어(노드)가 있을 경우 자원 가용량에 따라 최적의 노드에 배치. 통신을 위한 네트워크와 볼륨을 할당
  • 컨트롤링(Controlling) : 배포에서 요청 한 스펙과 현 상태를 비교하여 항 상 같은 상태를 유지 할 수 있도록 조정 
  • 자가 복구(Self Healing) : 컨테이너 헬스 체크(Health Check)를 통해 문제가 있는 컨테이너를 재기동. 인프라에 문제 가 있을 경우  정상 인프라에 재배치
  • 오토 스케일링(Auto Scaling) : CPU와 같이 컨테이너 자원 사용량을 기준으로 수평적 스케일링(Scale-out)을 수행
  • 롤링 업데이트(Rolling Update) : 서비스에 영향 없이 컨테이너를 업데이트

컨테이너 오케스트레이션을 위해서는 인프라가 클러스터 형태로 구성되어야 한다. 클러스터는 하나 이상의 노드와 컨테이너 네트워크, 외부 볼륨 등으로 구성되는데 가상화 기반의 클라우드 인 경우 인프라 프로비져닝을 자동화 할 수 있다.

이러한 동적 관리 환경은 DevOps에서 배포, 운영 업무를 효율화 하며 안정된 어플리케이션 또는 서비스의 운영을 지원한다. 컨테이너 빌드와 같이 배포에 관한 정보도 정의 파일을 통해 관리 되어 반복적인 업무를 최소화 하고 릴리즈에 대한 버젼 관리를 수행 할 수 있다.

컨테이너 오케스트레이션 기반의 동적 관리 환경의 특징을 정리 하면 다음과 같다

그림1

모니터링

컨테이너 모니터링은 오케스트레이션과 함께 제공 된다. 컨테이너 운영 시 가장 주요한 모니터링 대상은 CPU, Memory 등 자원의 사용량이다. 동적 관리 환경에서 오류 복구나 스케일링 등은 자원의 사용량 또는 상태를 기준으로 자동으로 수행 된다. 이 경우 문제가 발생 시 사람의 개입 보다는 자동화 복구에 필요한 환경을 관리 하는 것이 더 중요하다. 따라서 운영자는 모니터링을 통해 자원 사용량을 추적하고 전체 가용량을 확인하여 운영에 필요한 인프라를 유지/관리 하여야 한다.

축적된 모니터링 데이터는 문제에 대한 원인 파악과 자원의 가용량 예측등에 사용된다. 따라서 자원 사용량 이외에도 로그 수집/분석, 이벤트 등의 정보를 통합하여 관리 하여야 한다. 이 부분은 어플리케이션 또는 운영 전략에 따라 다양한 요구가 있을 수 있으므로 자신에 맞는 모니터링 환경을 구성하는 것이 필요하다.

다음은 컨테이너와 오케스트레이션 모니터링 구성 예이다

full_stack_container_monitoring-1

출처 : What does “full stack” monitoring mean for container environments? – JAXenter (https://jaxenter.com/full-stack-monitoring-container-135539.html)

마이크로 서비스와 찰떡 궁합인 컨테이너

마이크로 서비스(Micro Service)는 클라우드 컴퓨팅의 확산과 함께 주목 받고 있는 어플리케이션 아키텍처 스타일이다.

마이크로 서비스는 어플리케이션을 구성하는 모듈을 독립된 서비스로 분리하고 각 서비스가 하나의 워크로드(Workload)을 책임지도록 구성한다. 이 독립화 된 서비스를 마이크로 서비스라 부른다. 마이크로 서비스는 서로 가볍고 표준화된 프로토콜을 통해 데이터를 주고 받아 전체 어플리케이션 로직을 처리하는데 보통은 웹프로토콜(HTTP REST)을 사용한다.

다음은 마이크로 서비스의 개념을 도식화 한 예이다

decentralised-data

출처 : Microservices (https://martinfowler.com/articles/microservices.html)

이러한 마이크로 서비스로 구성된 어플리케이션은 기존(비교하는 말로 모노리틱, Monolithic 어플리케이션이라 부른다)에 비해 다음과 같은 장점을 가진다.

  • 어플리케이션 업데이트 시 전체가 아닌 일부 마이크로 서비스를 대상으로 함으로 테스트와 배포의 노력을 절감 할 수 있고 민첩한 요구 대응이 가능 하다
  • 마이크로 서비스는 독립된 워크로드로 자체 아키텍처와 언어로 개발/운영되어 어플리케이션 각 모듈간 의존도를 없애고 확장이 용이한 장점을 제공한다
  • 신규 어플리케이션 개발 시 기존 마이크로 서비스를 재사용 할 수 있다

마이크로 서비스 아키텍처는 다수의 서비스를 결합한 구성을 가진다. 즉 기존 어플리케이션에 비해 관리하고 운영할 대상이 늘어나며, 각각의 서비스 자원 할당과 스케일링등의 조정이 매우 중요하다. 따라서 마이크로 서비스는 컨테이너로 구성하고 배포, 운영하는 것이 매우 유리 하다.

이 점을 말해 주듯이 최근 마이크로 서비스는 컨테이너 기술을 통해 확산 되고 있다.  대표적으로 소셜 미디어 업체인 스포티파이(Spotify)의 경우 6천만이 넘는 사용자에게 음악을 제공하고 빠른 요구 대응과 확장을 위해 컨테이너 기반의 마이크로 서비스를 운영 하고 있다(출처 : Containers in Production: Case Studies, Part 1 – The New Stack(https://thenewstack.io/containers-production-part-case-studies/) )


다음 글 : 오픈소스가 주도 하는 클라우드 네이티브 생태계
이전 글 : 컨테이너 기반의 클라우드 네이티브 컴퓨팅 시대 도래

 

컨테이너 기반의 클라우드 네이티브 컴퓨팅 시대 도래(2/3)

컨테이너 기반의 클라우드 네이티브 컴퓨팅 시대 도래(1/3)

클라우드 네이티브 컴퓨팅에 대한 내용을 요약하여 공유 합니다. 길이가 길어 총 3편으로 나누 었습니다

도움이 되었으면 합니다


 

최근 클라우드 컴퓨팅에 컨테이너 기술을 접목한 새로운 컴퓨팅 환경이 주목을 받고 있다. 클라우드 네이티브 컴퓨팅(Cloud Native Computing)이 그 것이다.

클라우드 네이티브 컴퓨팅은 어플리케이션 또는 서비스 시스템 관리를 컨테이너 기반 기술로 자동화 한 환경으로, 기존 환경에 비해 시스템 안정성을 높이고 운영/관리 업무의 효율화와 비즈니스 요구에 대한 빠른 응대, 시스템 확장이 용이한 특징을 가진다.

이러한 장점으로 최근 IT 기술 중심 기업을 시작으로 점차 도입이 확산 되고 있다. 미국 소재의 산업 분석 전문 블로그 미디어인  RedMonk가 조사한 바에 따르면 2017년을 기준으로 포츈 100대 기업 중 클라우드 네이티브 기술을 도입한 기업이 70%를 넘어 섰으며, IT 기업 뿐아니라 금융, 리테일 등 다양한 산업 군으로 확장 되는 추세이다.

cloudnative-f100-percent

출처 : Cloud Native Technologies in the Fortune 100 – Charting Stacks (http://redmonk.com/fryan/2017/09/10/cloud-native-technologies-in-the-fortune-100/)

또한 리눅스 재단 산하의 Cloud Native Computing Foundation(CNCF)의 2017년 커뮤니티 맴버에 대한 설문에 따르면 응답자 550개 기업 중 250개 이상의 컨테이너를 배포하고 운영 중인 기업이 49%에 달한다.  CNCF의 커뮤니티가 IT를 대표 하는 글로벌 기업인 점과 미국 뿐아니라 유럽의 기업들이 다수 포함되어 있다는 점을 고려하면 의미 있는 결과라 할 수 있다.

chart5

출처 : Cloud Native Technologies Are Scaling Production Applications – Cloud Native Computing Foundation(https://www.cncf.io/blog/2017/12/06/cloud-native-technologies-scaling-production-applications/)

기존 클라우드 공급자들와 IT기업들도 앞다투어 컨테이너 관련 솔루션 또는 서비스를 출시 하고 있다

  • Google : 컨테이너 오케스트레이션 엔진인 Kubernetes 개발, 오픈소스 화. 구글 클라우드 플랫폼에서 Google Kubernetes Engine(GKE) 컨테이너 서비스 제공
  • Microsoft Azure : 컨테이너 서비스 Azure Container Service (ACS) 제공
  • AWS : 두 형태의 컨테이너 서비스 제공. Elastic Container Service(ECS), Elastic Kubernetes Service(EKS)
  • IBM : Bluemix 컨테이너 관리 플랫폼과 Cloud Private 클라우드 플랫폼 재공
  • RedHat : Openshift 컨테이너 관리 플랫폼과 컨테이너 운영체계 등 핵심 기술 보유 기업인 CoreOS 인수
  • 시스코 : CISCO Container Platform 출시

글로벌 IT기업의 대표 주자 격인 이들 기업 모두 컨테이너를 기반으로 하는 클라우드 컴퓨팅 또는 서비스 제품을 출시하고 지속적인 투자를 하고 있다.  이와 같은 추세를 볼 때 클라우드 네이티브 컴퓨팅이 미래 컴퓨팅 환경으로 자리잡을 것은 명백한 듯 하다

 

그럼 왜 컨테이너 기반의 클라우드 컴퓨팅 환경에 주목을 하는 것일까 ? 여러가지 이유가 있지만 시스템 관리측면의 변화를 살펴 보면 그 해답을 얻을 수 있다.

시스템 관리 방법의 변화 : 정적 인프라 -> 동적 인프라 -> 컨테이너

이 곳에서 말하는 시스템은 어플리케이션 또는 서비스를 구성하는 서버(Server)를 대상으로 함을 먼저 말해 둔다. 원래 시스템은 서버 뿐아니라 네트워크, 스토리지 등과 같은 인프라, 보안 등의 요소들이 더 있지만 컨테이너는 서버 관리에 대한 기술로써 많이 활용 됨으로 이 부분을 이해하는 것이 적합 하다고 생각한다.

서버는 특정 기능과 데이터를 제공하는 시스템의 구성 요소 이다. 흔희 이야기하는 웹서버는 웹상에서 문자와 이미지, 동영상을 제공하는 역할을 담당한다. 이외에도 비즈니스 로직이나 데이터, 캐시, 스트리밍 등 다양한 역할의 서버가 있다.

정적 인프라

클라우드 이전, 정확히 말하면 가상화(Virtualization)이전의 서버는 하드웨어(Hardware)와 한 몸으로 관리 되었다. 하드웨어 상에 운영체계(OS)를 설치 하고 서버 구성에 필요한 라이브러리, 미들웨어, 코드등 소프트웨어를 설치 하여 구성하였다. 한번 서버가 구성(생성) 되면 변경은 서버에 로그인 후 명령어나 스크립트를 통해 수행하였고 이 때 서비스에 영향이 없도록 세심한 주의와 노력이 필요 하다.

서버의 하드웨어 준비와 구성에 시간이 들고 변경 시 영향도를 고려 할 때 자유 스럽지 못한 점등으로 이를 “정적 인프라”라 부른다. (이와 반대 되는 개념을 이후 설명 할 “동적 인프라”라 부른다) 즉 서버의 구성 뿐 아니라 관리 방식을 고려한 명칭이다.

  

정적 인프라를 좋다 나쁘다를 기준으로 이야기 할 수 없다. 시스템 마다 다른 특성과 구성을 가지고 있으므로 정적 인프라 방식이 적합한 시스템도 있다.

하지만 클라우드가 등장 한 후 정적 인프라는 관리 효율화 면에서 개선의 대상이 되었고 근래에 들어서는 점차 줄어 들고 있는 추세이다

동적 인프라

서버 등 하드웨어 가상화 기술을 기반으로 하는 클라우드가 확산 됨에 따라 서버에서 하드웨어가 분리되기 시작 했다. 즉, 가상화 서버(가상 머신)은 하드웨어와 하이퍼바이져(Hypervisor)상에 실행되는 개념으로 서버를 준비(Provisioning)하는 과정이 운영체계 이미지를 대상 하드웨어 상에서 실행하는 방식으로 바뀐 것이다.

한 발 더 나아가 가상 머신을 운영체계 뿐 아니라 서버에 필요한 소프트웨어 까지 구성하여 이미지 화 한 후 이것을 인프라 위에서 실행 함으로써 준비와 배포에 드는 시간과 노력을 획기적으로 줄일 수 있게 되었다. 이렇게 이미지화 하는 데는 별도 관리 소프트웨어나 코드를 통해 가능하다.

이렇듯 소프트웨어 또는 코드를 통해 서버를 구성하고 배포하는 방식의 인프라를 “동적 인프라”라고 한다

서버를 예로 들었지만 사실 가상화 된 인프라에서는 모든 것을 코드화 하여 동적으로 구성, 변경하고 관리 할 수 있다. 이를 “코드로서의 인프라”(Infrastructure as Code) 관리 방식이라 한다.(Kief Morris의 동 제목 저서 참고, O’REILLY)

동적 인프라는 코드로서 관리 된다.  즉 사람의 개입을 최소화 하고 운영/관리를 자동화 할 수 있으며 특히 변경에 대한 버젼 관리, 추적등 일원화 할 수 있다는 점에서 기존 정적 인프라 보다는 높은 효율화를 얻을 수 있다. 서버의 경우 표준 구성을 코드화하고 이미지를 통해 교체 하는 방식으로 배포, 변경 함으로써 서비스에 대한 영향도가 적고 구성과 변경에 대한 오류를 최소화 할 수 있다는 장점이 있다.(Kief Morris의 저서에서는 이를 불변 서버(Immutable Server)라 부른다) 무엇보다 모든 과정을 자동화 한다는 것이 가장 큰 매력이 될 수 있다

따라서 클라우드 기반 컴퓨팅 환경하에서는 인프라 운영/관리 효율성을 높일 수 가 있다. 하지만 한가지 고려해야 할 점이 있다. 가상화 인프라 환경을 도입한 기업들 중에서도 관리 방식을 기존 “정적 인프라” 방식으로 운영 하는 경우를 흔히 볼 수 있다. 즉 가상머신의 준비(프로비져닝)만을 자동화 하고 서버 구성과 변경은 기존 로그인 후 처리 방식으로 하는 경우인데, 이 경우에는 동적 인프라의 장점을 반쪽 만 얻을 수 밖에 없다.

동적 인프라 방식을 잘 적용한 사례 중 하나가 최대의 온라인 VOD 서비스인 넷플릭스(Netfilx)이다.글로벌 클라우드 선두 주자인 AWS 인프라를 통해 모든 과정을 자동화 하여 빠르게 변화하고 확장 하는 시스템의 요구를 동적 인프라를 통해 유연하게 대응 한 예 이다. 그 결과 물은  Netflix OSS(Netflix Open Source Software Center, https://netflix.github.io/) 에 오픈소프로 공개 되어 있다.

컨테이너

앞서 이야기 한 동적 인프라가 주는 잇점은 매우 크다. 하지만 컨테이너의 등장으로  동적 인프라는 새로운 전환을 맞이하게 된다.

컨테이너는 운영체계 상에서 소프트웨어를 독립적으로 실행 할 수 있는 일종의 OS 가상화 기술이다. 앞서 가상머신이 하드웨어를 분리 하였다면 컨테이너는 OS와 어플리케이션 또는 서버 소프트웨어를 분리 하여 관리 할 수 가 있다.(이 때문에 컨테이너를 Micro-VM이라 하기도 한다)

서버 측면에서 컨테이너와 가상 머신과 비교하면 운영/관리 상 다음과 같은 주요 특징이 있다

  • 가상 머신의 기동, 재기동에 시간이 소요 된다.(오토 스케일링과 같은 빠른 확장이 필요 할 경우 약점이 된다). 컨테이너의 경우 OS상에서 기동되는 프로세스를 가상화 함으로써 기동/재기동 속도가 빠르다
  • 서로 다른 하이퍼바이져에서는 가상 머신의 이미지가 호환 되지 않아 이동성이 떨어 진다. 컨테이너는 인프라와 무관하게 어디든 배포/실행 할 수 있다.(컨테이너는 리눅스 재단을 통해 표준화 되어 있다)
  • 가상 머신과 같이 컨테이너도 독립 실행된다. 따라서 서버의 구성, 운영/관리에 적합 하다

다음은 가상 머신과 컨테이너의 가상화 형태 비교를 도식화 한 것이다

ContainerVsVM

출처 : Container Technology Chapter 1 | Docker, VM, LXC & Container Basics (https://www.twistlock.com/resources/all-about-container-technology/)

컨테이너가 세상에 알려 진 데는 오픈 소스인 도커(Docker)가 큰 역할을 하였다. 도커는 리눅스 기술이 었던 컨테이너를 활용 하는데 필요한 도구와 함께 제공 함으로써 개발자를 중심으로 로컬 개발 환경을 구성하고 관리하는데 널라은 경험을 제공하였다. 이 후 서버에 적용 되는데는 구글의 오픈 소스인 Kubernetes(K8s)가 한 몫 하였다. K8s는 다수의 서버 인프라(노드)를 클러스터로 구성하고 컨테이너를 배포 관리 하는 환경을 제공하여 앞서 보았듯이 다수의 기업들이 자사의 어플리케이션 및 서비스에 핵심 플랫폼으로 사용하고 있다.

동적 인프라를 가볍고 이동성이 뛰어난 컨테이너로 관리하고 자동화 하는 환경도 지속적으로 발전하여 현재는 클라우드 네이티브 컴퓨팅(Cloud Native Computing)이라 부르고 클라우드 네이티브 컴퓨팅 재단(Cloud Native Computing Foundation, CNCF.io)에서 구글, AWS, MS등 주요 IT기업들의 참여 속에 관리 되고 있다.

Members_-_Cloud_Native_Computing_Foundation

출처 : Cloud Native Computing Foundation Platinum Members,(https://www.cncf.io/about/members/)

컨테이너는 기존 클라우드 컴퓨팅을 획기적으로 효율화 하였고, 현재도 계속해서 확산되고 있는 추세이다. 동적 인프라가 가지는 장점에 가볍고 이동성이 뛰어나다는 것이 더 얹어져 앞으로도 당분간은 서버외에도 다양한 분야에서 널리 활용 될 것으로 예상 된다.


다음 글 : DevOps 컨테이너로 날개를 달다

컨테이너 기반의 클라우드 네이티브 컴퓨팅 시대 도래(1/3)

Cloud Native Computing

지난 주말 인터넷 서핑을 하다가 Cloud Native Computing Foundation(클라우드 네이티브 컴퓨팅 재단, https://www.cncf.io/) 홈페이지를 방문하였다. 이전에 제품 기획을 하다가 Cloud Native Application 이란 컨셉을 접한 적이 있었는데, 당시 이 재단에 대해 언급한 글이 생각나서 이것 저것 훑어 보니 “어?” 라는 소리가 나올 정도로 빠르게 성장하고 있었다.

클라우드에 종사하는 사람들 조차 클라우드 네이티브라는 용어가 생소 할 만큼 이 재단의 역사는 그리 오래되지 않았다. 2015년 7월에 설립되고 구글을 비롯한 다수의 오픈소스 맴버들이 자신의 오픈 소스를 이곳 프로젝트로 등록하여 클라우드 네이티브 컴퓨팅이라는 비젼하에 시스템에 필요한 스택을 제공하여 운영되고 있는데 현재 88개 업체가 맴버로 등록 될 만큼 규모가 커졌다. 우리나라에서는 삼성SDS와 NCSOFT가 참여 하고 있다.

[클라우드 네이티브 컴퓨팅 재단의 Platinum 맴버]

이 재단은 기존 다른 오픈소스 재단과는 다른 면을 가지고 있다. 이 재단에서 프로젝트로 진행되는 오픈소스는 이전에는 맴버사가 개별로 운영하던 것이었다. 이것을 클라우드 네이티브라는 컨셉을 시스템화 하는 스택으로 통합하여 제공한다는 것이다. 즉 개별 프로젝트 보다 상생과 시너지를 더하는 모습니다.

[현재 재단에서 운영하는 프로젝트]

[Cloud Native system 참조 아키텍처]

재단에서 이야기하는 클라우드 네이티브라는 컨셉은 어플리케이션에 무게를 두고 있다.쉽게 이야기 하면 클라우드상에서는 클라우드에 최적화된 어플리케이션을 구축하고 운영해야 한다는 것이다. PC의 경우 웹브라우져를 통해 사용하는 Web App과 OS 라이브러리 기반의 네이티브 App과 차이를 생각하면 된다. 성능과 OS의 자원을 충분히 사용한다는 점에서 웹앱 보다는 네이티브 앱이 가지는 장점이 있다. 클라우드 네이티브도 클라우드의 자원과 특성, 장점등을 충분히 활용하는 시스템과 어플리케이션을 구축, 운영한다는 점에서 PC의 경우와 유사하다.

클라우드 네이티브 시스템은 다음과 같은 특성을 가진다

  • Container packaged
  • Dynamically managed
  • Micro service oriented

Container packaged란 어플리케이션을 컨테이너로 패지징하고 배포/실행 한다는 것이다. 컨테이너는 리눅스로 부터 시작된 기술로 어플리케이션에 필요한 모든 컴포넌트가 단일 이미지로(파일) 패키징되고 실행시 격리된 독립 공간에 필요한 CPU, 메모리, 네트워크등의 자원을 할당하여 실행됨으로 배포가 용이하고 인프라 자원의 이용률을 최적화 할 수 있는 장점이 있다. 나도 많이 경험 하였지만 아무리 잘 개발된 어플리케이션도 실행 시 서버의 CPU자원을 100%로 사용하지는 못한다. 컨테이너로 패키징 하여 배포하면 하나의 서버에서도 같은 또는 다른 여러 어플리케이션을 필요한 만큼 자원을 할당하여 실행 할 수 있기 때문에 유휴 자원을 활용할 수 있고 클라우드 인프라 비용을 효율화 할수 있다.

Dynamically managed는 컨테이너를 다수의 컴퓨팅 노드(서버,VM,인스턴스 등)의 자원을 분석하여 배치하고(Scheduling) 다중화, 스케일링, 노드 오류 시 재배치, 무중단 업데이트(롤링 업데이트)등의 작업을 동적으로 자동화 하는 개념이다. 이를 컨테이너 오케스트레이션(Orchestration)이라 하는데 어플리케이션 운영 작업을 자동화 할 수 있어 기존 보다 업무 효율과 어플리케이션의 가용성, 확장성을 획기적으로 높일 수 있다. 오케스트레이션은 구글이 자체 클라우드에서 적용하고 관련 기술을 오픈 소스로 공개 하여 알려 졌는데 현재는 많은 기업에서 활용 할 만큼 효과가 입증 되어 있다.

Micro service oriented는 기존 모노리틱(Monolitic)한 어플리케이션을 작은 단위의 서비스로 분리, 경량화 하고 API를 통해 재사용 할 수 있도록 만드는 아키텍처로 서비스의 배포/업데이트가 민첩해지고 레고 블럭과 같이 기존 서비스와 신규 서비스를 재구성하여 빠르게 비즈니스 요구에 대응 할 수 있는 장점이 있다. 우리나라도 마찬가지이지만 기존 어플리케이션 아키텍처를 전환하는 부담으로 아직은 널리 사용되고 있지는 않지만 최근 신규 개발 서비스를 중심으로 확산 추세에 있다.

기술적인 이해를 접어두더라도 재단에서 이야기하는 클라우드 네이티브 컨셉은 기존 클라우드 기반 어플리케이션을 변화 시키기 충분하다. 클라우드 네이티브 컴퓨팅 재단은 앞서 이야기 했듯이 이 컨셉을 구현하기 위한 전체 오픈소스 스택을 제공하고 있으며 각 오픈소스 프로젝트의 로드맵도 상호운영을 기저에 둔 형태로 운영되고 있다.

클라우드 업종에 종사하는 터라 자의 반 타의 반으로 이 재단에 관심을 두고 있지만 어찌보면 곧 다가올 클라우드 트랜드로 생각 되어 현재 재단의 빠른 성장과 확장이 당연한 듯 느껴진다.

클라우드를 도입하는 경우 기존 어플리케이션의 이전 또는 전환이 필요한데 이때 클라우드 네이티브를 적용 하는 사례가 많아지게 되지 않을까…

Cloud Native Computing

내 Evernote에 Inbox가 있는 이유

Evernote(에버노트)를 쓴지 3년정도 되어가는 군요. 처음에는 건망증 때문에 보조기억장치로 사용하다가 지금은 내가 하는 대부분의 일에 활용하고 있습니다. 뭐 특별히 에버노트 파워 유저는 아니지만 언제 어디서든지 스마트폰이건 태블릿이건 노트북이건 가리지 않고 기록하고 검색할수 있다는 점이 자꾸 에버노트를 사용하게 만드는 것 같습니다.

에버노트를 사용할 때 저만의 방법이 하나 있습니다. 바로 Inbox 노트북을 만들고 무엇이든 기록할때 먼저 이 노트북에 기록하는 것인데요. 이렇게 사용한지는 한 1년 전부터 입니다.

Inbox라는 이름은 메일에서 따온것은 아니고 GTD(Getting Things Done)이라는 할일 관리 방법론에서 가져 왔습니다.

GTD에서는 자신의 머리속에 있는 모든 할일에 대한 생각을 Inbox에 적거나 모아 놓고 바로 할수 있는 것은 즉시 처리하고, 일의 중요도에 따라 다음(Next), SomeDay와 같은 분류로 나누어 처리하는 방법을 제안 합니다. 더 많은 방법이 GTD에 있지만 가장 중요한 “우선 모으고 처리한다”라는 개념만 가져온 것 입니다.

한가지 예를 들어 보겠습니다. 인터넷을 서핑하다가 괜찮은 맥용 유틸리티 발견하였습니다. 침대에 누워 자기전 아이패드를 사용하고 있어 바로 다운로드를 할 수 도 없고 졸린지라 나중에 받기로 결정 합니다. 이때 이 유틸리티의 소개 블로그 주소를 에버노트 Inbox에 스크랩 해 둡니다. 조금만 더 서핑을 즐기다 읽을 만한 영문 블로그 포스트를 발견합니다. 해석하는 데도 시간이 걸리고 집중해서 봐야 하는거라 이것도 Inbox에 스크랩합니다. 그리고 브라우져를 닫을 즈음 다음주에 작성해야 할 보고서의 내용에 대한 아이디어가 갑자기 떠올라 이것도 까먹지 않도록 Inbox에 노트를 만들어 메모 해 둡니다. 그리고 잠에 바로 빠집니다.

다음날 아침 회사에 조금 일찍 출근 한 저는 가장 먼저 Inbox 노트북을 엽니다. 유틸리티를 다운 받아 설치하고 해당 노트는 지웁니다. 보고서 아이디어는 목차와 내용을 정리해둔 해당 노트북으로 옮겨 놓고 내용에 반영 합니다. 마지막으로 커피 한잔을 탄 후 영문 블로그를 천천히 읽고 내용을 스크랩 노트에 요약 하고 스크랩 노트북으로 옮겨 놓습니다.

이렇게 저는 모든 것을 우선 Inbox노트북에 기록 합니다. 고민 없이 말이죠. 그러면 Inbox에 있는 노트는 해야 할일과도 같습니다. 해치워야 할 것들이죠. 그래서 그런지 Inbox에 노트 하나라도 있으면 무언가 개운치 않고 다 비워지면 해우소에 온듯한 시원함과 뿌듯한 기분이 듭니다.

그리고 Inbox노트북은 필터 역할도 합니다. 스크랩, 아이디어등을 여러 노트북에 나누어 기록하면 이후에 잘 열어보지 않고 왜 스크랩했는지, 아이디어를 어떻게 생각 했는지 기억 할수 없을 때도 많습니다.하지만 Inbox 한 노트북에 일단 스크랩 한 후, 틈틈히 리뷰하고 지울건 지우고 내용을 보충할 건 하고 보관하기 때문에 좀더 가치 있는 기록을 만들고 활용 할 수 있습니다.

결국 Inbox 노트북은 저에게는 할일 도구이자 임시 보관소인 것입니다.

이것이 제 에버노트에 Inbox가 있는 이유 입니다.

내 Evernote에 Inbox가 있는 이유

에버노트로 WordPress 블로그에 포스팅 하기

에버노트(http://www.evernote.com/)는 내가 가장 많이 사용하는 도구 중 하나이다.

내가 에버노트를 사용하는 곳을 몇 가지 살펴보면 다음과 같다

  • 생각의 정리(아이디어)
  • 웹에서의 정보수집(스크랩)
  • 문서만들기(조각조각 적어 놓았다가 나중에 문서로 편집)
  • 보조기억장치(까먹지 말아야 할 것을 적어 놓음)
  • 프로젝트 관련 기록(회의록, 아이디어, 할일, 이슈 등)

이것 말고도 여러 방면에서 활용하고 있으나, 그동안 가장 아쉬웠던 것은 바로 블로그 포스팅이었다.

에버노트는 다양한 디바이스를 지원하기 때문에 집 과 회사 노트북 간, 이동중 모바일 기기에서 짬날 때마다 생각난 것을 기록하거나 틈틈히 글을 작성할 수 있는 장점이 있다. 하지만 작성한글을 내가 사용하는 블로그인 WordPress에 올리려 하면 Copy & Paste하고 이미지의 경우 별도로 업로드 해야 하는 불편함이 있었다. 때문에 작성과는 별도로 블로그에 올리는 작업은 매우 귀찮은 작업 중 하나였다.

하지만 오늘 무심코 구글링을 하다가 이를 해결할 수 있는 방법을 찾았다.

방법은 바로 “이메일을 이용한 블로그 포스팅”이었다.

방법은 의외로 간단하다

  1. 먼저 워드프레스의 Dashboard의 내블로그(My Blogs)메뉴를 선택한다
  2. 블로그 리스트의 컬럼 중 “Post by Email”의 Enable 버튼을 클릭한다
  3. 버튼을 클릭하면 포스팅을 할 이메일 주소가 나오는데 이를 주소록에 등록하거나 잘 기억해둔다
  4. 에버노트로 글을 작성한 후 공유메뉴의 “이메일로 보내기…”를 눌러 포스틍 이메일주소를 넣고 발송한다.
  5. 블로그에 들어가 확인해 보면 등록이 된 것을 확인 할 수 있다.

시험삼아 나도 글을 에버노트로 작성한 후 이메일로 등록 해 보았다. 잘되었다. 더군다나 이미지의 경우 자동으로 미디어라이브러리로 업로드되어 화면에 나타났다.(조금 놀랐음)

하지만 주의할 점이 있다. 이미지를 여러개 글에 넣으면 워드프레스는 자동으로 하나만 본문에 넣고, 나머지는 갤러리 방식으로 문서 끝에 넣는데 이것을 막을려면 문서 내에 라는 Shortcode를 넣으면 된다. Shortcode는 이메일을 보낼 때 본문에 추가시켜 포스팅의 설정을 할수 있는 것으로 문서내(보통은 맨 앞 부분에 []를 넣어 사용한다. ShortCode의 종류는 다음과 같다. 자세한 내용은 http://en.support.wordpress.com/post-by-email/를 참조하라(Shortcode가 적용되어 이미지를 캡처해서 올렸다)

그리고 몇가지 더 알아둘점

  • 포스팅 된 글에는 From EverNote라는 링크가 삽입된다. 아마도 에버노트에서 자동 삽입되는 것 같은데 지울수 있는 방법은 글을 status 의 pending Shortcode로 올리고, 워드프레스에 가서 올라온 글을 편집하여 지우면 된다.(어차피 제대로 올라 갔는지 확인은 한번 하지 않는가?)
  • 그리고 만약 잘못 올려서 지우고 다시 올릴경우 글 내에 이미지는 중복되어 계속 업로드 된다. 이경우 워드프레스의 미디어 메뉴에서 찾아 지우면 된다.

에버노트로 블로그 글 까지 작성하고 포스팅을 할 수 있게 된 것도 흥미 있는 일이지만

하나의 도구가 이렇게 까지 활용도가 높다는 것이 더더욱 흥미롭다

시간이 나면 내가 사용하는 에버노트 활용법을 정리하여 포스팅 하겠다.

에버노트로 WordPress 블로그에 포스팅 하기