REFERENCE‎ > ‎

Google App Engine 체험기

음력 날짜를 해당하는 양력 날짜로 바꿔주는 간단한 Django 프로젝트를 만들었다. 규모는 크지 않지만 외부에 공개되고 널리 쓰이기 위해서는 가용성이 중요하다는 생각에, 그리고 시험삼아, 기왕 만든 거 구글 앱엔진에 올려보자는 생각이 들었다. 
Django 책 부록에 앱엔진 사용법이 간결하게 들어가 있어서 보고 필수적으로 맞춰야 할 구조를 따라하였다. 앱엔진 SDK는 1.3.2를 받아 우분투에서 시행하였으며 SDK 자체는 건드릴 필요도 없이 중간중간 dev_appserver.pyappcfg.py를 호출하는 걸로 충분하였다.

우선 urls.py+views.py 구조를 app.yaml+index.py 식으로 바꾸고 내부적으로 거기에 맞게 구조를 변경하였다. 이 과정에서 urls.py가 해주던 named regexp 처리를 해주지 않는 걸 알아서 방법을 찾아보니 앱엔진의 WSGIApplication 클래스 일부를 덮어써서 호출시에 kwargs(즉 dict 식으로 전달되는 변수=값 쌍)을 직접 만들어주는 방법이 있길래 가져와서 썼다. 이 과정에서 호출되는 함수만 덮어쓰는 것으로는 클래스 내부변수에 접근하지 못하는 문제가 있어서 아예 클래스를 확장하는 방식으로 처리했다. 이 편이 조금 더 깔끔한 것 같다.

models.py도 약간씩 다른 부분이 있었다. 통큰 구글답게 자료형 최적화는 없이 문자열, 숫자, 날짜 식으로 큰 분류의 타입을 쓰도록 되어 있고 max_length 같은 건 쓰지 않았다. help_textverbose_name과 대응하는 것 같아 인자명만 바꾸었다. 그리고 choices의 경우 Django에서는 튜플에 값과 이름의 짝을 지어주는데 앱엔진은 그냥 값의 목록만 주도록 되어 있었다.
vobject 모듈을 통해 iCalendar 출력을 생산했는데 이는 당연히 앱엔진이 지원하는 라이브러리에는 존재하지 않는 모듈이다. 따라서 아예 vobject 전체를 복사하고, 의존성이 있는 dateutil도 복사해 넣었다. 이때 vobject에서 socket.gethostname()을 호출하는 부분은 앱엔진에는 존재하지 않는 부분이라서 그냥 임의 문자열로 대체했다. (UID 생성에 쓰이는 부분이라 아무 의미가 없었다)

또한 fixtures/initial_data.json으로 들어가 있던 부분은 파일 자체가 커서 앱엔진에는 올라가지도 않았고, 앱엔진에서는 .csv를 변환 클래스를 통해 appcfg.py로 올리는 방법을 취하고 있었다. 원래 있던 .xls에서 일부를 뽑아내고 적당히 다듬어서 .csv를 준비했다. 그리고 변환 클래스를 준비해 앱엔진에 잘 올렸다. 원래 로컬의 개발서버에 넣어보려고 했으나 인증하라는 문구가 떠서 당황했는데 (책이나 문서에 언급된 바가 없었다), 자료 전달에 쓰이는 /remote_api 주소에 일단 접근을 해서 메일 주소를 주고 로그인을 하라는 안내가 있어서 해보니 정말 인증 순서에서 그 메일 주소와 빈 암호를 주니 통과가 된다. 하지만 이상하게도 로컬의 서버가 그리 빠르지도 않고 올리는 만 단위의 자료를 몇 천 개 받아들이지도 못하고 에러를 내곤 해서 그냥 두었다. dry_run 옵션을 주었을 때 통과는 잘 됐지만. 게다가 문서에는 중간에 멈춘 업로드를 계속 이어서 한다고 되어 있었는데 계속 덤프 파일을 새로 생성할 뿐 이어서 처리하지는 않았다. 별도의 옵션을 줘야 되는 건지는 모르겠다.

appcfg.py update 명령을 통한 프로젝트 업로드는 app.yaml에 기록된 버전 번호가 바뀌지 않는 이상 계속 덮어쓰기가 된다. 앱엔진 자체에는 파일별 리비전 관리 같은 기능이 같이 있지는 않은 것으로 보인다.

간단한 프로젝트를 Django로 만들고 앱엔진으로 바꿔보니 모듈의 제한이 있어 이런저런 모듈을 다양하게 가져다 쓰는 개발방식은 맞지 않을 것으로 보인다. 앱엔진이 어떤 것을 제공하고 어떤 것을 할 수 있는지 충분히 파악하고 프로젝트를 거기에 맞게 구상할 필요가 있어 보인다.


2010년 4월 기록.
Comments