OpenStack 사용자를 위한 Google Cloud Platform

이 문서는 OpenStack에 익숙한 사용자가 하이브리드 배포를 이전 또는 구현하려고 고려할 때 GCP(Google Cloud Platform)를 시작하기 위한 핵심 개념을 익힐 수 있도록 제작되었습니다.

개요

이 문서에서는 먼저 OpenStack과 GCP의 3 계층 웹 애플리케이션 아키텍처 샘플을 비교한 후 OpenStack과 GCP의 기능을 비교하고, 빠른 참조 표를 사용해서 OpenStack과 GCP에서 사용되는 용어 및 개념을 서로 비교해서 보여줍니다.

OpenStack과 GCP에서 제공되는 SDK, API 또는 명령줄 도구의 비교는 이 문서에서 다루지 않습니다.

Google Cloud Platform 제품의 전체 목록은 제품 및 서비스를 참조하세요.

Cloud 컴퓨팅 서비스

Cloud 컴퓨팅 서비스는 컴퓨팅, 저장소, 네트워킹, 액세스 관리는 물론 종종 데이터베이스 서비스까지 포함된 기본 서비스 집합을 제공합니다.

OpenStack의 기본 서비스는 다음과 같습니다.

  • 컴퓨팅: OpenStack Compute(Nova 및 Glance)
  • 저장소: OpenStack Block Storage(Cinder)
  • 네트워킹: OpenStack Networking(Neutron)
  • ID 및 액세스 관리: OpenStack Identity Service(Keystone)

Cloud Platform의 기본 서비스는 다음과 같습니다.

Google Cloud Platform의 가격 책정

GCP에서 대부분의 서비스는 초당 또는 분당 청구 및 사용량 증가 시 자동 할인이 포함된 사용한 만큼만 지불하는 가격 책정 모델을 기준으로 제공됩니다. 커스텀 머신 유형과 같은 유연한 리소스 할당과 결합된 GCP 가격 책정 모델은 애플리케이션의 비용 효율 성능을 최적화하는 데 도움을 줍니다.

빠른 가격 예상 도구 및 세부정보는 가격 계산기를 참조하세요.

Google Cloud Platform을 선택해야 하는 이유

지난 15년 동안 Google은 전 세계에서 가장 빠르고, 강력하며, 품질이 가장 뛰어난 클라우드 인프라 중 하나를 개발하고 있습니다. Google에서는 내부적으로 이 인프라를 사용하여 글로벌 규모로 운영되는 Gmail, 지도, YouTube, 검색 등 여러 서비스의 높은 트래픽을 감당하고 있습니다. GCP는 이러한 인프라를 개발자의 서비스에서 사용할 수 있게 해줍니다.

샘플 아키텍처 비교

이 섹션에서는 OpenStack과 GCP에서 3 계층 웹 애플리케이션 시스템을 구축하는 방법을 비교해서 보여줍니다.

  • OpenStack은 활성-백업으로 구성됩니다.
  • GCP는 관리형 서비스를 활용해서 활성-활성으로 구성됩니다.

일반적인 3 계층 웹 애플리케이션은 다음과 같은 구성요소로 이뤄집니다.

  • 부하 분산기
  • 웹 서버
  • 애플리케이션 서버
  • 데이터베이스 서버

OpenStack: 활성-백업 구성

그림 1에 표시된 샘플 OpenStack 구성은 다음과 같은 특성을 갖습니다.

  • 중복성을 위한 두 개의 개별 오류 도메인으로 두 지역 간에 리소스를 배포합니다.
  • 네트워크는 각 지역의 모든 계층에 대해 단일 서브넷을 사용하고, 모든 서버는 VM(가상 머신) 인스턴스입니다.
  • 4개의 서버 역할에 대한 보안 그룹을 정의하고 이를 적절한 인스턴스에 할당합니다.
  • Cinder 볼륨이 데이터베이스 서버에 데이터 볼륨으로 연결됩니다. 오류 도메인 간 중복성을 보장하기 위해, 활성 지역의 데이터베이스가 객체 저장소로 백업되고, 필요한 경우 백업 지역의 저장소로 복원됩니다. (이 아키텍처에서는 지역 간 대역폭이 제한적이기 때문에 실시간 데이터베이스 복제가 사용되지 않습니다.)
  • 이 아키텍처는 활성-백업 구성을 제공합니다. 서비스를 다른 리전으로 장애 조치할 때는 백업 리전에서 가장 최근의 백업을 데이터베이스 서버에 복원합니다.

