読者です 読者をやめる 読者になる 読者になる

@thorikiriのてょりっき

@thorikiriがWebとかAndroidとかの技術ネタや本を読んだブログです

appengine ja night #24 #ajn24 に行ってきました

event appengine

というわけで、メモです。

ゲスト Googleアジア・パシフィックの方

Appengineへこれまでの投資や利用ありがとうございます。皆さんの貢献ありがとうございます。これからの継続的な発展を期待しています。
アジア・パシフィックは日本での成功に依存しています。アジア・パシフィックでは、年度内に3つのデータセンターを作ろうとしていて、さらにサポートも強化していきます。
Google Cloud Support Services — Google Cloud Platform

  • 質問
    • データセンターに東京は?
    • ヨーロッパでは選択出来るみたいだけど、選択出来るの?
      • AppEngineとComputeEngineは、EUとアメリカで選択出来る。アジア・パシフィックも同じように選択出来る。
  • Google Compute Engine
    • Google Compute Engineも使えるようになっている
    • GoldSupportに入って頂く必要がある

ゲスト 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をクライアントアプリのバックエンドとしてより簡単に使えるようにするもの
    • クライアントーサーバで連携する場合
      • Endpointsでは、通信部分が隠蔽される
      • クライアントライブラリのメソッドを呼ぶだけで、サーバのメソッドを呼び出すことが出来る
      • サーバのことを知らない人でもOK
    • AndroidiOSJavaScriptのクライアントライブラリを作成可能
    • OAuth2.0認証をサポートしている
    • Google App Engineで動いているので、Datastoreなど各種Serviceを利用することが出来る
    • APIエクスプローラで実行可能
      • Google APIs Discovery Serviceに準拠しているため
      • Endpointsで生成したクライアントライブラリは準拠するので使うことが出来る
    • OAuth2での認証した状態でのAPI実行も可能
  • 実装手順
    • 環境
    • 手順
      • プロジェクト作成
      • サーバ側実装
      • APIエクスプローラで動作確認
      • クライアントライブラリの生成
      • クライアントの実装
    • プロジェクと作成
      • Androidアプリを作る場合、クライアントとなるAndroidプロジェクトを作ってから、連携用のサーバ側プロジェクトを作ったほうが良い
      • Androidアプリが不要の場合、普通にサーバ側プロジェクトを作れば良い
    • サーバ側実装
    • 異常系の場合
      • NotFoundException
      • InternalServerErrorException
      • HTTPのステータスコードごとにある
      • 例外を自作する場合には、ServiceExceptionを継承して作る
      • アノテーションに指定した情報が、APIのなるので、命名などには気を使った方が良い
    • ポイント
      • API名は、小文字から始める
      • 戻り値として、リテラルは使えないし、EntityクラスもNG
      • 独自のDTOクラスを作る
      • リテラルを戻り値にしてもコンパイルエラー等は発生しないが、クライアントライブラリを生成する時にエラーが出る
      • ページングにはCollectionResponseをつかうと、ページング情報を保持できる。
      • HttpServletRequestなども引数にすれば使える
    • JUnit
      • Slim3をつかうと簡単です
    • APIエクスプローラでのテスト
      • 必須項目は赤字
      • プットではテキストフィールドを入力する
      • OAuthが必要で認証していない場合エラーになる
      • エクスプローラの右上のON,OFFボタンで認証する
      • 認証してからだと正常にput出来る
    • クライアントライブラリ作成
      • エラーはこのタイミングで表示される
      • Eclipseの「問題」のタブではないので注意すること
  • クライアントの実装
    • JS
      • AngularJSとの連携
      • APIの実行後のコールバックで$scope.$apply()を呼ぶ必要がある
      • エラーハンドリング
      • エラーメッセージとステータスコードを元に判断する
      • エラーはローカル環境と、サーバ環境で異なってしまっているので注意してください
      • 今後修正されるかもしれません
    • Android
      • CloudEndpointUtilsを使うと良いかもしれない
      • 例外は、GoogleJsonResponseExceptionでキャッチする
      • ステータスコードとエラーメッセージでハンドリングする
      • 通信出来ない場合は、IOExceptionが発生しますので、ハンドリングする
    • ポイント
      • 一度書き方を覚えてしまえば、通信処理とかを考える必要はない
      • Google純正のAPIと似ているので、実装の参考にすると良い
    • CloudEndpointsUtilを使う場合
      • デバッグ用の環境に接続出来る
      • 設定が必要
  • 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エクスプローラからと、JavaScriptAndroidからとで、サーバ側の挙動が異なる場合がある
      • User型のデータから取得出来る項目に差異がある
      • ID TOKENと、ACCESS TOKENでのアクセスとで違うから
      • 本日リリースされた最新版でも治っていなかった
  • 資料一覧
