Best Practice for Python Development

on Google Cloud Platform (IMHO)

by Tae-lim Oh

BENEFIT PROBLEM SOLUTION

TABLE OF CONTENTS

BENEFIT PROBLEM SOLUTION

집중

BENEFITS OF GOOGLE CLOUD

안정성 강력한 기능무한한 확장성 COMPONENTS경제성

구글 클라우드 플랫폼은 구글의 인프라와 기술력을 기반으로무한한 확장성과 안정성을 제공합니다.

강력한 서비스 API는 개발자의 시간을 절약해 줍니다.모든 것은 필요한 만큼만 사용하고 과금되므로저렴한 비용으로 서비스를 운영할 수 있습니다.

이 모든 것은 결국 개발자가 비즈니스 로직에 집중할 수 있도록 하기 위함입니다.

BENEFIT PROBLEM SOLUTION

새로운 기술을 적용하기 위해선 결국 학습 곡선을 피할 수 없습니다.IAAS가 아닌 PAAS인 Google App Engine의 경우 특히 더 그러합니다.

LEARNING CURVE

특정 서비스에 종속 되는 것은 두려운 일일 수 있습니다.이는 상대가 구글이라도 마찬가지입니다.

LOCK-IN

BENEFIT PROBLEM SOLUTION

제가 권장하는 방법은Google Cloud Platform을 활용하기 위해 사용되는 모든 코드를

일반적인 코드로 포장하는 것입니다.

WRAP

그 외의 모든 부분에서는일반적인 코드와 구조를 사용합니다.

GENERALIZE

그 결과 Google Cloud Platform을 사용할지라도어떤 환경에서도 사용할 수 있는 형태의 뼈대를 얻게 됩니다.

SKELETON

이것은 생각보다 간단합니다.이 뼈대를 이용한다면

같은 프레임워크를 공유하는 사용자들 간에 공유가 가능해지며그 뒤는 쉽게 웹앱을 양산하는 공장이 될 수 있습니다.

MASS PRODUCTION

제가 오늘 공유드릴 뼈대는파이썬을 위한 것입니다.같은 파이썬 웹 프레임워크인

DJANGO와 FLASK 모두에게 적용 가능한 내용입니다만저는 제가 사용하는 DJANGO를 기준으로 설명 드리겠습니다.

PYTHON

INFRA FILE WRAP

STRUCTURE

INFRA FILE WRAP

Google Cloud Platform 상에서 선택할 수 있는 Computing은Google App Engine과 Google Compute Engine이 있습니다.

저는 주로 Google App Engine을 사용하는데샌드박스 환경을 제공해 주기 때문에

서버 세팅의 번거로움이 현저히 적기 때문입니다.

COMPUTE

Google Cloud Platform 상에서 선택할 수 있는 Database에는Cloud SQL와 Cloud Datastore가 있습니다.

차이는 간단히 말해 전자는 관계형이지만 후자는 아니라는 것입니다.각자 용도에 따른 장단점이 있습니다만

제가 사용하는 웹 프레임워크인 Django의 경우에는기본적으로 관계형 DB사용을 전제로 하기 때문에

저는 Cloud SQL을 연결해 사용합니다.참고로 Cloud SQL은 단순히 구글 서버에서 작동하는 MySQL 5.5일 뿐입니다.

DATABASE

Google Cloud Platform 상에서 선택할 수 있는 Storage는Blobstore와 Cloud Storage가 있습니다.제가 후자를 선택한 이유는 크게 3가지인데,

상대적으로 더 저렴하고 UI가 편리하기 때문입니다.

STORAGE

INFRA FILE WRAP

저는 일반적인 DJANGO 프로젝트를 위한 TWO SCOOPS of DJANGO 템플릿을 개조해GAE를 위한 DJANGO SKELETON을 작성해 사용하고 있습니다.

https://github.com/gluwa/gae-django-skeleton개조 내용은 FLASK 프로젝트에도 동일하게 적용할 수 있으실 것입니다.

TWO SCOOPS of DJANGO

DJANGO 프로젝트는 전반적인 사항들을 SETTINGS 모듈에서 설정하도록 하고 있습니다.SETTINGS는 여러 개의 파일로 나뉘어

