구글 앱엔진의 새로운 데이터베이스 라이브러리인 ndb의 사용법과 팁을 소개한다.

@tasklets.tasklet

이 데코레이터를 사용하면, 함수를 내부에 yield 구문을 사용할 수 있는, generator 함수로 바꿀 수 있다. 대신 맨 끝에는 raise tasklets.Return(x,y,z) 의 형태로 리턴을 해야 한다. (그냥 리턴을 하면 에러로 간주된다)

이 데코레이터로 둘러싼 함수를 호출하려면

x, y, z = my_func_async().get_result()

또는

x, y, z = yield my_func_async()

와 같이 사용할 수 있다. 다만 yield 를 사용하려면 호출하는 쪽도 tasklet 이 되어야 한다는 단점이 있다.

여기까지는 매뉴얼에 설명된 부분이고, 기본적인 단어의 의미를 살펴보자.

• tasklet : 비동기적으로 실행되는 단위 함수(coroutine)
• yield : 비동기 함수의 결과를 받을 때까지 대기하면서, 다른 tasklet 에게 스케줄링을 양보한다. 결과가 도착하면 get_result() 와 동일하다.
• future : 비동기 함수의 실행 상황을 저장해두는 객체. jQuery 의 promise 와 같다.
• eventloop : 내부 큐에 쌓여있는 tasklet 들을 잘 실행해주는 스케줄러다. @context.top_level 의 소스를 보면 큐에 쌓여있는 모든 작업들을 끝낼 때까지 무한루프(eventloop.run())를 돌리는 걸 볼 수 있다.

이제 실제 사용예를 살펴보자.

여러 개의 비동기 함수를 기다리기

futures = []
f1 = A.get_async()
futures.append(f1)
f2 = B.get_async()
futures.append(f2)
x, y = yield futures
# or
x, y = yield A.get_async(), B.get_async()

이 경우 2개의 쿼리는 동시에 실행되며, 둘 다 끝날 때까지 대기하는 배리어(Barrier) 패턴을 사용할 수 있다. 주의할 점은 동시에 실행하는 함수들은 서로 서로 관계가 없어야 된다는 점이다.

@tasklets.tasklet
def load_async(v):
    x = yield X.get_async()
    v.x = x
    raise taskets.Return(x)

yield load_async(A), A.put_async()

위 예제처럼 하나의 tasklet에서 객체를 변형하는데, 동시에 그 객체를 저장하는 함수를 실행할 경우, 완료 순서가 다름으로 인해서 A의 값이 저장될 수도 있고 되지 않을 수도 있다. 예제가 너무 극단적이지만 실제 프로젝트에서 비동기 함수들이 간접적으로 재귀 호출이 되는 상황에 처하다 보면, 헷갈릴 때가 많으니 주의 바란다.

Map Query

쿼리로 읽어온 객체의 참조 속성(reference property)을 다시 읽어와야 할 경우라든지, 읽어온 값을 이용해서 또다른 쿼리를 해야 할 때 사용한다.

@tasklets.tasklet
def prefetch(x):
    ref = yield x.ref_prop
    raise tasklets.tasklet(x, ref)

values = X.query().filter().map(prefetch)
values = yield X.query().filter().map_async(prefetch)

map/map_async는 파이썬 기본 함수인 map()처럼, 개별 쿼리 결과에 대해서 동기/비동기로 콜백을 실행해주는 함수다. 참고로, 위 예제를 아무리 병렬로 실행해본들, 첫번째 쿼리의 결과가 끝나야 그다음 결과를 읽어올 수 있다는 점에 주의할 것.

어쨌거나 내부적으로 AutoBatcher 가 2개의 쿼리로 만들어준다고 하니 믿고 써보자. 운좋게 컨텍스트 캐시에 적중하면 좀 더 빠르겠지…

위 예제를 yield 없이 구현하면 명백한 2개의 쿼리로 만들 수는 있다. 아주 직관적이지만 코드는 좀 더럽다.

