본문으로 건너뛰기

솔루션 · 컨테이너

Docker에는 어느 정도의 서버가 필요할까요?

컨테이너는 작은 가상 머신이 아니라 하나의 커널을 공유하는 프로세스입니다. 데몬이 약 100 MB를 차지하고, 그 이후는 모두 고객님의 프로세스일 뿐입니다. 그래서 답은 질문이 예상하는 것보다 작습니다. 프록시, 앱, 데이터베이스, 캐시를 합쳐도 약 515 MB로, BD-8($12.90)에 여유 있게 들어갑니다.

컨테이너가 실제로 차지하는 자원

벤치마크가 아닌 범위값

이미지, 구성, 트래픽이 어떤 표보다도 이 수치를 크게 좌우합니다. 직접 스택에서 docker stats를 실행하십시오. 고객님께 해당하는 수치는 그것뿐입니다.

일반적인 컨테이너 워크로드의 상주 메모리
컨테이너일반적인 메모리BD-8(8 GB)에 적합
리버스 프록시nginx, Caddy, Traefik15–60 MB129 상한 기준
소규모 웹 앱Node, Python, Go: 단일 프로세스60–200 MB38 상한 기준
PostgreSQL 또는 MySQL소규모 데이터셋, 기본 풀200–500 MB15 상한 기준
Redis캐시로 사용, maxmemory로 제한20–200 MB38 상한 기준
JVM 서비스Java, Kotlin, Elasticsearch500–2000 MB3 상한 기준

계산해 보기

플랜별 수용량

메모리에서 운영 체제용 300 MB와 데몬용 100 MB를 뺀 뒤, 컨테이너가 차지하는 양으로 나눈 값입니다. 가운데 열은 프록시, 앱, 데이터베이스, 캐시로 구성된 전체 스택으로, 약 515 MB입니다.

플랜별 컨테이너 및 스택 용량, 디스크와 실시간 가격
플랜RAM전체 스택소규모 앱디스크가격배포
VPS-11 GB1325 GB$9.90배포
BD-88 GB1538100 GB$12.90배포
BD-1212 GB2359200 GB$17.90배포
BD-2424 GB46120300 GB$31.90배포

디스크는 두 번째 복병이며 나중에 마주치게 됩니다. 이미지, 볼륨, 로그가 조용히 쌓입니다. 급해진 뒤가 아니라 그 전에 docker system prune를 주간 cron에 넣어 두십시오.

우리 자신과 비교

이 제품을 구매하지 않으셔야 할 때

관리형 컨테이너 플랫폼은 운영을 대신해 주기 때문에 비용이 더 듭니다. 그것도 충분히 돈을 낼 만한 가치입니다.

VPS는 root 권한을 드리는 대신 업데이트, 재시작, 인증서 관리, 장애 대응 호출까지 모두 고객님께 넘깁니다. 비용은 훨씬 저렴하지만 실제로 일이 더 많습니다. 그 일을 원하지 않으신다면 관리형 플랫폼이 솔직한 답이며, 패치되지 않은 데몬이 인터넷에 노출된 채 방치될 서버를 파느니 차라리 관리형 플랫폼을 권해 드리겠습니다. 같은 맥락의 작은 조언 두 가지: 모든 컨테이너에 메모리 제한을 설정해 문제가 생긴 컨테이너가 데이터베이스 대신 종료되도록 하시고, 서버 한 대에서 Kubernetes를 쓰지 마십시오. 스케줄링할 대상이 없는 오케스트레이터는 복잡성만 더할 뿐입니다.

질문

구매 전에 자주 묻는 질문.

Docker 자체는 RAM을 얼마나 사용하나요?
아주 적으며, 사람들이 가장 놀라는 부분이 바로 이것입니다. Docker 데몬은 약 100 MB를 차지하고, 그 이후의 모든 컨테이너는 그저 프로세스일 뿐입니다. 가상 머신과 달리 두 번째 운영 체제도, 두 번째 커널도, 컨테이너당 고정 비용도 없습니다. 따라서 계산은 간단합니다. 서버의 메모리에서 운영 체제용 약 300 MB와 데몬용 100 MB를 뺀 나머지를 실제로 실행하는 프로세스들이 나눠 씁니다.
소형 VPS에서 컨테이너를 몇 개나 실행할 수 있나요?
질문이 암시하는 것보다 많습니다. '컨테이너 하나'는 크기의 단위가 아니기 때문입니다. 리버스 프록시 10개와 Elasticsearch 1개는 전혀 다른 규모의 서버를 요구합니다. BD-8(8 GB, $12.90)에서는 프록시, 웹 앱, 데이터베이스, 캐시를 합쳐도 약 515 MB로, 서버의 대부분이 남습니다. 위 표가 계산을 해 드리며, 실제로 고객님께 해당하는 수치는 직접 스택에서 `docker stats`를 실행해 확인하십시오.
VPS가 관리형 컨테이너 플랫폼보다 저렴한가요?
가격만 보면 거의 항상 그렇지만, 비교는 가격만으로 끝나지 않습니다. 플랫폼은 업데이트, 재시작, 인증서, 새벽 3시의 장애 호출 같은 운영을 대신하기 때문에 더 비쌉니다. VPS는 root 권한을 드리고 그 모든 일을 고객님께 돌려드립니다. 컨테이너를 운영하면서 그 일을 직접 맡을 의향이 있으시다면 VPS가 훨씬 저렴합니다. 그렇지 않다면 플랫폼에 비용을 지불하십시오. 패치되지 않은 데몬이 돌아가는 채로 방치될 서버를 파느니 이렇게 말씀드리는 편이 낫습니다.
Docker Swarm이나 Kubernetes가 필요한가요?
서버 한 대라면 필요 없습니다. 단일 서버에서 동작하는 스택에는 Compose로 충분하며, 셀프 호스팅 환경의 압도적 다수에 올바른 선택입니다. 오케스트레이터의 역할은 여러 서버에 걸친 스케줄링인데, 서버가 한 대라면 스케줄링할 것이 없습니다. 실제로 여러 대의 서버가 있고 복잡성을 감수할 이유가 있을 때 Kubernetes를 도입하십시오. 그 전에는 아닙니다.
메모리, CPU, 디스크 중 무엇이 먼저 한계에 도달하나요?
대개 메모리이며, 요란하게 문제가 드러납니다. 커널의 OOM(메모리 부족) 킬러가 프로세스 하나를 골라 종료하는데, 이는 컨테이너가 이유 없이 재시작되는 것처럼 보입니다. 컨테이너마다 메모리 제한을 설정해 문제를 일으킨 컨테이너가 데이터베이스 대신 종료되도록 하십시오. 디스크는 두 번째 복병입니다. 이미지, 볼륨, 로그가 조용히 쌓이므로, 급해지기 훨씬 전에 `docker system prune`을 주간 cron에 넣어 두어야 합니다.
호스트에서는 어떤 이미지를 실행해야 하나요?
어느 것이든 괜찮습니다. 모든 플랜에서 모든 이미지를 실행할 수 있고 Docker는 그 전부에서 동작합니다. 특별히 선호하는 것이 없다면 Ubuntu LTS를 기본으로 고르시는 것이 좋습니다. 대부분의 컨테이너 문서가 이를 전제로 하기 때문입니다. 배포판은 생각보다 훨씬 덜 중요합니다. 컨테이너가 자체 사용자 영역을 가져오므로 호스트는 커널과 데몬 정도에 불과합니다.