클라우드

클라우드는 남이 갖춰 둔 컴퓨터 자원을 네트워크 너머에서 빌려 쓰는 방식입니다. 필요할 때 필요한 만큼 가져다 씁니다. 다 쓰면 돌려줍니다. 쓴 양이 측정되고 그만큼 값을 치릅니다.

상세

동네 빨래방을 떠올리면 됩니다. 세탁기를 집에 사서 두지 않습니다. 필요할 때 가서 돌린 만큼만 값을 냅니다.

미국 국립표준기술연구소(NIST, National Institute of Standards and Technology)가 낸 SP 800-145 「The NIST Definition of Cloud Computing」이 이 방식을 한 문장으로 정의합니다. 설정할 수 있는 컴퓨팅 자원의 공유 풀에 어디서나 손쉽게 요청 즉시 네트워크로 접근하게 해 주는 모델입니다. 여기서 자원이란 네트워크·서버·스토리지·애플리케이션·서비스 같은 것을 말합니다. 그 자원은 관리 노력이나 서비스 공급자와의 상호작용을 최소로 하고도 신속하게 마련되고 반납됩니다.

이 정의는 무엇을 클라우드라 부를 수 있는지를 다섯 가지 본질 성질로 풀어 적습니다. 성질을 적을 때는 앞서 말한 자원을 능력이라 부릅니다.

배경

컴퓨터를 직접 갖추려면 쓰기 전에 사야 합니다. 몇 대를 살지는 앞으로의 수요를 미리 재서 정합니다. 그런데 수요는 하루 안에서도 요일 사이에서도 오르내립니다. 정점에 맞춰 사 두면 평소에는 그만큼이 놉니다. 평소에 맞춰 사 두면 정점에 모자랍니다. 장비를 더 들이는 데는 주문과 설치 시간이 걸립니다. 그 시간 동안 서비스는 모자란 채로 돕니다.

없애야 할 불편이 둘이었습니다. 하나는 수요가 오르내리는 대로 자원을 늘리고 줄이는 일입니다. 다른 하나는 쓴 만큼만 값을 치르는 일입니다. 앞의 표에서 신속한 탄력성과 측정되는 서비스로 적힌 두 성질이 이 둘에 닿습니다. 사용량 과금이나 사용 건당 과금은 측정되는 서비스 성질이 값으로 드러나는 자리입니다.

이 방식에 붙은 이름이 클라우드 컴퓨팅입니다. NIST 정의는 이 모델이 다섯 가지 본질 성질과 세 가지 서비스 모델, 네 가지 배포 모델로 이루어진다고 적습니다.

갈래

축이 둘입니다. 하나는 무엇을 빌리느냐입니다. 서비스 모델 셋이 이 축 위에 놓입니다. 다른 하나는 누가 쓰느냐입니다. 배포 모델 넷이 이 축 위에 놓입니다.

서비스 모델을 가르는 것은 빌리는 쪽이 무엇을 만질 수 있느냐입니다. 정의는 모델마다 두 문장을 짝으로 적습니다. 하나는 소비자에게 제공되는 능력이 무엇인지이고, 다른 하나는 소비자가 무엇을 관리하거나 통제하지 못하는지입니다.

세 모델이 다 같이 딛고 있는 것이 클라우드 인프라입니다. 다섯 가지 본질 성질을 가능하게 하는 하드웨어와 소프트웨어의 모음을 가리킵니다. 정의의 각주는 이것을 물리 레이어와 추상 레이어 둘로 나눠 봅니다. 물리 레이어는 제공되는 클라우드 서비스를 떠받치는 데 필요한 하드웨어 자원입니다. 보통 서버·스토리지·네트워크 구성요소가 여기 듭니다. 추상 레이어는 그 위에 배포되어 본질 성질을 드러내는 소프트웨어입니다.