BigQueryのBigJoin
  • BigQuery
    • テラバイトクラスのデータを扱えるようにする
    • SQLライクなクエリが出来る
  • 今までは、JOINする対象のテーブルに制限があったが、BigJoinによって制限がなくなった
  • GROUP BYも同様
    • GROUP BY → GROUP EACH BYにするだけ
  • 以前より制限が緩和されました
    • 一応、ドキュメント上は制限がなくなったとはありましたが、大きいデータで、エラーが発生したり、帰って来なかったりします
    • 限界がどこにあるかはわかりませんが、お金がかかるので検証出来ていません
  • 参考資料
QA
  • Google Cloud Endpoints
    • テストの時に、Mockを返すには?
      • わかんないっす
    • 認証関係のテストは?
    • 生産性上がるの?メリットは?
      • 通信部分を作りこまなくて良いのがメリット
      • BaaSではなく、RPCのフレームワークと言える
      • JavaScriptAndroidiOSのクライアントライブラリがつくれるのがメリット
  • BigQuery
    • 常にEACHをつけたら?
      • EACHを付けない方が速度は早いです
    • サブクエリでGROUP BYするとエラーになるのですが
      • 小さいサブセットでやってみてください
      • 必ずエラーになるのであればIssueを登録します
      • 結果が大きいとエラーになるので、それが原因の可能性もある

セッション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を設定する
      • ただし、今後変更する可能性もあります。
  • 問題点
    • Slim3以外での利用実績がない
      • JPAとか、生のLL APIとかの実績
    • Slim3以外の環境では、バグが出る可能性があるので、何かあったら教えて下さい
    • ProjectionQueryは考慮対象外になります
    • プロジェクトの途中から導入したことはないので、気をつけて。
    • AggressiveQueryCacheStorategyの無効な理由
      • 内部的に、状態を持っているので、不用意にキャッシュ出来ないため
      • Cursorには、IDが振られていて、キャッシュしたQueryだと、IDが・・・。
      • 後で、Nextが発生するとやばい
      • Limit < PrefetchSize であればOKかもしれない
  • GAE活用事例
    • TopGate社の場合
      • Android 3〜4割
      • GAE 2〜3割
      • GAE + Google Apps 2〜3割
      • GAE + AWS 1割 (ファイルをあつかうもの)
      • 今後は、GAE+GCEになるかも
    • 製品
      • SmartBiz+
      • Chienoki 社内ナレッジベース的なもの GAE+Appsを利用
    • Memvache
      • 2案件、まだリリースしていない
      • 個人での利用はあり
  • その他
    • DatastoreV4
      • 現在は、DatastoreV3です。
    • GAE/Go正式版まだー?
    • GAE/Python
      • ndbで同様なことをやっているらしい
      • いいアイデアあったら教えて下さい
  • QA
    • データストア以外を触るは?URLFetchとか
      • Memcache以外は今のところ考えていませんでした
      • おれおれStorategyで実装すればいけると思う
    • ライセンスは?
      • Apache2 です。
    • ダッシュボードから触る場合は?
      • 開発環境では、Filterが適応されるので大丈夫かもしれません
      • プロダクション環境では、Flushしてください
    • 効果は?
      • 計測はしていない
      • ケースバイケース
      • ちゃんと使えば9割くらいだと思う
      • PUTが多いアプリだと恩恵が少ない
    • LocalCacheについては?
      • static変数で保持するのもStorategyで作れる?
      • 作れるとおもう

BeerTalk(懇親会)

BeerTalk1:「Google App Engineを使って仕事をするということ」
  • 仕事で使うメリット
    • 開発環境をすぐに構築できる
    • 複製も出来る、○○環境用
    • 環境構築しなくてよい
    • 運用費の見積はむずかしい
    • システム管理者の管理が簡単
    • ログインも簡単、Google Account
  • 苦労
    • Kind設計
    • 60秒制限が、業務用では厳しい場合もある
    • 他システムとの連携で相手側のIP制限が出来ない
    • ログの保存が大変
  • 業務アプリの特徴
    • CPU利用率で・・・20%しかつかっていない
    • ただし、データ量が結構多い
    • マスタ件数が25万件とか
      • 月1で全量更新
    • マスタ件数10万件で、毎日全量更新
    • 小さい規模の会社でもサーバとかいらないから色々出来る
  • GA使用料
    • 114アプリで、100ドル+サポート500ドル
  • 検証
    • 検証してほしいもの募集です
  • QA
    • 見積はどうしてるの?
      • READ/WRITEの量、
      • Indexの貼り方で変わるけどノウハウ
      • アプリ保守料という形でやってます。とは言え、実績はまだまだです。
    • 整合性
      • EntityGroupは使っていない
      • あんまりシビアな状態はない
      • 数万人規模であれば、そんなでもない
      • 業務アプリの場合は、夜間に止めるなど出来るので大丈夫
    • 年末に不安定になることは?
      • 今のところ30分程度で復旧するので、問題無さそう
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実践ガイド

Google API Expertが解説する Google App Engine for Java実践ガイド