AWS 전문가를 위한 Google Cloud: Compute

업데이트: 2017년 11월 21일

AWS(Amazon Web Services) 및 Google Cloud가 해당 클라우드 환경에서 제공하는 컴퓨팅 서비스를 비교합니다. 컴퓨팅 서비스는 일반적으로 4가지 서비스 모델로 제공됩니다.

  • Infrastructure as a Service(IaaS): 사용자가 가상 머신 및 관련 서비스 모음에 필요에 따라 직접 액세스하여 일반적인 태스크를 자동화합니다.
  • Platform as a Service(PaaS) - 머신 레이어가 완전히 추상화되고, 사용자가 높은 수준의 서비스 및 API를 사용하여 리소스와 상호작용합니다.
  • FaaS(서비스로서의 기능) - 다양한 트리거에 대한 응답으로 개별 기능을 실행할 수 있는 서버리스 컴퓨팅 모델입니다.
  • CaaS(서비스로서의 컨테이너) - 머신 레이어를 추상화하지만 IaaS 모델의 유연성을 상당 부분 유지하는 IaaS/PaaS 하이브리드입니다.

이 문서에서는 Google Cloud 및 AWS에서 제공되는 IaaS, PaaS, FaaS, CaaS 서비스를 집중적으로 살펴봅니다.

IaaS 비교

IaaS를 위해 AWS는 Amazon Elastic Compute Cloud(EC2)를 제공하고 Google Cloud는 Compute Engine을 제공합니다. Google과 Amazon은 해당 IaaS 서비스에 대해 비슷한 접근 방식을 사용합니다. Amazon EC2와 Compute Engine 모두 다음과 같은 특성을 갖습니다.

  • 클라우드 환경의 기본 구성요소입니다.
  • 플랫폼에서 거의 모든 유형의 고객 워크로드를 실행하는 데 사용됩니다.

상위 수준에서 Amazon EC2 용어와 개념은 Compute Engine과 일치합니다.

기능 Amazon EC2 Compute Engine
가상 머신 인스턴스 인스턴스
머신 이미지 Amazon 머신 이미지 이미지
임시 가상 머신 스팟 인스턴스 선점형 VM
방화벽 보안 그룹 Compute Engine 방화벽 규칙
자동 인스턴스 확장 자동 확장 Compute Engine 자동 확장 처리
로컬 연결 디스크 임시 디스크 로컬 SSD
VM 가져오기 지원되는 형식: RAW, OVA, VMDK, VHD 지원되는 형식: RAW, OVA, VMDK, VHD
배포 지역 영역 영역

가상 머신 인스턴스

Compute Engine과 Amazon EC2 가상 머신 인스턴스의 많은 기능이 동일합니다. 두 서비스 모두에서 다음을 수행할 수 있습니다.

  • 저장된 디스크 이미지에서 인스턴스를 만듭니다.
  • 주문형으로 인스턴스를 시작하고 종료합니다.
  • 제한 없이 인스턴스를 관리합니다.
  • 인스턴스에 태그를 지정합니다.
  • 인스턴스에 사용 가능한 여러 운영체제를 설치합니다.

머신 액세스

Compute Engine 및 Amazon EC2는 머신 액세스 방법이 약간 다릅니다.

  • Amazon EC2에서 인스턴스에 대한 터미널 액세스가 필요하면 사용자 고유의 SSH 키를 포함해야 합니다.
  • Compute Engine에서는 인스턴스가 이미 실행 중이더라도 필요할 때 키를 만들 수 있습니다.
  • 로컬 머신에 키를 저장할 필요 없이 Google Cloud Console에서 제공되는 Compute Engine의 브라우저 기반 SSH 터미널을 사용할 수 있습니다.

인스턴스 유형

Amazon EC2와 Compute Engine은 모두 특정 양의 가상 CPU, RAM, 네트워크가 포함된 사전 정의된 다양한 인스턴스 구성을 제공합니다.

  • Amazon EC2에서는 이러한 구성을 인스턴스 유형이라 합니다.
  • Compute Engine에서는 이를 머신 유형이라고 부릅니다.
  • Compute Engine에서는 사전 정의된 구성에 얽매이지 않고 워크로드에 맞게 인스턴스의 CPU 및 RAM을 맞춤설정할 수 있습니다.

사전 정의된 인스턴스는 다음 표에 설명된 대로 의도된 용도에 따라 대략적으로 분류됩니다.

머신 유형 설명
공유 코어

단일 물리적 CPU의 일부에서 실행되는 머신입니다.

리소스가 많이 필요하지 않지만 장시간 온라인 상태로 유지해야 하는 태스크에 적합합니다.

표준

컴퓨팅, 네트워크, 메모리 리소스의 균형을 제공하는 머신입니다.

특정 리소스 요건이 없는 대부분의 일반적인 애플리케이션에 적합합니다.

고성능 메모리

메모리 대 vCPU 비율이 표준보다 높은 머신입니다.

컴퓨팅 요구보다 메모리 요구가 더 높은 애플리케이션에 적합합니다. 일례로 고성능 데이터베이스 애플리케이션, 대용량 데이터 캐시를 유지해야 하는 애플리케이션, 기업 관리 시스템과 같은 대형 데이터 중심 애플리케이션이 있습니다.

고성능 CPU

vCPU 대 메모리 비율이 표준보다 높은 머신입니다.

메모리 요건이 비정상적으로 높지 않은 컴퓨팅 중심 애플리케이션에 적합합니다. 일례로 데이터 변환 소프트웨어(예: 동영상 인코딩), 과학 및 공학용 시뮬레이션 소프트웨어, 트래픽 양이 많은 웹 서버가 있습니다.

GPU

개별적인 GPU(그래픽 처리 장치)가 포함된 머신입니다.

높은 산술 처리 능력이 요구되는 애플리케이션에 적합합니다. 일반적인 예시는 머신러닝이지만 이 외에도 고급 산수 처리 GPU가 제공하는 향상된 효율성을 활용할 수 있는 태스크가 많이 있습니다.

SSD 스토리지

로컬 SSD(솔리드 스테이트 드라이브) 저장소가 포함된 머신입니다.

높은 저장소 처리량이 요구되는 애플리케이션에 적합합니다. SSD 저장소는 마그네틱 저장소보다 빠른 데이터 액세스 성능을 제공합니다.

고밀도 스토리지

고용량 마그네틱 미디어 스토리지가 포함된 머신입니다.

로컬 디스크에 대용량 데이터를 보존하는 애플리케이션에 적합합니다. 많은 경우에 대용량 스토리지가 필요한 애플리케이션은 VM에 연결된 디스크 대신 다른 웹 서비스에 데이터를 저장할 수 있습니다.

다음 표에서는 2016년 5월을 기준으로 두 서비스의 인스턴스 유형을 보여줍니다.

머신 유형 Elastic Compute Cloud Compute Engine
공유 코어 t2.micro - t2.large f1-micro
g1-small
표준 m3.medium - m3.2xlarge
m4.large - m4.10xlarge
n1-standard-1 - n1-standard-64
고성능 메모리 r3.large - r3.8xlarge
x1.32xlarge
n1-highmem-2 - n1-highmem-64
고성능 CPU c3.large - c3.8xlarge
c4.large - c4.8xlarge
n1-highcpu-2 - n1-highcpu-64
GPU g2.2xlarge
g2.8xlarge
대부분의 머신 유형에 GPU 추가
SSD 스토리지 i2.xlarge - i2.8xlarge n1-standard-1 - n1-standard-64
n1-highmem-2 - n1-highmem-64
n1-highcpu-2 - n1-highcpu-64*
고밀도 스토리지 d2.xlarge - d2.8xlarge 해당 사항 없음

