google app engine vs リアルタイムウェブ

Google APP Engine vs リアルタイムウェブ

自己紹介

● Twitterid:takayuki_h● ブログでは技術解説ネタを主に

● Google　APP　Engine　Python入門● http://d.hatena.ne.jp/kagigotonet/20100209/1265726225

● 長らく体を壊してほぼニート状態● ホームページ屋さんの下っ端の孫の手の先を細々と● IphoneアプリのバックエンドのGAE開発とかやってます

● ちょっとあいちゃったのでお仕事のお話とかあれば

今日のBeerTalkについて

● livernalnet　jpというTwitterBotの開発経験のシェア

● Twitterのようなリアルタイムウェブを相手にしたサービスをどうGAEで作るか？

● 自由にプロダクトをインストールできないGAEの弱点の克服にも

@livernal_jp● ネットを通じた「ライブ」をサポートするBOT● livernal.netというWebサービスの一機能

● 現在はUSTREAMのライブ放送をサポート● 開始の捕捉・告知● 盛り上がっているライブを報告● ＠でライブの告知や予告● 非公式RTとリプライでオススメ

バックエンド

● 言語はPython● フレームワークは現在開発中のもの● テストは根性(ぉ

最大の課題はVSリアルタイムウェブ

VS　リアルタイムウェブ

● 全てがリアルタイム● 変動が大きい

● 100倍程度違う● 不要な時には「たたむ」仕組が必要

● 変化が速い● 短ければ1分程度で色々なことが起きる● シーケンシャルなアクセスでは追いつかない

クローリングも大変

● 時間が見積もれない● 相手がある

● Twitterは調子のいい時と悪い時が全然違う● .USTREAMはあまり頻繁にアクセスするとはじかれる

● 相手が原因のエラー対応● 30秒制限のクリア

リアルタイムウェブと戦うには？

● 不要な時は最小限● 変動にはすばやく対処● 高速なクローリング

● 並行処理必須

でもこんなこと最初はまったくわかってませんでした ( ´д｀;)

最初は全部CRON

未展開の短縮URLを展開

ustre.amをTwitter検索

未展開の短縮URLを展開

タイトルを取得

メッセージ送信

完全に問題の見積もりを間違えていた

全然ダメ( ´д｀;)● USTに連続してアクセスしようとするとはじかれる

• はじかれるとリトライ処理が面倒• そもそも、スローペースでのアクセスが必要

• 詰まっているものだからアクセス中に30秒制限超える• 先の処理に進まない● さらにうっかり日本語のみのライブに限らなかったものだ

からえらいことに● db.put()は500エンティティまでって解りました

● ( ﾟ∀ﾟ)ｱﾊﾊ八八ﾉヽﾉヽﾉヽﾉ ＼ / ＼/ ＼

TaskQueueを使う方式に変更

展開・タイトル取得・分析結果保存

1.urlごとにTaskQueueに投入

メッセージ送信

ustre.amをTwitter検索

盛り上がり告知

● Ustの処理は専用のキューを設定● 一分あたり10回程度のゆっくりとしたアクセス● Bａcket_Sizeを大きくすることで、タスク量にあわせた処理

速度を自動的にできるようにも● メッセージ送信もキューに入れるように

● 反応の加速とリトライの自動化

変更点

結果

● 失敗の影響は局限化できた● ある程度リトライして、それでもダメなら諦めればいい● TaskQueueの設計のコツは、副作用がなくなるまで細分化

することだとわかる

● しかしUST配信が多い夜間は詰まる● 詰まり具合に応じて柔軟には対応してくれるけど、量が多すぎる

● Twitterのインデクシングもいい加減● 部分一致は頼りにならない● 個別のURL単位でのクローリングが必要

現在ustre.amをTwitter検索

盛り上がり告知

展開・タイトル取得

1.新しいurlごとにキューイング

メッセージ送信URLごとに検索・分

析

同じタスクをキューに投入

2.

現在のキュー構成● デフォルト● 全般の監視

● 最初の一回はcronで起動。次があった場合はページングをTaskQueueで順次処理

● Memcahceによるセマフォでロック

● Utream短縮アドレスの展開● 新しいURLを展開し、タイトルを取得● 個別チャンネルのクローラーを起動

● 個別チャンネルのクローリング● チャンネルのURLで検索・分析・終了判定● 同じタスクにcountdownつきで投げる擬似cron

TaskQueueの活用にサービス層は大事

● TaskQueueをフル活用すると、どうしても一つの処理を複数のリクエストで分散して行うことになる

● コードが拡散する● リクエストを受け取る層とモデルの間データに対する共

通処理を表現するサービス層を挟んで解決● CakePHPで言うCompornentを発展させたもの

● はてなが使っているというMVACパターン

例　リプライと短縮URLの処理

リクエスト受け取り

リプライ取得

メッセージ判定

お勧め、告知などのサービス層

短縮URL展開サービスリプライ取得

3.展開の必要の有無を返す

1.

2.

4.

7.コールバック

5.キューイング6.展開

サービス層のメリットデメリット

● メリット● TaskQueueを介した処理を隠蔽できる

● 適切なリクエストさえサービス層に出せばいい● コードが集約できる● 再利用性が高まる

● デメリット● 依存性の切り分け

● サービス間の依存をどこまで許容するか● オーバーヘッド

まとめ

● リアルタイムウェブに対抗するにはTaskQueueが必要

● TaskQueueの設計は副作用がゼロになるように

● TaskQueueはサービス層を挟むようにすると便利

● TaskQueueはゆっくりしたアクセスにも便利

● TaskQueueは面白いです

御清聴、ありがとうございました

おまけです

@livernal_jpからみたUSTREAM

● 現在判明している日本語USTチャンネル数は約5600件● 同時放映数は一桁から数百オーダーまで● 一日あたりだと700～1000くらい

どのくらいの人がUST流しているの？

どんなのがあるの？● DＪ系

● ライブハウスと自宅● トーク番組

● 女の子が出ていると盛り上がる● 報道・講演系● ゲーム実況● 作業中継● 定点ストリーミング● 会見放送は盛り上がりはともかく数としては少ない

● というか、他が多すぎ(^^;)

放送のパターン

● 基本的に深夜に大盛り上がり● 数としてはクラブ・ライブハウス文化が主流

● 昼にも中盛り上がり● 5時からも小盛り上がりがあることも● 曜日的に言うと、意外と水曜日が盛り上がる● 時間的には、夜の8時から午前1時くらいまで● 一番大きいのは土曜から日曜にかけて

● 八時くらいから翌朝九時までオールでアゲアゲ

● ζ*'ヮ')ζ＜今夜はもやし祭りです～

例：4月22日午後5時から24時間の負荷

でもGAEでは無料枠で戦えてます

● CPU負荷でも多くても30～40%くらい

● 通信料は大きくても10%程度● 多分、ちょっといい共有サーバーレベルが無料

● 運営会社によっては追い出されているかも？

● ありがたいことですm(_　_)m

御清聴、ありがとうございました