2017.08.03

“컨테이너 주도권 노린다” 마이크로소프트 애저 컨테이너 인스턴스의 이해

Simon Bisson | InfoWorld
"서비스 형태의 컨테이너"는 오버헤드 없이, 손쉬운 명령 스크립트를 통해 쿠버네티스 애플리케이션을 포함한 컨테이너화된 애플리케이션을 신속하게 만들어 실행할 수 있게 해준다.

마이크로소프트 애저가 툴과 인력에 대한 전략적 투자에 힘입어 빠른 속도로 컨테이너 기반의 퍼블릭 클라우드로 탈바꿈하는 중이다. 또한 애저는 정기적으로 새로운 컨테이너 중심의 제품과 서비스를 내놓고 있다. 처음의 애저는 아마존 웹 서비스 기능을 따라하기 급급했지만 PaaS와 IaaS 사이를 잇는 가교 역할을 하는 컨테이너 서비스를 출시하면서 아마존을 뛰어넘었다.

서비스 형태의 컨테이너(Container as a Service)
새로운 종류의 클라우드 플랫폼인 애저 컨테이너 인스턴스(Azure Container Instances, 이하 ACI)는 아무런 오버헤드 없이, 손쉽게 스크립팅 가능한 명령 집합을 사용해서 신속하게 컨테이너화된 애플리케이션을 만들어 실행할 수 있게 해준다. 자체적으로도 작동하고 쿠버네티스 등의 툴과 함께 작동할 수도 있는 ACI는 애저에 컨테이너 관리 명령을 추가하고 이를 초당 사용량을 기반으로 하는 청구 모델과 결합한다. 이 과정에서 컨테이너 호스트를 만들고 배치할(그리고 비용을 지불할) 필요가 없다.

다만 세 가지로 구성된 청구 모델은 약간 복잡하다. 첫째, 컨테이너 인스턴스를 생성하기 위한 요청당 0.0025달러의 고정 요금이 있다. 둘째, 설정된 후 메모리 비용으로 초 단위로 기가바이트당 0.0000125달러가 청구되고, 사용되는 코어 비용으로 초 단위로 코어당 0.0000125달러가 청구된다. 따라서 무엇을 얼마나 오래 사용하는지 주시해야 한다. 특히 대규모 애플리케이션의 확장을 ACI를 사용해 처리할 경우 더 신경 써야 한다.

ACI를 사용하여 컨테이너 배치하기
ACI는 애저 명령줄 인터페이스를 사용하므로 처음 접하는 경우에도 쉽게 ACI 컨테이너를 설정할 수 있다. 현재 버전은 리눅스 컨테이너만 실행할 수 있지만 곧 윈도우 컨테이너도 추가될 것이다. 애저의 컨테이너 서비스를 다룰 때와 마찬가지로 애저 클라우드 셸 또는 원격 애저 명령줄 인스턴스를 사용해서 ACI 컨테이너를 위한 리소스 그룹 생성을 시작으로 컨테이너를 구축하고 관리하게 된다.

명령줄 컨테이너 명령은 사용하기 쉽다. 이 명령들을 사용해서 ACI에서 사용할 컨테이너를 정의할 수 있다. 기반 호스트 VM을 구축하고 시작할 필요가 없기 때문에 기존 리포지토리에서 컨테이너를 배포하는 과정은 간단하다. ACI가 기존 VM을 컨테이너에 할당하므로 설정하고 실행하는 데 소요되는 시간은 몇 초 정도에 불과하다. 컨테이너를 배치하는 데 사용되는 요청에서 필요한 메모리와 사용할 코어의 수도 정의할 수 있다.

컨테이너 상태의 세부 사항을 받는 JSON 형식의 명령이 있다. 실제 작업에서는 ACI에 컨테이너를 배포하는 스크립트를 작성하고, 이를 데이터센터 OS에서 실행하거나 지속적 통합 플랫폼의 빌드 프로세스 일부로 실행하게 된다. JSON 상태 데이터는 퍼블릭 및 프라이빗 서비스 사이의 네트워킹 서비스 또는 연결을 구성한다.

여기에는 자동화를 위한 여지가 상당히 많고, 애저 CLI는 배시(Bash)를 기반으로 하므로 특히 스크립팅에 적합하다. 마이크로소프트는 클라우드 셸의 파워셸 릴리스와 애저 CLI를 약속했는데, 파워셸이 ACI와 어떻게 상호 작용하게 될지 흥미롭게 지켜볼 일이다.

