GAE 위에서 DJANGO 사용하기

Best Practice
for Python Development
on Google Cloud Platform
(IMHO)
by Tae-lim Oh

TABLE OF CONTENTS
BENEFIT PROBLEM SOLUTION

BENEFITS OF GOOGLE CLOUD
무한한 확장성 안정성 강력한 기능 COM경P제O성NENTS
집중
구글 클라우드 플랫폼은 구글의 인프라와 기술력을 기반으로
무한한 확장성과 안정성을 제공합니다.
강력한 서비스 API는 개발자의 시간을 절약해 줍니다.
모든 것은 필요한 만큼만 사용하고 과금되므로
저렴한 비용으로 서비스를 운영할 수 있습니다.
이 모든 것은 결국 개발자가 비즈니스 로직에 집중할 수 있도록 하기 위함입니다.

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

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

WRAP
제가 권장하는 방법은
Google Cloud Platform을 활용하기 위해 사용되는 모든 코드를
일반적인 코드로 포장하는 것입니다.

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

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

MASS PRODUCTION
이것은 생각보다 간단합니다.
이 뼈대를 이용한다면
같은 프레임워크를 공유하는 사용자들 간에 공유가 가능해지며
그 뒤는 쉽게 웹앱을 양산하는 공장이 될 수 있습니다.

PYTHON
제가 오늘 공유드릴 뼈대는
파이썬을 위한 것입니다.
같은 파이썬 웹 프레임워크인
DJANGO와 FLASK 모두에게 적용 가능한 내용입니다만
저는 제가 사용하는 DJANGO를 기준으로 설명 드리겠습니다.

COMPUTE
Google Cloud Platform 상에서 선택할 수 있는 Computing은
Google App Engine과 Google Compute Engine이 있습니다.
저는 주로 Google App Engine을 사용하는데
샌드박스 환경을 제공해 주기 때문에
서버 세팅의 번거로움이 현저히 적기 때문입니다.

DATABASE
Google Cloud Platform 상에서 선택할 수 있는 Database에는
Cloud SQL와 Cloud Datastore가 있습니다.
차이는 간단히 말해 전자는 관계형이지만 후자는 아니라는 것입니다.
각자 용도에 따른 장단점이 있습니다만
제가 사용하는 웹 프레임워크인 Django의 경우에는
기본적으로 관계형 DB사용을 전제로 하기 때문에
저는 Cloud SQL을 연결해 사용합니다.
참고로 Cloud SQL은 단순히 구글 서버에서 작동하는 MySQL 5.5일 뿐입니다.

STORAGE
Google Cloud Platform 상에서 선택할 수 있는 Storage는
Blobstore와 Cloud Storage가 있습니다.
제가 후자를 선택한 이유는 크게 3가지인데,
상대적으로 더 저렴하고 UI가 편리하기 때문입니다.

TWO SCOOPS of DJANGO
저는 일반적인 DJANGO 프로젝트를 위한 TWO SCOOPS of DJANGO 템플릿을 개조해
GAE를 위한 DJANGO SKELETON을 작성해 사용하고 있습니다.
https://github.com/gluwa/gae-django-skeleton
개조 내용은 FLASK 프로젝트에도 동일하게 적용할 수 있으실 것입니다.

BASE
LOCAL PRODUCTION
DJANGO SETTINGS
DJANGO 프로젝트는 전반적인 사항들을 SETTINGS 모듈에서 설정하도록 하고 있습니다.
SETTINGS는 여러 개의 파일로 나뉘어
필요에 따라 임의로 상속하여 사용할 수 있습니다.
주로 개발 환경과 배포 환경을 구분하는데 쓰이는데,
개발 환경에만 적용 되는 사항들은 LOCAL에
배포 환경에만 적용 되는 부분들은 PRODUCTION에 정리해 넣습니다.
그리고 공통 되는 부분은 BASE에 담습니다.

BASE
LOCAL PRODUCTION
GAE
GAE SETTINGS
하지만 일반적인 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

LIBRARIES
GAE는 샌드박스 환경이기 때문에
3rd party library들을 배포 환경에 직접 설치할 수가 없습니다.
이는 SDK에서도 마찬가지이기 때문에
개발자들은 모든 3rd pary 모듈을 프로젝트 폴더 안에 포함 시켜야 하며
이는 프로젝트가 커지면 커질 수록 관리를 어렵게 합니다.
해결 방법은 프로젝트 폴더 밖에 lib 폴더를 따로 두는 것입니다.
GAE 프로젝트 폴더 안에 lib 폴더 안에 있는 모듈들을 심링크로 포함시키면
GAE 배포시 SDK는 자동으로 링크 된 파일들을 긁어 와 줍니다.

BASIC
먼저 GAE에서 기본적으로 제공하는 서비스들을 위한 WRAP이 필요합니다.
EMAIL, MEMCACHED, STORAGE를 위한 WRAP은
이미 수 많은 개발자들로부터 오픈소스로 개발되어 왔으며
아래의 링크는 그중 제가 선별해 놓은 코드들입니다.
https://github.com/gluwa/gae-django-skeleton/tree/master/project_name/django_gae
이제 이들을 SETTINGS의 GAE에 연결해 놓기만 하면 됩니다.

CUSTOM
API PROJECT
CUSTOM API
GAE는 다양하고 강력한 기능의 API를 제공하고 있으며
GAE API
ALTERNATIVE
이들을 이용 시 개발자는 더욱 빠르게 강력한 앱을 만들 수 있습니다.
예를 들어, IMAGES API는
이미지 파일을 순식간에 리사이징이나 크롭 해주는 강력한 기능을 제공하고 있습니다.
하지만 이런 API를 직접적으로 적용할 경우
마이그레이션 시 해당 부분을 모두 변경해 주어야하는 번거로움이 생기며
이는 LOCK-IN 요소가 됩니다.
이때 GAE의 API를 CUSTOM API로 간싸 놓아서 쓰면
GAE에서 마이그레이션 하게 될 경우
혹은 기능의 customization이 필요할 경우
동일한 기능을 통일된 API로 개발하여 연결해 쓰면
PROJECT의 다른 부분을 손대지 않고 손쉽게 변경이 가능합니다.

FORK
때론 3rd party에서 GAE가 지원하지 않는 기능을 요구하는 경구도 있습니다.
예를 들어 로컬 파일 시스템을 사용하려 하는 경우
GAE의 샌드박스 환경에선 권한이 없으므로 작동하지 않습니다.
이때 CUSTOM API의 경우처럼 부분적인 패치로 해결 할 수 없다면
과감하게 해당 REPO를 FORK하고
문제 부분을 수정하는 것을 추천합니다.

SAMPLE
이 발표에 사용 된 GAE DJANGO SKELETON 샘플 코드는 아래에서 찾으실 수 있습니다.
https://github.com/gluwa/gae-django-skeleton

GAE 위에서 DJANGO 사용하기

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to GAE 위에서 DJANGO 사용하기

Similar to GAE 위에서 DJANGO 사용하기 (20)

GAE 위에서 DJANGO 사용하기