구글 앱 엔진 소개

구글 앱 엔진(Google App Engine)은 구글 클라우드 플랫폼에서 구동되는 웹 프레임워크입니다. HTTP/HTTPS 요청을 처리하는 서비스로서 아마존 웹서비스(이하 AWS)의 Beanstalk와 유사합니다. 하지만 이 둘 사이에는 결정적인 차이가 있습니다. 구글 앱 엔진은 완전 관리형(Fully managed) 서비스, AWS는 일부 관리형 서비스라는 점이죠.

쓸만한가요?

근무하고 있는 곳에서는 REST API를 구글 앱 엔진에 올려서 사용하고 있으며, 하루에 수 백 ~ 수 천만건의 요청을 처리하고 있는 중입니다. 일하는 기간 동안에 구글 앱 엔진에서 문제가 발생한 적은 없었습니다. 장애는 주로 DB쪽이나 다른 모듈에서 문제가 발생해서 생긴 적이 대부분이었습니다.

구글 앱 엔진의 장점

쉽고 간단하다

같은 서비스를 EC2를 사용해 구축한다고 하면 Elastic Load Balancer + Auto Scaling Group + EC2 + Route53 설정 등을 해줘야하고 추가적으로 배포도 신경 써줘야 하며, 앱이 죽었는지 살았는지 Health Check도 필요합니다. 하지만 구글 앱 엔진은 이런게 필요없습니다. Load Balancer와 Scaling 설정은 스스로 혹은 간단한 옵션으로 관리하며 인스턴스가 죽으면 자동으로 해당 인스턴스를 자동으로 재시작합니다.

무중단 서비스는 기본이다

내부적으로 Blue Green Deployment를 구현, 새로운 앱을 배포하면 앱 엔진 내부에서 새로운 앱을 배포 후 라우팅을 새로운 앱으로 돌립니다.

강력한 HTTP URL기반 라우팅

개인적으로 매우 마음에 드는 기능입니다. 태그에 의존하는 AWS과는 달리 구글 클라우드는 프로젝트 이름 단위로 리소스가 확실히 구분됩니다. 구글 클라우드에서 example 이라는 프로젝트를 만들었으면 앱 엔진의 URL주소는 https://example.appspot.com이 됩니다. 배포용은 가만히 냅두고 개발용으로 별도의 인스턴스를 만들어서 사용하고 싶을 경우에는 개발용 버전(예: staging)을 배포하면서 이 인스턴스에 트래픽을 주지말라는 옵션을 줍니다. 그리고 개발용 인스턴스에 요청을 보내고 응답을 받고 싶을때는 그냥 https://staging-dot-example.appspot.com 이라고 호출하면 자동으로 개발용 버전으로 해당 트래픽을 연결합니다.

안쓰면 0원 & 지속적으로 사용하면 최대 30% 할인

별도 옵션을 두지 않을 경우 일정 시간동안 요청이 없으면 Instance 갯수가 0이 됩니다. 즉 과금이 없습니다. 펫 프로젝트 할 때 제격이죠. 또한 지속적으로 인스턴스를 켜두면 알아서 30% 정도 깎아줍니다. AWS처럼 스팟 인스턴스니 뭐니 하면서 요금에 신경을 조금 덜 써도 됩니다.

구글 앱 엔진의 단점

한국 리전이 없다

AWS와는 달리 구글 앱 엔진은 한국 리전이 없습니다. 당분간 제일 가까운 리전은 도쿄 리전인데 보통 30 ~ 50ms 정도 Latency를 보입니다. 보통 AWS 서울 리전은 10 ~ 20ms 의 Latency를 보이는 것에 비해서 약간 느린 편이죠.

언어 및 언어 버전에 제약이 있다

지원하는 언어는 Python, Java, PHP, Go 뿐입니다. 아니 구글 앱 엔진 문서에는 C#, Node.js 도 적혀있는데 왜 이러시냐고 묻으실 분들은 아래 조금만 더 읽어주시면 됩니다 : )

프레임워크와 궁합이 좋지 않다

구글 앱 엔진은 완전 관리형 시스템인 PaaS 서비스다보니까, 제약이 상당히 많습니다. Go 언어의 예를 들죠. 일반적인 Go 어플리케이션의 Main은 아래와 같은 형태를 띕니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
package main

import (
"fmt"
"log"
"net/http"
)

func main() {
http.HandleFunc("/", handle)
log.Fatal(http.ListenAndServe(":8080", nil))
}

func handle(w http.ResponseWriter, r *http.Request) {
if r.URL.Path != "/" {
http.NotFound(w, r)
return
}
fmt.Fprint(w, "Hello world!")
}

하지만 구글 앱 엔진의 Main의 형태는 아래와 같습니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
package main

import (
"fmt"
"net/http"

"google.golang.org/appengine"
)

func main() {
http.HandleFunc("/", handle)
appengine.Main()
}

func handle(w http.ResponseWriter, r *http.Request) {
fmt.Fprintln(w, "Hello, world!")
}

뭐가 다른지 아시겠나요? 웹 어플리케이션은 라우팅 설정을 한 후 특정 포트를 Listen 상태로 들어가는데 앱 엔진에는 이 부분이 없습니다. 따라서 모든 부분을 관리하는 모노리스 웹 프레임워크 중 일부는 웹 엔진에서 제대로 구동이 안될 수 있습니다. 장고(Django) 도 초반에는 앱 엔진에서 제대로 돌릴 수 없었고 Go 언어의 Revel 역시 앱 엔진에서 돌릴 수 없습니다.

Flexible Environment 의 최소 비용이 비싸다

여기서 앞에서 언급한 단점인 ‘언어에 제약이 있다’에 대해서 설명할 수 있습니다. 구글 앱 엔진에서는 Standard Environment(이하 SE)와 Flexible Environment(이하 FE)가 있습니다. 이 둘의 결정적인 차이는 SE는 샌드박스 환경에서 실행되고 FE는 AWS의 EC2와 같은 가상 컴퓨팅 머신 위에서 실행된다는 차이입니다. 따라서 FE는 웹 프레임워크의 제약이 없고 언어의 제약도 많이 없지만 SE는 샌드박스 상에서 돌아갈 수 있는 런타임 위에서만 구동됩니다. 예를 들어 Python 3.x가 십 수년전부터 존재함에도 불구하고 SE상에서는 Python 2.7만 지원하며, PHP7이 나왔음에도 SE에서는 PHP5.5만 지원하지요.

SE는 인스턴스 시간당 비용으로 과금되지만 FE는 CPU, Memory, 디스크 용량의 사용량으로 과금한다는 점이 다릅니다. 암튼 EC2와 같은 가상 컴퓨팅 환경에서 돌아가는게 FE라고 했는데 가장 싼 CPU 타입으로 해도 월 $40을 피할 수는 없습니다. 이는 EC2의 가장 저렴한 인스턴스 타입인 t2.micro가 $8.5에 비한다면 매우 비쌉니다. 개인적으로 이 부분이 가장 아쉬운 부분입니다.

SE와 FE의 차이에 대한 글 : https://cloud.google.com/appengine/docs/the-appengine-environments

공유하기 댓글