futures = []
v1 = []
for x in X.query().filter().fetch():
   futuers.append(x.ref.get_async())
   v1.append(x)
values = zip(v1, yield futures)

여기까지는 그럭저럭 손코딩이 빠를 수 있지만, 여기에 서브 쿼리가 들어가고 리턴되는 양도 많아지면, 오히려 AutoBatcher가 더 빠르다고 한다.

@tasklets.tasklet
def prefetch_subquery(x):
    ref, subquery = yield x.ref_prop, Y.query().fetch_async()
    raise tasklets.tasklet(x, ref, subquery)
values = X.query().filter().map(prefetch)

잘 생각해보면, 이걸 아무리 손으로 최적화해본들 쿼리의 절대 숫자(1+첫번째 쿼리 결과 갯수)는 줄일 수가 없다. 따라서 첫번째 쿼리 결과가 많아지면 손으로 최적화하기 보다는 자동으로 처리하고 Guido에게 비는게 가장 좋은 방법이다.

@tasklets.synctasklet

이 데코레이터는 generator 함수를 일반 함수로 바꿔준다. 예를 들면

@tasklets.synctasklet
def func_async(k):
    v = yield some_async(k)
    raise tasklets.Return(v)

v = func_async(k)

위와 같이 평범한 함수 호출처럼 사용할 수 있다. 그냥 일반 tasklet 에서 get_result() 를 한번 더 호출해주는 걸로 구현되었다.

@context.top_level

이 데코레이터는 내부적인 모든 비동기 루틴들이 완료될 때까지 기다린다. 소스 코드를 살펴보면 eventloop 로 무한루프를 돌리는 걸 확인할 수 있다. django view 라든지 webapp view 에 사용하면 된다.

최적화

ndb 최적화는 결국 RPC 호출을 얼마나 줄이느냐에 달려 있다. 다음 두 문장을 살펴보자.

x = MyModel.get_by_id_async('a')
y = MyModel.get_by_id_async('b')
x.get_result()
y.get_result()

x, y = MyModel.get_by_id_async('a'), MyModel.get_by_id_async('b')
x.get_result()
y.get_result()

x, y = yield MyModel.get_by_id_async('a'), MyModel.get_by_id_async('b')

Octopress는 정적 사이트 생성기인 Jekyll 을 이용해서 블로그를 손쉽게 구성하도록 해주는 루비 프레임워크다. 말 그대로 정적 HTML 파일들을 미리 만들어서 어딘가로 올려서 서비스하는 거라, GitHub에서 블로그를 서비스할 수 있음은 물론, Amason S3나 구글 앱엔진에서도 블로그 서비스가 가능하다.

큼직큼직한 글씨와 미려한 테마, 코드 문법 하일라이팅, blockquote, gist 코드 포함 등의 다양한 플러그인이 지원되며, 생성, 배포, 최신 소스 업데이트, 글쓰기 등의 작업들이 rake 콘솔 명령으로 간편하게 포장(?)되어 있다. DB를 쓰지 않기 때문에 코멘트는 Disqus 같은 외부 사이트를 이용하게 된다. 워낙 매뉴얼이 잘 되어 있어서 설치나 사용법은 그냥 따라해도 충분하다. 레이옷은 DropBox에 origin 레파지토리를 두고 사용중이다.

중요한 건 기존 블로그를 얼마나 손쉽게 이전하느냐인데, 워드프레스.com에서 이사오는 데 거의 3일이 걸렸다. 워낙 블로그 이사를 많이 다녀서 메타 정보가 개판이었고 본문에 이런 저런 비표준 태그를 많이 써서 문제는 더욱 심각했다. 또 워드프레스에서 내보내기로 받아온 XML 자체에도 문제가 많았다. (내 경우에는 글들이 중간에 짤려서 태그가 제대로 완결이 안되었다든지, ^Z가 본문 중에 있어서 파싱이 안되기도 했다.) Jekyll에서 제공하는 스크립트는 마크다운 변환 기능이 빠져 있고, 유니코드 에러를 자주 뱉기 때문에 직접 파이썬으로 만들어야만 했다. (루비 책 몇 권 사놓고도 문법을 보니 머리가 아파서 포기했다.)

