한빛출판네트워크

제공 : 한빛 네트워크
저자 : Anna Gerber
역자 : 김상현
원문 : 3 challenges for using Docker

컨테이너가 어떻게 사용되고 어떤 기술과 인프라가 채택되고 있는지 알아봅시다.

요즘 컨테이너는 IT 업종에서 가장 뜨거운 주제입니다. 그런데 실제로 컨테이너가 어떻게 사용되고 있습니까? 2015년 5월에 Ruxit과 공동으로 O"Reilly Media는 현재 조직이 어떻게 컨테이너를 사용하고 있는지 또는 사용할 계획인지를 공유하기 위해 O"Reilly커뮤니티에 사람들을 초대해서 조사를 했습니다.
그 결과 컨테이너 기술들은(특히 Docker는) 어플리케이션 배포를 빠르고 쉽고 보다 유연하게 해주기 때문에 빠르게 채택되고 있는 것으로 밝혀졌습니다. 2015년 DockerCon에서 있었던 설문에서는 컨테이너를 어떻게 사용하고 있는지,어떤 컨테이너 기술과 인프라를 채택하고 있는지 그리고 그 컨테이너를 사용하는 데에 동기를 주거나 연관된 요소들은 무엇인지 밝히는 데에 중점을 두었습니다.

컨테이너, 확실하긴 하지만…
설문 응답자들 중 40%는, 현재 개발을 위해 사용하고 있다는 86%와 비교하여 "생산을 위해 컨테이너를 사용한다"고 대답 했습니다. Docker 컨테이너는 "한번에 빌드를 하고 언제 어디서나 실행 가능하도록" 설계 되어있습니다. 그런데 왜 컨테이너를 생산에 좀더 많은 부분에서 사용하지 않는 걸까요? 응답자들은 컨테이너를 채택하기 위해서는 기술의 성숙도, 오케스트레이션, 모니터링,자동화, 그리고 환경의 크기뿐만 아니라 컨테이너를 적용함으로써 생기는 장점을 개발팀, 관리팀, 고객에게 설득해야 하는 어려움도 존재 한다고 대답했습니다.


적용하는데 걸림돌이 되는 기술 성숙도
56%이상의 설문 응답자들은 컨테이너 기술을 활용한 인프라 구조로 변경하는데 가장 큰 장벽은 기술의 성숙도라고 응답했습니다. 과거 2년동안 릴리즈된 컨테이너와 연관된 모든 툴과 프로젝트들을 계속해서 파악하는 것은 어렵습니다. 그리고 그 것들 중 몇몇은 이름이 바뀐 것도 있고 아직 베타 버전인 경우도 있습니다. 이렇게 개발의 빠른 속도는 아직 안정성이나 성숙도를 보여줄 정도는 아닙니다.

그러나 컨테이너로 패키징 되고 동적으로 관리되는 마이크로 서비스 기반의 어플리케이션 개발을 발전시키기 위한 기존 기술들과 조화를 이루는데 초점을 맞췄던 설문은 6월, OCI가 포메이션에 대한 발표를 하기 전과 7월, Cloud Native Computing Foundation(CNCF)가 설립 되기 전에 종료되었습니다. 이런 주도적인 행동들로 짧은 기간에 컨테이너 기술이 어떤 영향을 줄 수 있는지 말하는 것은 쉽지 않습니다. 기존 기술들과 융화 되려면 아직은 시간이 필요합니다.

그러나 이 공간에 기존 툴을 가지고 있는 선두 업체들이 돌아오게 되면 이러한 주도적인 행동들은 안정성을 보장할 수 있게 됩니다. 그리고 그들은 컨테이너로 기동하는 일련의 안정적 통합 솔루션을 찾기 위한 진입 점을 제공할 것입니다.

대규모 배포 시에 중요한 요소인 오케스트레이션
응답자중 절반은 컨테이너를 채택하려고 할 때 오케스트레이션은 하나의 요소라고 응답했습니다. 이미 Docker를 사용하고 있던 응답자들은 이런 응답을 했습니다.

오케스트레이션은 멀티 컨테이너, 멀티 호스트 어플리케이션에 있는 컨테이너를 조직화하고 연결하는 기능을 가지고 있습니다. 그리고 특히 마이크로 서비스 아키텍쳐로 되어 있는 어플리케이션들을 위해 중요한 역할을 합니다. 예를 들어 웹 어플리케이션은 각각의 컨테이너에서 동작하는 수많은 백앤드 서비스들과 마찬가지로(페일오버나 로드발란싱을 위한) 프론트 앤드의 여러 개 인스턴스를 관리하기 위한 웹 서버들을 구동하는 컨테이너의 집합으로 구성되어있습니다.

