Google App Engine과 Google Compute Engine의 차이점은 무엇입니까?
답변:
App Engine 은 Platform-as-a-Service입니다. 그것은 단순히 코드를 배포하고 플랫폼이 다른 모든 기능을 수행한다는 것을 의미합니다. 예를 들어 앱이 성공하면 App Engine은 증가 된 볼륨을 처리 할 인스턴스를 자동으로 생성합니다.
Compute Engine 은 IaaS (Infrastructure-as-a-Service)입니다. 고유 한 가상 머신 인스턴스를 생성하고 구성해야합니다. 유연성이 뛰어나고 일반적으로 App Engine보다 훨씬 저렴합니다. 단점은 앱과 가상 머신을 직접 관리해야한다는 것입니다.
필요한 경우 App Engine과 Compute Engine을 모두 혼합 할 수 있습니다. 둘 다 Google Cloud Platform 의 다른 부분과 잘 작동합니다 .
편집 (2016 년 5 월) :
한 가지 더 중요한 차이점 : 요청이없는 경우 App Engine에서 실행되는 프로젝트는 인스턴스를 0 개로 축소 할 수 있습니다. 이는 인스턴스 시간의 넉넉한 무료 할당량을 넘지 않고 몇 주 동안 갈 수 있으므로 개발 단계에서 매우 유용합니다. 유연한 런타임 (예 : "관리되는 VM")은 지속적으로 실행 되려면 하나 이상의 인스턴스가 필요합니다.
편집 (2017 년 4 월) :
클라우드 기능 (현재 베타 버전)은 추상화가없는 App Engine의 다음 단계입니다. 인스턴스는 없습니다! 개발자는 HTTP 요청, Cloud Storage의 변경 등을 포함하여 다양한 이벤트에 응답하여 한 입 크기의 코드를 배포 할 수 있습니다.
App Engine과의 가장 큰 차이점은 기능이 100 밀리 초마다 가격이 책정되는 반면 App Engine의 인스턴스는 15 분 동안 활동이 없으면 종료됩니다. 또 다른 이점은 Cloud Functions가 즉시 실행되고 App Engine에 대한 호출에는 새 인스턴스가 필요할 수 있으며 새 인스턴스를 콜드 스타트하려면 몇 초 이상이 걸릴 수 있습니다 (런타임 및 코드에 따라 다름).
이로 인해 Cloud Functions는 (a) 드문 호출에 이상적입니다. 상황이 발생하는 경우 인스턴스를 계속 유지할 필요가 없습니다. (b) 인스턴스가 자주 회전하고 종료되는로드를 빠르게 변경하며 더 많은 사용 사례가있을 수 있습니다.
기본 차이점은 GAE (Google App Engine ) 는 PaaS ( Platform as a Service ) 이고 GCE (Google Compute Engine ) 는 IaaS (Infrastructure as a Service )라는 점 입니다.
GAE에서 애플리케이션을 실행하려면 코드를 작성하고 다른 두통없이 GAE에 배포하면됩니다. GAE는 완벽하게 확장 가능하므로 트래픽이 증가 할 경우 더 많은 인스턴스를 자동으로 획득하고 트래픽이 감소하면 인스턴스를 줄입니다. 실제로 사용 하는 리소스에 대해 요금이 청구됩니다. 즉 , 앱에서 실제로 사용한 인스턴스 시간 , 전송 된 데이터 , 스토리지 등에 대한 요금이 청구 됩니다. 그러나 제한 사항은 Python, PHP, Java, NodeJS, .NET, Ruby 및 ** Go 에서만 응용 프로그램을 만들 수 있다는 것 입니다.
반면에 GCE는 가상 머신 형태의 전체 인프라를 제공합니다 . 프로그램을 작성하거나 설치할 수 있으므로 해당 VM의 환경과 런타임을 완전히 제어 할 수 있습니다. 실제로 GCE는 Google 데이터 센터를 가상으로 사용하는 방법입니다. GCE에서는 Load Balancer 를 사용하여 확장 성 을 처리하도록 인프라를 수동으로 구성해야합니다 .
GAE와 GCE는 모두 Google Cloud Platform의 일부입니다 .
업데이트 : 2014 년 3 월 Google은 App Engine에서 Managed Virtual Machine 이라는 새로운 서비스를 발표했습니다 . 관리 형 VM은 앱 플랫폼, CPU 및 메모리 옵션에 비해 앱 엔진 애플리케이션에 약간의 유연성을 제공합니다. GCE와 마찬가지로 앱 엔진 애플리케이션을 위해 이러한 VM에서 사용자 정의 런타임 환경을 생성 할 수 있습니다. 실제로 App Engine의 관리되는 VM은 IAAS와 PAAS의 경계를 어느 정도 흐리게합니다.
간단히 말해 : 계산 엔진은 모든 제어 / 책임이있는 서버를 제공합니다. 운영 체제에 직접 액세스 할 수 있으며 원하는 모든 소프트웨어 (일반적으로 웹 서버, 데이터베이스 등)를 설치합니다.
앱 엔진에서는 기본 소프트웨어의 운영 체제를 관리하지 않습니다. 코드 (Java, PHP, Python 또는 Go)와 voila 만 업로드하면 실행됩니다 ...
앱 엔진은 특히 경험이 부족한 사람들을 위해 많은 수의 두통을 줄여 주지만 2 가지 중요한 단점이 있습니다. 가능하거나 한 가지 특정 방식으로 만 가능합니다 (예 : 파일 저장 및 쓰기).
또는 GAE 표준과 GAE Flex를 구별하지 못하는 경우가 있기 때문에 더 간단하게 만들 수 있습니다.
Compute Engine 은 예를 들어 작은 웹 사이트 + 데이터베이스를 배포하는 가상 PC와 유사합니다. 설치된 디스크 드라이브 제어를 포함하여 모든 것을 관리합니다. 웹 사이트를 배포하는 경우 DNS 등을 설정해야합니다.
Google App Engine (표준) 은 실행할 코드를 업로드하고 나머지 부분에 대해 걱정하지 않는 읽기 전용 샌드 박스 폴더와 같습니다 (예 : 읽기 전용-고정 된 라이브러리 세트가 설치되어 배포 할 수 없음) 제 3 자 라이브러리는 자유롭게 사용할 수 있습니다. DNS / 하위 도메인 등은 매핑하기가 훨씬 쉽습니다.
Google App Engine (Flexible) 은 실제로 전체 파일 시스템 (잠금 폴더가 아님)과 유사하며 표준 엔진보다 더 많은 전원을 공급합니다 (예 : 읽기 / 쓰기 권한이 있지만 Compute Engine에 비해 적음) ). GAE 표준에는 고정 라이브러리 세트가 설치되어 있으며 원하는대로 타사 라이브러리를 배포 할 수 없습니다. 유연한 환경에서는 Python 3과 같은 사용자 지정 빌드 환경을 포함하여 앱이 의존하는 모든 라이브러리를 설치할 수 있습니다.
GAE Standard는 다루기가 매우 번거롭지 만 (Google에서는 간단하게 들리지만) 압박을 받으면 확장 성이 매우 뛰어납니다. 잠겨진 환경과의 호환성을 테스트하고 확인해야하며 사용중인 타사 라이브러리가 GAE 표준에서 작동하지 않을 수있는 다른 타사 라이브러리를 사용하지 않아야하므로 번거 롭습니다. 실제로 설정하는 데 시간이 오래 걸리지 만 간단한 배포의 경우 장기적으로 더 보람이있을 수 있습니다.
여기 목록 위의 App Engine vs Compute Engine 노트 외에도 Google Kubernete Engine과의 비교 및 소규모에서 대규모에 이르는 광범위한 앱 경험에 기반한 일부 노트도 포함됩니다. 자세한 내용 은 App Engine 환경 선택 페이지의 Google Cloud Platform 문서 App Engine Standard 및 Flex 기능에 대한 고급 설명을 참조하십시오 . App Engine 및 Kubernetes 배포에 대한 다른 비교는 Daz Wilkin App Engine Flex 또는 Kubernetes Engine 의 게시물을 참조하십시오 .
앱 엔진 표준
찬성
- 직접 비용 및 앱 유지 관리 비용 측면에서 트래픽이 적은 앱에 매우 경제적입니다.
- 자동 스케일링이 빠릅니다. App Engine의 자동 확장은 경량 인스턴스 클래스 F1-F4를 기반으로 합니다.
- 버전 관리 및 트래픽 분할 이 빠르고 편리합니다. 이러한 기능은 기본적으로 App Engine (Standard 및 Flex)에 내장되어 있습니다.
- 최소한의 관리, 개발자는 앱에만 집중해야합니다. 개발자는 GCE와 같이 안정적인 VM 관리 또는 GKE와 같은 클러스터 학습에 대해 걱정할 필요가 없습니다.
- 데이터 스토어에 대한 액세스가 빠릅니다. App Engine이 처음 릴리스되면 런타임이 Datastore와 함께 배치되었습니다. 나중에 Datastore는 독립형 제품 Cloud Datastore로 분리 되었지만 Datastore와 함께 제공되는 App Engine Standard의 공동 위치는 그대로 유지됩니다.
- Memcache에 대한 액세스가 지원됩니다.
- App Engine 샌드 박스는 매우 안전합니다. 운영 체제 수준에서 가상 시스템이 인계되지 않도록하기 위해 직접 노력해야하는 GCE 또는 기타 가상 시스템의 개발과 비교하여 App Engine Standard 샌드 박스는 기본적으로 비교적 안전합니다.
단점
- 일반적으로 다른 환경보다 더 제한적입니다. 인스턴스가 더 작습니다. 이는 빠른 자동 확장에 유용하지만 최대 96 코어의 GCE 인스턴스 크기와 같은 더 큰 인스턴스의 이점을 얻을 수있는 앱이 많습니다.
- 네트워킹이 GCE와 통합되지 않았습니다
- Google Cloud Load Balancer 뒤에 App Engine을 넣을 수 없습니다. 지원되는 런타임 (Python 2.7, Java 7 및 8, Go 1.6-1.9 및 PHP 5.5)으로 제한됩니다. Java에서는 서블릿에 대한 지원이 있지만 전체 J2EE 표준은 지원하지 않습니다.
App Engine Flex
찬성
- 사용자 정의 런타임을 사용할 수 있습니다
- GCE 네트워킹과의 기본 통합
- 버전과 트래픽 관리가 편리하며 표준과 동일
- 더 큰 인스턴스 크기는 대규모의 복잡한 응용 프로그램, 특히 많은 메모리를 사용할 수있는 Java 응용 프로그램에 더 적합 할 수 있습니다.
단점
- 네트워크 통합이 완벽하지 않음-내부로드 밸런서 또는 Shared Virtual Private Cloud와 통합되지 않음
- 일반적으로 사용할 수없는 관리 형 Memcache에 대한 액세스
구글 쿠 버네 티스 엔진
찬성
- 컨테이너와의 기본 통합을 통해 사용자 정의 런타임과 클러스터 구성을보다 강력하게 제어 할 수 있습니다.
- 변경 불가능한 런타임 환경 및 이전 버전으로 쉽게 롤백 할 수있는 기능과 같은 가상 머신 작업에 대한 많은 모범 사례를 구현합니다.
- 일관되고 반복 가능한 배포 프레임 워크 제공
- 클라우드와 온-프레미스 간 이식성을위한 공개 표준, 특히 Kubernetes를 기반으로합니다.
- Docker 컨테이너 및 Google 컨테이너 레지스트리를 사용하여 버전 관리를 수행 할 수 있습니다.
단점
- 트래픽 분할 및 관리는 스스로 수행하므로 Istio 및 Envoy를 활용할 수 있습니다.
- 일부 관리 오버 헤드
- 포드, 배포, 서비스, 수신 및 네임 스페이스와 같은 Kubernetes 개념을 강화할 시간
- 현재 베타 버전 인 Private Clusters를 사용하지 않는 한 일부 공용 IP를 노출 해야하지만 그 필요성을 제거 할 수 있지만 kubectl 명령을 실행할 위치에 대한 액세스를 제공해야합니다.
- 완벽하지 않은 모니터링 통합
- L3 내부로드 밸런싱은 Kubernetes Engine에서 기본적으로 지원되지만 L7 내부로드 밸런싱은 자체적으로 수행되므로 Envoy를 활용할 수 있습니다
컴퓨팅 엔진
찬성
- 손쉬운 확장-Kubernetes 또는 App Engine에서 확장 할 필요없이 이전 경험에서 알고있는 것을 재사용하십시오. 이것이 Compute Engine을 직접 사용하는 주된 이유 일 것입니다.
- 완벽한 제어-많은 Compute Engine 기능을 직접 활용하고 가장 좋아하는 최신 정보를 설치하여 최신 정보를 유지할 수 있습니다.
- 퍼블릭 IP가 필요 없습니다. 공개 IP에 노출 된 것이 있으면 일부 레거시 소프트웨어를 잠그기가 너무 어려울 수 있습니다.
- Docker 컨테이너를 실행하기 위해 컨테이너 최적화 OS를 활용할 수 있습니다
단점
- Cloud Launcher를 포함한 다양한 장소에서 솔루션을 재사용 할 수 있지만 대부분 자체적으로 수행하는 것으로 안정성과 보안을 위해 적절하게 수행하기 어려울 수 있습니다.
- 더 많은 관리 오버 헤드. Compute Engine에는 많은 관리 도구가 있지만 App Engine 및 Kubernetes Engine 모니터링 도구와 같이 응용 프로그램을 배포 한 방법을 반드시 이해하지는 않습니다.
- 자동 확장은 GCE 인스턴스를 기반으로하며 App Engine보다 느릴 수 있습니다.
- 경향은 눈송이 GCE 인스턴스에 소프트웨어를 설치하는 것입니다.
이미 설명했듯이 GCE (Google Compute Engine)는 IaaS (Infrastructure as a Service)이고 Google App Engine (GAE)은 PaaS (Platform as a Service)입니다. 더 나은 방법으로 차이점을 이해하기 위해 다음 다이어그램을 확인할 수 있습니다 ( 여기 에서 설명하고 더 잘 설명 합니다 ).
Google Compute Engine
GCE는 대부분의 GCP 서비스가 관리 계층 아래에서 GCE 인스턴스 (VM)를 사용하기 때문에 Google Cloud Platform (GCP)에서 제공하는 중요한 서비스입니다. 여기에는 App Engine, Cloud Functions, Kubernetes Engine (Earlier Container Engine), Cloud SQL 등이 포함됩니다. GCE 인스턴스는 가장 사용자 지정 가능한 단위이므로 응용 프로그램을 다른 GCP 서비스에서 실행할 수없는 경우에만 사용해야합니다. 대부분의 사람들은 최소한의 변경만으로 GCE를 사용하여 On-Prem 애플리케이션을 GCP로 전송합니다. 나중에 앱의 개별 구성 요소에 다른 GCP 서비스를 사용하도록 선택할 수 있습니다.
Google App Engine
GAE는 GCP에서 제공하는 첫 번째 서비스입니다 (Google이 클라우드 비즈니스에 오기 전부터 오래 지속됨). 0에서 무제한 인스턴스까지 자동 확장됩니다 (아래에서 GCE 사용). 표준 환경과 유연한 환경의 2 가지 맛이 제공됩니다.
표준 환경은 정말 빠르며, 아무도 앱을 사용하지 않을 때 인스턴스가 0으로 축소되고, 초 단위로 확장 및 축소되며, 캐싱, 인증 등을위한 전용 Google 서비스 및 라이브러리가 있습니다. 표준 환경의 단점은 매우 제한적이라는 것입니다 샌드 박스에서 실행되기 때문입니다. 특정 프로그래밍 언어에 대해서만 관리 런타임을 사용해야합니다. 최근에 추가 된 Node.js (8.x) 및 Python 3.x입니다. 이전 런타임은 Go, PHP, Python 2.7, Java 등에서 사용할 수 있습니다.
Docker 컨테이너를 사용하므로 사용자 정의 런타임을 사용할 수 있으므로 Flexible Environment가 더 개방적입니다. 따라서 제공된 런타임에서 런타임을 사용할 수없는 경우 항상 실행 환경에 대한 고유 한 dockerfile을 작성할 수 있습니다. 주의해야 할 점은, 아무도 앱을 사용하지 않는 경우에도 최소 1 개의 인스턴스를 실행해야하며 확장 및 축소에는 몇 분이 소요됩니다.
후자는 실제 Kubernetes를 사용하고 훨씬 더 많은 사용자 정의 및 기능을 제공하므로 GAE flexible과 Kubernetes Engine을 혼동하지 마십시오. GAE Flex는 상태 비 저장 컨테이너를 원하고 응용 프로그램이 HTTP 또는 HTTPS 프로토콜에만 의존 할 때 유용합니다. 다른 프로토콜의 경우 Kubernetes Engine (GKE) 또는 GCE가 유일한 선택입니다. 더 나은 설명을 위해 다른 답변 을 확인하십시오 .
App Engine을 통해 개발자는 Google Compute Engine 코어를 제어 할 수 있으며 Google Compute Engine 데이터 처리 애플리케이션을위한 웹 프론트 엔드를 제공 할 수 있습니다.
반면 Compute Engine은 가상 머신의 직접적이고 완벽한 운영 체제 관리 기능을 제공합니다. 앱을 제시하려면 리소스가 필요하며 Google Cloud Storage는 자산 및 데이터를 저장하는 데 이상적입니다. 전 세계 호스팅을 통해 데이터에 빠르게 액세스 할 수 있습니다. 99.95 %의 가동 시간으로 안정성이 보장되며 Google은 데이터를 백업 및 복원 할 수있는 기능을 제공하며, 저장 용량에 제한이 없습니다.
Google Cloud Storage를 사용하여 자산을 저장, 검색, 표시 및 삭제하여 자산을 관리 할 수 있습니다. Cloud Storage에 보관 된 플랫 데이터 시트를 빠르게 읽고 쓸 수도 있습니다. 다음은 Google Cloud 라인업에서 BigQuery입니다. BigQuery를 사용하면 방대한 양의 데이터를 분석 할 수 있으며 몇 초 내에 수백만 건의 레코드를 공유하고 있습니다. 액세스는 간단한 UI, Representational State Transfer 또는 REST 인터페이스를 통해 처리됩니다.
데이터 스토리지는 의심 할 여지없이 문제가되지 않으며 수백 TB로 확장됩니다. BigQuery는 Java, .NET, Python, Go, Ruby, PHP 및 Javascript를 포함하여 다양한 클라이언트 라이브러리를 통해 액세스 할 수 있습니다. 이러한 클라이언트 라이브러리 또는 웹 사용자 인터페이스를 통해 액세스 할 수있는 NoSQL이라는 SQL 유사 구문을 사용할 수 있습니다. 마지막으로 Google Cloud 플랫폼 데이터베이스 옵션, Cloud SQL 및 Cloud Datastore에 대해 이야기하겠습니다.
큰 차이가 있습니다. Cloud SQL은 주로 관계형 데이터베이스를위한 것이며 Cloud Datastore는 noSQL을 사용하는 비 관계형 데이터베이스를위한 것입니다. Cloud SQL을 사용하면 미국, 유럽 또는 아시아에서 호스팅 할 수 있으며 데이터베이스 인스턴스 당 100GB의 스토리지와 16GB의 RAM이 제공됩니다.
Cloud Datastore는 한 달에 최대 50K 읽기 / 쓰기 지침과 한 달에 1GB의 데이터를 저장하여 무료로 사용할 수 있습니다. 그러나이 할당량을 초과하면 요금이 부과됩니다. 또한 App Engine은 API 백엔드 생성을위한 Cloud Endpoints, 데이터 분석 및 추세 예측을위한 Google Prediction API 또는 다국어 출력을위한 Google Translate API를 포함하여 덜 알려진 다른 대상의 Google Cloud 플랫폼 멤버와 함께 작동 할 수 있습니다.
App Engine만으로도 상당한 금액을 할 수는 있지만 동료 Google Cloud 플랫폼 서비스와 쉽고 효율적으로 작업 할 수있는 능력을 고려할 때 잠재적 인 급상승입니다.
이해하기 쉬운 방식으로 설명하겠습니다.
Compute Engine : IT 전문가이거나 IT 팀이 있고 특정 OS (예 : Linux)가있는 클라우드에서 컴퓨터를 임대하려는 경우 Compute Engine으로 이동하십시오. 혼자서 모든 것을해야합니다.
App Engine : (예를 들어) 파이썬 프로그래머이고 실행중인 웹 서버가있는 Linux와 필요한 모듈 및 통합 할 플러그인이있는 최신 Python 3이있는 클라우드에서 사전 구성된 컴퓨터를 임대하려는 경우 다른 외부 서비스는 App Engine으로 이동합니다.
서버리스 컨테이너 (Cloud Run) : 로컬 설정 환경의 정확한 이미지 (예 : python 3.7 + flask + sklearn)를 배포하려고하지만 서버, 스케일링 등을 처리하지 않으려는 경우 컨테이너를 만듭니다. 도커를 통해 로컬 컴퓨터에서 Google Run에 배포하십시오.
서버리스 마이크로 서비스 (Cloud Functions) : 특정 작업을 수행하는 많은 API (함수)를 작성하려면 Google Cloud Functions로 이동하십시오. 이러한 특정 기능에만 초점을 맞추고 나머지 작업 (서버, 유지 관리, 확장 등)은 기능을 마이크로 서비스로 노출하기 위해 수행됩니다.
더 깊이 들어가면 유연성이 떨어지지 만 불필요한 기술적 측면에 대해 걱정하지 않아도됩니다. 또한 조금 더 지불하지만 시간과 비용을 절약 할 수 있습니다 (IT 부분) : 다른 사람 (Google)이 대신해줍니다.
로드 밸런싱, 스케일링 등을 신경 쓰지 않으려면 별도의 스토리지 (데이터베이스 또는 BLOB 스토리지)에 영구적 인 내용을 쓰는 "무 상태"웹 서비스로 앱을 분할하는 것이 중요합니다. 그러면 Cloud Run과 Cloud Functions가 얼마나 멋진 지 알게 될 것입니다.
개인적으로 Google Cloud Run은 (무국적 상태의 경우) 개발의 절대적인 자유, 웹 서비스로 노출, 솔루션 도킹, Cloud Run으로 배포하는 멋진 솔루션이라는 것을 알았습니다. Google을 IT 및 DevOps로 설정하면 확장 및 유지 관리에 신경 쓸 필요가 없습니다.
다른 모든 옵션을 시도했지만 각각 다른 목적에 적합하지만 Google Run은 훌륭합니다. 나에게 그것은 개발의 유연성을 잃지 않고 진정한 서버리스입니다.
Google Compute Engine (GCE)
클라우드에서 호스팅되는 가상 머신 (VM). 클라우드 이전에는 가상 사설 서버 (VPS)라고도합니다. 실제 서버를 사용하는 것과 같은 방식으로 운영 체제를 설치 및 구성하고, 응용 프로그램을 설치하고, 데이터베이스를 설치하고, OS를 최신 상태로 유지하는 등의 방법을 사용합니다. 서비스 형 서비스 (IaaS).
VM은 기존 응용 프로그램이 데이터 센터의 VM 또는 서버에서 실행되고 있고 GCP로 쉽게 마이그레이션하려는 경우에 가장 유용합니다.
Google App Engine
App Engine은 운영 체제, 네트워킹 및 물리적 서버 또는 VM으로 관리해야하는 기타 여러 가지 사항을 처리 할 필요없이 코드를 호스팅하고 실행합니다. 응용 프로그램을 자동으로 배포, 버전 및 확장 할 수있는 런타임이라고 생각하십시오. 이를 PaaS (Platform-as-a-Service)라고합니다.
App Engine은 애플리케이션의 자동 배포 및 자동 확장을 원할 때 가장 유용합니다. 애플리케이션에 맞춤 OS 구성이 필요하지 않은 경우 App Engine은 VM을 직접 구성하고 관리하는 것보다 유리합니다.