Offcanvas
Some text as placeholder. In real life you can have the elements you have chosen. Like, text, images, lists, etc.
Offcanvas
1111Some text as placeholder. In real life you can have the elements you have chosen. Like, text, images, lists, etc.

컨테이너

리뷰 : 레드햇 아토믹 호스트 “도커를 해결하는 수준 높지만 어려운 방법”

프로젝트 아토믹(Project Atomic)은 쿠버네티스(Kubernetes)와 레드햇의 엔지니어링 역량을 최첨단 컨테이너 호스트에 쏟아 부었다. 하지만 사용자는 소매를 걷어붙일 준비를 해야 할 것이다. 레드햇의 프로젝트 아토믹은 리눅스 컨테이너를 실행하는 위한 독창적인 방법이다. 아토믹 호스트 운영체제에는 도커(Docker, 컨테이너), 플란넬(Flannel, 네트워킹), OS트리(OSTree, 호스트 관리), Etcd(분산키 저장소)가 따라오며, 쿠버네티스(오케스트레이션)가 사전 설치되어 있다. 이로써 “모든 것을 갖췄다”고 말할 수도 있지만, 그에 따른 추가적인 복잡성과 관리 오버헤드가 있다. 쿠버네티스는 여러 대의 아토믹 호스트에 걸쳐 “팟(Pod)”의 생성을 조율한다. 팟이란 하나의 애플리케이션에 있는 서비스들을 논리적으로 분리시키는 도커 컨테이너들의 그룹을 지칭한다. 하나의 팟에 있는 컨테이너는 IP 주소를 공유하고 내부접속(localhost)을 통해서 통신한다. 플란넬은 아토믹 호스트들을 위한 오버레이 네트워크를 제공해 클러스터에 있는 모든 팟이 해당 클러스터 내부의 다른 모든 팟 또는 서비스와 통신할 수 있게 해준다. 이 오버레이 네트워크는 컨테이너 네트워킹용으로만 사용된다. 쿠버네티스 프록시 서비스(Proxy Service)는 호스트 IP 공간에 대한 액세스를 제공한다. Etdc는 클러스터에 있는 모든 호스트 전체에 대해 쿠버네티스와 플란넬의 모두에 대한 구성을 저장하는 데 사용된다. 아토믹 컨테이너 클러스터는 쿠버네티스 때문에 몇 가지 가정을 두는데, 관리자들은 아토믹에 대해서 실제로 선택의 여지가 없다: 쿠버네티스를 사용하거나 아니면 다른 컨테이너 OS를 찾거나. “관습에 의한 설계”로 짜증이 나고 컨테이너 호스트에 대해 더 많은 자유로움과 유연성을 원한다면, 랜처OS(RancherOS)나 VMware 포톤(Photon)을 고려해 볼 수도 ...

레드햇 리뷰 컨테이너 2017.09.08

메소스피어, DC/OS에서 쿠버네티스 공식 지원

쿠버네티스의 오랜 경쟁자인 메소스피터가 자사의 DC/OS 상에서 쿠버네티스를 지원하면서 쿠버네티스 진영에 합류했다. 메소스피어의 데이터센터 관리 플랫폼 DC/OS가 컨테이너 오케스트레이션용 공식 지원 옵션으로 쿠버네티스를 추가했다. 아파치 메소스(Mesos) 클러스터 관리 프로젝트를 기반으로 하는 DC/OS는 메소스피어의 마라톤(Marathon)을 기본 오케스트레이션 시스템으로 제공해 왔다. 하지만 쿠버네티스는 폭넓은 사용자 기반과 클라우드 네이티브 컴퓨팅 재단의 보증을 기반으로 마라톤을 앞질렀다. 메소스피어는 2015년부터 DC/OS 상에 쿠버네티스 운영을 옵션으로 제공했다. 하지만 어디까지나 얼리 액세스 프로그램일 뿐이었다. 이번 발표 역시 공식적으로는 베타 딱지가 붙어 있지만, ‘향후 몇 개월 내에’에 정식으로 제공한다는 것이 메소스피어의 계획이다. 메소스피어에 따르면, DC/OS용으로 사용하는 쿠버네티스 에디션은 DC/OS 맞춤 버전이 아니라 커뮤니티 주 배포판이다. 이는 쿠버네티스 애플리케이션 및 관리 툴과 높은 수준의 호환성을 제공한다는 의미이다. 메소스피어는 “특정 명령어에는 kubectl을 쓰고 또 다른 인터페이스에는 특정 업체의 명령어를 쓰는 일은 없을 것”이라고 밝혔다. 그외의 기능 역시 쿠버네티스를 주요 구성요소로 사용하는 다른 플랫폼에서 지원하는 것과 같은 방식이다. 이런 기능 중 메소스피어가 언급한 것은 쿠버네티스의 “비파괴적인 업그레이드”이다. 즉 DC/OS 전반에 걸쳐 다른 애플리케이션이나 클러스터 운영을 건드리지 않고 쿠버네티스를 업그레이드할 수 있다. 현재 코어OS가 자사 쿠버네티스 배포판용으로 비슷한 기능을 제공한다. 메소스피어는 단일 컨테이너로 쉽게 압축할 수 없는 복잡한 인프라를 구성하고 관리할 수 있다는 점을 내세워 오랫동안 DC/OS를 다른 컨테이너 기반 운영체제와 차별화했다. 쿠버네티스가 다중 컨테이너 애플리케이션 배치 방안을 제...

