Google App Engine まとめin development

 
date:2011.02.07   posted by:yokoyama
 

お久しぶりです。横山です。
無料から始められ、難しい設定も必要ないクラウド環境「Google App Engine」のまとめを書きたいと思います。ただお手軽なだけじゃない、その裏側にある「奥深さ」に魅力があります!トラブルシューティング的にまとめることで、少しでも表現できれば幸いです。

*リンク先のほとんどがPythonの情報となっております。ご了承ください。

●概要
・デプロイ(アップロード)するだけで、自動でスケールアウトするサーバーを利用できる。→急速なアクセス増加に対応可能。ソーシャル系サービス等に有利。
・ボトルネックになりやすいDBサーバーも、Bigtable(実際にGoogleが活用している、分散データストア)なら、問題なし。
・他社サービスと比較して割安となるケースがほとんど。

●Bigtableの特徴
【読み書き】
・書き込みと読み込みで速度差が大きい
基本的な速度例(api-cpu-ms)
読み込み:8ms
保存:48ms
*ユニークなものは必ずKey(「key_name」や「Entity key」)でアクセスする。複数キーを操作する場合バッチ(Batch Operations)にて行うことで、API待機ロスを減らせる。
・書き込み時の速度が遅い
2倍程度の差は簡単に生じてしまう。
→index(検索用データ)の量によって保存速度が大幅に遅くなるため、可能な限りindexを使わない。(index=False)
→「Composite index」が必要なケース(index.yamlに明示する必要があるクエリ)は、極力減らす。
・RDBの設計と同じでは遅い。正規化を行わない。
→「ユーザーの更新を即座に反映する必要」の有無を考慮し、同じデータを各場所に保存させることで、検索回数を減らす。
→データのどの部分が無限に増えていくかを考慮し、分散させないことを選択肢に入れる。

【検索】
・複合範囲検索ができない
→その範囲自体に番号を割り当て、その番号を保存する。複合範囲検索は、「ListProperty」により可能となる。
・ページングはどうする?
基本的な方法:何件でもページング可能
ライブラリの利用:1000件までの範囲でのページングならこちらが楽(1000件以上も可能ではあるが、避けるほうが良い。)
・膨大な件数のカウントは不可能
→memcacheにて排他制御を行い集計させる。cronやtaskqueueにて定期的に保存。カウンタの実装
→データを定期的に更新し、表示する。その際mapreduceにより集計する。

【分散データの受け渡し】
・エンティティグループを超えたトランザクション処理は不可能
同じエンティティグループは、イメージ的に同じサーバーに保存されておりトランザクションによる安全なデータ移行が可能。違うグループは別サーバーであるため、トランザクションが不可能となる。また、全ユーザーのデータを同じエンティティグループにすることは、もちろん現実的ではない。
→処理を複数ページに分散する。
メリット:実際の確認画面等で簡潔にできるため実装が簡単。速度も速い。
デメリット:リトライできないものや、同時変更が必須であるものには利用できない。送り手の遷移が増える。
slim3にてグローバルトランザクションでの実装(Javaのみ)
→taskqueueの利用。
taskqueueのオプション「transactional=True」にて可能。ただし、taskqueueは並列処理をするため、同じエンティティグループがバッティングする可能性があ。そのため、taskqueueの処理自体では「transaction」や「get_or_insert」を使えない。
送り先と同じエンティティグループにデータを追加することで対応し、ローカルトランザクションにて処理
メリット:並列処理にて高速かつ、確実に送ることができる。
デメリット:受け取り手の動作が必要。ロールバックが必要なケースでは特にコードが複雑化する。
[参考]
Song of Cloud-グローバルトランザクション処理のパターン
Song of Cloud-送金のトランザクション処理パターン

●インスタンスサーバーの特徴
・インスタンス増加の条件には、アクセスの集中が連続している必要がある。
→「JMeter」での連続アクセスでもスケールアウトする。以前より簡単に増加するようになっていると体感。
・インスタンスの起動が遅い。
→軽量なフレームワークを利用する。「Warmup Request」にて先にモジュールを読み込む。「Always On」オプションにより、常に3台のインスタンスを起動させておく。
・海外サーバーなのでレイテンシがある。
→静的コンテンツは別サーバーを利用する。
→GAEにて動的ページ生成を行わない。(AjaxやFlash、スマートフォンアプリのバックエンド利用。アプリケーションサーバーを別途用意し、RESTサーバーとしてのみの利用。)

●エラーへの対策
・DeadlineExceededError
処理時間が30秒前後に達した際発生し、コード自体に問題がない場合でも発生する。頻繁に発生するページが固定されている場合、設計を見直す必要がある。
→memcacheの利用。importを分散させる。
発生しても問題ないように設計する。
→taskqueueはtransactionalにて利用する。
→データストアにタイムアウトを設定する。

●参考URL
Python入門
Google-App-Engine-Japan
ステイルハウスの書庫
VirtualTechnology

 
Copyright © TheDesignium inc. powered by WordPress & mootools.
Relative Keyword|none