* Compute Engine이 이러한 AWS 인스턴스 유형과 정확하게 일치하는 머신 유형을 제공하지 않지만 다른 머신 유형에 SSD 로컬 스토리지를 연결하면 동일한 효과를 얻을 수 있습니다.

Compute Engine과 AWS는 표준, 고성능 메모리, 고성능 CPU, 공유 코어와 같은 상위 수준의 인스턴스 유형 모음을 공유합니다. 하지만 Compute Engine은 로컬 SSD 스토리지를 사용하는 인스턴스에 대한 특정 카테고리가 없습니다. 모든 Compute Engine의 비공유 인스턴스 유형에서는 로컬 SSD 디스크 추가가 지원됩니다. 각 환경이 로컬로 연결된 SSD를 구현하는 방법을 자세히 비교하려면 로컬로 연결된 스토리지를 참조하세요.

Compute Engine은 현재 대용량 마그네틱 스토리지를 제공하지 않습니다.

임시 인스턴스

임시 인스턴스는 다른 프로세스에 할당된 리소스의 여유 사이클에서 실행되는 가상 머신입니다. 결과적으로 전용 리소스로 생성된 VM보다는 비용이 낮은 VM이 사용 가능 여부가 예측 불가능한 상태로 제공됩니다. 임시 인스턴스는 다음 경우에 유용합니다.

  • 작업 손실 없이 중단 가능한 작업
  • 특정 시간 범위 내에 완료할 필요가 없는 우선순위가 낮은 작업
  • 사용 가능한 컴퓨팅 능력이 있는 경우, 이로 인한 부스트를 활용할 수 있는 작업을 위한 추가 리소스. 예: 동영상 렌더링.

Amazon EC2는 스팟 인스턴스라는 임시 인스턴스를 제공하고 Compute Engine은 선점형 VM이라는 비슷한 인스턴스를 제공합니다. 두 가지 모두 비슷한 기능을 제공하지만 가격 책정 모델이 다릅니다.

스팟 인스턴스와 선점형 VM은 모두 다음 특성을 갖습니다.

  • 일반적인 주문형 인스턴스보다 적은 종류의 인스턴스 유형 및 머신 이미지 집합으로 제한됩니다.
  • 실행 중에는 주문형 인스턴스와 동일한 성능을 발휘할 수 있습니다.
  • 실행 중에는 완전히 제어 가능합니다.

Amazon EC2 스팟 인스턴스는 두 가지 형태로 제공됩니다.

  • 일반적인 스팟 인스턴스는 다음과 같습니다.
    • 스팟 시장에서 경매로 판매됩니다.
    • 입찰이 수락되면 시작됩니다.
    • 사용자가 종료하거나 AWS가 중단할 때까지 활성 상태로 유지합니다.
  • 스팟 블록은 다음과 같습니다.
    • 일반적인 주문형 요율보다 낮은 고정 가격이 적용됩니다.
    • 할인된 요율로 최대 6시간으로 제한됩니다.

Compute Engine 선점형 VM이 스팟 인스턴스와 다른 점은 다음과 같습니다.

  • 가격이 고정되어 있습니다. 머신 유형에 따라 선점형 VM 가격은 주문형 요율보다 거의 80%까지 할인될 수 있습니다.
  • Compute Engine에서 회수되지 않을 경우, 선점형 VM이 최대 24시간 동안 실행된 후 자동으로 종료됩니다.
  • 라이선스 요금이 포함된 프리미엄 운영체제를 사용하는 경우, 해당 선점형 VM을 사용하는 동안 라이선스의 전체 비용이 청구됩니다.

머신 이미지

Compute Engine과 Amazon EC2는 모두 머신 이미지를 사용해서 새로운 인스턴스를 만듭니다. Amazon에서는 이러한 이미지를 AMI(Amazon 머신 이미지)라고 부르고, Compute Engine에서는 이를 단순히 이미지라고 부릅니다.

Amazon EC2와 Compute Engine은 상당히 비슷하므로, 두 플랫폼 모두 이미지를 생성할 때 동일한 워크플로를 사용할 수 있습니다. 예를 들어 Amazon EC2 AMI와 Compute Engine 이미지 모두 운영체제가 포함됩니다. 또한 웹 서버나 데이터베이스와 같은 기타 소프트웨어도 포함될 수 있습니다. 그리고 두 서비스 모두 타사 공급업체에서 게시된 이미지나 개인용으로 제작된 커스텀 이미지를 사용할 수 있습니다.

Amazon EC2와 Compute Engine은 다른 방식으로 이미지를 저장합니다. AWS에서는 이미지를 Amazon S3(Simple Storage Service) 또는 Amazon EBS(Elastic Block Store)에 저장합니다. Amazon S3에 저장된 이미지를 기반으로 인스턴스를 만들 경우 생성 중에 Amazon EBS보다 높은 지연 시간이 발생합니다.

Google Cloud에서 이미지는 Compute Engine 내에 저장됩니다. 사용 가능한 이미지를 보거나 이미지를 만들거나 가져오려면 Cloud Console 이미지 페이지로 이동하거나 Cloud SDK에서 gcloud 명령줄 도구를 사용합니다.

Amazon EC2와 달리 Compute Engine에는 이미지를 공개적으로 제공하는 방법이 없고 사용 가능한 이미지를 가져올 수 있는 커뮤니티 저장소도 없습니다. 하지만 이미지를 Cloud Storage로 내보내고 이를 공개적으로 제공하여 이미지를 비공식적으로 공유할 수 있습니다.

Amazon의 머신 이미지는 특정 리전 내에서만 사용할 수 있습니다. 반면에 Compute Engine의 머신 이미지는 전역적으로 사용할 수 있습니다.

공개 이미지

Amazon EC2와 Compute Engine 모두 일반적으로 사용되는 운영체제가 포함된 다양한 공개 이미지를 제공합니다. 두 플랫폼 모두에서 라이선스가 필요한 운영체제가 포함된 프리미엄 이미지를 설치할 경우 일반적인 인스턴스 비용 외에도 라이선스 요금을 지불해야 합니다.

두 서비스 모두에서 가장 일반적인 운영체제의 머신 이미지에 액세스할 수 있습니다. Compute Engine에서 제공되는 전체 이미지 목록은 공개 이미지 목록을 참조하세요.

Amazon EC2에서는 Compute Engine에서 공개 이미지로 제공되지 않는 일부 운영체제 이미지 지원을 제공합니다.

  • Amazon Linux
  • Windows Server 2003(프리미엄)
  • Oracle Linux(프리미엄)

커스텀 이미지 가져오기

Amazon EC2와 Compute Engine 모두 기존 머신 이미지를 각각의 환경으로 가져오는 방법을 제공합니다.

