App Engine: Now Serving Javaを見たメモ
- App Engine API jar
- パッチリリースのアップグレードは自動的に行われ、再デプロイの必要はない
- ApiProxy
- Flexible Sandboxing
- きめ細かなサンドボックス制御で、安全性を確保しつつ、できるだけ多くの既存コードを動かせる環境を提供する
- app engineで使える既存ライブラリ
Dependency Injection Frameworks - Guice, Spring, etc. Aspect Oriented Programming - AspectJ, Spring AOP, etc. Web frameworks - Google Web Toolkit, Tapestry, BlazeDS (Flex), etc. - Grails (Just Announced!) Alternate JVM languages - Scala, Rhino, JRuby, Jython, Clojure, Groovy, PHP, etc.
- DevAppServer
- ローカル環境で各APIをエミュレート
- ローカルディスクでDatastore
- Memcache
- URL fetch
- ローカル環境で各APIをエミュレート
- 近日リリース予定
- Questions
- （高負荷時などに）アプリが新しいノードにデプロイされたときの遅延は？
- アプリが使うライブラリ規模にもよるが、数100ms〜数秒程度。
- Java版とPython版の性能の違いは？
- きちんとした比較はしていない。使い方によって異なるが、あまり大きな違いはない。GAE以外の環境で両者を比べた場合と同じ程度。
- Cometサポートは？
- 現状ではレスポンスのストリーム送信に対応しないため、Cometは使えない。現状、Cometサポートはロードマップにはないが、XMPPはサポート予定なので、プッシュ通信は実装できるようになる。
- どんなJVMを使っている？
- googleスタッフがデータを閲覧しないためのセキュリティポリシーはあるか？
- 社内のポリシーがある。
- （高負荷時などに）アプリが新しいノードにデプロイされたときの遅延は？
Offline Processing on App Engine: a Look Aheadを見たメモ
Offline Processing on App Engine: a Look Ahead
- 背景
- バックグラウンド処理やバッチ処理の要求がとても多い
- cronはあるが、たくさんの処理や高頻度の処理には向かない
- バックグラウンド処理やバッチ処理の要求がとても多い
- TQとは？
- ベストエフォートFIFOに処理要求を登録しておくと、バックグラウンドで実行。
- 実行に失敗した場合は、成功するまでリトライする
taskqueue.add(description_of_work )
- TQのメリット
- 非同期
- 軽量で遅延が少ない。Datastoreの最大3倍
- 信頼性が高い：成功するまでリトライ
- スケーラブル：新しいタスクをいくらでも追加できる。それぞれ並列処理される。
- 他のTQシステム
- 各種MQ、Amazon SQS、Azure queuesなど
- pub-subメッセージングと統合されていることが多い
- Queueingとpub-subの違い
- Queueing：非同期処理によりネットワークやCPU、ディスクのキャパシティを効率よく引き出し、スループットを最大化する
- pub-sub：非同期処理により多数の小さなtxを効率よく扱う。fan-outや優先処理、フィルタリング、分散txなどを提供
- app engineのTQは前者のみを対象とする
- GAE TQの特徴
taskqueue.add(url='/work/mail', params=dict(
to='foo@example.com',
subject='Hello',
body='this is a message!'))
- タスクはIdempotenceにする
- タスクは繰り替えし（二重に）実行されても問題のないように書くこと
- さまざまな理由（タスク自身の問題、コンテナの問題、またはそのほかの理由）でタスクは2回以上実行されることがある
- memcacheなどを使って排他する方法が考えられる
- Queueの使い方
- queue.yamlで定義
- 優先度や処理頻度の違いに応じて異なるQueueを定義。さまざまなタスクが混在できる
queue: - name: mail_queue rate: 2000/d - name: speedy_queue rate: 5/s
応用例
- Write behind cache
- ユーザーリクエスト処理時はキャッシュに書き込んでおき、TQのタスクでDatastoreに一括書き込み
- カウンターでの利用：memcacheのカウンター値を加算し、タスクでDatastoreに書き込み
Future
- JMS統合
- MapReduceサポート: しかし他にももっとツール（シャッフル用の中間ストレージなど）が必要
- Queue用AdminConsole
The Softer Side Of Schemas - Mapping Java Persistence Standards To the Google App Engine Datastoreを見たメモ
The Softer Side Of Schemas - Mapping Java Persistence Standards To the Google App Engine Datastore
Datastoreについて
- ストレージをシンプルにする
- Gmailのような規模でなくても、どんなアプリでもスケーラビリティを考える必要がある。
- Entity
- Kind（テーブル）
- Key（主キー）
- Entity Group（パーティション／階層化の単位）
- Property（カラム）
- Datastoreの特徴的な機能
Soft Schema
- Soft Schemaとは
- DatastoreでのSS
- リレーションシップ管理
- Entity Groupの透過的な管理
- 1つのEGの書き込み処理は、1〜10回／sec程度に限られる
- "owned"関連を持つentity同士でEGを形成する：EGの使い方を理解しやすい
- "unowned"関連はサポートしていない：EGがないのでtx管理できない
GAEへのマイグレーション
- プライマリーキーの扱い
- 単一カラムの場合はそのまま使える
- 複合キーの場合はentityの親子関係に置き換える
- N:N用のマッピングデーブル（ジョインテーブル）はList Propertyに置き換える
- トランザクションの扱い
- データモデルからEGのroot entityを見つける
- オンラインサービスでは「ユーザー」データが最適な場合が多い
- 複数のroot（EG)に対するトランザクションが必要な場合
- 仕様を見直す
- compensating txを実装：2つめのtxが失敗した場合は、最初のtxをキャンセルする、など
- データモデルからEGのroot entityを見つける
- クエリの扱い
- joinは使えない：非正規化するか、複数のクエリに分割する
select * from PERSON p, ADDRESS a where a.person_id = p.id and p.age > 25 and a.country = “US” ↓ select from com.example.Person where age > 25 and country = “US”
-
- 関数が使えない（toUpperなど）：関数適用後の値を別カラムに入れておく
- 書き込み時にできるだけ事前処理を行っておくことで、読み込みを高速化できる
- そのほか、条件演算子の不足：メモリ上でフィルタ
- 関数が使えない（toUpperなど）：関数適用後の値を別カラムに入れておく
GAEからのマイグレーション
Questions
- 大規模なグラフ（関連）を一括で取得するような、何らかのプリフェッチ機能（eagar loading）はないか？
- joinできないので、サポートできない。複数のクエリが必要となる。JDOのバッチgetは利用できる。
- 分散txをサポートする予定はあるか？
- 未定。アプリレベルでGAE上で分散txを実装した例がある（他セッションを参照）
- DataNuculeusのダーティフィールド検出を使っているか？
- 使っていない。Datastoreでは1つのプロパティのみの更新ができないので、全フィールドの更新となる。
- JDOのowned関係にないentity間でEGは形成できるか？
- できる。Low Level APIを使う必要はなく、他のentityのキーを持つunowned関係を明示的に記述する必要がある。
KVSやMapReduceはクラウドの真価ではない
ちょっと逆説的に書きました。key-value store (KVS)やMapReduceは、クラウドにはなくてはならない重要な技術ではありますが、それらの技術単体では一般のエンジニアにとってそれほど価値はありません。もともと分散ストレージや分散処理技術は昔から学術研究の恰好のネタでしたし、最近になって技術的ブレークスルーがあったわけでもありません。
クラウドの真価は、「すでに巨大なクラウドがそこにあり、きちんと運用され、ビジネスモデルがある」ということです。学術研究や、まだ実績の少ないOSSフレームワークなどのレベルから、Google並の商用サービスに至るまでには、超えられない壁があります。例えばBigtable論文では、クラウドを構築して実運用することがいかに大変かが記されています。
One lesson we learned is that large distributed systems are vulnerable to many types of failures, not just the standard network partitions and fail-stop failures assumed in many distributed protocols. For example, we have seen problems due to all of the following causes: memory and network corruption, large clock skew, hung machines, extended and asymmetric network partitions, bugs in other systems that we are using (Chubby for example), overflow of GFS quotas, and planned and unplanned hardware maintenance.
たとえて言うならば、クラウドは「マンション」のようなものです。HadoopやCouchDBはたいへん面白い技術ですが、それは「マンションを建てる基礎技術」に過ぎず、上述のような泥臭い苦労を背負ってまで自前でマンションを建てる必要に迫られる人はごく少数です（Amazonとかmixiの中の人）。
クラウドのブレークスルーは、AmazonやGoogleが苦労して建てた巨大マンションの部屋が、とても安く（タダで）賃貸され始めたことです。KVSという簡素な収納しかなく、その使い方も相当慣れが必要ですが、代わりにいくらでも物を置けて部屋も好きなだけ拡張できます。マンションによっては、困った時にはご近所さん総出で助けてくれるMapReduceという仕組みもあります。たくさんの人が、これらの珍しい装備を見よう見まねで使い始め、意外にも結構「住みやすい」ことに気づき始めたところです。
