というわけで、メモです。
ゲスト Googleアジア・パシフィックの方
Appengineへこれまでの投資や利用ありがとうございます。皆さんの貢献ありがとうございます。これからの継続的な発展を期待しています。
アジア・パシフィックは日本での成功に依存しています。アジア・パシフィックでは、年度内に3つのデータセンターを作ろうとしていて、さらにサポートも強化していきます。
Google Cloud Support Services — Google Cloud Platform
ゲスト Google法人営業の方
昨年から、Google Cloud Platformの営業活動を始めている。日本は2名体制となっています。
サポートのパッケージがグローバルで変更になりましたので、アナウンスします。
オンラインサインアップで、クレジットカードで申し込めます。今は、フォーラムでのQAがメインです。
もう一つの契約形態で、契約書ベースのものもあります。カスタマーサポート部隊でサポートします。
今までは日中時間帯のみでしたが、いつでもよくなりました。
- 契約は4段階
- ブロンズ：無償のフォーラム形式のみ
- シルバー、ゴールド、プラチナが有料
- 昨年までは1つでした。シルバーサポート同等で、月額500ドルでGoogle App Engineで、他プロダクト毎に＋α
- 今回、法人ごとに1契約で済むようになりました。
- 今までと同じ内容よければ、シルバーサポートで、月額150ドル
- ゴールドは、24時間365日
- 電話は英語になる
- ポータルでは英語だけど、日本語書いてもOK
- プラチナは、完全にカスタマイズなサポート
- エンジニアを1人貼り付けるとかそういうこと
- Google Compute Engineが誰でも使えるようになったが、Goldサポートがないとダメ
セッション1：「Google Cloud Endpointsを使って作るJS/Android/iOS対応Webバックエンド」「BigQueryの大規模JOINとGROUP BY」
資料 → appengine ja night #24 Google Cloud Endpoints and BigQuery
Google Cloud Endpoints
- 概要
- AppEngineをクライアントアプリのバックエンドとしてより簡単に使えるようにするもの
- クライアントーサーバで連携する場合
- Android、iOS、JavaScriptのクライアントライブラリを作成可能
- OAuth2.0認証をサポートしている
- Google App Engineで動いているので、Datastoreなど各種Serviceを利用することが出来る
- APIエクスプローラで実行可能
- Google APIs Discovery Serviceに準拠しているため
- Endpointsで生成したクライアントライブラリは準拠するので使うことが出来る
- OAuth2での認証した状態でのAPI実行も可能
- 実装手順
- クライアントの実装
- OAuth2認証
- APIConsoleでClinetIDを作成
- クライアントの種類ごとに作成
- Androidの場合は、Audienceの定義も必要
- APIメソッドの引数に、User userを付け加える
- 認証していない時にはUserがnullになるので、nullかどうかで判断する
- クライアントJavaScript
- CLIENT_IDを設定して、SCOPEを設定
- SCOPEとしてuserinfo.emailが必要
- load関数でoauthを読み込んでサインインする
- Androidの場合もサンプルどおりでOK
- GoogleAccountCredentioanが必要。
- アカウント取得用のPicker経由でアカウントを取得して、認証する。
- OAuth2での開発での注意点
- APIエクスプローラからと、JavaScriptやAndroidからとで、サーバ側の挙動が異なる場合がある
- User型のデータから取得出来る項目に差異がある
- ID TOKENと、ACCESS TOKENでのアクセスとで違うから
- 本日リリースされた最新版でも治っていなかった
- APIConsoleでClinetIDを作成
- 資料一覧
BigQueryのBigJoin
- BigQuery
- テラバイトクラスのデータを扱えるようにする
- SQLライクなクエリが出来る
- 今までは、JOINする対象のテーブルに制限があったが、BigJoinによって制限がなくなった
- GROUP BYも同様
- GROUP BY → GROUP EACH BYにするだけ
- 以前より制限が緩和されました
- 一応、ドキュメント上は制限がなくなったとはありましたが、大きいデータで、エラーが発生したり、帰って来なかったりします
- 限界がどこにあるかはわかりませんが、お金がかかるので検証出来ていません
- 参考資料
QA
- Google Cloud Endpoints
- BigQuery
- 常にEACHをつけたら？
- EACHを付けない方が速度は早いです
- サブクエリでGROUP BYするとエラーになるのですが
- 小さいサブセットでやってみてください
- 必ずエラーになるのであればIssueを登録します
- 結果が大きいとエラーになるので、それが原因の可能性もある
- 常にEACHをつけたら？
セッション2 「Datastoreへのアクセスを楽してMemcacheアクセスに置き換えるライブラリ作った in GAE/J」
資料 → Datastoreへのアクセスを楽してMemcacheアクセスに置き換えるライブラリ作った
- Google App Engine Datastore
- お金がかかる
- Datastoreに対するREAD、WRITEの回数に応じて課金される
- 1回Entityをputすると、Entity本体の他に、Indexを更新する
- Memcacheを使ってREAD回数を減らす
- 通常は、Memcacheにデータがあればそれを使い、なければDatastoreから取得する
- put時には、Memcacheから削除するなどする
- Queryを保持している場合、Memcacheからデータをクリアしてあげなければ、更新時に正しくなくなる
- がんばって実装して、正しい状態を保たなければならない
- 一箇所にデータアクセスを纏めなければ、バグの温床になる
- Memcacheを使えば、安くなるけど、複雑になる
- お金がかかる
- Memvache（めむばっしゅ）
- データストアへのアクセスを書き換えてMemcacheを使う
- Memcacheを使っていないコードはそのままでOK
- 仕組み
- 通常の流れは次の通り
- Request→AppServer→RPC→Datastore
- RPCの裏で流れているデータをフックして、実装している
- ProtcolBufferでSerializeなどをやっている。
- ApiProxyのgetDelegate, setDelegateで書き換えている
- getDelegateを書き換えている
- 通常の流れは次の通り
- Memvache
- Strategyを組み合わせている
- PutとGetでMemcacheに置き換える場合
- GetPutCacheStrategy
- Txが効いている場合は素通りになる
- QueryをMemcacheに置き換える場合
- QueryKeysOnlyStrategy
- 自動的に、KeysOnlyに書き換える
- Keyをゲットしたら、BatchGetを実行する
- EventualなEntityをとれる問題も回避出来ます
- 少なくとも、古いデータではない
- ただし、正しい検索結果には必ずしもならない
- Queryをまるごと自動でキャッシュする
- AggressiveQueryCacheStorategy
- Kindが更新されたら、カウントをインクリメントする
- キャッシュ自体は消さない
- 導入方法
- 自作のStorategyを作る
- Storategyを実装して、preProcessとpostProcessを実装する
- 自作のFilterを作らないといけない
- RpcVisitor もあり、フックすることが可能
- AggressiceQueryCacheStrategy
- 設定ファイルを書く
- 期間と、無視するKindを設定する
- ただし、今後変更する可能性もあります。
- 問題点
- GAE活用事例
- TopGate社の場合
- Android 3〜4割
- GAE 2〜3割
- GAE + Google Apps 2〜3割
- GAE + AWS 1割 （ファイルをあつかうもの）
- 今後は、GAE＋GCEになるかも
- 製品
- SmartBiz＋
- Chienoki 社内ナレッジベース的なもの GAE＋Appsを利用
- Memvache
- 2案件、まだリリースしていない
- 個人での利用はあり
- TopGate社の場合
- その他
- QA
- データストア以外を触るは？URLFetchとか
- Memcache以外は今のところ考えていませんでした
- おれおれStorategyで実装すればいけると思う
- ライセンスは？
- Apache2 です。
- ダッシュボードから触る場合は？
- 開発環境では、Filterが適応されるので大丈夫かもしれません
- プロダクション環境では、Flushしてください
- 効果は？
- 計測はしていない
- ケースバイケース
- ちゃんと使えば9割くらいだと思う
- PUTが多いアプリだと恩恵が少ない
- LocalCacheについては？
- static変数で保持するのもStorategyで作れる？
- 作れるとおもう
- データストア以外を触るは？URLFetchとか
BeerTalk（懇親会）
BeerTalk1：「Google App Engineを使って仕事をするということ」
- 仕事で使うメリット
- 開発環境をすぐに構築できる
- 複製も出来る、○○環境用
- 環境構築しなくてよい
- 運用費の見積はむずかしい
- システム管理者の管理が簡単
- ログインも簡単、Google Account
- 苦労
- Kind設計
- 60秒制限が、業務用では厳しい場合もある
- 他システムとの連携で相手側のIP制限が出来ない
- ログの保存が大変
- 業務アプリの特徴
- CPU利用率で・・・20%しかつかっていない
- ただし、データ量が結構多い
- マスタ件数が25万件とか
- 月1で全量更新
- マスタ件数10万件で、毎日全量更新
- 小さい規模の会社でもサーバとかいらないから色々出来る
- GA使用料
- 114アプリで、100ドル+サポート500ドル
- 検証
- 検証してほしいもの募集です
- QA
- 見積はどうしてるの？
- READ/WRITEの量、
- Indexの貼り方で変わるけどノウハウ
- アプリ保守料という形でやってます。とは言え、実績はまだまだです。
- 整合性
- EntityGroupは使っていない
- あんまりシビアな状態はない
- 数万人規模であれば、そんなでもない
- 業務アプリの場合は、夜間に止めるなど出来るので大丈夫
- 年末に不安定になることは？
- 今のところ３０分程度で復旧するので、問題無さそう
- 見積はどうしてるの？
BeerTalk2：「Dig・基幹系でAppEngineを掘る」
資料 → Ajn24
- 基幹系でAppEngine
- ジャーナルエントリーが発生するものです
- Cloud First
- Offline First
- Offlineでの操作をする。
- 日本以外では、Offlineが圧倒的に早い。
- Mobile First
- 基幹系
- CloudSQLはDatastoreに比べて遅い
- Memcacheの方が圧倒的に早い
- とは言え、Client側で図ると、あんまり変わらない
- ネットワークレイテンシーの方が桁違いかかるから
- あんまり差は感じられない。サーバがアメリカにあるから。
- なので、日本に作って欲しい
- WebStorageの方が圧倒的に早い
- 在庫管理とはのトランザクションは？
- アナログと組み合わさった業務なので大丈夫
- 現物を見ながら、やりますよ。
- アナログと組み合わさった業務なので大丈夫
- Cloud+UX技術(?)と言う本で今書いている内容です
Google API Expertが解説する Google App Engine for Java実践ガイド
- 作者: 小川信一
- 出版社/メーカー: インプレスジャパン
- 発売日: 2012/03/16
- メディア: 大型本
- クリック: 12回
- この商品を含むブログ (14件) を見る