3 계층 웹 앱

그림 1: OpenStack의 3 계층 웹 애플리케이션 시스템

GCP: 활성-활성 구성

그림 2에 표시된 샘플 GCP 구성은 다음과 같은 특성을 갖습니다.

  • 중복성을 위해 단일 리전의 여러 영역(zone)을 포함하는 단일 서브넷에 리소스를 배포합니다.
  • 웹 서버 및 애플리케이션 서버를 VM 인스턴스로 배포합니다.
  • 패킷 대상을 지정하는 태그를 사용해서 방화벽 규칙을 정의합니다.
  • Cloud SQL 구성에 속하는 소스 IP 주소를 기준으로 데이터베이스 연결에 대한 액세스 제어를 구성합니다. Cloud SQL은 여러 영역(zone) 간 데이터 복제를 제공하는 MySQL 데이터베이스를 위한 GCP 관리형 서비스입니다. 예약된 데이터 백업 및 장애 조치 프로세스가 자동화되고, 동일 리전에서 여러 영역(zone)의 데이터베이스에 액세스할 수 있습니다. 영역(zone) 간 장애 조치는 VM 인스턴스에서 실행되는 애플리케이션에 투명하게 작동합니다. 여러 영역(zone)에서 단일 Cloud SQL 인스턴스에 액세스할 수 있습니다. (Cloud SQL에는 Cloud SQL 1세대와 Cloud SQL 2세대가 있습니다. 이 두 가지는 복제 및 장애 조치에 대한 기본 동작 및 특성이 서로 다릅니다.)
  • Google Cloud Load Balancing은 단일 전역 IP 주소(VIP)를 사용하여 여러 리전 및 영역(zone)으로 클라이언트 액세스를 분산할 수 있는 HTTP(S) 부하 분산 서비스입니다.
  • 이 아키텍처는 여러 영역(zone) 간 활성-활성 구성을 제공하여 장애 조치 도메인 간 중복 서비스를 지원합니다.

3 계층 웹 앱 2

그림 2: GCP의 3 계층 웹 애플리케이션 시스템

기능 비교

이 섹션에서는 동일 아키텍처에서 사용되는 기능들에 대한 세부 정보를 비교합니다.

네트워크 아키텍처

이 섹션에서는 OpenStack 네트워크와 GCP 네트워크가 지역 및 영역 내에서 작동하는 방법을 비교하고 프로젝트, 테넌트, IP 주소 및 장애 조치, 방화벽 규칙을 설명합니다.

지역과 영역

OpenStack과 GCP의 용어 및 개념 비교는 다음과 같습니다.

OpenStack GCP 참고
지역 지역 OpenStack에서 한 지역은 여러 데이터 센터를 포함할 수 있습니다. GCP에서 지역은 일반적으로 여러 개의 독립 건물을 포함하는 데이터 센터 캠퍼스에 해당합니다.
가용성 영역 영역 OpenStack에서 가용성 영역은 일반적으로 공통 특성을 갖는 서버 집합을 식별하기 위해 사용됩니다.

GCP에서 영역은 데이터 센터 내의 클러스터에 해당합니다.

OpenStack에서 지역은 전용 컨트롤러 노드로 관리되는 단일 클러스터로 정의됩니다. 지역은 가용성 영역으로 구성됩니다. 가용성 영역을 사용하면 컴퓨팅 노드 및 저장소 인클로저와 같은 여러 리소스 그룹을 정의할 수 있습니다.

GCP에서 지역은 일반적으로 여러 영역들로 구성되는 독립적인 지리적 영역입니다. 지역 내 위치들은 일반적으로 95 백분위 수에서 5밀리초 미만의 왕복 네트워크 지연 시간을 갖습니다. OpenStack 가용성 영역과 같이, 영역은 지역 내 GCP 리소스의 배포 영역입니다. 영역은 단일 오류 도메인으로 간주되어야 합니다.

GCP는 모든 지역 간에 전용 내부 네트워크를 제공하므로, 동일 지역의 다른 영역 간 대역폭 및 지연 시간이 단일 지역 내 대역폭 및 지연 시간과 비슷합니다. 영역 간 대역폭 및 지연 시간을 염려할 필요 없이 여러 영역 간에 밀접하게 연결된 클러스터 애플리케이션을 배포할 수 있습니다.