필요에 따라 임의로 상속하여 사용할 수 있습니다.

주로 개발 환경과 배포 환경을 구분하는데 쓰이는데,개발 환경에만 적용 되는 사항들은 LOCAL에

배포 환경에만 적용 되는 부분들은 PRODUCTION에 정리해 넣습니다.그리고 공통 되는 부분은 BASE에 담습니다.

DJANGO SETTINGS

LOCAL PRODUCTION

BASE

하지만 일반적인 SETTINGS는 GAE에선 제대로 작동하지 않습니다.GAE는 경우 app.yaml 파일에서 사용할 SETTINGS 모듈의 위치를 지정하도록 되어 있으며

이는 개발 환경에서도 영향을 미칩니다.또한, 배포 환경에 원격으로 접속할 시에는 PRODUCTION의 내용을 써야 할 때도 있습니다.

해결 방법은 GAE를 위한 파일을 따로 만드는 것입니다.

GAE파일은 자동으로 개발과 배포 환경을 오가며GAE에서만 사용 되는 설정 내용을 담습니다.

https://github.com/gluwa/gae-django-skeleton/blob/master/project_name/project_name/settings/gae.py

GAE SETTINGS

LOCAL PRODUCTION

BASE

GAE

GAE는 샌드박스 환경이기 때문에3rd party library들을 배포 환경에 직접 설치할 수가 없습니다.

이는 SDK에서도 마찬가지이기 때문에개발자들은 모든 3rd pary 모듈을 프로젝트 폴더 안에 포함 시켜야 하며

이는 프로젝트가 커지면 커질 수록 관리를 어렵게 합니다.

해결 방법은 프로젝트 폴더 밖에 lib 폴더를 따로 두는 것입니다.GAE 프로젝트 폴더 안에 lib 폴더 안에 있는 모듈들을 심링크로 포함시키면

GAE 배포시 SDK는 자동으로 링크 된 파일들을 긁어 와 줍니다.

LIBRARIES

INFRA FILE WRAP

먼저 GAE에서 기본적으로 제공하는 서비스들을 위한 WRAP이 필요합니다.EMAIL, MEMCACHED, STORAGE를 위한 WRAP은이미 수 많은 개발자들로부터 오픈소스로 개발되어 왔으며아래의 링크는 그중 제가 선별해 놓은 코드들입니다.

https://github.com/gluwa/gae-django-skeleton/tree/master/project_name/django_gae

이제 이들을 SETTINGS의 GAE에 연결해 놓기만 하면 됩니다.

BASIC

GAE는 다양하고 강력한 기능의 API를 제공하고 있으며이들을 이용 시 개발자는 더욱 빠르게 강력한 앱을 만들 수 있습니다.

예를 들어, IMAGES API는이미지 파일을 순식간에 리사이징이나 크롭 해주는 강력한 기능을 제공하고 있습니다.

하지만 이런 API를 직접적으로 적용할 경우마이그레이션 시 해당 부분을 모두 변경해 주어야하는 번거로움이 생기며

이는 LOCK-IN 요소가 됩니다.

이때 GAE의 API를 CUSTOM API로 간싸 놓아서 쓰면GAE에서 마이그레이션 하게 될 경우

혹은 기능의 customization이 필요할 경우동일한 기능을 통일된 API로 개발하여 연결해 쓰면

PROJECT의 다른 부분을 손대지 않고 손쉽게 변경이 가능합니다.

CUSTOM API

ALTERNATIVE

GAE API

CUSTOM

API PROJECT

때론 3rd party에서 GAE가 지원하지 않는 기능을 요구하는 경구도 있습니다.예를 들어 로컬 파일 시스템을 사용하려 하는 경우

GAE의 샌드박스 환경에선 권한이 없으므로 작동하지 않습니다.

이때 CUSTOM API의 경우처럼 부분적인 패치로 해결 할 수 없다면과감하게 해당 REPO를 FORK하고문제 부분을 수정하는 것을 추천합니다.

FORK

이 발표에 사용 된 GAE DJANGO SKELETON 샘플 코드는 아래에서 찾으실 수 있습니다.

https://github.com/gluwa/gae-django-skeleton

SAMPLE

QUESTION?