Home > アーカイブ > 2010-02

2010-02

Twitter キーワードがつぶやかれた数をリアルタイムで比べる方法

この記事の所要時間: 153

Twitterであるキーワードがどの程度つぶやかれているかをお手軽に見る方法です。

キーワード

今日まさに旬な「R1」「ドラマ」「オリンピック」が、Twitter上でどれくらいつぶやかれているかを調べます。

方法はいたって簡単。

Twitter公式検索(search.twitter.com)で調べたいキーワードを検索するだけです。

複数のキーワードを調べる時はブラウザのタブを追加して、検索します。

検索した直後のタブは以下のようになります。各タブには検索したキーワードが表示されていますね。

これをしばらくそのまま放置しておくと、その間にキーワードにマッチするつぶやきの件数が表示されます。

さらに放置すると件数が増えていきます。

Twitterドラマのおかげか「ドラマ」が伸びていますね。

URL

次は、あるサイトのURLがどれくらいつぶやかれているかを見てみます。

キーワードと同じようにsearch.twitter.comで検索しても良いのですが、なぜか取りこぼしが多いようなので、別サイトのbacktweets.comというサービスを利用します。

最近はやっている○○ったージェネレータサイトの「ツイットメーカー」と「なんでもメーカー」を見てみましょう。

ブラウザでタブを2枚開いておいて、各々のタブでbacktweets.comへURLを入力します。どちらのサービスもサイトへのURLが書かれているのですが、ドメイン部分などサービス内で共通の部分を入力します。

ツイットメーカーなら

なんでもメーカーなら

これを検索した状態です。お互いのURLがタブに表示されています。

これもしばらく放置しておくと、その間にURLがtweetされた数がタブに表示されます。

例えばこんな使い方

いろいろと使い方は考えられると思いますが、例えばこんな使い方。

  • はやりのキーワードを比べる
  • はやりのサイトを比べる
  • 同時期に開催しているイベントのハッシュタグを比べる

などなど。

仕掛けておくとドンドン数字が増えていくので眺めていると面白いですね。気になるキーワードがある方はお試しを:D

約半月で 4,000,000PV を華麗にさばく Google App Engine

この記事の所要時間: 66

なんでも判定ツクール」へ多数のアクセスありがとうございますm(_ _)m

1月末にリリースした当初は僅かのアクセスだったのですが、Twitterで火が付いてからは一気にアクセスが集まり、気が付けば2月1日〜2月16日で4,000,000PVを超えました。

自分では絶対に考えつかないであろうユニークな判定がたくさんできて、私自身もとても楽しんでいます:-D(面白い発想をする人は世の中にたくさんいるものです)

このサイトはGoogle App Engine(GAE)+Pythonで構築しているのですが、このアクセス数ならではのGAE上で体験できたことをざざっと書いていきます。

無料?課金?

まずはじめに大事なこと。

「なんでも判定ツクール」ではGAEを課金状態にしています。無料のQuotaではとてもではないですが、このアクセスは捌けません:D

GAE公式サイトには

月間約 500 万ページ ビューに対応できる十分な CPU と帯域幅を、すべてのアプリケーションで完全に無料で利用できます。
Google App Engine について – Google App Engine – Google Code

といった記載があるのですが、少なくともDataStoreを使うような動的サイトでは5,000,000PV/月を無料Quotaで捌くのはかなり難しいと思います。

秒間200リクエスト

アクセスは日によって時間によってバラツキがあるのですが、瞬間最大風速では200超req/s(GAE DashboardのChart上)を記録しました。

この200req/sを記録したのは 2010/02/15 夜だったのですが、ブラウザでサイトにアクセスする分にはそれほど重さは感じませんでした。ですが、実は裏では結構なアクセスをさばいてくれています。

これはGAEの真骨頂とも言える「チャージ金額上限まで自動でリソースを割り当ててくれる」サービスのおかげですね。まさにクラウドです。チャージ上限金額までは負荷に合わせて勝手にリソースを確保していってくれるので、アクセスどんと来いという気持ちになります(比例して財布は少し寂しくなりますが><)

もちろん、これにはアプリケーションの設計も大きく関連します。いくらプラットホームであるGAEがスケールしていっても、アプリケーションがそれを想定していた作りになっていなければアプリケーション側がボトルネックとなります。「なんとか判定ツクール」は業務システムに比べると単純な作りになっているので、このあたりもGAEのスケーリングの恩恵が受けやすいということはあるでしょうね。