flowchart BT
    subgraph 클라우드 인프라
        P["물리 레이어 — 서버 · 스토리지 · 네트워크"] --> A["추상 레이어 — 본질 성질을 드러내는 소프트웨어"]
    end
    A --> S1["서비스형 인프라"]
    A --> S2["서비스형 플랫폼"]
    A --> S3["서비스형 소프트웨어"]

그림의 화살표는 모두 같은 뜻입니다 — 아래 것이 위 것을 가능하게 합니다. 세 서비스 모델은 그 인프라 위에서 각자 무엇을 만질 수 있는지로 갈립니다.

서비스형 인프라

IaaS(Infrastructure as a Service, 서비스형 인프라)에서 소비자에게 제공되는 능력은 처리 능력·스토리지·네트워크를 비롯한 근본 컴퓨팅 자원을 마련하는 것입니다. 그 위에서 소비자는 임의의 소프트웨어를 배포하고 실행합니다. 운영체제도 애플리케이션도 여기 들어갑니다.

소비자는 밑에 깔린 클라우드 인프라를 관리하거나 통제하지 못합니다. 대신 운영체제·스토리지· 배포한 애플리케이션은 통제합니다. 호스트 방화벽 같은 일부 네트워킹 구성요소에 대해서는 제한된 통제를 갖기도 합니다.

서비스형 플랫폼

PaaS(Platform as a Service, 서비스형 플랫폼)에서 제공되는 능력은 소비자가 만들었거나 사들인 애플리케이션을 클라우드 인프라 위에 배포하는 것입니다. 그 애플리케이션은 공급자가 지원하는 프로그래밍 언어·라이브러리·서비스·도구로 만들어집니다. 각주는 이 능력이 다른 출처의 호환 언어·라이브러리·서비스·도구를 반드시 배제하지는 않는다고 못 박습니다.

소비자는 밑에 깔린 네트워크·서버·운영체제·스토리지를 관리하거나 통제하지 못합니다. 배포한 애플리케이션은 통제합니다. 애플리케이션을 띄우는 환경의 설정도 통제할 수 있습니다.

서비스형 소프트웨어

SaaS(Software as a Service, 서비스형 소프트웨어)에서 제공되는 능력은 공급자의 애플리케이션을 쓰는 것입니다. 그 애플리케이션은 클라우드 인프라 위에서 돕니다. 웹 브라우저 같은 얇은 클라이언트 인터페이스로 닿습니다. 프로그램 인터페이스로 닿기도 합니다. 정의가 든 보기가 웹 기반 전자우편입니다.

소비자는 네트워크·서버·운영체제·스토리지는 물론 개별 애플리케이션 기능까지도 관리하거나 통제하지 못합니다. 예외가 있다면 사용자별 애플리케이션 설정 정도입니다.

배포 모델 넷

배포 모델은 그 인프라를 누구 몫으로 마련했느냐로 갈립니다.

예시

AWS EC2 인스턴스 한 대 띄우기

AWS(Amazon Web Services)의 명령줄 도구 레퍼런스가 EC2(Elastic Compute Cloud) 인스턴스를 띄우는 명령을 이렇게 적습니다.

aws ec2 run-instances \
    --image-id ami-0abcdef1234567890 \
    --instance-type t2.micro \
    --key-name MyKeyPair

--image-id 는 부팅에 쓸 AMI(Amazon Machine Image)를 가리킵니다. --instance-type 은 인스턴스의 규격입니다. 여기서는 t2.micro 한 대입니다. 문서는 이 명령이 현재 리전의 기본 서브넷에 인스턴스 하나를 띄운다고 적습니다. 서브넷과 보안 그룹을 안 적으면 무엇을 쓸지는 기본 VPC(Virtual Private Cloud)가 있는지로 갈립니다. 그 갈림은 아래와 같습니다.