컨테이너 오케스트레이션 쿠버네티스 2017.09.08

리뷰 | VM웨어 포톤 OS “도커 컨테이너용으로 탁월”

VM웨어는 포톤(Photon) 오픈소스 프로젝트를 통해 가상 환경에서 컨테이너화된 애플리케이션을 구동하는 환경 관련 커뮤니티를 구축하고자 한다. 포톤 프로젝트는 포톤 OS를 이용해 가상머신 ‘상’에 컨테이너를 배치하는 방법과 VM웨어 인프라 상에 가상머신‘으로’ 컨테이너를 배치하는 방법을 포함한 여러 프로젝트를 가리키는 포괄적인 용어이다. 포톤 OS은 작은 리눅스 컨테이너 호스트로, 가상머신에서 실행되도록 설계되었으며 VM웨어 하이퍼바이저용으로 최적화되어 있다. VM웨어는 도커라는 움직임을 본격적으로 받아들였으며, 이는 VM웨어에만 국한된 것도 아니다. 구글 컴퓨트 엔진(Google Compute Engine)과 아마존(Amazon) EC2를 비롯한 다른 하이퍼바이저에서도 포톤 OS를 실행할 수 있다. 단, 물리 서버에는 포톤 OS를 설치할 수 없다. 포톤 OS는 도커가 기본값으로 설치되지만, 컨테이너 관리 툴이 포함되어 있지는 않다. 관리자는 포톤 패키지 관리자를 이용해 기본 OS 위에서 원하는 컨테이너 관리 도구를 이용할 수 있다. 포톤 OS 시스템 관리 포톤 OS에서는 패키지 관리를 TDNF(Tiny Dandified Yum)으로 한다. TDNF는 VM웨어에서 만든 오픈소스로서 윰(Yum)의 대규모 파이톤(Python)이 없는 DNF 호환 패키지 관리를 제공한다. VM웨어는 패키지 관리를 위해 자체 윰 호환 저장소를 제공하고 GPG(GNU Privacy Guard) 서명으로 패키지를 서명한다. 이렇게 하면 시스템을 기본적으로 안전하게 보호하는 데 도움이 된다. 서명 검증은 자동으로 이루어진다. 따라서 시스템 관리자나 스크립트에 의해 요구되는 추가 단계가 없다. 포톤 OS 저장소는 “큐레이트(curated)” 되어 있다. 따라서 모든 패키지를 다운로드할 수 있는 것은 아니다. 포톤 OS 1.0 리비전 2는 도커 구형 버전으로 패키징되어 있기 때문에 필자는 먼...

리뷰 컨테이너 VM웨어 2017.08.31

글로벌 칼럼 | 마이크로서비스가 디지털 미래의 초석인 이유