배포된 컨테이너는 공용 IP 주소 또는 비공개 내부 주소로 실행된다. 공용 주소는 공개된 서비스를 호스팅할 수 있으며, 비공개 주소는 공용 인터페이스를 지원하는 데 사용되는 비공개 애플리케이션이나 내부 서비스에 적합하다. 마이크로소프트의 초기 ACI 문서 대부분은 확장 가능한 웹 애플리케이션을 위해 고밀도 웹 서버를 호스트로 배포하는 웹 서비스를 위한 호스트에 초점을 두고 있다. 문서에서 유용한 Node.js 애플리케이션 배포 방법을 찾을 수 있다.

쿠버네티스와 함께 대규모로 ACI 사용하기
ACI는 테스트 및 개발을 위해 신속하게 컨테이너를 배포하기 위한 툴로 상당히 효과적이지만 특히 쿠버네티스와 함께 사용할 경우 프로덕션 용도로도 유용한 툴이다. 유용한 기능인 컨테이너 그룹을 쿠버네티스 팟(pod)으로 포장하는 기능이 아직 실험 단계라는 점은 아쉽다. 쿠버네티스용 ACI 커넥터는 오픈소스 프로젝트로 깃허브에 호스팅되므로 쿠버네티스에서 ACI에 컨테이너를 배포할 수 있다.

ACI 커넥터를 사용한 작업은 일반적인 큐브릿(kubelet) 작업과 마찬가지이며 컨테이너 팟을 호스팅하고 관리하기 위한 명령줄을 사용한다. 커넥터는 ACI를 무제한 용량 노드로 등록한다. 일단 등록되면 노드 이름을 사용해 ACI 계정에서 팟을 실행하고 익숙한 쿠버네티스 명령을 사용해 컨테이너를 생성 및 해체하면 된다. 이 기능을 사용하기 위해 애저에서 쿠버네티스를 실행할 필요는 없다. ACI 쿠버네티스 API를 위한 공용 IP 주소만 있으면 된다. 그러면 어느 서비스에서 실행되든 관계없이 모든 쿠버네티스 마스터에서 ACI를 사용할 수 있다.

ACI를 프로덕션 상태까지 끌어오기 위해 마이크로소프트가 쿠버네티스 커뮤니티와 어떻게 협력해 나갈지가 흥미롭다. 충분히 유용하기 때문에 프로덕션 워크로드용으로 권장되지 않음에도 불구하고 사람들은 빠르게 ACI를 도입하고 있다. 그러나 필자의 예상으로 사람들은 온프레미스 환경이나 클라우드 간에 사용하기보다는 주로 애저에서 실행되는 쿠버네티스에서 ACI를 사용하게 될 것으로 보인다.

ACI가 초 단위로 청구된다는 비용 측면의 이점은 쿠버네티스를 사용해서 애플리케이션과 서비스를 잠깐씩 확장하는 경우 상당히 크게 작용한다. 또한 오픈소스 ACI 커넥터는 메소스(Mesos)와 도커 스웜(Docker Swarm)용 커넥터 개발에 도움이 될 것이다.

애저 컨테이너의 미래
마이크로소프트가 ACS와 ACI를 통해 애저 컨테이너에 전념하는 데는 그럴 만한 이유가 있다. 특히 값비싸고 많은 리소스를 소비하는 IaaS 모델에서 벗어나 플랫폼이라는 애저의 뿌리와 긴밀히 연결되는 쪽으로 이동한다는 측면에서 이를 고려하면 더욱 그렇다. 쿠버네티스나 그와 비슷한 것을 사용해 컨테이너를 관리한다면 PaaS에서 실행되는 컨테이너는 자연스러운 다음 단계다.

애저가 컨테이너 확장과 컨테이너 배치를 관리하면 복잡한 가상 인프라를 직접 구축하고 관리하는 데 시간을 들일 이유가 별로 없다. 대신 그 시간 동안 리소스 그룹을 구성 및 관리할 방법을 파악하고 애저의 서비스 패브릭과 같은 메시지 기반 프레임워크를 사용해 컨테이너를 애플리케이션에 연결하는 데 집중할 수 있다. 이 새로운 환경에서 작동하는 코드를 구축하는 작업은 처음 시작할 때는 복잡할 수 있지만 컨테이너를 주 배포 모드로 사용하면 업데이트와 확장이 간소화된다.

현재까지 마이크로소프트는 컨테이너 시장에서 빠른 후발 주자(fast follower)였지만, 최근 데이스(Deis)를 인수했고 지금은 클라우드 네이티브 컴퓨팅 재단(Cloud Native Computing Foundation)의 회원사이기도 하다. 단순히 컨테이너를 사용하는 데 그치지 않고 본격적으로 컨테이너의 개발을 주도하기 위한 태세를 갖췄다.  editor@itworld.co.kr


