Home | 문태준 | 시스템어드민 메일링 | Sys Admin 세미나
Skip to end of metadata
Go to start of metadata

The State of Containers and the Docker Ecosystem: 2015

오렐리에서 현재의 컨터이너 상황과 Docker Ecosystem 에 대한 레포트가 나온 것이 있는데 실서비스에 도입하려는 경우 유용한 정보가 많이 있습니다.
무엇 때문에 컨테이너 기술을 도입하는지, 어떤 컨테이너 기술을 쓰는지, 컨테이너 기술을 쓰려는 동기와 도입을 하는데 어려움이 있는 것은 어떤 것인지 등을 설명하고 있습니다.
간단하게 요약을 해 보았습니다.

1.Introduction
컨테이너 도입을 하려는 가장 큰 목적은 애플리케이션 배포를 빠르고 쉽고 유연하게 하려고 하는 것이구요.
응답을 한 곳중 10,000명 이상 있는 조직은 13%이고 50%는 500명 미만입니다.

1. Container Uptake is high
이 응답에 답한 65%가 이미 컨테이너 기술을 사용하고 있습니다.
- Docker Is a Widely Adopted Container Technology
컨테이너 기술 : Docker 78%, LXC 24%, RTK 16%

아직은 적지만 16%가 rtk 를 사용하거나 고려하고 있네요. Open Container Initiative(OCI)가 만들저기면서 표준화된 컨테이너 기술로 가려는 흐름이 있는데요. OCI가 성공적으로 가면 어떤 컨테이너 기술을 사용할지는 작은 이슈가 될 수도 있습니다.

- Lifecycle Adoption Starting to Pick Up in Production
현재는 86%가 Dev, 64%가 testing 이고 Integratin(CI), Staging 이 뒤를 따르고 있고 실환경은 40%입니다.
그렇지만 현재 컨테이너 기술을 쓰고 있지 않은 회사중에 80%가 계획을 가지고 있습니다. (이건 컨테이너에 대한 조사를 했기 때문에 관심있는 회사에서 참가했기에 당연한 결과이겠죠)
53%가 1년 이내에 실서비스에 대한 도입계획을 가지고 있습니다. 실서비스에 점차 빠르게 도입되고 있다는 것을 알 수 있습니다.

1. Why Are Organizations Adopting Containers?
85%가 빠르고 쉬운 배포, 62%가 유연한 배포입니다. 54%는 better isolation가 보안입니다. 48%가 아키텍쳐(마이크로서비스)이고 그 뒤를 비용 절감이 있습니다. 마이크로서비스 아키텍쳐와 컨테이너 기술이 밀접하게 연관이 있다는 것을 보여주네요.

1. Deployment Size
여기 조사에서는 컨테이너의 숫자가 아니라 VM을 포함한 호스트 숫자로 기준을 정했는데요. 250대 이상이 21%이고 1-10대가 27%, 11-50대가 29%입니다.
컨테이너를 올리는데 사용할 OS로는 EC2 Amazon Linux 가 46%, Ubuntu/Debian 이 45%, CentOS 25% 입니다. 컨테이너 기술을 도입했거나 하려는 회사들이 이미 아마존 서비스에 익숙하고 잘 쓰고 있다는 것이겠네요.

- How Are Containers Impacting Infrastructure?
컨테이너를 도입함으로써 인프라에 어떤 영향을 미쳤나는 질문입니다.
왜 컨테이너를 쓰려고 하는지 질문과 연관이 되는데 쉽고 빠른 배포입니다. 속도라고 보면 되겠지요.
그 다음이 자동화된 배포와 DevOps 프로그램을 통합하여 전체 관리를 개선할 수 있다는 부분입니다. 결국 더 자주 배포할 수 있다는 것입니다.
컨테이너를 도입하여 운영호스트를 줄일 수 있고 이를 통해서 운영비용 절약이 될 수 있다고 응답한 사람들이 30%입니다. 그렇지만 소규모 환경에서는 더 복잡해질 수 있고 컨테이너를 위한 레지스트리, 모니터링이 필요하기 때문에 비용절약에는 영향을 안 미칠 수 있습니다.

1. Challenges
40%가 실서비스에 쓰고 있는 반면 86%가 개발에 쓰고 있다고 하였습니다. 컨테이너를 도입하는데 있어서 풀어야 하는 부분(challenge)에 대해서 다루고 있습니다.
56%가 기술 성숙도, 50%가 orchestration, 46% 모니터링, 40% 자동화입니다.
아직은 본격적으로 도입된지 얼마 안 된 상태이고 빠르게 각종 프로그램들이 나오고 있는 상태입니다.
컨테이너 기술을 쓰고 있는 곳에서는 Orchestration 을 많이 지적하였습니다. 대규모 환경에서는 컨테이너를 빠르게 배포하고 관리하기 위한 프로그램이 필수적입니다.
오케스트레이션 관리한 툴로는 Kubernets, Mesosphere's Marathon 이 있고 Docker 에서도 swarm, compose, machine 등이 최근에 나왔지요.
38%가 Docke swam 을 쓰거나 쓸 계획이라고 하고 22%는 Kubernets, 22%는 Mesos 였습니다. 대규모 조직에서는 Kubernets 를 선호하네요.
향후 컨테이너 오케스트레이션 툴들이 경쟁을 하면서 어떻게 성숙해 나갈지 살펴보는것이 필요합니다.

- Monitoring Scalability a Limiting Factor
컨테이너 기술이 실서비스에 빠르게 도입되고 있지만 모니터링 프로그램에 대한 요구사항도 함께 증가하고 있습니다. 기존의 모니터링과 레포팅 프로그램은 단일 호스트 기반에 디스크의 로그 파일에 의존을 하고 있는 기존의 모니터링 프로그램과 레포팅 프로그램은 컨테이너 모니터링에서는 달라져야 하는 것이 있지요. Docker 에서는 1.5 버전부터 Stats API를 지원했다고 하는군요. 이것을 통해서 현재 실행하고 있는 컨테이너의 리소스 사용 현황을 알 수 있다고 하고 벤더에서 제공하는 호스트 모니터링 프로그램에서도 Docker Stats API를 지원한다는 군요.

- Automation
자동화는 40%가 답을 했고 immutable 마이크로서비스 기반의 분산 애플리케이션을 구현하는데 매우 유용한 부분입니다. 전통적인 CI 프로그램인 Jenkins(배포를 위한 ansible 등과 같은 CM tool과 함께 조합하여 사용) 그리고 CircleCI와 같은 컨테이너를 지원하는 ci 서비스에서는 dockerhub 에서 바로 docker 이미지를 가져와 빌드, 배포하는 CI/CD 프로세스를 지원한다고 합니다. etcd, Consul 같은 service discovery 프로그램은 link를 사용하는 대신에 통신이 필요한 서비스를 자동으로 확인할 수 있도록 해줍니다.

1. 결론
절반 이상이 1년 이내에 컨테이너를 실서비스에 배포할 계획을 가지고 있습니다. 이것을 보면 실서비스에서 사용할 수 있는 안정적이고 통합된 솔루션이 필요하다는 것이 명확해 진다고 이야기를 하구요. 주요하게 지원을 해야 하는 부분은 분산된 컨테이너 기반의 애플리케이션을 위해서 오케스트레이션, 모니터링, 자동화가 중요한 과제입니다.

레포팅 파일은 제가 여기에도 올립니다. State_of_Containers_Ruxit_compressed_V2.pdf
https://ruxit.com/docker/?imm_mid=0db624&cmp=em-webops-na-na-newsltr_20151030#dockerreport_exec-summary

Labels
  • No labels