Amazon EC2는 VM 가져오기/내보내기라는 서비스를 제공합니다. 이 서비스는 여러 Windows, RHEL(Red Hat Enterprise Linux), CentOS, Ubuntu, Debian 등을 포함한 다양한 운영체제는 물론 RAW, OVA, VMDK, VHD 등과 같은 여러 가상 머신 이미지 유형을 지원합니다. 가상 머신을 가져오려면 가상 머신 이미지를 번들로 묶고 이를 AMI로 Amazon Simple Storage Service(S3)에 업로드하는 명령줄 도구를 사용합니다.

Compute Engine으로 머신 이미지를 가져오는 프로세스와 요구사항은 Amazon EC2의 프로세스 및 요구사항과 유사합니다. VM 가져오기/내보내기와 마찬가지로 Compute Engine 가져오기 도구는 RAW, OVA, VMDK, VHD 이미지 유형과 Windows, RHEL, CentOS, Ubuntu, Debian 운영체제를 지원합니다. 가상 머신을 가져오려면 Cloud Storage에 이미지를 업로드한 다음 gcloud 명령줄 도구 또는 Cloud Console을 사용하여 이미지를 Compute Engine으로 가져오는 프로세스를 완료합니다. 이미지 및 기타 가상 애셋을 Compute Engine으로 가져오는 방법에 대한 자세한 내용은 가져오기 방법 선택을 참조하세요.

고유한 커스텀 운영체제를 빌드하고 Compute Engine에서 실행하려면 운영체제가 커스텀 이미지의 하드웨어 지원 및 커널 요구사항을 충족하는지 확인합니다.

이미지를 Amazon S3 또는 Cloud Storage에 저장하는 비용 외에, AWS나 Google Cloud 모두 해당 가져오기 서비스에 대한 비용을 부과하지 않습니다.

자동 인스턴스 확장

Compute Engine과 Amazon EC2는 모두 사용자 정의된 정책에 따라 인스턴스를 만들고 삭제하는 자동 확장을 지원합니다. 자동 확장을 사용하면 항상 특정 인스턴스 수를 유지하거나 특정 조건에 따라 용량을 조정할 수 있습니다. 자동 확장된 인스턴스는 사용자 정의된 템플릿에서 생성됩니다.

Compute Engine과 Amazon EC2는 자동 확장을 비슷한 방식으로 구현합니다.

  • Amazon의 자동 확장은 그룹 내에서 인스턴스를 확장합니다. 자동 확장 처리는 사용자가 선택한 확장 계획에 따라 인스턴스를 만들고 삭제합니다. 그룹 내의 각 새 인스턴스는 시작 구성에서 생성됩니다.
  • Compute Engine의 자동 확장 처리는 관리형 인스턴스 그룹 내에서 인스턴스를 확장합니다. 자동 확장 처리는 자동 확장 정책에 따라 인스턴스를 만들거나 삭제합니다. 인스턴스 그룹 내의 각 새 인스턴스가 인스턴스 템플릿에서 생성됩니다.

Amazon의 자동 확장에서는 세 가지 확장 계획이 허용됩니다.

  • 수동 - 자동 확장이 확장 또는 축소하도록 수동으로 지시합니다.
  • 예약 - 예약된 시간에 확장 또는 축소하도록 자동 확장을 구성합니다.
  • 동적 - 자동 확장이 정책을 기준으로 확장합니다. Amazon CloudWatch 측정항목 또는 Amazon SQS(Simple Queue Service) 큐를 기준으로 정책을 만들 수 있습니다.

반면에 Compute Engine의 자동 확장 처리에서는 동적 확장만 지원합니다. 평균 CPU 사용률, HTTP 부하 분산 제공 용량, Cloud Monitoring 측정항목을 기준으로 정책을 만들 수 있습니다.

내부 네트워크

Compute Engine과 Amazon EC2 모두에서 새 인스턴스는 기본 내부 네트워크에 자동으로 연결됩니다. 또한 대체 네트워크를 만들고 두 서비스 모두 해당 네트워크로 인스턴스를 시작합니다. Google Cloud 네트워킹과 AWS 네트워킹의 전체 비교는 네트워킹 문서를 참조하세요.

방화벽

Amazon EC2와 Compute Engine 모두 사용자가 가상 머신 인스턴스에 대한 트래픽을 선택적으로 허용하고 거부할 수 있도록 방화벽 정책을 구성할 수 있습니다. 기본적으로 두 서비스 모두 네트워크 외부에서 들어오는 모든 트래픽을 차단하며, 패킷이 인스턴스에 연결될 수 있도록 하려면 사용자가 방화벽 규칙을 설정해야 합니다.

Amazon EC2와 Amazon Virtual Private Cloud(VPC)는 보안 그룹네트워크 액세스 제어 목록(NACL)을 사용하여 들어오고 나가는 트래픽을 허용하거나 거부합니다. Amazon EC2 보안 그룹은 Amazon EC2 클래식의 인스턴스를 보호하고, Amazon VPC 보안 그룹 및 NACL은 Amazon VPC의 인스턴스 및 네트워크 서브넷을 보호합니다.

Compute Engine은 방화벽 규칙을 사용해서 Compute Engine 가상 머신 인스턴스 및 네트워크를 보호합니다. 규칙은 소스 IP 주소 범위, 프로토콜, 포트 또는 사용자 정의된 태그를 지정하여 만듭니다. 사용자 정의된 태그는 가상 머신 인스턴스의 소스 및 대상 그룹을 나타냅니다.

블록 스토리지

Amazon EC2와 Compute Engine 모두 네트워크에 연결된 블록 스토리지와 로컬로 연결된 블록 스토리지를 지원합니다. 블록 스토리지 서비스의 세부적인 비교는 블록 스토리지를 참조하세요.

비용

이 섹션에서는 Compute Engine과 Amazon EC2의 가격 책정 모델을 비교해서 보여줍니다.

주문형 가격 책정

Compute Engine과 Amazon EC2에는 인스턴스를 실행할 수 있는 비슷한 주문형 가격 책정 모델이 있습니다.

  • Amazon EC2는 초 단위로 비용을 청구하고 최소 청구 비용은 1분입니다. Windows 또는 RHEL과 같은 프리미엄 운영체제는 시간별로 청구되며, 1시간 단위로 반올림됩니다.
  • Compute Engine은 초 단위로 비용을 청구하고, 최소 청구 비용은 1분입니다.

두 서비스 모두 인스턴스를 무기한 실행할 수 있습니다.

할인 가격

Compute Engine과 Amazon EC2는 할인 가격 책정 방식이 매우 다릅니다.

다음과 같이 예약 인스턴스를 프로비저닝하여 Amazon EC2에서 할인 가격을 적용받을 수 있습니다.

  • 1년 또는 3년 동안 특정 개수의 인스턴스를 약정해야 합니다.
  • 해당 인스턴스에 대해서는 비용이 낮게 책정됩니다.
  • 3년 약정이 1년 약정보다 할인폭이 더 큽니다.
  • 초기 지불 비용이 높을수록 할인폭이 더 커집니다.
  • 예약된 인스턴스는 구매 시의 특정 인스턴스 유형 및 가용성 영역으로 제한됩니다.
  • 가용성 영역 전환 및 예약된 인스턴스 교환은 동일 제품군 내의 다른 인스턴스 유형에서만 가능합니다.

Compute Engine 인스턴스에서는 지속 사용 할인을 얻을 수 있습니다.

  • Compute Engine은 인스턴스가 해당 월에 활성 상태로 유지된 시간에 따라 인스턴스에 할인을 자동으로 적용합니다.
  • 해당 월에 인스턴스를 더 오래 사용할수록 할인 폭이 커집니다.
  • 지속 사용 할인은 표준 주문형 요율의 최대 30%까지 비용을 줄일 수 있습니다.

