2013年8月アーカイブ

Amazonアフィリンク

勘定系などの大規模システムでのシステム障害がどのように引き起こされるのかを、技術的な深掘りをしつつ、実名は伏せつつも実例を数多く紹介して解説している本。日経コンピュータ監修とあるあたり、結構本当のことを書いてくれてんだなぁと思われるくらいには具体的な話となっている。

読み物としてはおもしろいんだけど、技術者が読む本としてはどーなんかなぁという仕上がりです。「技術的な観点でまとめた」とは書いてますが、結構当たり前な技術用語の解説から入ったりしている箇所も多いという感じで。とはいえ全くのIT素人を相手にしているという感じの内容でもない。実務経験がほとんどない情報系の大学生か、技術の中身については必ずしも詳しいわけではないIT系会社の管理職か、あたりが対象という感じかなぁ。どうも実例の紹介の書き方が某IPA試験の問題を彷彿されるようなものでなんか気にくわない(ぉ

で、確かに技術的な話を出しつつ障害の原因別にまとめて紹介はしてるんだけど、それに対して具体的にどうしろこうしろというわけでもなく、平たく言えば「テストしっかりしよう」といってるに過ぎないのもなぁというとこです。まぁ解決策を考えるための本でもないのでそこまで求めるのも酷かな。むしろこの本としては、障害を減らす努力は絶えず行うべきだけどどうしても起こってしまうんだよなぁどうしようもないよなぁ、的なノリですね。私が特に気にするソフトバグの原因については、まぁありがちな話のオンパレードという感じですね。とはいえその基本が大事なんですけどね。

あとは、謝辞に出てくる企業名が「富士通」「日立製作所」「日本オラクル」「日本ニューレット・パッカード」「NEC」「日本IBM」となっているあたりに、本書の対象がそういう勘定系に偏ってるのが伺えます。そのためか、実名を伏せていても「ああ例の株の誤発注か」とわかってしまう例が多いのもなんだか。そいや誤発注をキャンセルできないというバグのせいで損害が広がったとして民事裁判まだやってんのよねぇあれ。額が額なだけに、技術的な話だけ切り離して考えるのも難しくて、どうしても責任問題もあわせて気になってしまいがち。

というわけで、読み物程度として読むにはよいですが、ここから何かを教訓として得たいという用途にはあまり向かないかぁなというとこです。

前回のさらに続き・・・みたいなもの」

「SQLアンチパターン」に「15章ランダムセレクション」があってズバリこの話があるようです。が、MySQLだと「limit N offset n」はnが大きいときにパフォーマンス悪くなる話や、ランダム1件じゃなくてランダムN件引っ張ってきた場合の話がないので、たぶん私の書いた内容の方がよりつっこんでるとは思ってます。「SQLアンチパターン」は読み終わったらまたレビュー書く予定。

「1からcountまでの整数の中からランダムにN件重複なしに引っ張ってくる」やり方に少しツッコミができてたんでそこを補足。これを解く一般的なやり方は、前回書いた「1からcountまでの間の乱数を重複なしN個そろうまでひたすら振る」のは効率悪くて、実際はこんな手順になります。

1. 1からcountまでのcount個の数字を配列につっこむ
2. 1からcountの間の乱数を振る
3. ↑で出た値を配列から取り除き結果格納の配列に移す
4. N個そろうまでcount--しながら 2と3を繰り返す
5. 結果格納に目的のid(というかoffsetというかが入った状態になる

という感じかと思います。なんだか言葉じゃ伝わりにくい気がしたのでPHPのコードも書いときます。

function make_random_list_string($maxnum, $count){
  $tmp_random_array = array();
  $result_array = array();
  for ($i=1; $i<=$maxnum; $i++){
    $tmp_random_array[] = $i;
  }
  for ($i=0; $i<$count; $i++){
    $maked_num = rand(0, $maxnum - $i);
    $result_array[] = $tmp_random_array[$maked_num];
    array_splice($tmp_random_array, $maked_num, 1);
  }
  return  implode(',', $result_array);
}

$countが大きいと$tmp_random_arrayや$result_arrayをメンテするコストもバカにならなくなってくるので、そういう場合はシャッフルを使う方が早いんじゃないかと。

function make_random_list_string($maxnum, $count){
  $tmp_random_array = array();
  $result_array = array();
  for ($i=1; $i<=$maxnum; $i++){
    $tmp_random_array[] = $i;
  }
  shuffle($tmp_random_array);
  return implode(',', array_splice($tmp_random_array, 0, $count));
}

確かに、make_random_list_string(100*10000,1)だと先の例の方が早かったけど、make_random_list_string(100*10000,100)だとこっちの方が早かった。ちなみに、PHPで大きい配列作ったりすると「Allowed memory size of 16777216 bytes exhausted」と怒られるので、そのときは /etc/php.ini に「memory_limit = 128M」とか書いときましょう。

とはいえ、$maxnumがさらにばかでかい(かつ$countが小さい)と、$tmp_random_arrayを作ることすらメモリが足りなくて現実的でなくなってしまう。そのときは、前回書いた例「重複しないN個がそろうまでひたすら乱数を振る」やり方が、アルゴリズム的には抜けがある(確率的になかなかN個そろわないことがどうしても起こりうる)けど、現実的には全く問題ないです。

Amazonアフィリンク

おそらく日本語では初のLLVMの本。LLVMとはなんぞやから始まり、インストールの手順、LLVM-IRの説明といき、DummyC(C言語のちょーサブセット)を対象としたフロントエンドの実サンプルの作成、Passの説明と実例、MIPSサブセットチックな仮想アーキテクチャをターゲットにしたバックエンドの作成、という構成になっている。

はしがきを読んであらビックリ。元はコミケで配布した本で、それが基となって電子書籍版が販売され、そして紙の本の書籍化になったようだ。謝辞や著者説明にTwitter ID が書かれていたりと、そういう方面でのカルチャーショックが大きかった。

「きつねさんでもわかる」内容なのかどうかは大いに疑問の残るとこだけど、それを置いといたとしても、この本はどういう人を対象にしているのかにはよく注意しないといけない。サブタイトル「コンパイラを自作するためのガイドブック」が非常に大事なところで、その上で、C/C++はコードを読むのに不自由しない程度の知識と経験、Linuxはそれなりに触ったことがある、gccが内部で何やってんのかが簡単にでも想像できる、あたりは最低必要でしょう。加えて、シェアドライブラリやELFについての知識、アセンブラや命令セットを見ても拒否反応を示さない、BNF記法に多少は馴染みがある、くらいでないと正直つらいと思う。逆に、実際に動くサンプルを作ってみるところまでを目標にした本なので、日常的にgccのRTLを眺めたりプログラムを命令ステップ実行したりしてる人には、内容がちょっと退屈かもしれない。

7.1章で著者が「んなもんソースコード読めよバーカ」と言いたげそうに悲鳴をあげている箇所があったり、5章と7章それぞれ半分以上が淡々とC++のソースコードを解説しているだけだったり、そういうところにコンパイラを作ることの大変さが見え隠れしてます。コンパイラを作ろうと思ったらソースコードどっぷりにつかる覚悟はやっぱ必要です。少なくとも紀伊国屋グランフロント大阪店のようにC言語の解説本の横に平積みしておくのは、大きな間違いだと思われます。きつねさんなので、置くならやっぱりオライリーの動物本の横辺りでしょう。O'Reillyよ、これがJapanese Animalsだ、と(謎)

決してこの本も悪いとまでは言い切れないけど、いくつかコンパイラ特有の考え方が説明なしに登場している箇所もあるあたり、一般的なコンパイラの作り方なら他の本を先に読んだほうがいいかもしれない。その上で、LLVMを使って実際にオレ言語とオレコンパイラを作ってみるというフェーズでこの本を手に取る方がいいようには思える。とはいえ動いてナンボの実例がGithub(DummyCCompiler, llvm-sample-target)で本を買わなくても手に入ってしまうあたり、公開されてるソースコードを見ただけじゃ中身が理解できないような人がこの本を買うべきという感じなのかもしれない。

というわけで、さすがにこれは、買った方がいい人はかなり限られる・・・

前回の続きみたいなもの。前回の後半のカイ二乗分布が出てきた当たりから、自分でもグダグダだなぁと感じてたんで、その辺の話の補強を。

N倍しろとかカイ二乗分布とかを考えたくない場合は、やっぱり素直に「ランダムに1つ取ってくる」操作を複数繰り返すべきとなります。というわけで、先の記事に示した1件のランダムを取ってくるSQL構文

select * from (select ri2.* from rinchan_images as ri2, (select max(id) as maxid from rinchan_images) as maxid, (select rand() as rnd) as rnd where ri2.id >= maxid.maxid*rnd.rnd and ri2.id < 1+(maxid.maxid)*rnd.rnd limit 1) as ri1;

をムダに改良してみることにしました。

まず連番で飛びがない前提なのでfloorを使ってwhere部分をすっきりさせつつ、1件しか返ってこない前提なのでlimit 1もとります。ます。その上で、ランダム値がN個入ったテーブルを用意すればいいじゃないかということでそのへんを改良。

select ri.* from rinchan_images as ri, (select max(id) as maxid from rinchan_images) as maxid, (select rand() as rnd from rinchan_images limit N) as rnd where ri.id = floor(maxid.maxid*rnd.rnd);

これで完成・・・と思いきややっぱりまだ甘くて、rand()使ってる限りはN回呼んだらN個ランダムに引っ張ってこれるとは限らない。・・・てかこの問題ってNを増やせばいいとかの結局カイ二乗分布の話に行き着く・・・「時々N個にちょっと足りなくてもよい」なら、この構文使って N*4個くらい引っ張ってきて最後に limit N しとくのがたぶん無難なんだろうなぁ。

というわけで、根本的な問題「重複しないランダムな値をN個持ってくる」が残ります。これは一般的にはコストのかかる問題で、もう一般的には「重複しないN個がそろうまでひたすら乱数を振り続ける」しかなさそうです。確率問題なので「乱数を振り続けても一生N個そろわない」可能性だってあります・・・てか「振り続ける」んだから「一生」はないのか・・・

重複しないN個の乱数を引っ張ってくる処理は、SQLでもプロシージャとかつけばたぶんできるんでしょうけど、そこまでやるならスクリプト言語側でやった方がいいやということで、こんな感じの関数でも作った方がいいでしょう。

function make_random_list_string($maxnum, $count){
  $tmp_random_array = array();
  do {
    $maked_num = rand(1, $maxnum);
    if (in_array($maked_num, $tmp_random_array)){
      continue;
    }
    $tmp_random_array[] = $maked_num;
  } while (count($tmp_random_array) < $count);
  return  implode(',', $tmp_random_array);
}

なんか「mt_randはrandよりも4倍速い」らしいけど、それはlibcのrand()関数が線形合同法だったりまだ怪しい時代だった時の話で、まともなrand()関数になった今時のlibcだとそういうことはないみたい。手元で試す限りmt_rand()の方が5%くらい早かったけどほとんど差がなし(PHP 5.1.6, glibc 2.5-107.el5_9.5) であとはこの関数の結果を where id in とかにしとけば完成と

$sql = 'select * from rinchan_images where id in (' . make_random_list_string($maxnum, $count) . ');';

ただこれだと、見つかった$count個のレコードがテーブルに格納されていた順に取り出されてしまう。たいていはレコードが挿入された順かな。これを防ぐためには、見つかったレコードをもう一度order by rand()しなおすしかないと。

$sql = 'select * from rinchan_images where id in (' . make_random_list_string($maxnum, $count) . ') order by rand();';

ちなみに今は「where id in (...)」の...が定数値だからあまり問題ないですが、ここが複雑なサブクエリになると最適化がいろいろ怪しいらしいので、書き方要注意のようです。

こんどこそ完成・・・と思いきやまだ穴があって、このやり方だと、このSQLを送るタイミングと、$maxnumを取得するために先に実行しておく予定の「select max(id)」を送るタイミングとの間に隙間があって、そこでupdateとかinsertとかが起こっているといろいろめんどい。そうそう気にするとこじゃないけど、そこまで気を回すならばトランザクション使っとくしかないよね。この場合必要なトランザクション分離レベルはREPEATABLE READ以上になるのかな。

てなわけで、いろいろ考えてみたもののやっぱりこれは一般には簡単には解決できない問題のようです。

「続々: SQL使ってテーブルからランダムにN件引っ張りたい場合」にさらに続いてしまったようだ。

知り合いに聞いたんだけど、どうも「フルスタックエンジニア」っていうのが最近のbuzzwordらしい。どれくらいbuzzwordなのかというと、togetherに皆の好き勝手な意見がまとまってるくらい。

とまぁこの手のは結局そもそも論に行ってしまうんだけど、どうも「上から下までちょーよくわかってるスーパーハカー」みたいなもんかという理解で、適当にググってトップに出てたページ(最近よく目にする「フルスタックエンジニア」とは何だろうか？)にいってみてあらびっくり。

設計とデプロイの深い経験があり、PythonとDjangoフレームワークのエキスパートで、JavaScript/CSS/HTML5のスキルとBackbone.jsかEmber.jsのJavaScript MVCフレームワークのスキルがあること、と。

・・・？フレームワークの中まで知ってればOKなの？それより下はどうでもいいの？

そりゃおまえ、フルスタックエンジニアってったら、まずは良質な石英の採掘からでしょ。発電用のウラン採掘とウラン濃縮に並行して、効率的な空調のためのインバータ開発、最新プロセスでのFab建築のために投資資金集め、gTLDの申請は必要だし、IXへの接続も考慮に入れて、斬新なアーキテクチャのCPUを設計し、安価にDRAM供給確保すべく業界No.1メーカをねらい、開発効率を上げる新たなプログラミング言語作って、最適化度のすごいコンパイラも用意し、フルスクラッチOSの開発、その上で動くスケーラブルなメモリ＆スレッド管理プログラム、耐障害性とパフォーマンスを両立するストレージエンジン、シンクライアントを実現する強固なクラウドサーバ管理に、リッチクライアントなユビキタス端末の業界標準を作り・・・

いやいや、マジメに答えたいわけじゃないんだけど、「フレームワークより下」を表すような言葉が具体的には何も出てきていない当たり、本当にそれより下をよく知らないんだろうなぁと思わざるを得ないです。

とはいえ、本当にそんな広範囲をマスターしていてかつ経験も豊富なエンジニアが現実にどれだけいるんだろうかという疑問もあるわけです。もしいたとしても、そんじゃそこらの求人見て応募してくるような生活しているとはとても思えない。

結局のところ「なんでも知っている」んじゃなくて「必要あれば調べて習得することができる」のが大事なんよねぇ。知らないことに出会ってあきらめたらそこで試合終了そこがあなたのエンジニアとしての限界ですよ。

結論先に書くと、根が深い問題なので一般化すると難しいです。が、規模が小さくて(数万件程度まで)primary keyが1つだけの場合は、

select * from rinchan_images where id in (select id from rinchan_images order by rand() limit N)

な感じで。MySQLが「ERROR 1235 (42000): This version of MySQL doesn't yet support 'LIMIT & IN/ALL/ANY/SOME subquery'」とかたれた場合は

select * from rinchan_images where id in (select id from (select id from rinchan_images order by rand() limit N) as hoge)

な感じで。( thanks to LIMIT付きのサブクエリでWHERE INしたい時のメモ)

みなさん、たくさんのリンちゃんの画像の中からランダムに20個引っ張ってきて眺めたいなんてこと、よくありますよね。あまりにありふれたシチュエーションなのでググればSQLのサンプルもすぐに見つかるかと思いきや、そうでもなかった。というわけで、世の中がリン廃で統一されるのはもう少し先のようです。・・・なことが言いたいんじゃなくて・・・

MySQLの場合、比較的すぐに「order by rand() を使え」てのが見つかります。が、それ以上に、ググった結果の上位に「order by rand() は使うな」というのも見えてきます。使うなっていうのの例だと、こことかこことか。結構ややこしい話なので順番に見えていきましょう。

まず、MySQLは「order by rand()」という機能をこういう目的のために提供してます。が、その内部実装はどうも、keyをテンポラリテーブルに並べてで乱数振って出てきた値を使ってkeyを並び替えてその結果を引っ張ってくる、ということのようです。

mysql> explain select id from rinchan_images order by rand() limit 1;
+----+-------------+-------+-------+---------------+---------+---------+------+------+----------------------------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+-------+---------------+---------+---------+------+------+----------------------------------------------+
| 1 | SIMPLE | twit | index | NULL | PRIMARY | 8 | NULL | 4213 | Using index; Using temporary; Using filesort |
+----+-------------+-------+-------+---------------+---------+---------+------+------+----------------------------------------------+

というわけで、この方針で行くなら、order by rand() で selectされるのは極力primary key のみにしておき、primary key以外のカラムもほしい場合はサブクエリとか使ってクエリを分けるべきとなります。というわけで、最初に示したような例になります。

でもちょっと待って、リンちゃんの画像なんて10万個や100万個くらいあるのが普通なので、primary keyを全部集めてテンポラリで並べ替えなんてオンメモリでできないです。・・・いや100万個ならメモリに乗るけど。でもやっぱりテンポラリテーブル作って並び替えるには負荷が高い。手元テストだと、10万件で0.9秒、100万件で9秒のオーダです。＠Atom N270 (1.60GHz Sinle(with HT)), DDR2-533 2GB。というわけで、件数多いとやっぱりつらいです。

回避策は、MySQLのマニュアルのコメントからリンクされてるページになり、要するにselectの外で別途乱数振れということですね。さらりと書いてくれてますがこれも結構やっかいなんです。ここから長いですがauto_incrementで連番が一切空いていないという仮定で話が少し続きます。

連番かつ空きがない場合は、0以上max(id)未満の値を引っ張ってきてそれに合致する行を1つだけselectすればいいわけです。無理矢理1つのSQLにするとこんな感じ。

select * from (select ri2.* from rinchan_images as ri2, (select max(id) as maxid from rinchan_images) as maxid, (select rand() as rnd) as rnd where ri2.id >= maxid.maxid*rnd.rnd and ri2.id < 1+(maxid.maxid)*rnd.rnd limit 1) as ri1;

1件じゃなくてN件なら「+1」を「+N」にすればいい・・・かと思いきやそれだと「ランダムに選んだ位置から連続してN個」になるのでNG。じゃこのSQLをN回実行すればいいかというとrand()とはいえ同じ値を引いてしまう可能性もあるのでやっぱりダメ、N/(count) くらいの確率で同じ値を引いてきてしまうのを覚悟しないといけない。まぁ異なるN個が出るまで何度も繰り返せばいいという手もあるけど。

その辺も考慮して1つのSQLにするとこんな感じ。

select * from (select ri2.* from rinchan_images as ri2, (select max(id) as maxid from rinchan_images) as maxid, (select count(*) as cnt from rinchan_images) as cnt where 4*N > cnt.cnt*rand() limit N) as ri1;

「4*N」ていうのが小細工で、いくらrand()が一様分布に従うことがわかっているからと言ってN回の試行でキレイに1/Nに一様分布するとは限らないので多めに取ってきてlimit Nしてます。ここでは適当に「4倍」しましたが、何倍にしないといけないかは実は結構小難しい話です。

何倍必要かは、一様分布に対するカイ二乗分布を考えないとダメな話となります。N個の等間隔の分割は例としてよく載ってるけど、今は N/count と (count-N)/count との2分割でのカイ二乗分布なのであんま例が載ってなくて私もよくわからない・・・たぶん自由度1でいいはずなんだけど・・・とりあえず手元でシミュレーションした結果こんな感じになりました。シミュレーションに使ったC#のソース

• N=1 の場合、+4で99%, +6で99.9%, +8で99.99%
• N=2 の場合、+6で99%, +9で99.9%, +11で99.99%
• N=3 の場合、+8で99%, +11で99.9%, +14で99.99%
• N=4 の場合、+10で99%, +12で99.9%, +15で99.99%
• N=5 の場合、+11で99%, +14で99.9%, +17で99.99%
• N=6 の場合、+13で99%, +16で99.9%, +19で99.99%
• N=7 の場合、+14で99%, +18で99.9%, +21で99.99%
• N=8 の場合、+15で99%, +19で99.9%, +21で99.99%
• N=9 の場合、+17で99%, +21で99.9%, +24で99.99%
• N=10 の場合、+18で99%, +22で99.9%, +26で99.99%

というわけで、+12か*3のうちの大きい方を選んどけばとりあえずOKっぽいです。とはいえ、しょせん乱数振ってるだけなので、例えたくさんめに取ってもものすごく低い確率で足りないことが起こりうることになります。auto_incrementで連番が空いていない前提でもこれです、ああ怖い。

連番が空いている場合、空き具合にもよりますがほとんど空いていないような場合は「えいや」で連番っぽく扱えばいいでしょう。ごくまれに出やすいヤツがいる程度で、実際にはほぼ誤差範囲でしょう。連番が結構空いている場合は、もはや一様分布を仮定できないので、ランダム値でselectするというやり方が崩壊して、より一般的なやり方に帰着せざるを得なくなります。

より一般的なやり方は「select * .... order by (primary key) limit N offset n」を使うやり方です。あらかじめ「select count(id) from rinchan_images」でcountを求めといた上で、0以上count未満の乱数nを発生させて、N個を引っ張ってきます。このままだと連番N個なので回避するにはN=1で必要な回数分だけたたくしかなさそう。・・・私の力では1つのsqlで書くことはできなかった・・・

ただこの「limit N offset n」というのも、nがテーブル内の個数に近いくらい非常に大きいとスケールしないやっかいな構文です。2カラムしかないテーブルだとこのまま「limit N offset n」とたたいた方が早かったですが、カラム数によっては先の例のように先にidだけをselectしといてそれを使ったサブクエリでid以外のカラムを引っ張ってきた方がいいかもしれません。

とまぁ大まかにこんな感じです。要するに一般化すると実質ムリです。auto_incrementでなかっただけでもこうなり、primary keyが複数行の場合とかもう考えたくもないですね・・・と思ったけどprimary keyが複数行の場合は単純に並べればいいだけか。MySQLってサブクエリに複数行書けたっけ？手元のMySQL5.1で試したらいけたっぽい。ということで、primary keyが複数行の場合はSQLに書き下すのがめんどいだけで、実質問題なさそうですね。

根本的にこの問題を解決したい場合は、そういうことができるようにデータ構造をあらかじめ準備しておくしかないです。つまり、SQLに頼らないレベルで、かつ乱数を使ってランダムに行を引っ張ってこれるように、事前に設計しておかなければなりません。

なんでこの話こんなにややこしいかというと結局、理論的なRDBMSがそもそも「順番」を扱えないからです。そもそもRDBMSが扱えるのは集合に対する選択・射影・結合で、それ以外のは各種エンジンが勝手に実装しているに過ぎず、たとえばorder byなんかは結果を一度出力してからそれを並び替えているだけですね。順番なんてのは並び替えられた後にしか存在しない概念です。というわけで、小難しくRDBMSだ正規化だとか考えるくらいなら、auto_increment使っといた方がいろいろ小細工がききやすい・・・ように感じられる今日この頃です。

・・・あれ、ところでぼくのリンちゃん画像(ランダム20件)は？

続: SQL使ってテーブルからランダムにN件引っ張りたい場合に続くようだ。

2013/08/20(Tue)に追記、この手のは既存のTwitterクライアントの実装を参考にすれば簡単だった・・・たとえばOpenTweenのThumbnailGeneratorクラスとか見れば一発ですね。

文字数制限のあるTwitterの影響なのか、ここ最近は短縮URLサービスが盛んです。同じサイト内で転送するならまだしも、他のサイトへも特に何の制限もなく転送するのも多くて、事前にドメイン確認できなくて危ないサイトに不用意にアクセスしかねないなぁ、とか思うわけですが。まぁそんなそもそも論はおいといて・・・

短縮URLで記されたものからたとえば画像のサムネイルを並べたページを作りたい場合、短縮URLからどうやってサムネイル画像のあるURLを引っ張ってくるのかがめんどいです。結局のところ、各種サービスのヘルプなりAPI仕様なりをちゃんと読めってのが王道なんだけど、それすらめんどいような(私のような)人のために、とりあえず簡単にまとめておきます。

● t.co
Twitterが提供する汎用URL短縮サービス。TwitterはAPIを使って短縮URLを解決しろというスタンスのようで、たとえばuser_timeline.jsonやshow.jsonに「include_entities=t」オプションをつけてアクセスすることで取得できるentitiesのurlsを参照しろとなってます。

Twitterの場合2年前くらいから公式の画像アップサービスを、そして8ヶ月ほど前には動画アップサービスのVineをやってます。これらについては、上記の「entities->urls」には記載されず、代わりに「entities->media」に記載されます。わざわざデータ構造を分けられてちょっとめんどいですが、mediaの場合だと画像直のURLが手に入ったり、画像のサイズがわかったり、といったメリットがあります。・・・動画は試してないから知らん・・・

● twitpic
twitpic developers API Documentationに記載があります。たとえば「http://twitpic.com/d7gln4」の場合は「http://twitpic.com/show/thumb/d7gln4」で画像が直でとれます。

● ついっぷる
API Thumbnailに記載があります。たとえば「http://p.twipple.jp/uQSTl」の場合は「http://p.twipple.jp/show/thumb/uQSTl」で画像が直でとれます。

● ニコニコ静画
記載が見つけられなかった・・・たとえば「http://seiga.nicovideo.jp/seiga/im3109882」の場合は「http://lohas.nicoseiga.jp/thumb/3109882q」で画像直がとれます。「q」が大きめサムネイル、「i」がオリジナル、(何もつけないのも含めて)それ以外が小さいサムネイル、のようです。

● フォト蔵
フォト蔵APIとはに記載があります。たとえば「http://photozou.jp/photo/show/2053083/183823434」の場合は「http://photozou.jp/p/img/183823434」で画像直がとれます。

● Instagram
Embedding Endpointsに記載があります。たとえば「instagram.com/p/cuDILYD62u/」の場合「http://instagr.am/p/cuDILYD62u/media/?size=t」で画像直がとれます。「instagr.am」ででも短縮URLサービスやってる(途中で切り替えた？)ので、やるなら両対応が必要です。

● img.ly
Viewing imagesに記載があります。たとえば「http://img.ly/vNOE」の場合は「http://img.ly/show/thumb/vNOE」で画像直がとれます。・・・でもなんか時々とれない画像があるような・・・

● yubitter
yubitterが「http://p.ybt.jp」でサービスやってるようですが、ここのはそもそもがjpegファイルへの直URLばっかりっぽいので、特に心配なし？

● そのほか
もしメジャーなヤツで漏れがあれば指摘いただければと思います。

これで大まかには対応できるんですが、しぶといヤツが2ついます。pixivとpiaproです。どうもここは外部から直接画像を参照してほしくないような感じです。もちろんページのHTMLを引っ張ってきてパースすればなんとでもなるんですが、あっちがやってほしくなさそうに見えることをわざわざやるのもということで、いったん対応は見合わせました。

・・・まぁこんな風なことをやるために調べてたわけで、完成したらオレ、リンちゃんの画像に埋もれて窒息死するんだ・・・