두 플랫폼 모두 여러 영역 또는 지역 간에 애플리케이션을 배포하면 예상치 못한 오류로부터 보호하는 데 도움이 될 수 있습니다. 영역은 GCP에서 독립적인 오류 도메인으로 간주됩니다. 반면에, OpenStack에서는 단일 지역의 가용성 영역이 동일한 컨트롤러 노드를 공유하기 때문에, 지역(가용성 영역 대신)이 독립적인 오류 도메인으로 간주됩니다. GCP 지역 및 영역 목록은 클라우드 위치를 참조하세요.

프로젝트 및 테넌트

OpenStack과 GCP의 용어 및 개념 비교는 다음과 같습니다.

OpenStack GCP 참고
테넌트 프로젝트 GCP의 모든 리소스는 프로젝트에 속해야 합니다. 사용자는 고유한 새 프로젝트를 만들 수 있습니다.

OpenStack에서는 관리자만 새 테넌트를 만들 수 있습니다.

GCP 서비스를 사용하려면 Google 계정을 설정해야 합니다. GCP는 서비스 사용량을 프로젝트별로 그룹화합니다. 개발자가 동일한 계정 내에서 완전히 개별적인 여러 프로젝트를 만들고, 사용자는 자신의 계정에 따라 고유한 프로젝트를 만들 수 있습니다. 단일 프로젝트 내의 리소스는 지역 및 영역 규칙에 따라 내부 네트워크를 통해 통신하는 등의 방식으로 서로 쉽게 협력할 수 있습니다. 각 프로젝트의 리소스는 다른 프로젝트의 리소스와 격리됩니다. 외부 네트워크 연결을 통해 쉽게 이를 서로 연결할 수 있습니다.

이 모델에서 개발자는 회사 내에서 별도의 지부 또는 그룹에 대한 프로젝트 공간을 만들 수 있습니다. 이 모델은 테스트 목적으로도 유용할 수 있습니다. 프로젝트를 마치고 나서 프로젝트를 삭제하면 해당 프로젝트에서 생성된 모든 리소스도 함께 삭제됩니다.

OpenStack은 여러 그룹의 리소스를 격리하기 위한 기능에 대해 테넌트라는 용어를 사용합니다. OpenStack에서는 시스템 관리자만 새 테넌트를 만들 수 있습니다.

네트워크 구성

OpenStack과 GCP의 용어 및 개념 비교는 다음과 같습니다.

OpenStack GCP 참고
Neutron Cloud Virtual Network Cloud Virtual Network는 관리형 네트워크 서비스입니다. GCP에서는 프로젝트에 여러 네트워크를 정의할 수 있으며, 각 네트워크가 독립적입니다.
가상 비공개 네트워크
가상 비공개 네트워크 단일 GCP 가상 비공개 네트워크에는 GCP의 내부 네트워크를 통해 연결된 모든 지역이 포함됩니다. Neutron 가상 비공개 네트워크에는 지역 내에 있는 모든 가용성 영역이 포함됩니다.

일반적인 OpenStack Neutron 배포에서, 각 테넌트의 가상 네트워크는 고유한 비공개 네트워크 공간으로 제한됩니다. 그림 1에 표시된 것처럼 여러 서브넷을 사용할 필요는 없지만, 필요한 경우 여러 서브넷을 구성할 수 있습니다. 그림 3은 단일 가상 라우터와 3개의 가상 스위치로 구성된 OpenStack 가상 네트워크를 보여줍니다. 가상 스위치 중 2개는 가상 라우터를 통해 외부 네트워크에 연결됩니다. AZ-1과 AZ-2는 가용성 영역입니다.

가상 네트워크

그림 3: OpenStack 네트워크 구성 예

GCP는 두 가지 유형의 네트워크인 이전서브넷 네트워크를 제공합니다.

이전 네트워크는 그림 4에 표시된 것처럼 전 세계에 걸친 모든 지역을 포함하는 단일 비공개 서브넷을 제공합니다.