디지털 트랜스포메이션이 비즈니스 방식을 뒤집어 놓을 것이라는 데는 의심의 여지가 없다. 그리고 클라우드 컴퓨팅은 이런 디지털 트랜스포메이션 머신의 핵심 기어가 될 것이다. 클라우드의 탄력성은 디지털 기업이 더 빨리 커뮤니케이션하고 혁신을 높이는 데 한몫할 것이다. 하지만 클라우드에서 최대의 가치를 뽑아내기 위해서 기업은 기존 애플리케이션을 이전하고 소프트웨어 개발을 가속화할 때 마치 총 싸움에 칼을 들고나온 것 같은 실수를 해서는 안된다. 많은 기업이 자사의 기존 온프레미스 애플리케이션을 들어다 클라우드로 옮기는 것으로 마이그레이션 여정을 시작한다. 애플리케이션 자체의 변화는 극히 적거나 전혀 없다. 하지만 이런 획일적인 애플리케이션 아키텍처를 클라우드에서 구동하는 것은 애플리케이션이 클라우드의 이점을 극대화하도록 만들어지지 않았다는 의미이다. 정반대로 이들 애플리케이션은 종종 확장성 문제가 생기고 비용도 늘어나고 애플리케이션 지원에 적지 않은 시간이 들 것이다. 궁극적으로 이런 애플리케이션이 디지털 트랜스포메이션 전략에 걸림돌이 될 것이다. 디지털 트랜스포메이션은 현대화되고 신속하게 반복 적용할 수 있는 확장형 애플리케이션을 기반으로 하기 때문이다. 클라우드의 이점을 극대화하기 위해서는 새로운 환경에 맞도록 애플리케이션 모델을 바꿔야만 한다. 동시에 클라우드와 온프레미스 인프라는 한동안 공존할 것이기 때문에 이 모델은 기존 가상화 환경에서도 잘 동작해야 한다. 디지털 트랜스포메이션에 맞는 애플리케이션 리프트 앤 시프트(Lift and Shift) 방식은 첫 단계에서는 쓸만한 방법이다. 물론 해당 애플리케이션이 온프레미스 환경에서 잘 동작해야 한다. 여기서부터 기업은 애플리케이션 리팩터링, 즉 애플리케이션의 아키텍처가 클라우드 환경과 호환되도록 상당한 수정을 가해 리프트 앤 익스텐드(Lift and Extend) 방식을 실행할 수 있다. 최적의 성능과 민첩성을 필요로 하는 고가치 애플리케이션에는 클라우드 네이티브 애플리케이션으로 전반...

컨테이너 애자일 데브옵스 2017.08.29

IDG 블로그 | 컨테이너 네트워킹의 가능성 보여주는 큐물러스 호스트 팩

약 한 달 전, 누군가 필자에게 ‘디지털 트랜스포메이션’이라는 용어를 정의해 달라고 했다. 처음에 필자는 사람과 프로세스, 데이터의 컨버전스를 언급하는 길고 기술적인 정의를 생각했지만, 이내 한 단어로 축약해 버렸다. 바로 ‘속도’이다. 디지털 트랜스포메이션은 모든 것을 경쟁업체보다 빨리하는 것이다. 말하기는 쉽지만 실제로 실현하는 것은 어려운 일 중의 하나다. 대부분 기업은 하고 싶다고 해서 빨리 움직일 수는 없다. IT에 대한 완전히 새로운 접근 방법이 필요한 일이다. 가트너는 ‘모드 2’라는 용어를 사용하지만, 익숙한 용어로는 애자일 개발이나 데브옵스가 될 것이다. 이 새로운 접근 방법은 여러 가지 새로운 기술을 필요로 하는데, 그 중 하나가 컨테이너다. 컨테이너 사용이 꾸준히 증가하는 것도 IT 부서가 신속하게 컨테이너를 구축한 다음, 원하는 작업을 수행하고 닫아버릴 수 있기 때문이다. 모든 프로세스는 자동화할 수 있기 때문에 심지어는 IT 부서가 개입할 필요도 없다. 하지만 컨테이너가 강력한 만큼 네트워크 관리자에게는 재앙이 될 수 있다. 가상 자원의 추적을 유지하는 것만으로도 어려운데, 아무리 네트워크 전문가라도 겨우 몇 분 동안 구동되는 무엇인가를 어떻게 추적하겠는가? 어디에 얼마 동안 존재하는지를 모르는 무언가에 네트워크나 보안 서비스를 적용할 물리적인 방법은 없다. 이 때문에 네트워크의 숨겨진 지점이 증가하고 네트워크 복잡성이 증가하고 결국에는 데브옵스 팀의 성능 문제로 이어질 수 있다. 이 문제를 해결하기 위해서는 네트워킹에 대한 새로운 접근 방법이 필요한데, 네트워크 자체가 좀 더 민첩하고 동적으로 진화해야 한다. 마치 가상화가 주류 환경이 되었을 때 네트워크 업계가 겪은 변화와 비슷하다. 컨테이너의 요구를 만족하는 제품을 개발하는 것은 전통적인 네트워크는 물론 가상 네트워크와도 상당히 다르다. 그저 가상 워크로드를 받아서 컨테이너로 밀어 넣는 것으로는 낮...

