January 01, 2012
正確にはtwitter apiが落ちているかはわからない。
twitterのツイートを送るという行為は、おそらく以下のような処理で作られていると思う。
1.ツイートを受信する
2.ツイートを見ることができる人のデータベースに、もれなくツイートが配信される。
（今ツイッターにアクセスしている人のメールボックスに即時、配信されるイメージ）
ただし、このツイートを見る事ができる人というのは、
・この人をフォローしている人
はもちろんなんですが、それ以外、ややこしい処理がありまして、
・ツイートが「会話（リプライ）」だった場合は、会話の相手もフォローしている人だけに配信される。（つまり、片方しかフォローしていない人には配信されない）
・ツイートの中に「@○○」が書いてあったらフォローに関係なく、相手のmentionボックスに配信される。
・その他
などの、RDBのSQL文一発では効率的に書けない配信ルールがあります。フォロー、フォロワーの関係に限らず、文章内に書かれている内容如何で、配信される範囲が自動的に制御される素敵なシステムです。
１４０文字はシンプルなのですが、その実、中身は複雑なシステムでして、読み手も沢山ツイッターにアクセスしていると、一つのツイートに対して、同時に処理しなきゃいけない処理量はどんどん増えて行くのではないかと思います。
つまり、
・書き込みが多い
・読む人も多い
場合には、とてつもなく処理が増えるのではないかと思います。
結局のところ、バルスやあけおめツイートの時には、これらの処理をしなきゃいけない量が大量になります。
ツイッターは、ピークにあわせて、かなり大規模にツイートを処理できるようにはなっていますが、短時間にツイートが集中しても、どうしてもツイートを処理できないケースが出てくるのではないかと思います。
大行列ができていれば、そのあとのツイートはその後ろに並ぶことになります。ということで、一度遅れが始まると、同じツイートを何度も送るケースや、「apiが落ちたー」みたいなツイートも行列に並んでしまい、処理しなきゃいけない情報量は雪だるま式に増えて行きます。
で、このような状況が起きた場合に、ツイッターapiがどう言う処理をするか？は、ツイッター側に委ねられていますが、おそらく今までのツイッターの成長の中で、ツイートが集中した時に、ユーザーやapiにて、どのような状態を返すか？というのは変わっているように思えます。
外から見ていての動作としては、昔は、ツイートが更新されない、いわゆる「遅延」の状態が多かったように思えます。エラーにはならずに同じデータが返ってくるものの、時間が止まっている状態です。それに対して、今は、apiがエラーで帰ってこないという動作になっているような気がします。
おそらくエラーという形で表向きはある程度は遮断状態を作っていて、裏側では溜まった行列を一気に処理している状態が存在しているんではないでしょうか？
緩い入場規制が行われている感じだと思います。これはツイッターapiが落ちているのではなく、「そういう風にエラーを返している」というのが適切で、裏ではせっせと溜まった情報を処理している状態ではないかと思います。
それに対して、いわゆるツイッターapiが落ちるという言葉が本当に適切なものは、
「全くレスポンスが返ってこない」
というものです。
また、落ちているという状態をもう少し詳しく書くと、２つのパターンが考えられて、
一つは、「即時にWebサーバーが500エラーを返す」 （例えば裏側のサーバソフトが落ちてしまった、とか。）
もう一つは、
「全くレスポンスが返ってこないで、apiの通信終了までひたすら待たされる（デッドロックか過負荷状態）」
という二つのパターンではないかと思います。特に後者はややこしくて、モバツイのような中間サーバーがproxyとして動くサーバーの場合は、一つのコネクションが待たされてしまうと、芋づる式にサーバーリソースをつかんだままにされてしまうので、タチが悪いです。
即時にエラーが返ってくるなら、そんなにモバツイサーバーは重くなりませんが、ツイッターへの通信が待たされすぎると、どんどんどんどん待ちの通信状態が増えてしまい、モバツイのwebサーバーも過負荷状態になってしまいます。この状態になるといくらサーバーを増やしても意味が無いので、ツイッターapiがコネクションをすぐに止める（エラーが返る）状態になるまで待つしかありません。
ということで、いろいろ書いてしまいましたが、通常よりも圧倒的に沢山のツイートが短時間に送られたら、そりゃツイッターサーバーが処理をしきれなくなって調子が悪くなってもおかしくないかなと思います。
いわゆる「未曾有の状態」への危機対策に近い話です。どこまでサーバリソースを準備しますか？というので年に一回のレベルのツイートの集中に設備量を合わせるのはあまり合理的とも言えませんからね。
地震の時にツイッターがうまく動いたのはワールドカップか何かのためにサーバを増強していたから、なんて話がありましたっけ？！
また、ここから先は考え方一つですが、もし、ツイッターが自分たちのサービスだけを守って安定稼働してるフリをするのであれば、短時間での一定以上のツイート送信は、ツイッター側が全部遮断して、twitter.comが落ちないように安定稼働を保つという考え方もあると思います。
しかし、彼らがそれをやらないのは、サービス自体がどんどん進化しているから、という意味だと思います。どっちが正しいかというのは考え方次第ですね。
むろんそうすると、一定時間に送られるツイート数にキャップがつきますので、記録を更新することもなくなります。
安定する代わりにつまらないサービスになります。
携帯電話は、正月０時直後は一定数以上のアクセスを遮断してしまうと思いますが、それと同じようになってしまうのもどうなんでしょうか？！
ちなみにfacebookは落ちないと言う部分で言うと、ツイッターほど即時反映に価値がないし、誰に何が配信されるか？！というフィルター自体がfacebookの判断にまかされている部分もあるので、うまくクッションを入れて負荷を制御しているんではないでしょうか？！
ツイッターはそうならない方が良いと思いますし、配信条件がユーザーのコントロールに委ねられていて、ツイート同士、ツイートとユーザーは密な結合をしている以上は、ツイッターがダメというよりは、ダメな状態を許容しているというのを、ポジティブに捉えてあげて欲しい気はしてます。
ユーザーからしてみると、こんな話は関係なく、希望通りサービスが動かなければ、落ちたんだと言われるのは仕方ないと思いますが、Webサービスは、そもそもピークに合わせては作られていなくて、人の利用が分散化するからこそ成り立ってるシステムでもあるので、人気のサービスが落ちるのは、人気の証だと余裕を持ってみてあげて欲しいとは思います。
余談ですが、モバツイでは先日のバルスの後にプログラムを改良し、「混雑モード」というものを作ったので、あけおめツイートではモバツイは全く不調にはなっておりません。
ただ、ツイッターapiが重くなってしまったので、マスターDBではなく、api前後で動いていたスレーブのDBアクセスの方でmax connectionsになってしまいました。結局のところユーザーさんからするとモバツイが落ちたように見えていますが、それは他のツイッタークライアントでも同じ状態だったと思います。なお、モバツイsmartでは、あまりスレーブDBの状態に依存性がなかったようなので、結構、普通にツイートができていたようでした。
----------------------
モバツイがきっかけに本を書きました。
何故、ツイッターが大きくなったのか？ということを2007年から毎日見てきた経験即をベースに書いています。
2012/1/10発売。現在、絶賛予約受付中。
100万人から教わったウェブサービスの極意 ～「モバツイ」開発1268日の知恵と視点
p.s.mixiにも同じような障害が出ていたようですね！もしかしたら、ツイッターでやってるんだから、うちもやれば良いじゃん、的なノリになっていたりして。
【追記】アクセス不具合のお詫び