그림 5에 표시된 것처럼 서브넷 네트워크에서, 가상 스위치는 OpenStack Neutron 가상 라우터에 해당하며, 가상 스위치가 내부 네트워크를 통해 연결됩니다. 모든 서브넷은 비공개 IP 주소를 통해 서로 라우팅할 수 있으므로, 지역 간 통신을 위해 전역 IP 주소 또는 인터넷을 사용할 필요가 없습니다.

GCP에서는 한 프로젝트에서 이전 네트워크와 서브넷 네트워크를 혼합하여 사용할 수 있습니다. 새로 생성되는 각 프로젝트에는 default라는 사전 정의된 네트워크가 포함되고, 여기에는 다시 각 지역의 default라는 서브넷이 포함됩니다.

이전 네트워크

그림 4: Google Cloud Platform 이전 네트워크 구성 예

서브넷 네트워크

그림 5: Google Cloud Platform 서브넷 네트워크 구성 예

IP 주소

OpenStack과 GCP의 용어 및 개념 비교는 다음과 같습니다.

OpenStack GCP
인스턴스에 비공개 내부 IP 주소가 포함됩니다. 필요한 경우 전역 IP 주소(유동 IP 주소)를 할당할 수 있습니다.

인스턴스에 비공개 내부 IP 주소가 포함됩니다. 또한 'gcloud' 명령줄 도구를 사용해서 인스턴스를 만들 때, 임시 IP 주소가 자동으로 할당됩니다. 필요한 경우 정적 IP 주소를 할당할 수도 있습니다.
다른 지역 또는 다른 가상 라우터의 인스턴스 간 통신을 위해서는 전역 IP 주소가 필요합니다. 모든 지역의 서브넷은 비공개 IP 주소를 통해 서로 라우팅할 수 있으므로, 인스턴스 간 통신을 위해 전역 IP 주소 또는 인터넷을 사용할 필요가 없습니다.

Neutron에서는 비공개 네트워크의 VM 인스턴스가 시작할 때 할당된 비공개 IP 주소를 사용해서 가상 스위치 및 라우터를 통해 통신합니다. 전역 IP 주소는 기본적으로 할당되지 않습니다.

가상 라우터는 VM 인스턴스에서 외부 네트워크로의 액세스를 처리하므로, 인스턴스가 가상 라우터에 할당된 공통 전역 IP 주소를 공유합니다. 인스턴스를 외부 네트워크에 노출하고 외부 사용자로부터의 연결을 허용하려면 전역 IP 주소 풀의 인스턴스에 부동 IP 주소를 할당합니다.

가상 네트워크는 단일 지역으로 제한되므로, 다른 지역의 인스턴스가 외부 네트워크를 통해 통신하려면 부동 IP 주소를 사용해야 합니다.

단일 네트워크는 여러 가상 라우터를 포함할 수 있습니다. 다른 라우터에 연결된 VM 인스턴스는 비공개 IP 주소와 직접 통신할 수 없습니다. 하지만 부동 IP 주소를 사용해서 외부 네트워크를 통해 통신합니다.

GCP에서 모든 VM 인스턴스는 시작할 때 내부 IP 주소 및 외부 IP 주소를 갖습니다. 필요한 경우 외부 IP 주소를 분리할 수 있습니다.

기본적으로 외부 IP 주소는 일시적이므로, 인스턴스 수명에 연결됩니다. 인스턴스를 종료하고 다시 시작하면 다른 외부 IP 주소가 할당될 수 있습니다. 또한 인스턴스에 연결할 정적 IP라고 부르는 영구 IP 주소를 요청할 수 있습니다. 정적 IP 주소는 개발자가 이를 릴리스하도록 선택할 때까지 개발자 소유이며, 개발자가 이를 VM 인스턴스에 명시적으로 할당합니다. 정적 IP 주소는 필요에 따라 인스턴스 연결 및 분리할 수 있습니다.

샘플 3 계층 웹 애플리케이션 아키텍처에 표시된 것처럼 OpenStack의 장애 조치 시에는 다른 지역에서 동일한 전역 IP 주소를 사용할 수 없으므로, 동적 DNS와 같은 추가 방식을 사용해서 클라이언트가 동일한 URL을 사용하여 서비스에 계속 액세스하도록 허용해야 합니다.