네트워킹 컨테이너 큐물러스 2017.08.28

“컨테이너 전성시대” 도커 생태계 현황과 프로덕션을 위한 조건 - IDG Video Talk Show

도커의 폭발적인 성장으로 컨테이너 기술을 둘러싼 IT 업계의 움직임이 날로 활발해지고 있다. 기본적으로 컨테이너는 애플리케이션과 애플리케이션을 구동하는 데 필요한 모든 종속 요소를 하나의 패키지로 묶은 런타임 환경으로, 가상머신이 각각의 운영체제를 필요로 하는 데 반해 수십 MB의 용량으로 애플리케이션을 구동할 수 있다. 특히 런타임 환경을 모두 가지고 있기 때문에 어떤 환경으로 옮겨도 똑같이 실행할 수 있다는 것이 장점이다. 이 때문에 데이터센터 운영자는 물론 애플리케이션 개발자에게도 적지 않은 이점을 가져다 주며, 인기 컨테이너 기술인 도커를 좀 더 효과적으로 잘 활용하기 위한 생태계 역시 빠르게 성장하고 있다. 도커의 주요 특징과 관련 생태계의 현황에 대해 살펴보고, 특히 기업의 프로덕션 환경에 도커를 적용하는 데 필요한 조건들이 얼마나 성숙했고, 또 이를 위한 관련 업계의 노력에 대해서도 구체적으로 알아본다. 주요 내용 - 컨테이너 기술 관련 트렌드와 도커의 특징 - 도커 생태계 현황 - 도커 데이터센터의 가능성 - 도커 기반의 프로덕션 환경을 위한 조건

컨테이너 프로덕션 도커 2017.08.25

글로벌 칼럼 | 이야기로 풀어보는 클라우드의 역사

클라우드 컴퓨팅의 역사를 재미있게 풀어본 이 칼럼은 인터넷 거품이 터지기 전의 시점에서 시작해 가상화를 거쳐 컨테이너까지 건드린다. 모든 핵심 요소를 정의하고, 권력이 어떻게 CFO에서 CIO로, 그리고 일군의 개발자에게로 넘어왔는지도 살펴본다. <편집자 주> 옛날 옛적에 ‘1990년대’라는 머나먼 마법의 땅이 있었다. 이곳에서 모든 애플리케이션은 저마다의 물리 서버를 가지고 있었다. 이 땅의 시민들은 종종 자신들을 ‘개발자’라 부르곤 했는데, 최고 부하를 처리할 만큼의 충분한 용량을 확보하지 못해서 쫓겨날까 봐 걱정했다. 새로운 물리 서버는 배달하는 데 몇 달이 걸렸고, 이 때문에 개발자들은 필요한 것보다 더 많은 데이터센터 하드웨어를 주문했다. 새로운 시스템을 얻는 것은 무척 어려운 일이었기 때문에 개발자들은 이들 시스템을 애완동물처럼 다루었다. 이름을 지어주고 언제나 잘 돌아가도록 지대한 관심을 기울여 보살폈다. 하지만 모든 사람이 ‘인터넷 거품’에 엄청난 기대를 품고 마법의 땅이 이를 기회로 붙잡으면서 더는 아무도 제대로 활용되지 못한 하드웨어에 관심을 두지 않는 것처럼 보였다. 서버를 공유하기 시작하다 그러던 어느 날, 사람들은 멋진 것보다는 수익성이 더 중요하다는 것을 깨달았다. 그러면서 인터넷 거품은 터져버렸다. CFO가 데이터센터 지출의 지배자가 되었으며, 왜 애플리케이션 2개가 데이터센터의 같은 복도에 있는 활용도가 20%가 안되는 서버를 차지하고 있는지 알고자 했다. 그리고 CFO는 애플리케이션은 하드웨어를 공유해야만 한다는 칙령을 내렸다. 둘 간에 아무런 공통점이 없어도 예외는 없었다. CFO 통치 하에서 일부 시민들은 새로운 물리 서버의 이웃에 관해 책임이 없었다. 한 애플리케이션에서 메모리 누수가 생기면, 서버를 함께 사용하는 모두가 느려졌다. 이들 시끄러운 이웃들은 행실이 나빴다. 가상머신의 부상 마법의 땅은 이름을 ‘1990...