FaaS 비교

FaaS(서비스로서의 기능)를 위해 Amazon에서는 AWS Lambda를 제공하고 Google Cloud에서는 Cloud Functions를 제공합니다. 이러한 서비스는 비슷한 서비스 모델을 갖고 있습니다.

  • 다양한 트리거에 대한 응답으로 개별 기능을 실행할 수 있는 서버리스 컴퓨팅 플랫폼입니다.
  • 해당 기능이 실행 중일 때만 비용이 청구됩니다.
  • 사용 패턴이 고르지 않은 서비스를 호스팅하기 위한 경제적인 방법입니다.

서비스 모델 비교

AWS Lambda와 Cloud Functions의 용어와 개념은 다음과 같이 비교될 수 있습니다.

기능 AWS Lambda Cloud Functions
코드 수집 Zip 업로드, 온라인 IDE, 데스크톱 IDE, Amazon S3 Zip 업로드, 온라인 IDE, Cloud Storage, GitHub
코드 업데이트 지연 시간 일반적으로 수 초 이내 일반적으로 2분 이내
최대 동시 실행 수 기본적으로 리전별로 1,000개 기본적으로 기능별로 1,000개
최대 배포 크기 50MB 압축, 250MB 비압축 100MB 압축, 500MB 비압축
트리거 S3, DynamoDB, Kinesis Streams Firehose, SNS, SES, Cognito, CloudFormation, CloudWatch, CodeCommit, 예약 이벤트, AWS 구성 변경사항, Amazon Echo, Amazon Lex, API Gateway(HTTP), IoT Button, CloudFront HTTP, Cloud Storage, Pub/Sub, Firebase, Cloud Logging
지원 언어 Node.js, 자바, Python, C#, Go Node.js 6, Node.js 8, Python
메모리 할당 128MB~1.5GB(64MB 단위) 128MB, 256MB, 512MB, 1GB, 2GB
시간 제한 한도 1초~15분 1초~9분
버전 관리 기본 제공 Cloud Source Repositories 사용
자동 확장
로깅 Amazon CloudWatch Cloud Logging
배포 지역 리전 지역
가격 책정 모델 요청별, 기간(0.1초 단위), 데이터 전송. 기간 비용은 메모리 사용량에 따라 확장됩니다. 요청별, 기간(0.1초 단위), 데이터 전송. 기간 비용은 메모리 및 CPU 사용량에 따라 확장됩니다.

시작 및 확장

AWS Lambda 및 Cloud Functions는 여러 기능을 공유합니다. 두 가지 모두 다양한 트리거가 포함된 서비리스 코드 실행을 제공하고, 필요에 따라 자동으로 확장됩니다. 두 가지 모두 단순 배포, 확장, 오류 복구를 제공합니다. 아키텍처는 코드 복사본으로 컴퓨팅 컨테이너를 시작하고, 요청 부하 처리를 위해 인스턴스 수를 자동으로 확장합니다. 이 기능이 배포된 다음에는 구성 또는 관리를 확장할 필요가 없습니다.

Google은 모든 새 인스턴스에서 첫 번째 요청에 대한 지연 시간을 크게 줄여주는 선점형 이미지 생성 아키텍처를 사용합니다. 이러한 방식은 실시간 애플리케이션 또는 애플리케이션이 매우 빠르게 확장되어야 하는 상황에서 큰 이점일 수 있습니다.

지원되는 언어 및 트리거

Lambda는 Cloud Functions보다 오랫동안 사용되었으며, 따라서 더 많은 언어와 트리거 유형을 지원합니다. Cloud Functions는 Firebase 트리거, Google Cloud 작업 제품군 로그, Pub/Sub를 지원합니다. 이러한 도구를 사용하면 다른 Google Cloud 서비스나 이벤트에서 Cloud 함수를 트리거할 수 있습니다.

런타임 제한

FaaS 플랫폼은 요청별 기준에 따라 인스턴스를 배포하는 순수한 트랜잭션 방식으로 설계되었으므로, 초기 요청을 벗어나서 코드를 연속으로 실행하기 위한 목적으로 사용할 수 없습니다 개발자는 애플리케이션을 스테이트리스(stateless) 및 단기 실행 방식으로 설계해야 합니다. 이러한 제한은 Lambda 및 Cloud Functions 모두에 적용됩니다.

  • AWS는 5분 후에 실행을 종료합니다.
  • Cloud Functions는 9분 후에 실행이 종료됩니다.

FaaS 배포

Amazon과 Google은 FaaS 배포에 약간 다른 방식을 사용합니다. AWS Lambda에서는 zip 파일 또는 jar 파일이나 CloudFormation 또는 S3을 통한 배포를 지원합니다. Google Cloud의 Cloud Functions는 zip 파일 외에도 GitHub 또는 Cloud Source Repositories의 Git 저장소에서 배포할 수 있습니다. Git 지원은 Cloud Functions를 해당 배포 프로세스에 밀접하게 연결합니다. 웹훅을 기반으로 자동화된 업데이트를 구성할 수도 있습니다.

비용

AWS Lambda 가격 책정에는 요청별 기본 요율과 함께 RAM 할당 및 컴퓨팅 시간을 기반으로 하는 가변 요율이 포함됩니다. AWS Lambda는 표준 EC2 요율로 데이터 전송 비용을 청구합니다.

Cloud Functions에서는 프로비저닝된 메모리와 CPU를 기준으로 하는 가변 요율과 호출 요율에 따라 비용을 청구합니다. AWS Lambda와 비슷하게 Cloud Functions는 이그레스 대역폭에 표준 요금을 청구하고 인그레스 트래픽에는 비용을 청구하지 않습니다.

자세한 내용은 Cloud Functions 가격 책정 페이지를 참조하세요. 특정 워크로드의 예상 비용을 계산하려면 Google Cloud 가격 계산기를 사용해 보세요.

PaaS 비교

PaaS에 대해 AWS에서는 AWS Elastic Beanstalk을 제공하고 Google Cloud에서는 App Engine을 제공합니다. 두 서비스 모두 비슷한 기능을 제공합니다.

  • 관리형 플랫폼 서비스로 코드를 푸시하여 애플리케이션을 게시할 수 있습니다.
  • 서비스는 다음을 관리합니다.
    • 기본 인프라
    • 자동 확장
    • 애플리케이션 버전 제어

서비스 모델 비교

AWS Elastic Beanstalk은 Amazon EC2 인스턴스 또는 Amazon RDS 데이터베이스와 같은 기본 AWS 리소스 집합을 구성 및 배포하여 입력 구성을 기준으로 애플리케이션에 적합한 런타임을 만듭니다.

