@thorikiriのてょりっき

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

appengine ja night #25 #ajn25 に行ってきました

会場についたらすでにピザが用意してあってビックリしました。
というわけで、メモです。PC忘れて行ったので、手書きの書き起こし。つらい。

App Engine の新機能の話 & Peter と話そう!

資料 → あるのかな?
App Engineの現状と、課題と、その解決のお話。すでに公開している情報も含まれています。

  • App Engine
    • 開発者がインフラを気にせずに開発できるようにしている
    • アプリやロジックに注力できる
    • 今まで順調にユーザが増えてきている
    • しかしながら、まだまだやらなくてはならないことが沢山ある
  • 現状
    • Versionが複数あり、複数インスタンスが立ち上がる
    • Memcacheを使ったりもしている
    • バックエンドで動く機能や、データ解析をするような機能もある
    • Task QueueやBlob Storeなども使われている
    • ビジネスが成功すると、複数のアプリを使うことになる
      • 特性の違う機能でも同じ設定しかできなかったり
      • データを共有することが難しかったりする
  • 課題
    • DatastoreはApp Engineでしか使うことができない
    • Memcacheは1アプリでのみキャッシュが有効
      • Youtubeなどとも共有のものである
    • 規模が大きくなることの課題
      • Task Queueが滞ったり、タスクが消えたりしてしまう
      • Blob Store、Cloud Storageがバラバラ
  • 現在の取り組み
    • App Engine Modules
      • アプリを複数コンポーネントに分割する
      • それぞれをバラバラに取り扱うことができる
      • それぞれのコンポーネントにスケーラビリティ、予算の設定ができるようになる
      • ただし、Storageについては共有することになる
      • ひとつは、信頼性の高い、応答速度を求められるような機能で沢山のインスタンスを必要とする
      • もうひとつは、時間がかかる処理であるが、応答速度はそんなに求められない
      • これまでは、ひとつのアプリケーションで2つを両立していたために、高いインスタンスを沢山使う必要があった
      • App Engine Modulesでは、それぞれに対して、設定ができるので、コストを下げることができる
      • 開発チームの効率化も出来る
    • Dedicated Memcache
      • 今までのMemcacheと異なり、アプリ専用のMemcache領域を持つことが出来る
      • 必要であれば、容量は増やせる。
      • 2TB利用している顧客もいる。
      • 専用領域なので、長期間保持したい場合にも利用することが出来る
      • 今までは、共有していたため、すぐに消えていた
    • Blob StoreはCloud Storageに
      • 多くの場合には、Blob StoreよりもCloud Storageを利用したほうがよい
    • PHPもサポート
    • App EngineとCompute Engineの融合
      • 2つの方法を行っている
      • 1つはApp EngineとCompute Engineの通信を高速化するということ
      • そのために、データセンターを同じところに移した
      • App EngineとEC2に分けてやっていたことを、Google Cloud Platform1つで出来るようになった
      • もうひとつは、VMランタイム
      • App EngineによりカスタムしたVMである
      • 既存のApp Engineアプリをデプロイするだけでよく、Compute Engine上で動かすことが出来る
      • コードはそのままで、設定を1行変更するだけでよい
      • 他のバイナリ(アプリ)も動かすことが出来る
    • Task Queue
      • パフォーマンスと信頼性の向上
      • 使われ方が想定外で、思った以上に使われている
      • cronの代わりと想定していたが、1秒に5000のタスクが作られるとは・・・
    • DatasotoreをREST APIで公開
      • App EngineとEC2でDatastoreを共有することが出来るようになる
      • Hadoop用のプラグインを作った
      • Cloud Storageで動かすことが出来る
    • Cloud Playground
    • App EngineにVMが追加
      • Runでプロジェクトを実行
      • デプロイをブラウザ上で行うことが出来る
      • Compute Engineだが、App Engineで管理されている
      • どんな言語でもOK
      • App Engineで次にどの言語がサポートされるの?と言う疑問には、すべての言語と言うことが出来る
  • QA
    • Google モデレーター
    • アジアのデータセンターは年内に出来る?
      • No データセンターが複数無いと、分散することが出来ないので年内ではない
      • 複数エリアで作らないといけない。
      • たとえ、1つの国が無くなっても大丈夫なように作っているところです
      • 静的コンテンツに関しては、Edge-Cachingサーバが日本にある
    • Play Groundは自分の作ったものが他の人にコピーされるの?
      • Yes 引き回していきます
    • Python3は?
      • 予定はあるが、時期は未定
    • Cloud StorageとGoogle Appsとの連携は?
      • 今言えることはないです
    • Search ServiceのIndexの見積はどうやるの?
      • 確認します
    • Memcacheの1M制限について
      • 確認します。
      • Cloud Storageでどうにかなるかな?
    • Java Servlet3
      • VMランタイムで!
    • Blob Storeから、Cloud Storageに移行するとURLが変わってしまう?
      • エンジニアに確認しないとなんとも
      • スマホアプリでURLを使っているけど、リダイレクトとかどうなるのか知りたい
      • アプリのバージョンアップを必ずしてくれるわけではないので・・・
    • Backendsの問題
      • VMに置き換えられます。
      • ただし、7日間に1回はリスタートします
      • Backendsは残して欲しいとのリクエストもあるので、移行ではなく、機能追加かも?
    • Backendsのログが最後しか出ない
      • んー・・・
    • ステートフルにするような、sticky sessionをサポートする?
      • スケーラビリティがApp Engineの哲学です。App Engine道です。
      • スケーラビリティが中程度でよければ、Compute Engineを利用してください
      • 最近の傾向としては、クライアントサイドで状態を持ち、サーバ側はステートレスが良いでしょう