가상머신 컨테이너 서버리스 2017.08.18

“아마존도 쿠버네티스로?” AWS, 클라우드 네이티브 컴퓨팅 재단 합류

클라우드 네이티브 컴퓨팅 재단(Cloud Native Computing Foundation, 이하 CNCF)에 아마존 웹 서비스가 합류했다. CNCF는 쿠버네티스와 컨테이너 생태계의 핵심 요소 기술을 개발하고 촉진하기 위한 산업 컨소시엄이다. 아마존은 최상위 등급인 플래티넘 회원사로 가입했다. CNCF의 이사회 구성원이 된 아마존의 아드리안 콕크로포트에 따르면, 아마존이 CNCF에 합류한 가장 큰 이유는 컨테이너다. 아마존은 이미 컨테이너 기술에 상당한 투자를 하고 있다. 아마존 ECS 서비스는 EC2 인스턴스 클러스터 상에 배치하는 머신 이미지를 통해 구동하는 매니지드 컨테이너 서비스를 제공한다. 좀 더 오래된 일랙스틱 빈스토크(Elastic Beanstalk) 서비스는 쿠버네티스가 아니라 아마존 내부 스택을 통해 확장하고 관리하기는 하지만, 도커 컨테이너를 배치하고 관리할 수 있다. 또한 사용자는 수작업으로 도커 엔터프라이즈 에디션이나 쿠버네티스 클러스터를 EC2 상에 배치할 수 있다. 도커 엔터프라이즈 에디션은 코어OS와 같은 컨테이너 중심 리눅스 운영체제이다. 콕크로프트는 아마존이 특히 컨테이너드(Containerd) 프로젝트에 관심이 많다고 밝혔다. 이 프로젝트는 도커가 CNCF에 기증한 컨테이너 인프라의 핵심 요소로, 컨테이너 개발을 위한 보편적인 공개된 기반을 제공한다. 아마존이 참여를 고려하고 있는 또 하나의 프로젝트는 CNI(Container Networking Interface)로, 컨테이너 간의 네트워킹을 제어할 수 있는 플러그인을 만들기 위한 표준이다. 콕크로프트는 “CNI가 AWS 상에서 모든 컨테이너 기반 네트워킹의 기초가 될 것으로 예상한다”고 설명했다. 남은 것은 쿠버네티스로, AWS와 다른 주요 클라우드 플랫폼 간의 가장 큰 차이이기도 하다. 구글 컨테이너 엔진은 당연히 자사가 만든 쿠버네티스를 우선적으로 지원하며, 마이크로소프트 애저도 애저 컨테이너 서비스를 통해 자체 쿠버네티스 기능을...

컨테이너 AWS 아마존 2017.08.10

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

"서비스 형태의 컨테이너"는 오버헤드 없이, 손쉬운 명령 스크립트를 통해 쿠버네티스 애플리케이션을 포함한 컨테이너화된 애플리케이션을 신속하게 만들어 실행할 수 있게 해준다. 마이크로소프트 애저가 툴과 인력에 대한 전략적 투자에 힘입어 빠른 속도로 컨테이너 기반의 퍼블릭 클라우드로 탈바꿈하는 중이다. 또한 애저는 정기적으로 새로운 컨테이너 중심의 제품과 서비스를 내놓고 있다. 처음의 애저는 아마존 웹 서비스 기능을 따라하기 급급했지만 PaaS와 IaaS 사이를 잇는 가교 역할을 하는 컨테이너 서비스를 출시하면서 아마존을 뛰어넘었다. 서비스 형태의 컨테이너(Container as a Service) 새로운 종류의 클라우드 플랫폼인 애저 컨테이너 인스턴스(Azure Container Instances, 이하 ACI)는 아무런 오버헤드 없이, 손쉽게 스크립팅 가능한 명령 집합을 사용해서 신속하게 컨테이너화된 애플리케이션을 만들어 실행할 수 있게 해준다. 자체적으로도 작동하고 쿠버네티스 등의 툴과 함께 작동할 수도 있는 ACI는 애저에 컨테이너 관리 명령을 추가하고 이를 초당 사용량을 기반으로 하는 청구 모델과 결합한다. 이 과정에서 컨테이너 호스트를 만들고 배치할(그리고 비용을 지불할) 필요가 없다. 다만 세 가지로 구성된 청구 모델은 약간 복잡하다. 첫째, 컨테이너 인스턴스를 생성하기 위한 요청당 0.0025달러의 고정 요금이 있다. 둘째, 설정된 후 메모리 비용으로 초 단위로 기가바이트당 0.0000125달러가 청구되고, 사용되는 코어 비용으로 초 단위로 코어당 0.0000125달러가 청구된다. 따라서 무엇을 얼마나 오래 사용하는지 주시해야 한다. 특히 대규모 애플리케이션의 확장을 ACI를 사용해 처리할 경우 더 신경 써야 한다. ACI를 사용하여 컨테이너 배치하기 ACI는 애저 명령줄 인터페이스를 사용하므로 처음 접하는 경우에도 쉽게 ACI 컨테이너를 설정할 수 있다. 현재 버전은 리눅스 컨테이너만 실행할 수 있지만 곧...