App Engine은 이와 동일한 모델을 사용합니다. 하지만 App Engine은 두 가지 고유한 환경을 제공합니다. App Engine 표준 환경과 App Engine 가변형 환경의 이 두 환경은 각각 특정 사용 사례를 염두에 두고 디자인되었습니다.

  • App Engine 표준 환경에서는 Google의 인프라에서 실행되는 컨테이너 인스턴스에 코드가 배포됩니다. App Engine 표준 환경은 기본 Compute Engine VM 인스턴스에 의존하지 않으므로, App Engine 가변형 환경보다 더 빠르게 확장됩니다. 하지만 App Engine 표준 환경의 맞춤설정 옵션은 App Engine 가변형 환경보다 제한적이며, 개발자가 미리 정의된 서비스의 런타임 환경 집합 중에서 런타임 환경을 사용해야 합니다.
  • App Engine 가변형 환경에서는 Compute Engine VM 인스턴스에서 실행되는 Docker 컨테이너에 코드가 배포되며, 이러한 컨테이너는 App Engine에서 관리됩니다. App Engine 표준 환경을 사용할 때보다 더 많은 지원되는 런타임 목록 중에서 선택할 수 있으며, 부분 또는 전체적으로 맞춤설정된 런타임을 만들 수 있습니다. 하지만 트래픽이 급증할 때는 애플리케이션이 App Engine 표준 환경보다 느리게 확장될 수 있습니다. 자신에게 적합한 App Engine 환경을 선택하는 방법에 대한 자세한 내용은 App Engine 환경 선택을 참조하세요.

Elastic Beanstalk은 각 서비스에 통합할 수 있습니다.

  • Amazon DynamoDB: 모든 데이터 양을 저장하고 검색할 수 있는 완전 관리형 NoSQL 데이터베이스입니다.
  • Amazon RDS: MySQL, PostgreSQL, MariaDB, Amazon Aurora, Oracle, Microsoft SQL Server에서 지원되는 관리형 관계형 데이터베이스 서비스입니다.
  • 자동 확장 및 부하 분산
  • SQS 통합이 포함된 작업자 등급 환경에서는 백그라운드 및 주기적 작업 처리가 허용됩니다.
  • 다른 AWS 서비스 및 API와 통합

두 App Engine 환경 모두 다음과 같은 동일한 플랫폼 서비스 집합을 사용할 수 있습니다.

  • Firestore: 쿼리, 정렬, 트랜잭션이 포함된 영구 스토리지
  • Cloud SQL: MySQL 또는 PostgreSQL(현재 베타)에서 지원되는 관계형 데이터베이스
  • 자동 확장 및 부하 분산
  • 요청 범위를 벗어나는 작업을 수행하기 위한 비동기 작업 대기열
  • 지정된 시간 또는 일정한 간격으로 이벤트를 트리거하기 위한 예약된 작업
  • 다른 Google Cloud 서비스 및 API와의 통합

주요 구성요소

AWS Elastic Beanstalk과 App Engine은 모두 비슷한 주요 구성요소 집합에서 작동합니다. 개발자의 관점에서 AWS Elastic Beanstalk는 다음과 같은 주요 구성요소들로 구성되어 있습니다.

  • 애플리케이션 버전: 개발자가 제출한 배포 가능한 코드의 이름이 지정된/레이블이 지정된 반복 작업입니다.
  • 환경: AWS 리소스에 배포된 특정 애플리케이션 버전의 실행 중인 인스턴스입니다.
  • 환경 구성: 특정 환경과 연결된 특정 애플리케이션 버전에 대해 Elastic Beanstalk이 기본 AWS 리소스를 배포 및 구성하는 방법을 제어하는 매개변수 및 설정 모음입니다.
  • 애플리케이션: 환경, 환경 구성, 애플리케이션 버전 모음에 대한 논리적 버킷입니다.

App Engine은 다음과 같은 주요 구성요소들로 이뤄집니다.

  • 버전: 개발자가 제출한 배포 가능한 코드의 이름이 지정된 반복 작업과 서비스를 만들기 위해 이 코드를 App Engine에 배포하는 방법을 지정하는 구성 파일입니다.
  • 서비스: App Engine 애플리케이션은 다른 런타임을 사용하고 다른 성능 설정에 따라 작동하도록 구성할 수 있는 하나 이상의 서비스로 구성됩니다. 각 서비스는 소스 코드와 구성 파일로 구성됩니다.
  • 서비스 구성 파일: URL 경로가 요청 핸들러 및 정적 파일에 해당하는 방법을 지정하는 파일입니다. 이 파일에는 또한 애플리케이션 ID 및 최신 버전 식별자와 같은 애플리케이션 코드에 대한 정보가 포함되어 있습니다.
  • 인스턴스: 서비스가 실행되는 기본 컴퓨팅 리소스입니다. App Engine 가변형 환경에서 인스턴스는 Compute Engine VM 인스턴스의 Docker 컨테이너입니다. App Engine 표준 환경에서 인스턴스는 Google 인프라에서 실행되는 컨테이너입니다.
  • 애플리케이션: 하나 이상의 서비스가 포함된 논리적 버킷입니다. 이 버킷은 다른 런타임을 사용하고 다른 성능 설정으로 작동하도록 구성할 수 있습니다.

상위 수준에서 플랫폼은 다음과 같이 비교될 수 있습니다.

기능 AWS Elastic Beanstalk App Engine 표준 환경 App Engine 가변형 환경
지원되는 언어 런타임 자바, PHP, .NET, Node.js, Python(2.6, 2.7, 3.4), Ruby, Go Python 2.7, 자바 7, PHP 5.5, Go 1.6 Python(2.7, 3.5), 자바 8, Node.js, Go 1.8, Ruby, PHP(5.6, 7), .NET
커스텀 런타임 없음
자동 확장
무료 등급 사용 가능 예(기본 AWS 리소스의 무료 등급 기준) 예(하루당 28 인스턴스 시간) 아니요
저장소 옵션 Amazon S3, Amazon RDS, Amazon EFS, Amazon ElastiCache, Amazon DynamoDB Cloud Storage, Cloud SQL, Memcache, Firestore Cloud Storage, Cloud SQL, Memcache, Firestore
IAM 역할
사용 가능한 위치 US, EMEA, APAC US, EMEA, APAC US, EMEA, APAC
애플리케이션 사용자 인증 및 승인 아니요, 애플리케이션 내에서 개발해야 함 예, Firebase(여러 ID 공급업체), Google Cloud Identity, OAuth 2.0, OpenID 사용 예, Firebase(여러 ID 공급업체), Google 및 G Suite 계정, OAuth 2.0, OpenID 사용
태스크 및 메시지 큐 예, SQS 사용 예, Cloud Pub/Sub 및 Task Queue API 사용 예, Cloud Pub/Sub 및 Task Queue API 사용
애플리케이션 업그레이드 및 A/B 테스트 백엔드 용량 기준의 확장을 사용한 순차적 업데이트, 일회성 트래픽 스왑을 사용한 블루-그린 배포. 가중 순차 순환 대기 방식은 DNS 기반 접근 방식에서 사용할 수 있습니다. 예, 버전 간 상세 트래픽 분할 사용 예, 버전 간 상세 트래픽 분할 사용
모니터링 예, 상태 보고, 인스턴스 로그, 환경 이벤트 스트림 예, Google Cloud 작업 제품군(요청/응답 및 활동 로그), 업타임 체크 사용 예, Google Cloud 작업 제품군(요청/응답 및 활동 로그), 업타임 체크, 기본 Compute Engine 리소스의 커스텀 측정항목 및 알림 사용
네트워킹 VPC에 배치 가능 네트워크 제어 없음, 인터넷에 노출된 IP 끝점만 VPC 네트워크에 배치 가능
가격 책정 기본 AWS 리소스 비용 기준 선택한 시간당 인스턴스 기준 3가지 매개변수로 가격 구성:
  • 코어 시간별 vCPU
  • GB 시간별 메모리
  • 월별 GB당 영구 디스크
