클라우드와 가상머신
“구글 문서는 어디에서 돌아갈까?”
구글 문서(Google Docs)나 구글 스프레드시트(Google Sheets) 같은 서비스는 브라우저에서 접속하면 바로 쓸 수 있어 매우 편리하죠. 사실 이런 서비스들은 모두 ‘클라우드’ 환경에서 동작하고 있습니다.
여기서 ‘클라우드’라고 하면, 물리적으로 보이지 않고 네트워크 너머 어딘가(=오프프레미스)에 있는 대규모 서버 인프라를 떠올리면 됩니다. 그 ‘어딘가’에 실제로는 데이터 센터가 있고, 엄청난 규모의 컴퓨터들이 돌아가고 있는 거죠.
“클라우드 = 가상머신?”
클라우드의 근본이 ‘가상머신(Virtual Machine, VM)’이다라는 말도 많이 들어보셨을 겁니다. 예전에는 컴퓨터 한 대에 OS(운영체제) 하나만 깔아서 필요한 프로그램들을 설치했죠. 하지만 여러 사용자가 동시에 같은 물리 서버를 쓰게 되면 문제가 생길 수 있습니다. 예를 들어, OS 계정을 여러 개 만들어서 권한을 분리하더라도 같은 OS 위에서 돌다 보니 어떤 프로그램이 다른 계정에 영향을 줄 수도 있다는 점이 여전히 걱정거리였습니다.
이 문제를 해결해주는 것이 가상머신입니다. 물리 서버(하드웨어)에 ‘하이퍼바이저(Hypervisor)’라는 소프트웨어 층을 깔고, 그 위에 여러 개의 VM을 띄우면 각각 독립된 운영체제가 돌아가요. 즉, 한 대의 물리 서버 위에 여러 대의 ‘가상 컴퓨터’를 올려놓는 셈이죠.
가상머신을 쓰면 물리 서버 자원을 각각의 VM에 ‘격리’해서 배분할 수 있습니다. 메모리가 부족하면 VM끼리 충돌하거나, 어떤 VM이 다른 VM을 침범하는 문제를 일으키지 않으니 훨씬 안전하고 유연합니다.
온프레미스 vs. 오프프레미스
클라우드는 크게 오프프레미스와 온프레미스로 나눌 수 있습니다.
- 오프프레미스(Off-premise)
다른 회사(예: AWS, GCP, Azure 등)가 서버와 네트워크를 운영하고, 우리는 그 회사의 서비스를 월별 사용료(혹은 트래픽 단가 등)로 빌려 쓰는 방식입니다. 서버를 직접 사고 운영하는 복잡함이 없으니 훨씬 편합니다. - 온프레미스(On-premise)
말 그대로 ‘직접 서버실을 구축’하고, 네트워크와 하드웨어, 운영체제 등 모든 인프라를 관리하는 방식입니다. 대기업 같은 경우 직접 데이터센터를 운영하기도 하는데, 초기 비용과 관리 비용이 크다는 단점이 있죠.
IaaS, PaaS, SaaS
클라우드 서비스 유형도 여러 가지가 있습니다. 대표적으로 IaaS, PaaS, SaaS를 많이 들어보셨을 텐데, 간단히 정리해보겠습니다.
-
IaaS (Infrastructure as a Service)
- 인프라(서버, 네트워크, 스토리지 등)만 제공합니다.
- 개발자가 직접 OS를 설치하고, Node.js나 MongoDB 같은 소프트웨어도 다 설치해야 합니다.
- 예: AWS EC2, Azure VM, Google Compute Engine 등
- 장점: 서버가 ‘빈 방’처럼 제공되므로 자유도가 높고, 다른 클라우드 서비스로 이전(마이그레이션)하기도 쉽습니다.
- 단점: 내가 일일이 설정과 설치를 해야 하니 설정 관리가 번거로울 수 있습니다.
-
PaaS (Platform as a Service)
- 플랫폼(개발/운영에 필요한 환경과 툴)까지 제공해줍니다.
- 예: Node.js, MySQL, Redis 등을 버튼 몇 번으로 설치할 수 있고, CI/CD도 기본 제공됩니다.
- 예: Heroku, AWS Elastic Beanstalk, Google App Engine 등
- 장점: 빠르게 개발 환경을 구축하고 배포할 수 있으니 운영이 편합니다.
- 단점: 제공되는 플랫폼에 종속되는 부분이 있어, 다른 서비스로 옮기거나 커스터마이징을 크게 하려면 어려울 수 있습니다.
-
SaaS (Software as a Service)
- 최종 사용자 입장에서 완성된 서비스를 그대로 씁니다.
- 예: Google Docs, Dropbox, Office 365, Slack 등
- 장점: 사용자가 직접 개발이나 인프라 구축을 할 필요 없이 웹이나 앱으로 접근만 하면 됩니다.
- 단점: 원하는 대로 수정하거나 확장하기 어렵고, 서비스 제공사의 정책에 따라야 합니다.
컨테이너와 도커(Docker)
최근에는 가상머신을 사용하는 대신, 컨테이너라는 방식을 많이 쓰고 있습니다. 특히 도커(Docker)가 컨테이너 활용을 폭발적으로 늘리는 데 큰 기여를 했습니다.
“컨테이너란?”
컨테이너는 애플리케이션과 그 애플리케이션이 동작하는 데 필요한 라이브러리, 설정 파일 등을 하나의 ‘상자’로 패키징해놓은 것입니다.
왜 이런 게 필요할까요?
- 어떤 서버에서는 잘 돌아가는 프로그램이 다른 서버에서는 라이브러리 충돌이나 OS 버전 문제 등으로 안 돌아가는 경우가 많습니다.
- 개발 환경과 운영 환경이 달라서 생기는 문제도 있죠.
컨테이너를 사용하면 환경설정, 종속성 등을 통으로 묶어서 어디든지 똑같은 형태로 옮길 수 있습니다. “한 번 빌드하면 어디서나 동작(Write once, run anywhere)”하는 느낌이죠.
“도커(Docker)”
도커는 컨테이너 기술을 가장 대표적으로 구현해낸 플랫폼입니다. docker run 한 줄이면 이미지를 바탕으로 컨테이너를 만들어서 구동할 수 있죠.
-
도커파일(Dockerfile)
패키지나 환경변수 설정 등을 기록해놓은 스크립트 파일입니다. 어떤 OS 기반으로 할지, 어떤 라이브러리를 설치할지 등을 한 번에 관리할 수 있습니다. -
도커이미지(Docker Image)
도커파일을 빌드하면 나오는 결과물로, 컨테이너를 실행하기 위한 모든 파일과 설정이 포함됩니다. 이미지는 ‘불변(Immutable)’하다는 특징이 있습니다. -
도커 컨테이너(Docker Container)
이미지로부터 실제 실행되는 프로세스입니다. 컨테이너가 죽어도 이미지는 변하지 않습니다. 컨테이너는 어차피 일회성으로 운영을 하고, 필요하면 새로 띄우면 되기 때문에 운영이 상당히 유연하죠.
구글에서는 이미 2014년부터 매주 20억 개 이상의 컨테이너를 돌렸다는 얘기도 있습니다. 이처럼 대규모 서비스들은 컨테이너가 필수적인 존재가 되었습니다.