컨테이너 애저 paas 2017.08.03

마이크로소프트 애저의 “쿠버네티스와 친해지기”

컨테이너화된 애플리케이션을 대규모로 관리하는 일이 새로운 과제로 떠올랐다. 특히 운영에서 최대한 많은 부분을 자동화하려고 하는 경우 피할 수 없는 과제가 된다. 데이터센터의 기반 인프라와 컨테이너 사이에는 근본적인 단절이 존재하는데, 바로 이 단절이 가용한 실제/가상 리소스에 컨테이너를 매핑하는 과정을 어렵게 하는 요소다. 그래서 컨테이너를 어디서, 어떻게 실행할지를 통제하기 위한 새로운 관리 계층을 제공하는 쿠버네티스와 같은 데이터센터급 툴이 요긴하게 사용된다. 구글이 처음 개발해 오픈소스화한 쿠버네티스 프로젝트는 현재 독립 기관인 클라우드 네이티브 컴퓨팅 재단(Cloud Native Computing Foundation)이 관리한다. 쿠버네티스는 애저를 포함한 모든 주요 퍼블릭 클라우드 플랫폼에서 제공한다. 데이터센터 운영체제라고 할 수 있는 쿠버네티스는 컨테이너화된 애플리케이션이 사용하는 리소스를 모니터링하고 각 요소를 기반 인프라에 배치해 서비스가 올바르게 수행되도록 보장하고 컨테이너 요구 사항과 기반 인프라 역량 간의 매핑을 관리한다. 마이크로소프트의 쿠버네티스 구현은 현재 애저의 컨테이너 서비스에 포함되며, 최신 애저 CLI 릴리스를 통해 접근할 수 있다. 쿠버네티스와 도커의 대부분은 익숙한 명령줄 도구를 사용해 조작하므로 애저에서도 명령줄을 사용하는 것은 적절한 선택이다. 애저 CLI는 데스크톱 PC에서 실행되지만 다른 옵션도 있다. 애저의 클라우드셸(CloudShell)은 윈도우 배시(Bash) 셸과 마찬가지로 iOS 및 안드로이드 기기에서 실행되는 브라우저 또는 애저 클라이언트에 배시 프롬프트를 제공한다. 애저 컨테이너 서비스는 컨테이너 관리와 오케스트레이션을 위한 세 가지 접근 방법을 제공한다. 애저는 쿠버네티스 외에 메소스피어(Mesosphere)의 DC/OS와 도커의 스웜(Swarm), 컴포즈(Compose)를 지원하며, 리눅스와 윈도우 컨테이너 모두에서 사용할 수 있다. 또한 이러한 도구를 위한 표준 API 엔드포인트도 ...

컨테이너 애저 마이크로소프트 2017.07.27

“데브옵스의 속도와 컨테이너의 효율성” 디지털 변혁을 지원하는 IT 운영 관리의 조건 - IDG Summary

애플리케이션의 중요성과 수요가 높아지고 애자일이나 데브옵스 등의 새로운 개발 방법론이 등장하면서 개발팀은 물론 IT 운영팀 역시 새로운 과제를 안게 되었다. 여기에 인프라 역시 전통적인 온프레미스 환경 은 물론 클라우드 기반의 유연하면서도 고성능을 제공하는 인프라에 대한 요구가 커졌다. 가상머신을 넘어 컨테이너까지 이어지고 있는 인프라의 변화로 IT 운영 관리 환경의 변화도 가속화되고 있다. 데브옵스의 속도와 최신 컨테이너 기술의 효율성을 IT 운영 관리에도 그대로 구현하는 방법을 살펴본다. 주요 내용 - 데브옵스의 속도를 만족하는 지속적인 IT 운영 - 지속적인 운영을 위한 핵심 요구사항 - 자동화와 오케스트레이션을 완성하는 ITOM 스위트 - 컨테이너 기반의 유연하고 확장성 높은 모듈식 구성 - IT 운영 방식을 바꾸는 혁신