Android アプリのガチ開発者が Mobile Backend Starter を使ってみた

資料 → 「Android アプリのガチ開 発者が Mobile Backend Starter を使ってみた」

  • Mobile Backend Starterとは?
  • メリット
    • サーバ側のコードを書かなくて良い
      • アプリ開発者でサーバ側を知らない人とかには非常に嬉しい
    • スケーラビリティが高い
    • 認証の機能がある
    • GCM(Google Cloud Messaging)の機能が組み込まれている
  • 使い方
  • 使い道
    • メッセージング
    • データ永続化
    • クラッシュログ
    • センサーなどのログ
  • GCM
    • アプリ ⇔ Google Playアプリ ⇔ Google Playサーバ ⇔ サードパーティサーバ
    • サードパーティサーバが必要で、GCMを送信する機能を作らないといけない
    • pushする
      • 同期のトリガーや、チャット、SNSなど。
      • お知らせ、アプリの状態を同期
      • 位置情報の共有など
    • オフライン対応必須
      • デバイスのDBにもデータを持つ
      • Backup Agentと言うバックアップ機能がある
      • 同期が面倒でコンフリクトにも対応しなければならない
    • クラッシュログ
      • 自前のクラッシュログ機能を入れる人向け
      • 既存の提供されている機能は、動作しなかったり、ユーザが送信してくれるとは限らない
      • α版、β版など
    • センサーデータの収集
      • 歩いている、走っているの情報など
      • 定点カメラ的に、定期的に写真をアップするものなど
    • アプリ内課金の検証
      • アプリの公開鍵をサーバ側に持たせる
      • セキュアなハンドシェイク
    • 複雑なものは出来ない
  • Client Library
    • Androidアプリ用のSDKやライブラリを作るときに抑えておきたいこと
    • SDKやライブラリを使ったサンプルアプリは作りましょう
    • 広く使って欲しい人には必要です
    • サンプルとライブラリをバンドルしないようにしましょう
      • Androidに依存しないものは、jarファイルにする
      • Androidに依存するものは、Android Library Projectとして提供する
      • リソースIDには注意する必要があるので、プレフィックスをつけるなどする
      • ActionBar Sherlockが参考になる → ActionBarSherlock - Home
    • build pathには注意すること
    • 画面の回転には注意すること
  • まとめ
    • サーバを書かずにGCMが使えて便利
    • 1分もかからずにpush通知が来て便利