2017.08.03

“컨테이너 주도권 노린다” 마이크로소프트 애저 컨테이너 인스턴스의 이해

Simon Bisson | InfoWorld
"서비스 형태의 컨테이너"는 오버헤드 없이, 손쉬운 명령 스크립트를 통해 쿠버네티스 애플리케이션을 포함한 컨테이너화된 애플리케이션을 신속하게 만들어 실행할 수 있게 해준다.

마이크로소프트 애저가 툴과 인력에 대한 전략적 투자에 힘입어 빠른 속도로 컨테이너 기반의 퍼블릭 클라우드로 탈바꿈하는 중이다. 또한 애저는 정기적으로 새로운 컨테이너 중심의 제품과 서비스를 내놓고 있다. 처음의 애저는 아마존 웹 서비스 기능을 따라하기 급급했지만 PaaS와 IaaS 사이를 잇는 가교 역할을 하는 컨테이너 서비스를 출시하면서 아마존을 뛰어넘었다.

서비스 형태의 컨테이너(Container as a Service)
새로운 종류의 클라우드 플랫폼인 애저 컨테이너 인스턴스(Azure Container Instances, 이하 ACI)는 아무런 오버헤드 없이, 손쉽게 스크립팅 가능한 명령 집합을 사용해서 신속하게 컨테이너화된 애플리케이션을 만들어 실행할 수 있게 해준다. 자체적으로도 작동하고 쿠버네티스 등의 툴과 함께 작동할 수도 있는 ACI는 애저에 컨테이너 관리 명령을 추가하고 이를 초당 사용량을 기반으로 하는 청구 모델과 결합한다. 이 과정에서 컨테이너 호스트를 만들고 배치할(그리고 비용을 지불할) 필요가 없다.

다만 세 가지로 구성된 청구 모델은 약간 복잡하다. 첫째, 컨테이너 인스턴스를 생성하기 위한 요청당 0.0025달러의 고정 요금이 있다. 둘째, 설정된 후 메모리 비용으로 초 단위로 기가바이트당 0.0000125달러가 청구되고, 사용되는 코어 비용으로 초 단위로 코어당 0.0000125달러가 청구된다. 따라서 무엇을 얼마나 오래 사용하는지 주시해야 한다. 특히 대규모 애플리케이션의 확장을 ACI를 사용해 처리할 경우 더 신경 써야 한다.

ACI를 사용하여 컨테이너 배치하기
ACI는 애저 명령줄 인터페이스를 사용하므로 처음 접하는 경우에도 쉽게 ACI 컨테이너를 설정할 수 있다. 현재 버전은 리눅스 컨테이너만 실행할 수 있지만 곧 윈도우 컨테이너도 추가될 것이다. 애저의 컨테이너 서비스를 다룰 때와 마찬가지로 애저 클라우드 셸 또는 원격 애저 명령줄 인스턴스를 사용해서 ACI 컨테이너를 위한 리소스 그룹 생성을 시작으로 컨테이너를 구축하고 관리하게 된다.

명령줄 컨테이너 명령은 사용하기 쉽다. 이 명령들을 사용해서 ACI에서 사용할 컨테이너를 정의할 수 있다. 기반 호스트 VM을 구축하고 시작할 필요가 없기 때문에 기존 리포지토리에서 컨테이너를 배포하는 과정은 간단하다. ACI가 기존 VM을 컨테이너에 할당하므로 설정하고 실행하는 데 소요되는 시간은 몇 초 정도에 불과하다. 컨테이너를 배치하는 데 사용되는 요청에서 필요한 메모리와 사용할 코어의 수도 정의할 수 있다.

컨테이너 상태의 세부 사항을 받는 JSON 형식의 명령이 있다. 실제 작업에서는 ACI에 컨테이너를 배포하는 스크립트를 작성하고, 이를 데이터센터 OS에서 실행하거나 지속적 통합 플랫폼의 빌드 프로세스 일부로 실행하게 된다. JSON 상태 데이터는 퍼블릭 및 프라이빗 서비스 사이의 네트워킹 서비스 또는 연결을 구성한다.

여기에는 자동화를 위한 여지가 상당히 많고, 애저 CLI는 배시(Bash)를 기반으로 하므로 특히 스크립팅에 적합하다. 마이크로소프트는 클라우드 셸의 파워셸 릴리스와 애저 CLI를 약속했는데, 파워셸이 ACI와 어떻게 상호 작용하게 될지 흥미롭게 지켜볼 일이다.