자동화 컨테이너 오케스트레이션 2017.07.25

IDG 블로그 | 클라우드 이식성, “아직은 공상과학 SF에 불과”

언제쯤 워크로드를 아무런 수정도 없이 퍼블릭 클라우드 간에 옮길 수 있을까? 금방은 힘들 것으로 보인다. 기업은 클라우드의 이식성을 원한다. 이유는 퍼블릭 클라우드 서비스 업체가 ‘막 나가는’ 경우를 피하기 위해서이다. 계속 질 나쁜 서비스를 제공한다거나 성능 문제, 아니면 서비스 요금을 터무니없이 올리는 등의 경우를 생각하는 것이다. 필자와 이야기를 나눈 많은 CIO가 “선택권을 가질 필요가 있다. 선택권은 영향력을 의미한다”라고 말했다. 제대로 된 선택권을 가지기 위해서는 애플리케이션과 데이터를 포함한 워크로드를 쉽게 이전할 수 있어야 한다. 코드를 이전하고 데이터를 이전하는 것은 새로운 클라우드 플랫폼에서의 재컴파일과 환경 설정, 테스트를 의미한다. 하지만 이런 것이 쉬웠던 적은 없다. 실제로 애플리케이션과 데이터를 퍼블릭 클라우드로 이식하려면, 일부 클라우드 네이티브 기능을 활용할 수 있도록 리팩터링해야만 한다. 클라우드 네이티브 서버와 스토리지를 돌려야 하고 클라우드 네이티브 보안과 거버넌스를 활용해야 한다. 클라우드 네이티브 서비스를 활용하지 않는다면, 클라우드를 이용할 이유도 없어진다. 워크로드 비용을 더 많이 내거나 비즈니스의 요구조건을 만족하지 못할 것이기 때문이다. 물론 클라우드 네이티브한 환경은 좋은 것이다. 하지만 이식성을 크게 제한한다. 한 퍼블릭 클라우드 서비스 상의 클라우드 네이티브 서비스는 다른 퍼블릭 클라우드 상에서는 새로운 클라우드 네이티브 서비스로 작성해야만 한다. 이들은 서로 호환되지 않으며, 설령 모든 것을 옮길 수 있다해도 엄청난 시간과 비용이 들 것이다. 때문에 실용적인 관점에서는 이식할 수 있다고 생각하기 어렵다. 물론 많은 기업이 신기술의 구원을 기대하고 있다. 예를 들어 컨테이너라든가 서버리스 컴퓨팅 등이다. 서버리스 컴퓨팅이 새로운 애플리케이션에 좋다고 하지만, 이는 서버리스 아키텍처에 맞춰 처음부터 설계해야 한다는 의미이다. 여기에 퍼블...

컨테이너 이전 클라우드 2017.07.17

쿠버네티스 1.7의 새로운 기능 : 로컬 스토리지, 암호화 등

