monthly gimite

試験運用中。

[tss][twitter] Tweet Search StreamがTwitterからアクセス禁止された経緯と復活した経緯

10/3-10/5ぐらいにかけてTweet Search Streamが落ちていたのですが、これはTwitterからアクセス禁止をくらってました :) その後Twitter Streaming APIの使い方を変えることで制限に引っかからないようにして復活しました。以下はその経緯です。

まずアクセス禁止を食らった理由ですが、たぶんこれです。

Access and Rate Limiting - Streaming API: Concepts

Excessive connection attempts, regardless of success, will result in an automatic ban of the client's IP address.

元の実装ではTweet Search Streamを開いているユーザの数だけStreaming APIのコネクションを張っていました。最初の頃は平気だったのですが、徐々にユーザが増えて、同時接続数がしょっちゅう20以上、ピーク時は50〜80ぐらいになったところでIPアドレス単位のアクセス禁止を食らいました。

当初からこれには引っかかるかも、と思っていました。ただ、excessive connection attemptsというのが一体10なのか100なのか1000なのか分からなかったので、見切り発車していたのです。

で、これはもうTweet Search Stream終了のお知らせかな、と思ったのですが、APIのドキュメントをよく見ると検索キーワードはORで400個まで同時に指定できると書いてあります。Tweet Search Streamは同じキーワードにアクセスが集中する傾向にあるので、キーワードの数は接続者数よりかなり少なくなります。なのでStreaming APIの接続を全体で1本にして、接続中の全ユーザのキーワードをOR(Streaming APIでは",")でつないで投げれば、今ぐらいのアクセス数なら余裕なのでは、ということに気づきました。で、そのように実装しなおして10/5に投入しました。

が、実はその後1度問題が起きました。10/8にちょっとしたバグ修正のためにTweet Search Streamのサーバを再起動したのですが…。再起動によってWebSocketの接続が切れると、Tweet Search Streamのページには"Disconnected. Retry"とか表示されるので、当然みなさんすぐにそれをクリックします。そうすると再起動直後にアクセスが集中することになります。新しい実装ではキーワードが増えるたびにStreaming APIのコネクションを切断→新しいキーワードを追加して接続しなおし、ということをやります。なので再起動直後は短期間でこの切断→接続が繰り返されることになり、Twitter側から「おちつけ」というエラーをもらって繋がらなくなってしまいました。そこで短期間で切断→接続を繰り返そうとしたときは、ちょっと待つ、という仕組みを入れて回避しました。

もうちょっと様子を見ないと分からないですが、これで今のところは安定しているようです。

ちなみに新方式ではさりげなくTwitterアカウントでのログインが不要になっています。これはコネクションが1本しかないので、僕のアカウントで認証すれば済むからです。*1

新しい実装はGuthubに上がってるので、興味のある人はどうぞ。Guthubのバージョンはさらにem-http-requestとem-websocketを使って完全にEM化されています。これについては後述。

*1:Streaming APIのコネクションは1ユーザ1本しか張れないので、旧方式では各ユーザに認証してもらう必要がありました。