디버깅 예, X-ray 사용 예, Google Cloud 작업 제품군 사용 예, Google Cloud 작업 제품군 사용

커스텀 런타임

AWS Elastic Beanstalk과 App Engine 가변형 환경에서는 개발자가 자신의 고유한 커스텀 런타임을 만들 수 있습니다. 이 기능을 통해서는 다른 프로그래밍 언어를 사용하거나, 플랫폼의 표준 런타임에 대한 다른 버전 및 구현을 사용할 수 있습니다.

AWS Elastic Beanstalk은 애플리케이션 실행에 필요한 바이너리를 포함하는 AMI(Amazon 머신 이미지)인 커스텀 플랫폼을 통한 맞춤설정을 지원합니다. 단일 소스 구성에서 여러 플랫폼에 대해 동일한 머신 이미지를 만들기 위한 오픈소스 도구인 Packer를 사용해서 커스텀 플랫폼을 만들 수 있습니다. Packer 구성 템플릿을 사용하면 운영체제, 언어, 프레임워크는 물론 애플리케이션 제공을 위해 필요한 메타데이터 및 구성 옵션도 맞춤설정할 수 있습니다.

App Engine 가변형 환경은 커스텀 런타임을 통한 맞춤설정을 지원합니다. 커스텀 런타임을 만들려면 원하는 기본 이미지로 Dockerfile을 생성한 다음 원하는 런타임 환경을 빌드하는 docker 명령어를 추가합니다. Dockerfile에는 언어 인터프리터 또는 애플리케이션 서버와 같은 추가 구성요소가 포함될 수 있습니다. HTTP 요청을 처리할 수 있는 모든 소프트웨어를 활용할 수 있습니다.

두 경우 모두, 개발자는 모든 구성 요소가 호환되고, 예상 성능으로 작동하는지 확인해야 합니다.

AWS Elastic Beanstalk은 Packer를 사용하고 사용자가 전체 OS 이미지를 제어할 수 있도록 합니다. App Engine 가변형 환경은 Docker 컨테이너만 빌드하고 사용자가 애플리케이션 코드 및 종속 항목만 제어할 수 있도록 합니다. App Engine 가변형 환경 사용자는 기본 VM의 OS 커널 버전과 같은 항목을 제어하도록 허용되지 않습니다.

자동 확장

AWS Elastic Beanstalk과 App Engine은 모두 자동 확장을 지원합니다. 자동 확장은 애플리케이션의 리소스 사용을 기준으로 실행되는 백엔드 인스턴스 수를 자동으로 늘리거나 줄일 수 있게 해줍니다.

다음과 같은 확장 옵션을 기준으로 AWS Elastic Beanstalk 자동 확장을 구성할 수 있습니다.

  • 시작 구성을 사용하면 확장 트리거를 선택하고 이에 대한 매개변수를 기술할 수 있습니다.
  • 수동 확장을 사용하면 최소 및 최대 인스턴스 수, 가용성 영역, 확장 대기 시간을 설정할 수 있습니다.
  • 자동 확장을 사용하면 측정항목 기반 매개변수를 설정할 수 있습니다. 지원되는 트리거에는 네트워크 입력/출력, CPU 사용률, 디스크 읽기/쓰기 작업/바이트, 지연 시간, 요청 개수, 정상/비정상 호스트 개수가 포함됩니다.
  • 시간 기반 확장을 사용하면 반복 기준 또는 계획된 일회성 이벤트에 대한 에측을 기준으로 인스턴스를 확장 또는 축소할 수 있습니다(최댓값, 최솟값 또는 원하는 인스턴스 수 설정).

App Engine 표준 환경은 다음과 같은 확장 옵션을 제공합니다.

  • 시작 구성을 사용하면 확장 옵션을 선택하고 매개변수를 기술할 수 있습니다.
  • 수동 확장을 사용하면 시작 시 서비스에 대해 인스턴스 수를 설정할 수 있습니다.
  • 기본 확장을 사용하면 최대 인스턴스 수를 설정하고 마지막 요청을 수신한 후 인스턴스가 종료된 다음의 유휴 시간을 설정할 수 있습니다.
  • 자동 확장을 사용하면 인스턴스 수에 대한 최소 및 최대 수준, 지연 시간, 서비스의 동시 연결을 설정할 수 있습니다.

App Engine 가변형 환경은 다음과 같은 확장 옵션을 제공합니다.

  • 시작 구성을 사용하면 확장 옵션을 선택하고 매개변수를 기술할 수 있습니다.
  • 수동 확장은 App Engine 표준 환경과 동일한 방식으로 작동합니다.
  • 자동 확장을 사용하면 인스턴스의 최소 및 최대 개수, 대기 시간 기간, 대상 CPU 사용률을 설정할 수 있습니다.

애플리케이션 업그레이드 및 A/B 테스트

다음과 비슷한 단계에 따라 AWS Elastic Beanstalk 및 App Engine에서 애플리케이션을 배포하거나 업그레이드할 수 있습니다.

  1. 구성 파일에서 애플리케이션을 기술합니다.
  2. 명령줄 도구를 사용하여 새 버전을 배포합니다.

두 서비스 모두 관리 콘솔을 통한 배포 기능을 제공합니다.

AWS Elastic Beanstalk에서 내부 업데이트를 수행하면 애플리케이션이 짧은 시간 동안 중단될 수 있습니다. 다운타임을 방지하기 위해서는 새 버전을 개별 환경에 배포한 후 환경 URL을 스왑하는 블루-그린 배포를 수행할 수 있습니다. 환경별로 활성 버전을 하나만 처리할 수 있습니다. 가중 순차 순환 대기 방식은 DNS 기반 접근 방식에서 사용할 수 있습니다.

App Engine에서는 새 버전을 만들고 이 버전으로 전환하여, 다운타임 없이 현재 버전에 업데이트를 적용할 수 있습니다. 또한 요청자의 IP 주소 또는 쿠키를 기준으로 트래픽을 분할하도록 App Engine 애플리케이션을 구성할 수 있습니다. 애플리케이션/서비스별로 많은 버전을 처리할 수 있습니다.

디버깅

디버깅의 경우 AWS Elastic Beanstalk 콘솔을 사용하면 개발 환경의 인스턴스에서 AWS X-Ray 데몬을 실행할 수 있습니다. 이 데몬은 서버에 대한 요청 데이터 및 다른 서비스와의 애플리케이션 공동 작업 데이터를 수집합니다. 애플리케이션의 문제를 해결하고 가능한 최적화 방법을 찾는 데 유용한 서비스 맵을 만들 수 있습니다.

Google Cloud에서는 로깅 문을 사용하지 않고, 애플리케이션을 중지하거나 느리게 만들 필요 없이 Cloud Debugger를 사용하여 모든 코드 위치에서 App Engine 애플리케이션의 상태를 검사할 수 있습니다. 디버깅 중 사용자에게 영향을 미치지 않습니다. 프로덕션에서 Debugger를 사용하면 로컬 변수 및 호출 스택을 캡처하고 이러한 변수를 소스 코드의 특정 줄 위치로 다시 연결할 수 있습니다. Debugger를 사용하면 애플리케이션의 프로덕션 상태를 분석하고 프로덕션에서 코드 동작을 이해할 수 있습니다.