인기 컨테이너 오케스트레이션 및 관리 시스템 쿠버네티스(Kubernetes) 1.7은 보안, 스테이트풀(stateful) 애플리케이션, 확장성 기능 등 다양한 신기능을 갖추었다. 쿠버네티스 1.6은 주로 안정화에 관한 것이었고, ETCD 분산 키 값 저장소 3 사용 등과 같이 오랫동안 계획된 변화를 실행했다. 그러나 쿠버네티스 1.7의 새 기능은 아직 알파 단계인 것이 많다. 쿠버네티스가 보다 광범위한 시나리오에서 더욱 쓸모 있기 위해 노력 중임을 알 수 있다. 다른 새 기능은 종전에 컨테이너 생태계의 다른 부분에 이관되었던 기능을 가져온 것이다. 쿠버네티스 1.7 스토리지와 상태 : 로컬과 업데이트 유지 쿠버네티스 1.7은 지속적인 상태 관리와 관련된 몇 가지 기능이 업데이트되었다. 지속 상태 관리 방법 중 가장 흔한 것은 컨테이너 실행 그룹, 즉 쿠버네티스 용어로 팟(pod)을 여러 종류의 스토리지 볼륨에 연결하는 것이다. NFS 공유폴더나 iSCSI 타깃은 물론, AWS나 애저와 같은 클라우드 서비스의 스토리지도 포함된다. 쿠버네티스 1.7에는 로컬 스토리지 매핑 기능도 추가됐다. 쿠버네티스의 네이티브 API가 실행되는 시스템 상의 데이터에 팟 워크로드가 접근할 수 있는 편리한 방법이다. 그러나 로컬 스토리지 사용은 아직 많은 쿠버네티스 시나리오에서 현명한 선택이 아닌 것 같다. 로컬 스토리지가 가장 유용한 것은 임시 방편 애플리케이션이나 미니큐브(Minikube)와 함께 나온 것과 같은 단일 시스템 개발 노드일 것으로 보인다. 또한 현재로서는 쿠버네티스 1.7 로컬 스토리지의 많은 부분이 원시적이거나 신뢰할 수 없는 상태다. 예를 들면, 로컬 블록 디바이스를 볼륨 소스로 사용하는 것이 아직 허용되지 않는다. 그러나 장기적으로는 로컬 스토리지를 쿠버네티스의 다른 스토리지 솔루션 중 가장 우선적인 것으로 만들 계획이다. 쿠버네티스의 상태 처리에 또 한 가지 달라진 점은 지속 상태가 있는 애플리케이션 관리에 대한 것이다. 애...

컨테이너 오케스트레이션 도커 2017.07.07

"왜 도커인가?" 도커와 리눅스 컨테이너의 이해

프리BSD 제일(FreeBSD Jail), 솔라리스 존(Solaris Zone)과 마찬가지로 리눅스 컨테이너는 별도의 CPU와 메모리, 블록 I/O, 네트워크 리소스를 갖추고 호스트 운영체제의 커널을 공유하는, 그 자체로 완전한 실행 환경이다. 일종의 가상머신처럼 느껴지지만 가상머신에 따르는 게스트 운영체제의 무거움과 시작 오버헤드가 없다. 대규모 시스템에서 VM을 실행하는 경우 보통 동일한 OS 인스턴스와 부팅 볼륨이 중복되어 여러 개가 실행된다. 컨테이너는 VM에 비해 더 능률적이고 가벼우므로 같은 하드웨어에서 VM에 비해 6~8배 더 많은 컨테이너를 실행할 수 있다. 따라서 웹 스케일 요구 사항이 있는 애플리케이션 환경에서 컨테이너는 전통적인 서버 가상화에 비해 매력적인 제안이다. 컨테이너를 이해하려면 먼저 호스트에서 실행되는 다른 프로세스와 컨테이너 사이에 벽을 치는 리눅스 커널 기능인 cgroup과 namespace부터 알아야 한다. IBM이 처음 개발한 리눅스 namespace는 시스템 리소스 집합을 래핑해서 이를 프로세스에 제공해 그 프로세서 전용 자원처럼 보이도록 한다. 구글이 개발한 리눅스의 cgroup은 프로세스 그룹의 CPU, 메모리와 같은 시스템 자원의 격리와 활용을 관장한다. 예를 들어 과학 컴퓨팅 애플리케이션과 같이 CPU 사이클과 메모리를 다량으로 소비하는 애플리케이션이 있는 경우 이를 cgroup에 배치해서 CPU 및 메모리 사용을 제한할 수 있다. namespace가 단일 프로세스용 자원의 격리를 다룬다면, cgroup은 일군의 프로세스용 자원을 관리한다. LXC에서 도커까지 최초의 리눅스 컨테이너 기술은 리눅스 컨테이너(Linux Container)다. 보통 줄여서 LXC라고 한다. LXC는 하나의 호스트에서 여러 개의 격리된 리눅스 시스템을 실행하기 위한 리눅스 운영체제 시스템 수준의 가상화 방법이다. 컨테이너는 운영체제에서 애플리케이션을 분리한다. 따라서 사용자는 깨끗한, 최소한의 리눅...

가상머신 컨테이너 도커 2017.07.03

회사명:한국IDG 제호: ITWorld 주소 : 서울시 중구 세종대로 23, 4층 우)04512
등록번호 : 서울 아00743 등록일자 : 2009년 01월 19일

발행인 : 박형미 편집인 : 박재곤 청소년보호책임자 : 한정규
사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2022 International Data Group. All rights reserved.