배포된 컨테이너는 공용 IP 주소 또는 비공개 내부 주소로 실행된다. 공용 주소는 공개된 서비스를 호스팅할 수 있으며, 비공개 주소는 공용 인터페이스를 지원하는 데 사용되는 비공개 애플리케이션이나 내부 서비스에 적합하다. 마이크로소프트의 초기 ACI 문서 대부분은 확장 가능한 웹 애플리케이션을 위해 고밀도 웹 서버를 호스트로 배포하는 웹 서비스를 위한 호스트에 초점을 두고 있다. 문서에서 유용한 Node.js 애플리케이션 배포 방법을 찾을 수 있다.

쿠버네티스와 함께 대규모로 ACI 사용하기
ACI는 테스트 및 개발을 위해 신속하게 컨테이너를 배포하기 위한 툴로 상당히 효과적이지만 특히 쿠버네티스와 함께 사용할 경우 프로덕션 용도로도 유용한 툴이다. 유용한 기능인 컨테이너 그룹을 쿠버네티스 팟(pod)으로 포장하는 기능이 아직 실험 단계라는 점은 아쉽다. 쿠버네티스용 ACI 커넥터는 오픈소스 프로젝트로 깃허브에 호스팅되므로 쿠버네티스에서 ACI에 컨테이너를 배포할 수 있다.

ACI 커넥터를 사용한 작업은 일반적인 큐브릿(kubelet) 작업과 마찬가지이며 컨테이너 팟을 호스팅하고 관리하기 위한 명령줄을 사용한다. 커넥터는 ACI를 무제한 용량 노드로 등록한다. 일단 등록되면 노드 이름을 사용해 ACI 계정에서 팟을 실행하고 익숙한 쿠버네티스 명령을 사용해 컨테이너를 생성 및 해체하면 된다. 이 기능을 사용하기 위해 애저에서 쿠버네티스를 실행할 필요는 없다. ACI 쿠버네티스 API를 위한 공용 IP 주소만 있으면 된다. 그러면 어느 서비스에서 실행되든 관계없이 모든 쿠버네티스 마스터에서 ACI를 사용할 수 있다.

ACI를 프로덕션 상태까지 끌어오기 위해 마이크로소프트가 쿠버네티스 커뮤니티와 어떻게 협력해 나갈지가 흥미롭다. 충분히 유용하기 때문에 프로덕션 워크로드용으로 권장되지 않음에도 불구하고 사람들은 빠르게 ACI를 도입하고 있다. 그러나 필자의 예상으로 사람들은 온프레미스 환경이나 클라우드 간에 사용하기보다는 주로 애저에서 실행되는 쿠버네티스에서 ACI를 사용하게 될 것으로 보인다.

ACI가 초 단위로 청구된다는 비용 측면의 이점은 쿠버네티스를 사용해서 애플리케이션과 서비스를 잠깐씩 확장하는 경우 상당히 크게 작용한다. 또한 오픈소스 ACI 커넥터는 메소스(Mesos)와 도커 스웜(Docker Swarm)용 커넥터 개발에 도움이 될 것이다.

애저 컨테이너의 미래
마이크로소프트가 ACS와 ACI를 통해 애저 컨테이너에 전념하는 데는 그럴 만한 이유가 있다. 특히 값비싸고 많은 리소스를 소비하는 IaaS 모델에서 벗어나 플랫폼이라는 애저의 뿌리와 긴밀히 연결되는 쪽으로 이동한다는 측면에서 이를 고려하면 더욱 그렇다. 쿠버네티스나 그와 비슷한 것을 사용해 컨테이너를 관리한다면 PaaS에서 실행되는 컨테이너는 자연스러운 다음 단계다.

애저가 컨테이너 확장과 컨테이너 배치를 관리하면 복잡한 가상 인프라를 직접 구축하고 관리하는 데 시간을 들일 이유가 별로 없다. 대신 그 시간 동안 리소스 그룹을 구성 및 관리할 방법을 파악하고 애저의 서비스 패브릭과 같은 메시지 기반 프레임워크를 사용해 컨테이너를 애플리케이션에 연결하는 데 집중할 수 있다. 이 새로운 환경에서 작동하는 코드를 구축하는 작업은 처음 시작할 때는 복잡할 수 있지만 컨테이너를 주 배포 모드로 사용하면 업데이트와 확장이 간소화된다.

현재까지 마이크로소프트는 컨테이너 시장에서 빠른 후발 주자(fast follower)였지만, 최근 데이스(Deis)를 인수했고 지금은 클라우드 네이티브 컴퓨팅 재단(Cloud Native Computing Foundation)의 회원사이기도 하다. 단순히 컨테이너를 사용하는 데 그치지 않고 본격적으로 컨테이너의 개발을 주도하기 위한 태세를 갖췄다.  editor@itworld.co.kr


X