모니터링

AWS Management Console에서 AWS Elastic Beanstalk 환경을 모니터링하는 작업은 CPU 사용률과 네트워크 입력 및 출력과 같은 기본 측정항목들로 구성됩니다. Amazon CloudWatch는 기본 인스턴스에 대한 기본 EC2 모니터링 측정항목은 물론 환경 상태를 추가합니다. 사용자는 또한 이러한 각 측정항목에 대한 경보를 추가할 수 있습니다. 모든 EC2 인스턴스는 애플리케이션 문제를 해결하는 데 사용할 수 있는 로그를 생성합니다.

Google Cloud Console 대시보드에서 App Engine 애플리케이션을 모니터링하면 총 요청, CPU 및 메모리 사용률, 지연 시간, 인스턴스 업타임 등의 매개변수를 확인할 수 있습니다. Google Cloud 작업 제품군을 사용하면 여러 매개변수에 대한 알림을 만들고 로그를 저장할 수 있습니다.

네트워킹

AWS Elastic Beanstalk을 사용하면 환경에서 사용되는 AWS 리소스의 연결 상태를 관리할 수 있습니다. Elastic Beanstalk이 EC2 VM을 특정 VPC에 연결하고 해당 인스턴스에서 보안 그룹을 구성하도록 지정할 수 있습니다. 이렇게 하면 Elastic Beanstalk이 App Engine 가변형 환경과 비슷한 특정 수준의 네트워크 연결 투명성을 얻을 수 있습니다.

App Engine 표준 환경은 네트워킹 구성을 완전히 추상화합니다. 개발자가 작업해야 하는 유일한 네트워킹 관련 설정은 애플리케이션의 외부 주소에 대한 커스텀 도메인 이름과 부하 분산에 적용됩니다. dos.yaml 파일을 사용하여 네트워크 '블랙리스트'를 설정하면 DOS 보호 서비스를 적용할 수 있습니다. 애플리케이션과 함께 배포된 경우에는 App Engine이 금지된 IP 범위로부터의 요청에 대한 응답으로 오류 페이지를 제공하도록 지정할 수 있습니다.

App Engine 가변형 환경은 Compute Engine VM(가상 머신)을 사용해서 Docker 컨테이너에서 애플리케이션을 호스팅합니다. 다음 작업을 할 수 있습니다.

  • VPC 네트워크에 연결되도록 App Engine 가변형 환경에서 관리되는 VM을 구성합니다. VPC 네트워크는 가변형 앱과 동일한 프로젝트에 존재하거나, 여러 프로젝트 간에 공유될 수 있습니다.
  • Cloud VPN을 사용해서 다른 대상에 연결되도록 App Engine 가변형 환경 인스턴스를 사용하여 VPC 네트워크를 구성합니다.
  • 인스턴스 태그를 사용해서 App Engine 가변형 환경 인스턴스에 방화벽 설정을 적용합니다.
  • 디버깅 및 프로파일링을 위해 가변형 인스턴스의 네트워크 포트를 Docker 컨테이너에 매핑합니다.

이러한 유연성은 다른 서비스에 대해 투명한 연결이 필요하고 Google Cloud 또는 Google Cloud 외부에서(온프레미스 또는 다른 클라우드에서) 실행되는 App Engine 가변형 환경 애플리케이션을 빌드할 때 유용합니다.

비용

AWS는 Elastic Beanstalk에 대해 추가 비용을 부과하지 않습니다. 기본 EC2 인스턴스 및 기타 리소스에 대해서만 비용을 지불합니다.

App Engine 표준 환경은 인스턴스 실행 시간을 기준으로 비용을 부과합니다. 인스턴스가 시작되면 청구가 시작되고, 수동 인스턴스가 종료되고 15분 후에 또는 기본 인스턴스의 마지막 요청이 처리되고 15분 후에 청구가 종료됩니다. 성능 설정에서 설정한 최대 유휴 인스턴스 수를 초과한 유휴 인스턴스에는 요금이 청구되지 않습니다. 또한 무료 할당량도 있습니다. 자동 확장 모듈에는 하루당 무료 인스턴스 28시간이, 기본 및 수동 확장 모듈에는 하루당 무료 인스턴스 9시간이 할당되어 있습니다.

App Engine 가변형 환경은 개발자가 지정하는 가상 머신 유형의 리소스에 대해 비용을 부과합니다. 비용은 다음과 같은 매개변수 사용에 따라 결정됩니다.

  • vCPU(코어 시간별)
  • 메모리(GB 시간별)
  • 영구 디스크(월별 GB당)

이러한 비용은 분 단위로 청구되고 최소 사용 비용은 10분입니다.

자세한 내용은 Compute Engine 가격 책정 페이지를 참조하세요. 특정 워크로드의 예상 비용을 계산하려면 Google Cloud 가격 계산기를 사용해 보세요.

CaaS 비교

CaaS의 경우 AWS는 Amazon EC2 Container Service(ECS)를 제공하고 Google Cloud는 Google Kubernetes Engine을 제공합니다.

GKE와 Amazon ECS는 매우 비슷한 서비스 모델을 갖고 있습니다. 각 서비스에서 개발자는 컨테이너 노드의 클러스터를 만듭니다. 각 노드는 가상 머신 인스턴스이며, 각각 클러스터에서 해당 항목이 포함되었음을 알리기 위해 노드 에이전트를 실행합니다. 각 노드는 또한 노드가 컨테이너식 애플리케이션을 실행할 수 있도록 Docker와 같은 컨테이너 데몬을 실행합니다. 애플리케이션 파일 및 애플리케이션 실행 지침을 포함하는 Docker 이미지를 만든 후 클러스터에서 애플리케이션을 배포합니다.

Amazon ECS는 Amazon에서 개발되고 유지보수됩니다. Google Kubernetes Engine은 오픈소스 컨테이너 관리 시스템인 Kubernetes에서 빌드되었습니다.

높은 수준에서 Amazon ECS와 GKE의 용어와 개념을 다음과 같이 정리할 수 있습니다.

기능 Amazon ECS GKE
클러스터 노드 Amazon EC2 인스턴스 Compute Engine 인스턴스
지원되는 데몬 Docker Docker 또는 rkt
노드 에이전트 Amazon ECS 에이전트 Kubelet
컨테이너 그룹 작업 포드
배포 크기 조정 서비스 서비스 복제 컨트롤러
명령줄 도구 Amazon ECS CLI kubectl 또는 gcloud
이동성 AWS에서만 실행 Kubernetes가 실행되는 모든 위치에서 실행

플랫폼 구성요소

클러스터

Amazon ECS와 GKE 모두에서 클러스터는 가상 머신 노드의 논리적 그룹입니다. Amazon ECS에서 클러스터는 Amazon EC2 인스턴스를 노드로 사용합니다. 클러스터를 만들기 위해서는 개발자가 클러스터의 이름만 제공하면 Amazon ECS가 클러스터를 만듭니다. 하지만 이 클러스터는 기본적으로 비어 있습니다. 애플리케이션을 시작하려면 컨테이너 인스턴스를 해당 클러스터로 시작해야 합니다.

GKE에서 클러스터는 Compute Engine 인스턴스를 노드로 사용합니다. 클러스터를 만들려면 먼저 다음을 포함하여 원하는 값으로 설정된 기본 구성 세부정보를 제공해야 합니다.

  • 클러스터 이름
  • 배포 영역
  • Compute Engine 머신 유형
  • 클러스터 크기

