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

@thorikiriのてょりっき

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

appengine ja night #22 #ajn22 に行ってきました

event appengine

Google Cloud Platformの海外エンタープライズ事例紹介

  • Google エンタープライズ
    • AppEngine
    • ComputeEngine(来年ですね)
    • CloudStorage
    • BigQuery(テラバイト級のデータを)
    • 各種API
  • エンタープライズ クラウドプラットフォーム のサービス
    • プレミアムサポート
    • 請求書払い
    • 日本語サポートなど
  • 事例
    • 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盛りだくさんでやっている。全部入り。
  • まとめ

世界有数規模のApp Engine事例の開発ノウハウとBigQueryによるログ解析

  • 株式会社アプリボット
  • 大きいアプリの話です
    • 190MBのでかいアプリケーション。
    • DeadlineExceededException
      • 1リクエストが60秒かかると発生する。スピンアップで発生することがある。
      • 発生する、サーバが死ぬので、再起動とかなる。
      • スピンアップで発生すると無限ループ状態になってしまう。
    • loading request はdynamic インスタンスでも発生する。
    • Springは重厚なので、良くない。
    • Slim3にすれば、あまり起きなくなった。
      • でも、起きることは起きる。
      • Googleさんに色々対応してもらった。
    • DataStoreの件数処理
      • ゲームのランキング処理。
      • KeyFetchが件数に比例して時間がかかる。
      • 想定数を考えないとダメです。
      • ShardCounterとかする。
      • 裏で順番にナンバリングする。
      • MemCacheをカウンターにすればいいかなぁ〜とか言うところがあります。
      • ランキングはゲームでのキモなので、いいかも。
      • 過去のappengine ja nightで順位の話があった
      • たぶんこれ → Skiplists20100604
    • Index遅延
      • プット直後は、Queryに引っかからないことがある。
    • デプロイ問題
      • 10000ファイル制限
      • カードゲームのデータ。1枚のカードでも表示場所などによって数種類の画像ファイルがある。
      • 今では、CloudFrontに置いている。
      • EdgeCachingも考慮してみましょう。
    • JSP
    • Slim3
      • リクエスト毎にControllerを作っていた
      • ある程度をまとめるようにする。
    • デプロイ
      • JSPコンパイルは1ファイル1秒かかってしまう。
      • デプロイするのに2500ファイルだと40分かかってしまう。
    • ビルド失敗
      • アップロードのシェルのメモリを増やした。
  • AppEngineのアクセスログ
    • すぐに流れてしまう
    • macheを試しました。
      • たまに溢れることがあるらしい。
    • log2bq
    • 改良
      • 違うバージョンのログを取ってくる。
    • CloudStorage経由でBigQueryで解析する。
      • クラッシュログを解析する。
      • ユーザをキーにすれば、どういう経路で発生したのかがわかる。
      • わざわざ、解析用のインフラとか人員を配置しなくても良くなる。
      • 今は、エンジニアしか使っていないけど、マイニングチームにも使ってもらいたい。
      • Googleでも、エンジニアだけではなく、アナリストとかも使っている。
  • 解決までの道のり
    • エンタープライズサポートに入ろう
    • 英語だけど、日本語もOKです。
      • タイトルとサマリーは英語、細かいニュアンスは日本語で。
    • 緊急の時は英語で。

Google Cloud Endpointsでかなりラクするモバイルアプリ開発

blog → スティルハウスの書庫
Cloud Endpoints → Google Cloud Endpoints for Trusted Testers

  • 背景
    • 今時ははスマホだったり、HTML5バリバリであるのが主流になっている。
    • 少し前はフロントエンドにFlexを使って作ってたりする。
    • そうなると、クライアントでロジックを書く。サーバサイドの処理は単純になる。
      • データ出し入れとか、認証とか。
    • Backbone.jsとか、Anguler.jsとかはクライアントMVCを使う。
    • サーバ側はRESTなAPIを提供する。
  • じゃあ、どうするの?
    • RESTにする。JSON RPCでどうにかする。
      • これを0から自分で書くの?
      • Slim3などでも出来るけどね。
      • サーバサイドで実装しなければいけない、認証とか、ルーティングとか。
      • JSONの設計とかを自分でやる、毎回。
      • 結局同じような仕組みになる
  • 結局は、RPCが出来れば良い。
    • foo.save(blogpost)
    • って出来れば、登録されていてくれればいいだけなのにね。
    • 今時はこれさえあればいいよね。
  • そこで、Cloud Endpoints
    • アプリ専用のAPIの提供とRPCの実装です。
    • すごく簡単に作ることが出来る。POJOアノテーションを書けば良い。
    • 呼び出すためのクライアントライブラリを自動的に作ってくれる。
      • AndroidiOSJavaScriptで作ってくれる。
      • 今時は、この3つをサポートしなければならない。プラットフォームごとに作る必要はないね。
  • ユーザ認証の決定打はなかった。
    • Androidアプリの認証。
    • 今はGoogle OAuthを推奨しているよ
      • Endpointsであれば、Googleアカウントで認証する場合、認証のコードを描く必要はない
  • 出来ること
    • 各端末プラットフォームごとのライブラリを生成出来る。
    • オレオレAPIを呼び出すためのライブラリ
    • サーバ側では、POJOのクラスを書いて、アノテーションを設定する
    • OAuth2もサポートされている。
    • OAuthの知識は要らない。
      • ただし、あんまり勉強にはならない。
  • Endopoints
    • Google IOのスライドなど参照。
      • まもなく、プロダクションで使えるかもしれないかもしれないかもしれない!!
  • Blog APIを作る
    • postArticle(String message)を作る
    • Eclipse Google Plugin for Eclipseで出来ます。
    • API Consoleで、ClientIDを作る
    • Androidプロジェクトを作る。
      • 必ず作らないといけないわけではないよ。
      • Androidを先に作っておくと便利。
    • Google App Engine Backend を作成する。
    • 実装
    • クライアントライブラリの生成
      • 右クリックプロパティからクライアントライブラリを作成する
      • これで、各プラットフォームのAPIが作成されます。
      • 先に、Androidプロジェクトを作っておくと、自動的に、Androidプロジェクトの方に吐き出され、すぐ使える。
    • あとは、Android側でクライアント側のコードを書く。
    • サーバ側をデプロイする。
      • Google APIs Exploerでテストする。
      • Google APIs Explorer
      • 自分で定義したAPIをテストすることが出来る。
      • 実際にクライアント側の実装をする前に、テストすることが出来る
  • 資料
  • 今後
    • GoogleComputeEngineのものも呼び出せるようになるかもしれない
  • 関連