1日680,000PV

1日単位で見ると 2010/02/09 に 680,000PV を記録したのが最高値でした。

数値はGoogle Analyticsに記録されたものです。これはPC版の数字なので携帯版を加えるともう少し上乗せされます。

この日は秒間リクエストのピークは160くらいだったのですが、ピーク時以外もアクセスが続いたのでPVが伸びました。PVが伸びた分、課金額も一番です。

この数値を元に単純計算すると 680,000 * 30 = 20,400,000PV/月 はこなせそうです。

DataStoreの総エンティティ数が3,000,000

DataStoreのエンティティ数(RDBMSのレコード数のようなもの)の合計が3,000,000を超えました。

DataStoreにはいくつかのkind(テーブルのようなもの)があるのですが、これは全ての合計です。

中でも一番多いのが判定結果を表すエンティティで、1,500,000くらいです。つまりこれは延べ1,500,000回の判定(!)が行われたということです。(実際は、1,600,000エンティテイあるのですが、初期アプリケーションのゴミデータが含まれるので実質は1,500,000程度。)

これだけのデータがあってもキーを使った読み込みならとても高速に動作します。(これくらいのデータ量ならインデックスが効けばRDBMSでも早いですけどね。)

DataStoreエラー

負荷が上がった際、サイト自体は概ね動いているのですが、実はDataStore周りでいくつかエラーが発生しています。

例えば、平常時は瞬時に返答がある Model.get_by_key_name() でデータを取得するという単純な処理でも高負荷時は DeadlineExceededError が発生する場合があります。

これは避けがたい現象のようなので、クライアント側でリトライ処理を実装するなどして上手く付き合うしかないようです。

bit.ly

当初、判定結果をTwitterに報告する際にURLを短縮する方法としてbit.lyのAPIを利用していました。

これはとても上手く動いていたのですが、アクセス数が伸びるのに従って、bit.ly APIでエラーが発生するようになりました。一度この状態になるとエラーレスポンスが返ってくるばかりで短縮URLへの変換を行ってくれません。数十分経過すると復活するのですが、また負荷がかかると停止してしまいます。

bit.ly API のドキュメントでは1IPあたり同時アクセス数5未満とされているので、制限を超えるアクセスで止められるのは当然だと思います。なのでこれに関しては利用させて頂いてありがとうございますと、ごめんなさいという感じです。

いくらGAE自体がスケールしても、外部サービスに引っ張られて処理できないと元も子もないので、結局短縮URL機能を自作しました。

これには @kis さんとのTwitterでのやりとりが大いに参考になりました。ありがとうございました!

サイボウズさんキャンペーン

サイボウズさんのキャンペーンにて「なんでも判定ツクール」を利用して頂きました。

=>サイボウズコミュニティ – 特集 – 【終了しました】サイボウズ謹製ツバメノートプレゼント!

サイボウズさんにまつわる判定をやって、Twitterで報告するとノベルティが貰えるというキャンペーンだったのですが、多くの方が参加されて盛り上がったようです。

こういったキャンペーンに使えるという視点は当初は持っていなかったので面白かったです。

今後も絶賛募集中ですので、キャンペーンに使ってみたい、という方はご一報頂ければ嬉しいです:D

Google App Engineは使える!

「なんとか判定ツクール」を運営している感覚では、今更ながらですが、やはりGAEは十分に使えるなという印象を持ちました。

なんといってもチャージさえしておけば自動的にスケールしてくれる感覚は素晴らしいですね。これまで突発的な負荷に悩まされた経験がある方なら有難みが特に分かると思います。

もちろんGAEならではの制約(処理時間やDataStore仕様等々)があるので全てのアプリケーションをGAE上で動かすべきとは思わないですが、特性にマッチするアプリケーションであれば検討してみる価値がありますよ。

え、PHPしか書けない?PHP書けたらPython書けます。大丈夫:-D

Google App EngineのUser-Agent

この記事の所要時間: 354

Google App Engine(GAE)からHTTPアクセスするときのUser-Agentについて。

GAE上のアプリケーションがHTTPアクセスする際にどのようなUser-Agentになるかを調べてみました。環境は、Python2.5.4 + Google App Engine SDK 1.3.1 です。

GAE+PythonからHTTPアクセスするには幾つかの方法があるのですが、urllib2を使う方法とGAEのモジュールであるurlfetchモジュールを使う方法について見ています。

urllib2

urllib2でアクセスした場合のUser-Agentです。

