- appengine ja night #23 が開催されます - Google Developer Japan Blog
- appengine ja night #23 まとめ - Togetterまとめ
- appengine ja night #23 が終わりました - スティルハウスの書庫
- 過去のメモ
初めてGoogle本社に行って来ました。
と言うことで、メモったことなどを投下します。
Optimizing Your App Engine App (with Appstats)
資料 → http://proppy-appstats.appspot.com/
- App Engine アプリの最適化と Appstats
- 主にGoogle App EngineのDatastore利用におけるアンチパターンについて
- アンチパターン 1
- UserのKindにnameとdataプロパティを持つケース
- nameでクエリー実行する。
- 結果は、1回のリクエストで2回のデータストアのリードが発生している
- なぜでしょうか？
- queryで検索した場合には、Indexを読みに行ってから、実体を読みに行くから合計で2回見に行くことになる
- 1件しかないことが事前にわかっている場合には、IDで検索するべきです
- IDであれば1回のReadで済みます
- アンチパターン 2
- Index Propertyを使いすぎるケース
- デフォルトではインデックスが作成されます
- User Kindのsecret等のpropertyのような、検索キーにならないのにIndexを作成してしまう
- secretを更新してまたputすると、Datastoreへのwriteが9回も発生してしまう
- indexed=falseにしておくと、writeは3回で済むようになる
- これはupdate操作のために、Indexを削除してから、propertyごとにIndexをwriteするため
- アンチパターン 3
- Entity全体に対して検索するのはさける
- User Kindに、city, email, phoneのpropertyがあるケース
- 2つのEntityを作っておく
- Londonに住んでいる全てのユーザのemailが知りたい場合
- 3回のreadが発生する
- projection queryでemailと指定しておくと、readの回数は3回で変わらないが、small readになる
- Indexから直接読み込ませることが出来ることになる
- ただし、必ずしも良いわけではない。
- writeの場合にはpeopertyをIndexに書き込むコストが発生することは忘れないでください
- すでにインデックスされているpropertyの場合には有効です
- アンチパターン 4
- 20人のUserのEntityがある場合、10人にクエリ、さらに残りの10人にoffsetを指定してクエリする
- 結果32回のクエリが発生する
- cursolを使ってみましょう。
- fetch_pageとcursolを使えば、Readの回数が23回に減る
- offsetを使用した場合の動作は、offsetの前全部readしてから捨てている
- もし、offsetを大きい値にすると、ものすごくコストがかかってしまう
- 一方カーソルを使えば、前回のクエリからやるので早く安くなる
- アンチパターン 5
- アンチパターン 6
- RPC個別実行してしまう
- 100個のEntityをputする場合
- 1個1個をそれぞれputするとすごいコストがかかかる
- 100個のEntityを予め作成してから、一度にputすることで軽減出来る
- さらにput_asyncを利用することで、並列にputすることも出来る
- put処理をしている間に別のことができるようになる
- 処理を待つ場合はwaitモードを使う必要がある
- put_multiまたは、put_asyncでバッチモードを使って、並列モードでやればRPC呼び出しが減る
- 他のRPCを使うAPIにも同じ事が言える
- アンチパターン 7
- RPCを順番に実行してしまう
- ３つのURLフェッチを順番に書くと、順番に実行されてしまう
- ndbのcontextオブジェクトを使えば、並列に実行することが出来る
- futuresで終わるのを待てば良い
- 3つ分の時間ではなく、一番遅い時間で済むようになる
- アンチパターン 8
- アンチパターン 9
- アンチパターン 10
- すごい重要
- Global Queryは避けること、整合性が重要な場合は特に
- 変更しても、古いデータが取れるケースがある
- 更新の動作は内部的にIndexを更新してからレプリケーションするので反映が間に合わない事がある
- レプリケーションされるまでには時間がかかるので、クエリーを実行するたびに結果が変わってしまう可能性がある
- この場合には、AnsesterQueryを使う
- 親のEntityを指定すると良いです
- しかしながら、トレードオフがあり、1秒間に1回の書き込みしか出来ない
- 別の方法keys_get & get_multiで取ればOK
- KeyOnlyQueryを実行し
- 取得したKeyでget_multiで検索すると、古いデータが検索されることがなくなる。
- さらに
- GoogleIOの2012の資料を見てください
- さらに重いものはTaskQuereに入れて、非同期に実行させるべきです
- Adminコンソールのパフォーマンスセッティングにも注意すること
- パフォーマンスとコストとのトレードオフで設定すること
- AppStats → appstats-tour - interactive tour of App Engine optimization patterns - Google Project Hosting
- QA
- いくつまでputはまとめられるの？
- 自動的にチャンクを作ってやってくれるみたいです
- ndbライブラリでやってくれるらしいです
- Javaは
- slim3とかでやってくれるんじゃないの？
- 500位で区切ってたと思う
- 昔はそれ超えるとエラーになってたから
- AppStats使うとパフォーマンスは遅くなるの？
- 特定のRPCのみに対応しているので、遅くなるのは少ないよ
- Blogに書いてあるから
- デベロッパーが使う時だけ、AppStatsをかますようにしています
- キーは一位じゃないらしいですが、本当？
- EntityGroup内では一位ですよ。
- キーを削除した場合に、再利用されるケースはありますか？
- 微妙です
- データストアの仕組みとして、Keyの辞書順でソートされているので、一箇所に溜まってしまうことがあるので
- 採番は自分でやったほうがいいです。
- データストアチームでは、自動採番を実装中です。
- 将来的には新しいAPIを呼べばいいようになると思います。
- WebApp2のキーがNumericキーだったけど、大丈夫ですか？
- 聞き取れませんでした
- webapp2はこれのことなのかな？ → [Welcome to webapp2! — webapp2 v2.5.1 documentation
Google Compute Engine 最新動向と App Engine 連携
- 目次
- Google Compute Engineについて
- Google I/O 2012からのアップデート
- App Engineとの連携について
- Google Compute Engine
- アクセス方法
- プロジェクト
- VMはLinuxです
- Rootアクセスしてなんでも出来ます
- Modern CPUで1, 2, 4, 8を選べるし、メモリも選べる
- ネットワークは、2つ分類されている
- PrivateネットワークとInternetにつながるネットワーク。設定次第で、どこにつながるか設定出来る
- Privateの場合、Compute Engine内のDNSに名前をつけているので、インスタンス名でアクセス出来る
- Storageは、PersitentDisk、LoclaDisk、CloudStorageがある。
- Persistent：永続化される
- Ephemeral：テンプで消える、ここに保存するといつかなくなるよ
- または、App Engine Datastoreなどを使ったり色々出来る
- デモ
- App EngineからCompute Engineの立ち上げをするもの
- ソースコードもオンラインにある
- Google I/O 2012からのアップデート
- 変わってないこと、Limited Previewのまま
- 最初はCPUとメモリの割り当てが固定でした
- しかしながら、ソフトウェアによっては、何を使うかが違うので、色々なタイプが選べるようになりました
- テンポラリストレージがないものもあります
- IPアドレスをつなぎ替えることが出来るようにもなりました
- アプリのバージョンアップの時に使えそうです
- Read Only Persistent Disk
- 書き込みは1つのものにしかつながらないけれども、読むだけのものであれば、いくつでもつなげることが出来ました
- データを準備してから、他のマシンにつなげたり
- 両方一変にはできません。ReadOnlyかRewirteかどちらかしか使えません。
- Diskのスナップショットも可能です。5Gしか使ってなければ5Gしか消費しない
- Better Command Line Scripting
- And それ以外もあるよ
- インスタンスのクローンが出来る
- ヨーロッパのゾーンが出来た。アメリカとヨーロッパ
- ComputeEngine と AppEngine
- インスタンスを落とし忘れてしまうことがある
- 特別なインスタンス以外は自動的に落としてしまうようなアプリケーション
- Timeout Sample
- AppEngine
- ComputeEngine
- 普通に立ち上がっているだけ
- OAuth2 Auth
- ユーザが使っている場合はOK、クーロンジョブの場合は、ユーザは居ない
- 自分のアプリケーションだけ
- でも、誰でも消せたら困るので、AppEngineの管理ユーザを作って、設定しておく
- ComputeEngineのインスタンスにタグをつけて、落としてはいけないタグをは消せないようにしておけばいい
- REST APIにプロジェクト名を入れるだけで、一覧が取得することが出来ます
- cronのコードでは、Expiredだったら落とす
- QA
- ゾーンにアジアは追加されますか？
- IssueTrackerに星をつけてください。
- ドキュメントにあるらしいです。Starなりメールなりしましょう。
- ハードウェア障害になったらどうなるの？
- Terminateのステータスになります
- そのままですので、ご自分で立ち上げてください
- コントロールするソフトが必要になります
- 自分で書くか、ライブラリを使うかしましょう
- LifeScale？経由で色々出来るらしいです
- オーケストレーション？のソフトウェア
- HTTPのリクエストはAppEngineで、バックエンドはComputeEngineでやるのがおすすめかもしれない
- Linuxのディストリビューションは選べるの？
- TaskQuereの連携以外は？
- ComputeEngineからDatastoreの操作は出来るの？
- 今はAppEngineのAPIをそのまま呼び出すことはできません。
- HTTPのリクエスト経由で操作するように、作ってください。
- 自分のアプリでやる方法と、EndPointsを使ってAPIとして公開する方法があります
- JavaScriptやモバイル以外からも呼び出せるので、それでやる方法もあります
- AppEngineとComputeEngineのゾーンの組み合わせは？
- Persistentディスクの種類は選べるの？
- SSDとか選べるの？
- 特に選べないようです
- WebApplicationはAppEngine一択なの？
- ComputeEngineとしては、特におすすめはしていないようです
- アーキテクチャが合致するのであれば、別にWebアプリを作るのも問題ないです
- 計画停止があるので、ご自分でIPの付け替えをするなどしてください
- 無料枠あるの
- 今はないです
- Limited Previewは時間帯によって無料で使えたりするらしい
- Amazon EC2との差別化は？
- 1台のハードウェアを複数のインスタンスで共有していると思うけど、1つのインスタンスが高負荷状態になると影響あるの？
- あんまり影響ないようにがんばってるよ
- 昨日エンジニアがテストしてたけどね。
- VMはなんなの？
- ゾーンにアジアは追加されますか？
Google API Expertが解説する Google App Engine for Java実践ガイド
- 作者: 小川信一
- 出版社/メーカー: インプレスジャパン
- 発売日: 2012/03/16
- メディア: 大型本
- クリック: 12回
- この商品を含むブログ (14件) を見る