반면에 GCP에서는 Cloud Load Balancing에서 제공된 단일 전역 IP 주소(VIP)를 사용하여 클라이언트 액세스를 여러 지역 및 영역에 분산할 수 있습니다. 이렇게 하면 클라이언트에 투명한 방식으로 지역 및 영역 간 장애 조치가 제공됩니다.

방화벽

OpenStack과 GCP의 용어 및 개념 비교는 다음과 같습니다.

OpenStack GCP 참고
보안 그룹을 통해 방화벽 규칙을 적용합니다. 규칙 및 태그를 통해 방화벽 규칙을 적용합니다. OpenStack 보안 그룹에는 인스턴스 역할에 따라 개발자가 정의하고, 인스턴스에 할당하는 여러 ACL이 포함됩니다.

OpenStack 보안 그룹을 각 지역에 대해 정의해야 합니다.

GCP 규칙 및 태그는 한 번 정의하여 모든 지역에서 사용할 수 있습니다.

OpenStack에서 단일 보안 그룹에는 VM 인스턴스와 독립적인 여러 ACL(액세스 제어 목록)이 포함됩니다. VM 인스턴스에 보안 그룹을 할당하여 인스턴스에 ACL을 적용합니다. 웹 서버 또는 데이터베이스 서버와 같은 VM 인스턴스 역할에 따라 보안 그룹을 정의합니다.

예를 들어 샘플 아키텍처에서는 각 지역에 대해 다음과 같은 보안 그룹을 정의합니다.

보안 그룹 소스 프로토콜
load-balancer 모두 HTTP/HTTPS
관리 서브넷 SSH
web-server load-balancer HTTPS
관리 서브넷 SSH
web-application web-server TCP 8080
관리 서브넷 SSH
database web-application MYSQL
관리 서브넷 SSH

보안 그룹 이름 또는 서브넷 범위로 패킷 소스를 지정할 수 있습니다. 위 표에서 관리 서브넷은 시스템 관리자가 유지 관리 목적으로 게스트 OS에 로그인하는 서브넷 범위를 나타냅니다.

이 아키텍처에서는 클라이언트 SSL이 부하 분산기에서 종료되어, HTTPS를 사용하여 웹 서버와 통신한다고 가정합니다. 웹 서버는 TCP 8080을 사용해서 애플리케이션 서버와 통신합니다. 데이터베이스 서버에는 MySQL이 사용됩니다.

이러한 보안 그룹을 정의한 후에는 이를 각 인스턴스에 다음과 같이 할당합니다.

인스턴스 보안 그룹
부하 분산기 load-balancer
웹 서버 web-server
애플리케이션 서버 web-application
데이터베이스 서버 database

GCP에서는 Cloud Virtual Network를 사용하여 규칙태그 조합으로 모든 지역을 포함하는 방화벽 규칙을 정의할 수 있습니다. 태그는 VM 인스턴스와 연결된 임의의 레이블이고, 단일 VM 인스턴스에 여러 태그를 할당할 수 있습니다. 규칙은 다음 조건으로 패킷이 전송되도록 허용하는 ACL입니다.

  • 소스: IP 범위, 서브넷, 태그
  • 대상: 태그

예를 들어 대상 포트 TCP 80을 포함하는 패킷이 IP 주소에서 웹 서버 태그로 전송되도록 허용하는 규칙을 먼저 정의합니다. 그런 후 이에 대한 HTTP 연결을 허용하기 위해 모든 VM 인스턴스에 웹 서버 태그를 추가할 수 있습니다. 태그는 인스턴스 역할을 지정하고, 규칙은 개별적으로 역할에 해당하는 ACL을 지정합니다.

그림 6은 새로 생성된 프로젝트에서 기본 네트워크에 대한 몇 가지 사전 정의된 규칙을 보여줍니다. 예를 들어 10.128.0.0/9는 모든 지역의 기본 서브넷을 포함하는 서브넷 범위입니다. 이 서브넷 범위는 각 프로젝트에서 다를 수 있습니다. 시작부터 끝까지 규칙은 다음 네트워크 연결을 허용합니다.

  • 모든 외부 소스의 ICMP(인터넷 제어 메시지 프로토콜) 패킷
  • 기본 네트워크에 연결된 모든 인스턴스 사이의 모든 패킷
  • 모든 외부 소스의 RDP(원격 데스크톱 프로토콜) 연결
  • 모든 외부 소스의 SSH(보안 셸) 연결