클러스터를 구성한 후에는 GKE가 요청된 영역에서 클러스터를 만듭니다.

컨테이너 그룹

Amazon ECS와 GKE 모두 상호 의존적인 또는 관련된 컨테이너 집합을 상위 수준의 서비스 단위로 그룹화합니다. Amazon ECS에서는 이러한 단위를 태스크라고 하고 태스크 정의에서 정의합니다. GKE에서는 이러한 단위를 pod라고 하고 PodSpec에서 정의합니다. 태스크 및 pod 모두에서 컨테이너는 함께 배치되고 예약되며, 공유 IP 주소와 포트 공간을 사용해서 공유 컨텍스트에서 실행됩니다.

컨테이너 데몬

각 노드 머신은 컨테이너식 서비스를 지원하기 위해 컨테이너 데몬을 실행해야 합니다. Amazon ECS는 Docker을 컨테이너 데몬으로 지원합니다. Google Kubernetes Engine은 Docker 및 rkt를 모두 지원합니다.

노드 에이전트

Amazon ECS에서 각 Amazon EC2 노드는 Amazon ECS 대신 컨테이너를 시작하는 Amazon ECS 에이전트를 실행합니다. 이와 비슷하게 GKE에서 각 GKE 노드는 노드에서 실행되는 컨테이너의 상태 및 안정성을 유지 관리하는 kubelet을 실행합니다.

서비스 검색

Amazon ECS는 클러스터 내에서 서비스 검색 기본 메커니즘을 제공하지 않습니다. 이 문제를 해결하기 위해서는 Consul과 같은 타사 서비스 검색 서비스를 구성해서 특정 클러스터 내에서 서비스 검색을 사용하도록 설정할 수 있습니다.

GKE 클러스터를 사용하면 기본적으로 사용하도록 설정되는 Kubernetes DNS 추가 기능을 통해 서비스 검색을 사용하도록 설정합니다. 각 Kubernetes 서비스에는 서비스가 존재하는 한 안정적으로 유지되는 가상 IP 주소가 할당됩니다. DNS 서버는 Kubernetes API에서 새 서비스를 감시한 후 각 항목에 대해 DNS 레코드 집합을 만듭니다. 이러한 레코드를 통해 Kubernetes pod가 Kubernetes 서비스의 이름 확인을 자동으로 수행할 수 있습니다.

예약

Amazon ECS는 고유 스케줄러만 지원합니다.

GKE는 플러그인 가능한 아키텍처인 Kubernetes를 기준으로 빌드되었습니다. 따라서 GKE는 오픈소스이며, Kubernetes가 실행될 수 있는 모든 환경에서 실행 가능한 Kubernetes 스케줄러와 완전히 호환됩니다.

배포 자동화

Amazon ECS에서는 각 노드에 작업을 배포하기 위한 스크립트를 만들 수 있습니다. 하지만 이러한 동작은 서비스에서 기본 제공되지 않습니다.

GKE에서는 DaemonSet을 사용하여 클러스터의 모든 노드에서 특정 pod의 복사본을 실행할 수 있습니다. 클러스터에서 노드가 추가되거나 삭제되면, DaemonSet가 pod를 새 노드에 자동으로 복사하거나 이전 노드를 가비지 수집합니다. DaemonSet를 삭제하면 DaemonSet가 생성된 모든 pod를 삭제합니다.

디스크 관리

Amazon ECS 디스크는 호스트와 관련되기 때문에, 지정된 특정 디스크에 의존하는 컨테이너를 다른 호스트로 이동할 수 없습니다.

반면에, GKE는 노드에 디스크를 동적으로 마운트하고 지정된 pod에 자동으로 디스크를 할당할 수 있습니다. 특정 디스크를 사용하기 위해 특정 노드에서 pod를 실행할 필요가 없습니다.

ID 및 액세스 관리

Amazon ECS는 AWS IAM(Identity and Access Management) 서비스와 완전히 호환됩니다. GKE는 현재 Google Cloud의 IAM 서비스를 지원하지 않습니다.

멀티테넌시

Amazon ECS에서는 개별 클러스터를 만들고 각 클러스터에서 사용량을 제한하도록 AWS IAM을 수동으로 구성하여 멀티테넌시를 얻을 수 있습니다.

반면에, GKE는 사용자가 클러스터를 로컬로 그룹화하고, 멀티 테넌트 클러스터를 지원할 범위를 제공할 수 있게 해주는 네임스페이스를 지원합니다. 네임스페이스는 다음을 허용합니다.

  • 단일 클러스터에서 여러 사용자 커뮤니티 만들기
  • 클러스터의 파티션에 대한 권한을 신뢰할 수 있는 사용자에게 위임
  • 각 커뮤니티가 소비할 수 있는 리소스 양 제한
  • 사용 가능한 리소스를 특정 사용자 커뮤니티와 관련된 리소스로 제한
  • 지정된 사용자 커뮤니티에서 사용되는 리소스를 클러스터의 다른 사용자 커뮤니티로부터 격리

상태 확인

Amazon ECS에서는 Amazon ELB 상태 확인을 사용하여 오류를 감지할 수 있습니다. Amazon ELB에서는 HTTP/TCP를 통해 상태 확인을 수행합니다. 상태 확인을 받으려면 TCP 포트를 리슨할 필요가 없는 서비스를 포함하여 모든 컨테이너 서비스에서 HTTP 서버를 설정해야 합니다. 또한 서비스를 부하 분산할 필요가 없더라도 각 서비스가 ELB에 바인딩되어 있어야 합니다.

GKE에서는 준비 및 활성 프로브를 사용하여 상태 확인을 수행할 수 있습니다.

  • 준비 프로브를 사용하면 초기화 중 pod 상태를 확인할 수 있습니다.
  • 활성 프로브를 사용하면 더 이상 올바르게 작동하지 않는 pod를 감지하고 다시 시작할 수 있습니다.

이러한 프로브는 Kubernetes API에 포함되어 있으며 PodSpec의 일부로 구성할 수 있습니다.

이동성

Amazon ECS 에이전트는 Amazon EC2 인스턴스에서만 실행할 수 있기 때문에, Amazon ECS 구성은 실질적으로 Amazon ECS에서만 실행할 수 있습니다. 반면에, GKE는 Kubernetes를 기반으로 빌드되었기 때문에, Google Kubernetes Engine 구성은 모든 Kubernetes 설치에서 실행할 수 있습니다.

비용

Amazon은 개발자가 해당 배포에서 사용하는 Amazon EC2 인스턴스 및 Amazon EBS 디스크 볼륨에 대해 비용을 부과합니다. Amazon ECS의 컨테이너 관리 서비스에는 추가 비용이 청구되지 않습니다.

Google Cloud는 개발자가 배포에서 사용하는 Compute Engine 인스턴스와 영구 디스크에 대해 비용을 청구합니다. 또한 GKE는 클러스터 관리에 대해 시간별 비용을 부과합니다. 노드 수가 5개 이하인 클러스터에는 이 요금이 부과되지 않습니다. 자세한 내용은 GKE 가격 책정을 참조하세요.

다음 단계

AWS 전문가를 위한 다른 Google Cloud 문서를 확인하세요.