얼마전 iOS 개발자로 일하고 있는 친구와 함께 사진 공유 App을 런칭했다. (App Store Link). 어차피 돈 벌기 위한 작업이 아니었으므로 서버 비용을 최소화하는 방법으로 구현했다.
1. 사진 데이터는 Facebook에 올린다.
2. 우리 App에서 보여주기 위한 데이터(순위, 투표 현황 등)는 Google App Engine에 저장한다. 1 GB까지 무료이므로 어느정도 수준까지 무료로 서비스 가능. 이 이상이면 소액 지출로 해결한다. 1GB 이상의 데이터가 쌓일 정도면 일정 수준 성공한 서비스이므로 광고 등으로 유지 비용을 벌 수 있을 것이라 판단.
3. iOS App에서 cache를 적절히 활용하여 Google App Engine에 조회를 최소화한다.
위와 같은 방식으로 하면 초기 비용 없이 서비스를 한동안 제공할 수 있을 것이라 생각하고 App을 한달전 쯤 런칭하였는데... 딱 일주일만에 Google App Engine의 DB read 동작이 무료로 제공되는 한계치를 넘을려 하고 있었다. 어쩔 수 없이 유료화로 전환하여 약간의 비용을 지출하게 되었는데.
실제 사용자 수에 비해 DB read 횟수가 많아 보여 이를 감소하는 방법을 찾아 적용하였다. 혹시, Google App Engine을 사용하여 서비스를 구축하려는 분들에게 도움이 될 듯 싶어 공유한다.
DB read 동작 횟수에 대한 정확한 이해가 필요
- Entity를 읽으면 무조건 1회의 read 동작
- Query를 실행하면 1회, Query에서 얻어지는 모든 Entity에 대해 1회의 read 동작 (read는 100k 당 0.07 USD)
- Key만 조회하는 Query의 경우는 read 1회에 Query에서 얻어지는 모든 Entity Key에 대해 1회의 small 동작 (small은 100k 당 0.01 USD)
즉, Entity를 얻어오는 동작을 최소화하고 Query를 실행 시 Key 값만으로도 충분하다면 언제나 Key only 조회를 실행하는 것이 비용을 줄일 수 있다.
실제 구현은 어떻게?
1. GAE (Google App Engine)이 제공하는 memcache를 활용하여 DB의 물리적인 read를 줄인다. 성능의 이점뿐 아니라 비용을 줄일 수 있다.
2. Query를 실행 시 되도록 Key only Query를 사용한다. 1/7로 비용을 줄일 수 있다.
3. fetch의 offset 인자 대신 Cursor를 사용한다. fetch의 offset을 이용하여 특정 데이터를 skip시 read 동작으로 count 되기 때문이다. 더 자세한 설명은 아래 GAE 문서에서 발췌한 Note를 참고.
Note: Using an offset only avoids returning the skipped entities to your application, but these entities are still retrieved internally. The skipped entities do affect the latency of the query, and your application is billed for the read operations required to retrieve them. To avoid these costs, it is often better to use a query cursor instead of an offset.
4. Query를 이용하여 for loop에서 Entity를 가져오는 대신 Model의 get(keys) 를 이용하는 것이 read 횟수를 줄일 수 있다. Query의 경우 Query 1회, Entity 가져오기 1회의 read 동작이 필요하고 get(keys)는 Entity를 가져오는 1회의 동작만 필요하다.
댓글
댓글 쓰기