사전 정의된 방화벽 규칙

그림 6: 기본 네트워크를 위한 Virtual Cloud Network의 사전 정의된 방화벽 규칙

자세한 내용은 네트워크 및 방화벽 사용을 참조하세요.

GCP 방화벽 규칙에서는 태그를 사용하여 패킷 대상을 지정하고, 서브넷 범위 또는 태그를 사용하여 패킷 소스를 지정합니다. 이 시나리오에서는 다음 규칙을 정의합니다.

소스 대상 프로토콜
130.211.0.0/22 web-server HTTP, HTTPS
web-server web-application TCP 8080
관리 서브넷 web-server, web-application SSH

위 표에서 130.211.0.0/22는 부하 분산기 및 상태 검사 시스템이 웹 서버에 액세스하는 서브넷 범위입니다. 관리 서브넷은 시스템 관리자가 유지 관리 목적으로 게스트 OS에 로그인하는 서브넷 범위를 나타냅니다. web-serverweb-application은 각각 웹 서버 및 애플리케이션 서버에 할당된 태그입니다. 보안 그룹을 사용할 때와 같이 규칙을 할당하는 대신, 해당 역할에 따라 인스턴스에 태그를 할당합니다.

데이터베이스 연결을 위한 액세스 제어는 소스 IP 주소를 기준으로 Cloud SQL 구성에 속하는 것으로 구성됩니다.

저장소

OpenStack과 GCP의 용어 및 개념 비교는 다음과 같습니다.

OpenStack GCP 참고
Cinder 볼륨 영구 디스크 인스턴스 연결 영구 저장소

GCP 영구 디스크에서, 데이터는 인스턴스에서 영구 디스크 저장소로 전송되기 전에 자동으로 암호화됩니다.

임시 디스크 해당 없음 인스턴스 연결 임시 저장소
OpenStack Swift Cloud Storage 객체 저장소 서비스
임시 디스크 및 Cinder 볼륨

OpenStack은 인스턴스 연결 디스크에 대해 임시 디스크와 Cinder 볼륨이라는 두 가지 옵션을 제공합니다.

임시 디스크는 운영체제 파일을 포함하는 시스템 디스크로 사용하도록 디자인되었습니다. Cinder 볼륨은 영구 애플리케이션 데이터를 저장하도록 디자인되었습니다. 하지만 임시 디스크에서는 실시간 이전을 사용할 수 없기 때문에 시스템 디스크에 대해 Cinder 볼륨을 사용하는 경우가 많습니다.

임시 디스크를 시스템 디스크로 사용할 때는 OS 템플릿 이미지가 컴퓨팅 노드의 로컬 저장소에 복사되고, 로컬 이미지가 인스턴스에 연결됩니다. 인스턴스가 삭제되면 연결된 이미지도 삭제됩니다.

Cinder 볼륨은 외부 저장 장치에 있는 영구 디스크 영역을 제공합니다. 일반적인 배포에서는 블록 장치가 iSCSI 프로토콜을 사용해서 컴퓨팅 노드에 연결되고, 인스턴스에 가상 디스크로 연결됩니다. 인스턴스가 삭제될 때, 연결된 볼륨은 외부 장치에 유지되며, 다른 인스턴스에서 다시 사용할 수 있습니다.

또한 인스턴스에서 실행되는 애플리케이션 소프트웨어는 OpenStack Swift에서 제공되는 객체 저장소에 액세스할 수 있습니다.

임시 디스크 및 Cinder 볼륨

그림 7: OpenStack의 임시 디스크와 Cinder 볼륨 비교

영구 디스크

GCP는 OpenStack의 Cinder 볼륨과 비슷하게 영구 디스크의 형태로 인스턴스에 연결된 영구 저장소를 제공합니다. 영구 디스크는 운영체제 파일을 포함하는 시스템 디스크로 사용되며, 영구 애플리케이션 데이터를 저장하기 위해 사용됩니다. 데이터는 인스턴스에서 영구 디스크 저장소로 이동하기 전에 자동으로 암호화됩니다. 단일 영구 디스크를 최대 64TB까지 확장할 수 있지만, 연결된 디스크의 최대 용량 합계는 인스턴스 크기를 기준으로 제한됩니다. 자세한 내용은 저장소 옵션을 참조하세요.