어쨌든 그 삽질의 결과물을 아래와 같이 공개한다. 자유롭게 이용하되, 아래 스크립트의 사용시 책임은 사용자 본인에게 있다는 걸 미리 밝힌다. :P

참고로, 변환을 하다 보면 다양한 에러들을 만나게 된다. -_-+

• invalid byte sequence in UTF-8 : 이건 본문 중에 애매한 문자열이 있다는 건데, 강제로 유니코드로 변환했음에도 발생한다. 알아서 찾아서 고치는 수 밖에 없다. 단 octopress 소스를 아래와 같이 고쳐야 한다.

#ruby octopress/plugins/post_filters.rb
    def do_layout(payload, layouts)
      pre_render if respond_to?(:pre_render)
      begin
        old_do_layout(payload, layouts)
      rescue StandardError => e
          puts "Post Filter Error: " + e.message + self.url
      end
    end

• Liquid Exception: 혹시 django 나 jquery template 코드가 있을 경우, 이게 Jekyll 의 템플릿 엔진인 liquid의 태그와 동일하기 때문에 에러가 발생한다. 이런 문법에 따라 수동으로 잘 제거하는 수 밖에 없다.
• 핵심적으로 한글로 된 제목 때문에 가장 고생이 심했다. 아주 오래전에 쓴 글들은 제목은 한글, slug는 한글을 URL로 바꾼 %xx%yy와 같은 형식이었다. 이걸 다시 제대로된 유니코드로 역변환(unquote)해서 파일을 만들었는데 rake preview로 살펴보면 한글 URL 포스트에 접근이 안되는 것이었다. 몇 시간동안 삽질을 해본 결과 로컬 서버인 Webrick의 문제인지, GitHub에 올리니까 잘 되는 것이었다. 여기서의 교훈: slug는 영문을 애용할 것!!

jQuery Proven Performance Tips & Tricks 간단 요약

• 최신 버전을 사용해라. (1.4 보다 1.6이 2배 가까이 빠르다)
• id 선택자가 class 선택자보다 5-10배 이상 빠르다.
• 가상 선택자는 느리니까 최대한 쓰지 말 것. 검색 영역의 모든 요소를 다 뒤진다!!
• 부모에서 자식을 찾는 방법은 $parent.find('.child') 가 제일 빠르다. 다른 것은 잊어라. (근데 왜 children() 이 더 안빠르지..)
• jQuery 객체는 꼭 필요할 때에만 만들 것.
• 항상 캐싱할 것
• 체인 방식을 애용할 것. 이미 필터링된 집합을 이용하므로 빠르다. 코드도 간단해진다.
• bind, live 보다 delegate가 좋다!
• DOM insert/append 는 가급적 한번에 끝낼 것. 무거운 연산을 해야 할 경우 일단 detach 했다가 다시 넣으면 좋다.
• $.each() 는 느리니까 그냥 for 를 쓸 수 있으면 써라.
• $.method 보다 로레벨 함수인 $.fn.method 가 빠르다.

대체로 아는 이야기라는 점이 슬프다. 그걸 아는 놈이 짠 코드가 이 모양이라니.. ㅠㅠ

그나저나 jsperf.com 같은 걸로 브라우저별로 검증해보지 않으면 다 공허한 이야기인 듯. 재미있는 건 IE 6/7 클래스 선택자의 속도가 다른 브라우저보다 1000-2000배 느리다는 점과, 크롬 13.x 의 성능이 갑자기 앞뒤버전보다 확 떨어졌다는 것. :)