Beer Talk

VPSとGCSとGAEをハイブリッドで使う事例 〜GAEは目立たないぐらいがちょうどいい〜

資料 → Gaeja20121130
blog → ぶいてく: ajn22のBTで発表してきました

  • PDF検索サービス
    • VPS上で動いている。キャッシュとして使っている
    • 表側にAppEngine
    • 特許関連の全ての情報のPDFが乗っているCloudStorage。
    • それを検索するために、AppEngineにインデックス情報を持つ。
      • 検索するための本文の情報とキーになる情報や、PDFのリンク。
    • 検索した結果を次の人に渡すようなワークフローがある。
      • 情報を追加して、次の人に仕事を渡します。
      • リアルタイムに通知するために、WebSocketを利用いしてる。
    • キャッシュは通信を安くするためにやっている
      • 速度を求めているわけではない
      • サーバ通信費コストの削減とハイパフォーマンス、安全性。
    • 全部VPSに出来ない理由
      • クラウドストレージのような安全性。
      • なんだかんだ、AppEngineは安全である。
      • VPSに暗号化して置いても、インターネット上にさらしておくのは・・・。
      • 個人情報を暗号化している。
  • 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は。。。
      • 気を付けないといけないのは、サーバ負荷
      • 基本的には、ステートレスに近い感じに実装する
      • サーバが動いていなくても、動くように実装する
  • OAuth2
    • アクセストークンには、有効期限があって、リフレッシュトークンで再度取得する。
    • 1つのアクセストークンで、全てのAPIが利用出来る。
    • approval_prompt設定で認可画面をスキップさせないようにする。
    • access_type設定でオフラインでもOK
  • その他のクライアント技術について
    • Thin Server Architecture
      • サーバサイドのテンプレ技術は使わない。JSONを返す。
      • 70%の負荷を低減できる・・・らしい。
    • SlickGrid
    • LocalStorage
      • 栞の情報を保存しておく
NEWSTRAINERのご紹介
  • NEWSTRAINER
  • RSSリーダー
    • 種類
      • ブラウザ
      • メーラー
      • WEBアプリ
      • ネイティブアプリなどなど。
    • RSSリーダーのイメージは?
      • ほったらかすと、未読がすごい。
      • 配信元の人がカテゴリ分けしているけど、読者としてはちょっと違うのではないかと。
      • あんまよくないので、作ってみた。
    • 配信元
      • ニュースサイト
      • 個人ブログ
      • メーカーサイト
      • ECサイト商品情報
      • 配信元がカテゴリ分けしているけど、ミスマッチだったりするよね。
  • 記事の分類
    • iPhoneAndroidとかをタグ付けする。
    • これを手作業でするのは馬鹿らしいので、機械学習させる。
    • 最初は、勉強させるために振り分ける。
  • 機械学習について
  • ベイジアンフィルタ
    • 学習データが多いほど良い、誤りはユーザが教育(手動で)する必要がある。
    • 教育コストは反比例的になる。
    • スパムフィルタなどで利用されている。
    • 分類型の場合の学習は、成功しない場合を想定しないといけない。
  • 人工ニューラルネットワーク
    • 人間の脳や神経の仕組みをシミュレートする
    • 学習データ量が小さくして保存しやすい
    • 反面、出力から入力をたどることが出来ないので、デバッグしにくい。
  • 決定木学習
    • 根から葉までたどるように枝をたどる
    • 構造が理解しやすくてデバッグしやすい
    • データが大量に必要
  • 問題点
    • 膨大な計算量と学習データ
    • 数式
    • 何が何だか分からない。
  • 学習データ
    • スレッドプログラミング
    • 使えるところではCモジュール
    • 永続性が必要なデータ以外はMemcache
  • 勉強方法
    • スタンフォード大学のオンライン授業
    • わからなくなったら
      • 人や生物をよく観察する
      • 観察して、そこから盗んでいきましょう。
      • 医者の診察だとか。
      • 植物の育成を観察して、遺伝的アルゴリズム
      • どういう事をすると、生き残るのか、どうすると生き残れないのか。

集合知プログラミング

集合知プログラミング

Think Stats ―プログラマのための統計入門

Think Stats ―プログラマのための統計入門