고성능 로컬 저장소가 필요한 경우에는 로컬 SSD(솔리드 스테이트 디스크)를 사용할 수도 있습니다. 각 로컬 SSD의 크기는 375GB지만, 인스턴스당 최대 8개의 로컬 SSD 장치를 연결하여 로컬 SSD 저장소 공간을 총 3TB로 확대할 수 있습니다. 실시간 이전은 로컬 SSD가 연결된 인스턴스에서 사용할 수 있습니다. 로컬 SSD의 데이터는 실시간 이전 중 인스턴스 간에 복사되기 때문에 저장소 성능이 일시적으로 저하될 수 있습니다.

인스턴스에서 실행되는 애플리케이션 소프트웨어는 대부분의 바이너리 객체 또는 다양한 크기의 Blob을 저장하고 액세스하기 위한 호스팅된 서비스인 Cloud Storage에서 제공되는 객체 저장소에 액세스할 수 있습니다.

VM 인스턴스

OpenStack과 GCP의 용어 및 개념 비교는 다음과 같습니다.

OpenStack GCP 참고
인스턴스 유형 머신 유형 OpenStack에서 일반 사용자는 커스텀 인스턴스 유형을 만들 수 없습니다.

GCP에서는 모든 사용자가 커스텀 머신 유형을 만들 수 있습니다.
메타데이터 서비스 메타데이터 서버 OpenStack은 인스턴스에 대한 정보만 제공합니다.

GCP는 프로젝트에 대한 정보도 제공합니다.

OpenStack에서 새 VM 인스턴스를 실행할 때는 vCPU 수, 메모리 양과 같은 인스턴스 크기를 지정하기 위한 인스턴스 유형을 선택합니다. 시스템 관리자가 할당한 적절한 액세스 권한이 있으면, 추가 인스턴스 유형을 정의할 수 있습니다. 일반 사용자는 커스텀 인스턴스 유형을 추가할 수 없습니다.

GCP에서 인스턴스 크기는 머신 유형으로 정의됩니다. 사전 정의된 머신 유형 중 하나를 선택하는 것 외에도, vCPU 수 및 메모리 양을 개별적으로 변경해서 커스텀 머신 유형을 만들 수 있습니다. 자세한 내용은 머신 유형을 참조하세요.

메타데이터

OpenStack은 인스턴스 유형, 보안 그룹, 할당된 IP 주소와 같이 인스턴스 게스트 OS(운영체제)에서 VM 인스턴스 정보를 검색하기 위한 메타데이터 서비스를 제공합니다. 또한 키-값의 형태로 커스텀 메타데이터를 추가할 수도 있습니다. OpenStack은 사용자 데이터라는 메타데이터 유형을 제공합니다. 애플리케이션 패키지 설치와 같이 해당 콘텐츠에 따라 게스트 OS에서 실행되는 cloud-init 에이전트가 시작 구성 작업을 수행하도록 새 인스턴스를 시작할 때 실행 가능한 텍스트 파일을 user-data로 지정할 수 있습니다. http://169.254.169.254/latest/meta-data의 URL을 사용하여 게스트 OS에서 메타데이터에 액세스합니다.

GCP는 인스턴스 게스트 OS에서 인스턴스 및 프로젝트에 대한 정보를 검색하기 위한 메타데이터 서버를 제공합니다. 프로젝트 메타데이터는 프로젝트의 모든 인스턴스에서 공유됩니다. 인스턴스 메타데이터 및 프로젝트 메타데이터 모두에 대해 키-값의 형태로 커스텀 메타데이터를 추가할 수 있습니다. GCP는 개발자가 인스턴스를 각각 시작하거나 종료할 때 실행되는 startup-scriptshutdown-script라는 특수한 메타데이터를 제공합니다.

OpenStack user-data와 달리 startup-script는 인스턴스를 다시 시작할 때마다 실행됩니다. 두 스크립트인 startup-scriptshutdown-script는 OS 템플릿 이미지에 사전 설치되어 있는 compute-image-packages에 포함된 에이전트에 의해 처리됩니다. 자세한 내용은 인스턴스 메타데이터 저장 및 검색을 참조하세요.

다음 URL 중 하나를 사용하여 게스트 OS의 메타데이터에 액세스합니다.

  • http://metadata.google.internal/computeMetadata/v1/
  • http://metadata/computeMetadata/v1/
  • http://169.254.169.254/computeMetadata/v1/
