- appengine ja night #22 on Zusaar
- appengine ja night #22 まとめ - Togetterまとめ
- 前回のメモ → appengine ja night #ajn21 に行ってきました - @thorikiriのてょりっき
Google Cloud Platformの海外エンタープライズ事例紹介
- Google エンタープライズ
- エンタープライズ クラウドプラットフォーム のサービス
- プレミアムサポート
- 請求書払い
- 日本語サポートなど
- 事例
- The Royal Wedding
- http://www.officialroyalwedding2011.org/
- 去年
- 4週間で作った
- イベントのサイトなので、終わったらピークは過ぎたけど、今でもほそぼそとやっている。
- 秒間最大2000リクエスト
- 1日辺り560万人
- MessagesForJapan.com
- Messages for Japan - Home
- 震災のあと、1ヶ月で立ち上げた
- 世界中から日本に対してのメッセージを投稿する。
- Translate APIで翻訳。
- 世界中の言語で書き込みされて、日本語で見ることが出来る。
- Approvals Workflow Automation
- 既存のシステムとの連携をやった事例
- GoogleAppsをベースにして、ワークフローのアプリケーションを作った。
- GoogleAppsをベースにして、拡張をした。既存システムとも連携する。
- SharePointとか、SqlServerとか。
- 4半期に一度しかアップデート出来なかった。バッチ処理だったから？
- Webサービスとして連携する。
- スケーラビリティと信頼性、スケジュール実行。
- 結果、日次で出来る、インフラコスト、運用管理費の削減が出来るようになった。
- Clothes for Smile ユニクロ
- Clothes for Smiles (UNIQLO)
- 売上金の一部を子供の為に使おうのプロジェクト。
- ソーシャルなアプリで世界中の人が書き込みします。
- 英語や、中国語であればなんとなくわかる書き込みでも、その他の言語だとわからないのでGoogle Translate APIでなんとなくわかるようになっています。
- AKB48 総選挙
- ピーク時に24000qpsくらい。
- サイトはダウンしていない。
- GoogleAppEngineの特性を生かしている
- Applibot
- 後ほど
- Streak
- Appsを拡張したものです。
- Cloud Platform盛りだくさんでやっている。全部入り。
- The Royal Wedding
- まとめ
- Google Cloud Computing, Hosting Services & Cloud Support — Google Cloud Platform
- こちらを参考にしていただいてよろしくお願いします。
世界有数規模のApp Engine事例の開発ノウハウとBigQueryによるログ解析
- 株式会社アプリボット
- ソーシャルゲームとか
- 1日1億リクエストをAppEngineでさばいている
- クラウドストレージにバックアップを突っ込んだりとかしている。
- objectify-appengine - The simplest convenient interface to the Google App Engine datastore - Google Project Hosting
- ソーシャルゲームとか
- 大きいアプリの話です
- 190MBのでかいアプリケーション。
- DeadlineExceededException
- 1リクエストが60秒かかると発生する。スピンアップで発生することがある。
- 発生する、サーバが死ぬので、再起動とかなる。
- スピンアップで発生すると無限ループ状態になってしまう。
- loading request はdynamic インスタンスでも発生する。
- Springは重厚なので、良くない。
- Slim3にすれば、あまり起きなくなった。
- でも、起きることは起きる。
- Googleさんに色々対応してもらった。
- DataStoreの件数処理
- ゲームのランキング処理。
- KeyFetchが件数に比例して時間がかかる。
- 想定数を考えないとダメです。
- ShardCounterとかする。
- 裏で順番にナンバリングする。
- MeｍCacheをカウンターにすればいいかなぁ〜とか言うところがあります。
- ランキングはゲームでのキモなので、いいかも。
- 過去のappengine ja nightで順位の話があった
- たぶんこれ → Skiplists20100604
- Index遅延
- プット直後は、Queryに引っかからないことがある。
- デプロイ問題
- 10000ファイル制限
- カードゲームのデータ。1枚のカードでも表示場所などによって数種類の画像ファイルがある。
- 今では、CloudFrontに置いている。
- EdgeCachingも考慮してみましょう。
- JSP
- Slim3
- リクエスト毎にControllerを作っていた
- ある程度をまとめるようにする。
- デプロイ
- ビルド失敗
- アップロードのシェルのメモリを増やした。
- AppEngineのアクセスログ
- すぐに流れてしまう
- macheを試しました。
- たまに溢れることがあるらしい。
- log2bq
- 改良
- 違うバージョンのログを取ってくる。
- CloudStorage経由でBigQueryで解析する。
- クラッシュログを解析する。
- ユーザをキーにすれば、どういう経路で発生したのかがわかる。
- わざわざ、解析用のインフラとか人員を配置しなくても良くなる。
- 今は、エンジニアしか使っていないけど、マイニングチームにも使ってもらいたい。
- Googleでも、エンジニアだけではなく、アナリストとかも使っている。
- 解決までの道のり
- エンタープライズサポートに入ろう
- 英語だけど、日本語もOKです。
- タイトルとサマリーは英語、細かいニュアンスは日本語で。
- 緊急の時は英語で。
Google Cloud Endpointsでかなりラクするモバイルアプリ開発
blog → スティルハウスの書庫
Cloud Endpoints → Google Cloud Endpoints for Trusted Testers
- 背景
- じゃあ、どうするの？
- 結局は、RPCが出来れば良い。
- foo.save(blogpost)
- って出来れば、登録されていてくれればいいだけなのにね。
- 今時はこれさえあればいいよね。
- そこで、Cloud Endpoints
- ユーザ認証の決定打はなかった。
- Androidアプリの認証。
- WebViewでのURL。
- Intentで投げてブラウザで認証してもらって、アプリに戻る。
- 結構難しくて面倒くさい。
- 最近話題になってたよね → OAuthの認証にWebViewを使うのはやめよう - Shogo's Blog
- 今はGoogle OAuthを推奨しているよ
- Endpointsであれば、Googleアカウントで認証する場合、認証のコードを描く必要はない
- Androidアプリの認証。
- 出来ること
- Endopoints
- Google IOのスライドなど参照。
- まもなく、プロダクションで使えるかもしれないかもしれないかもしれない！！
- Google IOのスライドなど参照。
- Blog APIを作る
- postArticle(String message)を作る
- Eclipse Google Plugin for Eclipseで出来ます。
- API Consoleで、ClientIDを作る
- Androidプロジェクトを作る。
- 必ず作らないといけないわけではないよ。
- Androidを先に作っておくと便利。
- Google App Engine Backend を作成する。
- ビジネスロジックを書いていく。
- 実装
- クライアントライブラリの生成
- あとは、Android側でクライアント側のコードを書く。
- サーバ側をデプロイする。
- Google APIs Exploerでテストする。
- Google APIs Explorer
- 自分で定義したAPIをテストすることが出来る。
- 実際にクライアント側の実装をする前に、テストすることが出来る
- 資料
- 今後
- GoogleComputeEngineのものも呼び出せるようになるかもしれない
- 関連
Beer Talk
VPSとGCSとGAEをハイブリッドで使う事例 〜GAEは目立たないぐらいがちょうどいい〜
資料 → Gaeja20121130
blog → ぶいてく: ajn22のBTで発表してきました
- PDF検索サービス
- Cloud Storage
- 早くて信頼性高い、そして無限。
- GoogleDriveと比較すると、ものすごく早い。
- GoogleDriveにPDFに大量格納をした実験
- 登録に数ヶ月かかってしまっていた。
- CloudStorageでは1ヶ月ですんだ。
- Drive側で、速度制限があると思われる
- 2つの技術要素について
- ReflexWorks
- AppEngineはCPU使うのは苦手
- AppEngineはデータを格納して、クライアントで見せる。
- 仮想フォルダ管理をしていて、URLが階層構造である。
- これに対して、RESTのAPIを付けている。
- 仮想フォルダに対して、アクセス制限をつけることが出来る。
- 更新された場合には、リアルタイムに通信して通知している。
- WebSocketによる通知
- 接続情報をセッションで管理している。
- フォルダ共通でかつ、ログイン中の人のみに通知する。
- Open、Message、Close
- WebSocketのOpen時に認証もするようにしている。
- ただし、ウィルス対策ソフトに切断されるケースがある
- 時々ポーリングするようにしている。
- HTTPSだと大丈夫かも知れない。
- 本当はPollingしない方が良い。WebSocketだと負荷が少ないけど、Pollingは。。。
- 気を付けないといけないのは、サーバ負荷
- 基本的には、ステートレスに近い感じに実装する
- サーバが動いていなくても、動くように実装する
- ReflexWorks
- OAuth2
- その他のクライアント技術について
- Thin Server Architecture
- サーバサイドのテンプレ技術は使わない。JSONを返す。
- 70％の負荷を低減できる・・・らしい。
- SlickGrid
- mleibman/SlickGrid · GitHub
- jQueryプラグイン
- 数万件レコードでも高速にグリッド表示出来る
- LocalStorage
- 栞の情報を保存しておく
- Thin Server Architecture
NEWSTRAINERのご紹介
- NEWSTRAINER
- RSSリーダー
- 例
- 記事の分類
- 機械学習について
- ベイジアンフィルタ
- ニューラルネットワーク
- 決定木学習
- ベイジアンフィルタ
- 学習データが多いほど良い、誤りはユーザが教育（手動で）する必要がある。
- 教育コストは反比例的になる。
- スパムフィルタなどで利用されている。
- 分類型の場合の学習は、成功しない場合を想定しないといけない。
- 人工ニューラルネットワーク
- 人間の脳や神経の仕組みをシミュレートする
- 学習データ量が小さくして保存しやすい
- 反面、出力から入力をたどることが出来ないので、デバッグしにくい。
- 決定木学習
- 根から葉までたどるように枝をたどる
- 構造が理解しやすくてデバッグしやすい
- データが大量に必要
- 問題点
- 膨大な計算量と学習データ
- 数式
- 何が何だか分からない。
- 学習データ
- スレッドプログラミング
- 使えるところではCモジュール
- 永続性が必要なデータ以外はMemcache
- 勉強方法
- 作者: Toby Segaran,當山仁健,鴨澤眞夫
- 出版社/メーカー: オライリージャパン
- 発売日: 2008/07/25
- メディア: 大型本
- 購入: 91人 クリック: 2,220回
- この商品を含むブログ (277件) を見る
- 作者: Allen B. Downey,黒川洋,黒川利明
- 出版社/メーカー: オライリージャパン
- 発売日: 2012/08/25
- メディア: 単行本（ソフトカバー）
- 購入: 8人 クリック: 491回
- この商品を含むブログ (12件) を見る