flowchart TD
    A["서브넷을 적었나"] -->|예| E["그 서브넷을 씁니다"]
    A -->|아니오| B["기본 VPC가 있나"]
    B -->|예| C["기본 VPC의 기본 서브넷을 씁니다"]
    B -->|아니오| D["서브넷을 반드시 적어야 합니다"]
    C --> F["보안 그룹을 적었나"]
    E --> F
    F -->|예| G["그 보안 그룹을 씁니다"]
    F -->|아니오| H["그 VPC의 기본 보안 그룹을 씁니다"]

SSH(Secure Shell) 나 RDP(Remote Desktop Protocol) 로 접속할 계획이 없다면 키 페어는 선택입니다.

돌아오는 출력에 "InstanceId": "i-1231231230abcdef0" 와 "InstanceType": "t2.micro" 가 찍힙니다. "Placement" 안에는 "AvailabilityZone": "us-east-2a" 가 들어 있습니다. 사람과의 상호작용 없이 명령 한 줄로 자원이 마련되는 자리이고, 그 자원이 어느 가용 영역에 놓였는지가 값으로 드러나는 자리입니다.

오토 스케일링 그룹의 세 값

같은 공급자의 EC2 Auto Scaling 안내서는 그룹마다 최소 인스턴스 수와 최대 인스턴스 수를 지정할 수 있다고 적습니다. 그룹은 그 아래로도 그 위로도 가지 않습니다. 희망 용량을 지정하면 그만큼의 인스턴스를 유지합니다. 그룹을 만들 때 지정해도 되고 그 뒤 아무 때나 지정해도 됩니다.

안내서가 든 보기는 최소 4 · 희망 6 · 최대 12 인 그룹입니다. 인스턴스를 언제 얼마나 늘리고 줄일지 미리 정해 둔 규칙인 조정 정책이 지정한 기준에 따라 인스턴스 수를 그 최소와 최대 사이에서 움직입니다. 안내서는 이 그룹의 인스턴스에 Elastic Load Balancing 으로 트래픽을 흩을 수 있다고 적습니다. 인스턴스를 로드 밸런서에 등록하고 해제하는 일은 자동으로 이루어집니다. 내장 헬스 체크 말고 애플리케이션에 맞춘 헬스 체크를 따로 정의할 수도 있습니다. 거기서 떨어진 인스턴스는 희망 용량을 유지하기 위해 자동으로 교체됩니다. 최소·희망·최대 세 값도 이 자동 교체도 신속한 탄력성이 사람 손을 거치지 않고 자동으로 도는 자리입니다.

OpenStack openstack server create

퍼블릭 공급자 쪽만 있는 것이 아닙니다. 프라이빗 클라우드를 세우는 오픈소스 쪽에서는 OpenStack 명령줄 클라이언트 문서가 서버 하나를 만드는 명령을 이렇게 적습니다.

openstack server create
    --flavor <flavor>
    [--image <image> | --volume <volume> | --snapshot <snapshot>]
    [--network <network>]
    [--security-group <security-group>]
    [--key-name <key-name>]
    <server-name>

--flavor 는 그 규격으로 서버를 만들라는 뜻입니다. 이름이나 ID 로 적습니다. --image 는 서버의 부팅 디스크를 그 이미지에서 만들라는 뜻입니다. --network 는 서버에 네트워크 인터페이스를 하나 만들어 그 네트워크에 붙이라는 뜻입니다. 규격·이미지·네트워크를 골라 서버를 얻는 모양이 앞의 공급자와 같습니다. 부르는 이름만 다릅니다.

관련 항목

인스턴스를 마련할 때 지정하는 값

리전 · 가용 영역 · 서브넷 · VPC · 보안 그룹 · 머신 이미지 · 인스턴스 유형 · 하이퍼바이저 · 플레이버 · 스냅샷 · 키 페어

신속한 탄력성을 구현하는 방식

오토 스케일링 · 로드 밸런서 · 헬스 체크 · 조정 정책 · 클라우드 버스팅

클라우드 인프라를 나누고 두는 개념

멀티테넌시 · 자원 풀링 · 사용량 과금 · 클라우드 인프라 · 온프레미스 · 클라우드 공급자