게스트 운영체제 에이전트
OpenStack GCP 참고
cloud-init 구성 작업 에이전트 패키지 compute-image-packages 구성 작업 에이전트 패키지 OpenStack 에이전트는 초기 부팅 설정만 처리합니다.

GCP 에이전트는 인스턴스가 실행되는 동안 초기 부팅 설정과 동적 구성 변경 사항을 처리합니다.

OpenStack에서는 cloud-init라는 에이전트 패키지가 표준 게스트 OS 이미지에 사전 설치됩니다. 이 패키지는 처음에 부팅할 때 루트 파일 시스템 공간 확장, SSH 공개 키 저장, 사용자 데이터로 제공된 스크립트 실행 등 초기 구성 작업을 처리합니다.

GCP에서는 compute-image-packages라는 에이전트 패키지가 표준 게스트 OS 이미지에 사전 설치됩니다. 이 패키지는 처음에 부팅할 때 startup-script를 통해 초기 구성을 작업을 처리하고, 게스트 OS가 실행되는 동안 새로운 SSH 공개 키 추가 HTTP 부하 분산을 위한 네트워크 구성 변경 등의 동적 시스템 구성을 처리합니다. 인스턴스를 시작한 후 Google Cloud Platform Console 또는 gcloud 명령줄 도구를 통해 새 SSH 키를 생성하고 추가할 수 있습니다.

Google Cloud SDK는 GCP에서 표준 게스트 OS 이미지에 사전 설치됩니다. 이 SDK를 사용하면 기본적으로 특정 권한이 부여되는 서비스 계정을 사용하여 게스트 OS로부터 GCP의 서비스에 액세스할 수 있습니다.

액세스 제어

GCP에서 액세스 제어는 Google Cloud IAM에 의해 인스턴스별로 적용됩니다. 예를 들어 인스턴스에서 실행되는 애플리케이션이 Google Cloud Storage에 데이터를 저장하도록 하려면 해당 인스턴스에 읽기-쓰기 권한을 할당할 수 있습니다. Cloud IAM의 경우, 인스턴스에서 실행되는 애플리케이션에 대해 비밀번호 또는 사용자 인증 정보 코드를 수동으로 준비할 필요가 없습니다. 자세한 내용은 인스턴스의 서비스 계정 만들기 및 사용 설정을 참조하세요.

OpenStack Keystone은 사용자 계정을 기준으로 서비스 API에 대한 액세스 제어를 제공하지만, 객체 저장소 또는 데이터베이스의 읽기-쓰기 권한과 같이 애플리케이션 API에 대한 인스턴스 기반 액세스 제어를 제공하지 않습니다. 필요한 경우 애플리케이션 API에 대해 커스텀 액세스 제어를 구현할 수 있습니다.

IaaS: 서비스로서의 플랫폼 이후

이 문서에서는 IaaS에 필수적인 OpenStack 및 Google Cloud Platform에서 제공되는 구성요소를 비교해서 보여줍니다. 하지만 가용성, 확장성, 운영 효율성 측면에서 GCP를 최대한 활용하기 위해서는 전체 시스템의 기초 요소로서 관리형 서비스를 조합해야 합니다.

GCP 서비스의 전체 범위는 IaaS 플랫폼의 기존 개념을 넘어서 다음 항목 이상을 포함하도록 확장됩니다.

다음 단계

  • GCP의 저장소, 컴퓨팅 및 모니터링 서비스와 Google Cloud Dataproc를 통합하여 완전한 데이터 처리 플랫폼을 구축하는 방법을 알아봅니다.
  • Google Stackdriver를 사용한 모니터링, 로깅, 진단을 알아봅니다.
  • 서버리스 플랫폼을 제공하는 애널리틱스를 위한 완전 관리형 데이터 웨어하우스인 Google BigQuery에 대해 자세히 알아보고, 페타바이트급 데이터 세트에서도 SQL을 사용하여 데이터 분석을 수행하는 방법을 자세히 살펴봅니다.
  • Google Cloud Platform 제품 및 서비스에 대해 알아봅니다.
이 페이지가 도움이 되었나요? 평가를 부탁드립니다.

다음에 대한 의견 보내기...

OpenStack 사용자를 위한 Google Cloud Platform