분명하게 Google 의 Kubernates와 Mesosphere"s Marathone을 지원하는 오케스트레이션 툴들은 Apache Mesos로 만들어졌습니다. Docker 자체적인 오케스트레이션 툴인 Swarm, Compose, Machine은 2월에 릴리즈 되었고 Compose는 기존의 Fig 툴이 변경된 것입니다. 어떤 컨테이너 관련 기술들을 사용하고 있는지 응답자들에게 물었을 때 38%는 Docker Swarm을, 22%는 Kubernates를 , 22%는 Mesos를 사용하고 있거나 사용할 예정이라고 응답했습니다. 그리고 Kubernetes를 사용한다고 응답한 사람들은 대개 큰 기업에서 일을 하고 있었습니다. Docker Swarm과 Machine은 여전히 베타 버전이지만 Kubernetes는 CNCF를 출시했던 7월21일에 버전 1.0을 릴리즈 했습니다. 따라서 이러한 툴들이 발전할 수 있는 기회를 준 후에 적용 비율을 비교해보는 것은 매우 흥미로운 일이 될 것 입니다.

확장성 모니터링에 대한 제한 요인
컨테이너가 제품의 넒은 영역에 사용되면서 모니터링 툴에 대한 요구가 또한 증가하게 되었습니다. 응답자중 46%는 모니터링이 컨테이너화한 어플리케이션으로 변경하는데 중요한 요소라고 응답했습니다. 오직 1개의 호스트에서만 동작하고 디스크에 있는 로그파일(예:/var/log 아래)을 분석하는데 의존했던 기존 Linux기반의 모니터링과 리포팅 툴들은 멀티 컨테이너 클러스터 어플리케이션으로 변경하기에 적합하지 않았고 싱글 컨테이너 어플리케이션을 모니터링 하는 것 조차도 적합하지 않았습니다. 왜냐하면 저장되지 않은 데이터들은 컨테이너가 동작하지 않을 때에 디스크의 내용이 유지 되지 않기 때문입니다. 컨테이너 인식 모니터링 툴 또는 서비스를 사용하여 어플리케이션을 모니터링 하고 로그를 확인하는 것에 대한 집중화된 접근은 동적으로 다수의 컨테이너 어플리케이션을 관리하는 데에 더 적합합니다.

컨테이너의 상태를 모니터링 하기 위한 셀프 호스트 솔루션으로는 오픈 소스 툴인 cAdvisor와 Sensu, Prometheus가 있습니다.

Docker는 1.5버전부터 동작중인 컨테이너들의 스트리밍 자원의 사용 상태를 확인 하기 위한 Stats API를 지원해왔습니다. 그리고 수많은 벤더들은 New Relic, Scout, DataDog, SignalFX, AppDynamics 를 포함한 Docker Stats API로 만들어진 호스트 모니터링 툴을 제공합니다. 이 툴들은 컨테이너 상태를 모니터링 하지만 Stats API를 통해 제공된 데이터에 의존적입니다. 그리고 그런 이유로 컨테이너 안에서 동작하고 있는 서비스들이나 어플리케이션에 대한 좀더 상세한 정보는 제공하지 않습니다. Ruxits의 Docker Monitoring은 새로 생성된 컨테이너에 대한 오토 디스커버리를 제공합니다. 그리고 컨테이너 내부에서 동작하고 있는 어플리케이션과 서비스들에 대한 디스커버리와 Docker컨테이너 안에서 실행되는 마이크로서비스들과 동적 분산 어플리케이션에 대한 어플리케이션 중심 모니터링을 제공합니다.

자동화
40%의 응답자들은 자동화는 또 다른 요소라고 말합니다. 특히 자동화는 변경이 많은 마이크로 서비스 기반의 분산 어플리케이션 구현하는 데에 유용합니다. 예를 들어 하나의 서비스를 새로운 컨테이너로 변경 하는 것이 장소를 업그레이드 하는 것보다 낫습니다. 기존에 Jenkins와 같은 배포 툴(배포를 위해 Ansibl과 같은 CM 툴과 결합한)과 CircleCI같은 컨테이너 사용가능한 서비스들은 DockerHub로부터 직접적으로 Docker이미지들을 내려받고 CI/CD프로세스의 부분처럼 직접 빌드를 하고 배포를 할 수 있습니다. 동적으로 서로 관련이 있는 서비스들을 미리 연결하는 것보다 다른 서비스들을 동적으로 디스커버리 하는 것을 가능하게 하기 위한 Etcd와 Consul을 포함한 서비스 디스커버리 툴들은 이 이야기에 중요한 부분입니다.

요약
설문 응답자들에 의하면 컨테이너 기술 채택에 대한 높은 비율은 Docker와 컨테이너에 관련된 현재 업계에 대한 추세를 반영합니다. 응답자중 반 이상이 앞으로 6-12개월 안에 제품에 컨테이너를 사용할 예정이라고 말했습니다. 그리고 설문에 의해 확인된 분산 컨테이너 어플리케이션을 위한 자동화, 모니터링, 오케스트레이션과 같은 핵심적인 요소와 관련된 영역을 다루는 통합솔루션과 안정성, 제품준비에 대한 명백한 수요도 있습니다.
어떻게, 왜 사람들이 Docker를 사용하는지 배우기를 원하시나요? 설문의 나머지 부분을 읽어보십시요.