Google App Engine for PHP

資料 → appengine ja night #25 Google App Engine for PHP

  • Google App Engine for PHP概要
    • まだLimited Previewです。GAE/PHPがどうこうと言うより、現状はこうですと言う内容。
    • PHP 5.4.8
    • MySQL互換のCloud SQLを利用する
    • DatastoreはAPIを利用して使う
  • Google I/O後のアップデート
    • mbstringが使えなかったが、使えるようになった
    • mcript、iconvも追加された
      • Issue Trackerの報告を元に使いされているので、追加すれば入れてくれるかも?
    • Cloud Storageに置いたPHPファイルも動かすことが出来る
      • ただし、遅くなる
      • require "gs://mybacket/file.php"; // のように書くと読み込まれる
  • IDEについて
  • 既存アプリ
  • 気をつける点、制限
    • ローカルファイルが使えないのでCloud Storageを利用する
    • $_FILEが使えないので、Cloud Storageに対してアップロードするようにする
    • ファイルシステムに対するI/O
      • バグがある、存在チェックとか
      • realpathをサポートしていない、必ずファイルが見つからないと返される
      • ファイルアップロード、ログ出力なども注意
    • セッション管理
      • Memcacheのみで、制限がある
      • Session Handlerで、Cloud SQLに書き出すことも検討
    • メール
      • 標準のAPIは利用できない
      • MailServiceを使うように書き換える必要がある
    • 拡張モジュール
      • 入っていない拡張モジュールがあるかもしれない
  • フレームワーク
    • 一時ファイルを書き込まない
    • ログはSysログに書き出す
    • CakePHP
    • CakeMail
      • そのままでは駄目
      • MailServiceを使うように書き換えて、設定で変更しなければならなかった
      • 添付ファイルの送信も出来なかった
  • まとめ
    • アプリのポータビリティはそこそこあった。フレームワークも使えた。
    • 一部機能が透過的に動くようになればいいのに
      • メールとか、ファイルとか
    • スケーラビリティ
      • Datastoreも使えればいいのに

Google App EngineGoogle Apps API

資料 → 2013-07-16 ajn - Google スライド

  • File APIとGCS Serviceについて
    • File API
      • 非推奨になりました
      • 1年くらいで使えなくなると思われる
      • 問題があってもサポートされないので、なるべく早く切り替えたほうが良さそう
    • GCS Service
      • pom.xmlに追加する
      • 依存ライブラリは、guavaだけなので、本体と、guavaのjarを追加するだけでも良さそう
      • API自体はFile APIと似ているので、置き換えは容易
  • 問題点
    • Cloud StorageはAPI Console Projectから
    • ただし、組織ドメインのアドレスしか追加できない
    • 対応1
    • 対応2
      • GAE Service Accountを追加したGoogle Groupを作成し、API Console ProjectにTeam Memberとして追加する
      • 特に知識無くても出来るので、敷居が低い
  • Cloud Console と Cloud Integration
    • Cloud Console
      • API Console Project, GAE Projectを連携した状態でプロジェクトを作成可能
    • Cloud Integration
      • GAEと連携した状態のAPI Console Projectを作ってくれる

何やかんやあって・・・

    • Cloud Console と Cloud Integrationを使うと、問題点が解決できると思ったが、そうはならなかった。
    • しかも、容易なはずの、対応2が出来なくなった。
  • まとめ
    • Google Apps向けのアプリを作っている人は
      • Cloud Console、Cloud Integrationの利用は、とりあえずは見送ったほうが良い
追記
  • Dedicated MemcacheをDelegated Memcacheと勘違いして書いていたのを指摘いただいたので修正しました。
  • GAE/PHPの内容で発表者の@vierjpさんから指摘いただいたので修正しました。