特徴的なのは「AppEngine-Google」が付いているのとアプリケーションIDである「appid: XXXX」が付加されていることですね。アプリケーションIDはGAE上の各アプリケーションに割り振るIDで一意となります。

もしGAE上のあるアプリケーションからのアクセスを制御(許可、拒否等)したい場合は、このアプリケーションIDを見れば可能です。

"Python-urllib/2.5 AppEngine-Google; (+http://code.google.com/appengine; appid: XXXX),gzip(gfe)"

urlfetch

urlfetchでアクセスした場合です。

urllib2と比較すると「Python-urllib/2.5」が無い他は同じですね。

"AppEngine-Google; (+http://code.google.com/appengine; appid: XXXXX),gzip(gfe)"

User-Agentを変更した場合

urllib2でもurlfetchでもUser-Agentを変更することができるので、変更してアクセスしてみました。

# -*- coding: utf-8 -*-
url = "http://www.exaple.com/"

# urllib2
import urllib2
opener = urllib2.build_opener()
opener.addheaders = [('User-agent', 'PHP5.3.2')]
try: opener.open(url)
except: pass

# urlfetch
from google.appengine.api import urlfetch
urlfetch.fetch(url, headers={'User-Agent': 'CakePHP1.2.6'})

結果はどちらも変更したUset-Agentにはなっているのですが、AppEngine-Google以降の文字列が付加されています。もちろんappid:も付いているので、User-Agentを変更していてもアプリケーションIDによるアクセス制御は可能です。

urllib2

"PHP5.3.2 AppEngine-Google; (+http://code.google.com/appengine; appid: XXXXX),gzip(gfe)"

urlfetch

"CakePHP1.2.6 AppEngine-Google; (+http://code.google.com/appengine; appid: XXXXX),gzip(gfe)"

urllib2でUser-Agentを変更しない場合に「Python-urllib/2.5」が付くのは内部的にUser-Agentを設定しているだけの話です。

アクセス制御はアプリケーションIDで

GAEではサーバ環境を全ユーザで共有するので、IPアドレスでの制限はできません。(GAE全体からのアクセスを制限することはできるかもしれませんが。)

ただアプリケーションIDであればアプリケーション固有に付いている値なので、これを使えば特定のアプリケーションに対してだけ制御が可能です。User-AgentへのアプリケーションID付与(appid:)はGAE自体が行うので今のところ信頼して問題無いと思います。

時間が経つ毎に進化していくGAEですが、こういったところも気が利いていますね。

[参考] Apacheでアクセス制限 mod_access – Apache HTTP サーバ

携帯版Twitterサイトへのステータス付きリンク

この記事の所要時間: 147

携帯版Twitterサイトにステータス付きリンクを貼る方法です。

Webサービスやblogによくある「Twitterで報告する」といったリンクですね。

クリックするとTwitterページに遷移して、ステータス(つぶやき)を入れるテキストエリアにすでにメッセージが入っています。あとは「UPDATE」をクリックするだけで、つぶやくことができます。

PCだと「http://twitter.com/home?status=AAA」がおなじみなのですが、この方法だと携帯版(twtr.jp)ではステータスがうまく引き継げずにstatus=AAAの内容がテキストボックスに入りません。

携帯版ではリンクの記載方法を変えることにより、同じ動作が可能です。

携帯版ステータス付きリンク

これはリンク先とパラメータが変わるだけです。

http://twtr.jp/status/create/?text=XXX

XXXがテキストボックスにセットしたい内容です。

ただtwtr.jpではキャリアによって文字エンコーディングが異なるのでXXXの部分のエンコーディングをキャリアに合わせて記述してやる必要があります。

キャリア別文字エンコーディング

キャリアに合わせて以下の文字エンコーディングで記述します。

DoCoMo au SoftBank
utf-8 CP932 utf-8

DoCoMoはcookie対応機が手元に無かったので試していません。誰かもし持っていれば「なんでも判定ツクール」で試して頂ければ嬉しいです:-D

追記:DoCoMoですがutf-8で問題無いそうです。@H_O_0221さん、テストありがとうございました!

なんでも判定ツクールでは、基本UTF-8で記述しておいて、auだけCP932に変換しています。

URLエンコーディングを忘れずに

どの文字エンコーディングに変換してもXXXの部分はURLエンコード(PHPならurlencode())する必要がありますので、お忘れなく。

Home > アーカイブ > 2010-02

検索
フィード
メタ情報

Return to page top