구글 앱 엔진 파이썬3 변경사항

구글 엡 엔진 파이썬3(Standard Environment)에서는 기존과 많은 점이 변경되었습니다. gVisor 컨테이너 런타임의 영향으로 기존의 Flexible Environment에 가깝게 바뀌었는데요.

최신 런타임

파이썬 2.7 -> 파이썬 3.7

/tmp에 파일 입출력 가능

기존 파이썬2에는 파일 입출력이 불가능해서 /tmp을 쓰는 파이썬 라이브러리가 제대로 작동하지 않는 문제가 있었습니다. 이번 파이썬3 런타임에서는 /tmp에 파일 입출력이 가능합니다.

써드파티 라이브러리 설치 제약 해제

기존 파이썬 2.7 런타임에서는 사용 가능 라이브러리에 제약이 있었습니다. Whitelist 방식으로 사용 가능한 라이브러리 외에는 다 안되는 방식이었는데, 이번에는 어떠한 써드파티 라이브러리의 제약이 없습니다.

쓰레드 사용 가능

쓰레드가 사용가능했습니다. 다만 요청을 완료하기 전까지만 사용할 수 있습니다.

ndb 라이브러리의 퇴장

기존에 datastore를 사용할 때 사용했던 ndb를 사용하지 못하고 google-cloud-datastore 라이브러리를 사용해야 합니다.

로깅 방식의 변경

기존 런타임에서는 logging을 사용하면 바로 스택드라이버에서 사용할 수 있었지만, 새 런타임에서는 명시적으로 스택드라이버를 import 시켜서 로깅해야 합니다. 기존처럼 logging.info, logging.error 찍어도 로그에서 확인할 수 없습니다.

integrated 된 서비스 사용 불가

이 부분이 기존 flexible environment 비슷하게 되었습니다. 파이썬2 Standard environment와 긴밀하게 연결되어 있던 Mail, Search, memcache, Search, Task Queue를 사용할 수 없습니다. 다른 서비스를 사용해야 합니다.

local 개발 환경 변경

기존의 dev_appserver를 사용할 필요가 없습니다. 대신 개발 시 기존 SDK에서 제공하는 기능은 로컬 에뮬레이터를 사용해야 합니다.

URL Fetch out, Requests In

기존에는 앱 엔진 외부 Request는 URL Fetch를 사용해야 했으나 다른 앱처럼 Requests 라이브러리를 사용하세요~

대략적인건 이 정도 인듯 합니다. : )

구글 앱 엔진 2018 하반기 소식 모음

간만에 블로그 글을 씁니다. 2018년 하반기 구글 앱엔진에 굵직한 업데이트가 있었습니다.

Python3 지원

얼마전까지도 파이썬2의 종료일자는 다가오는데 구글측에서는 파이썬3를 지원 예정이라고만 언급해서 애를 태웠습니다. 그런데 2018년 8월 8일, 드디어 파이썬3 런타임을 베타로 지원하기 시작했고 어제인 12월 14일 GA로 올라왔습니다. 지원 런타임은 3.7입니다.

파이썬2에서 파이썬3로 올라오면서 굉장히 많은 변화가 생겼습니다.

기존 파이썬2 앱엔진은 제한된 샌드박스 위에서 구동되는 방식이었습니다. 그래서 사용할 수 있는 라이브러리와 버전도 굉장히 제한적이었고 파일 접근은 물론이요 네트워크까지 제약이 굉장히 많았습니다. 그래서 아무리 장고, 플라스크 앱이라도 구글 앱엔진용으로 수정을 해야 사용할 수 있었습니다.

하지만 파이썬3 앱엔진은 gVisor 콘테이너 런타임 기술을 사용해서 /tmp 를 마음대로 쓸 수 있으며 아무 라이브러리를 설치해서 쓸 수 있습니다.

기본 웹서버를 nginx로 변경

별 영향은 없다네요.

새로운 사용 가용 리전

us-west2(로스 엔젤레스), asia-east2(홍콩) 리전에서 앱 엔진을 사용할 수 있습니다.

참고 : 구글 클라우드

구글 앱 엔진 소개

구글 앱 엔진(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

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×