Osukiniへの週次バックアップが完了していたので、S3へのバックアップ先を色々変えて試してみた。
　とはいえ、真面目に転送するとお金が一円とか二円とか掛かってしまいますからして（どうでもいい）、ほんの五〜六秒の転送で実験。

　んで、東京リージョンへのs3cmdによるputはどう見ても1MB/sは余裕で超えてたので、SaaSesネック説はほぼ終了。
　そこから大幅に速度が落ちて、シンガポール、カリフォルニア、スタンダード（バージニア？）という順に速度低下。という訳で、シンガポールにすっかな、と思ったのだが、まあいいや。転送速度に本気で困るまではスタンダードで。

　単純な比較だと、転送速度がRTTに反比例している可能性も無くはない気がしたので、サイズ違いのファイル三つを並列転送してみる。スピードの出る接続と出ない接続があるなあ。一本だけ350KB/sで、他二本が110KB/sとか。そして、350KB/sのが終わっても、他の転送速度も劇的に向上はしない。そして、バルクとしての転送速度が230KB/s相当になった辺りで転送が終了した。もしかして遅くなっただけではなかろうか。
　まあ、東京なら転送速度が出る以上、この程度の並列でOsukiniのバックボーンへの過大な負担とかも無いはずだし、他の経路は巨大インフラだから気にするレベルじゃないし、cronに投げるのは逐次でも並列でも良さそうだが、次は逐次で試そう。

　そんなことよりAPIを見てて知ったのだが、単純な転送だと1オブジェクトの上限は5GBなのな。それ以上は分割アップロードが必要らしい。100MB以上なら分割した方がいいかもよー、とか書いてある。並列転送も問題無し。
　今のところはせいぜい1ファイル2GB程度でしか使ってないが、s3cmdは分割アップロードを実装していないので、使えなくなると厳しいなー。自前で書くのも出来れば避けたいけど。

　リージョンを決める時、あまり深く考えずにデフォのアメリカ東海岸にしていた。移動したくなったとしても、バックアップする時点でコピー先を変えるようにすれば追加コストも発生しないだろう、と踏んでいたので。
　具体的に言うと、バックアップ先を別バケットに変えて、バックアップ終了時点で旧バケットの中身を消去、である。古いバケットから新しいバケットに直接転送とかする訳ではないので、データ転送料金も変わらない。二回やれば、名前をキープしたままリージョン移動も出来る。
　一時的にデータがダブるので容量も二倍食うが、これもさほど高くは付かないはずだ。何バイトを何時間保持したか、という課金形態っぽいので。100バイトのデータを24時間保管したら、明細には2400バイト時と記録される感じ。1GBを30日保管して$0.15、という前提で概算すると、2GB日、48GB時で1セントの課金となるはずだ。つまり数時間のデータ増加はどうでもいい。…と思うが、何か勘違いしていたら怖いので、作業の前後では明細を確認しておきたい。

　で、東海岸のバケットだが、175KB/sしか出ていなかったのが気になる。S3のREST APIはエンコードとかもしてないようだし、単純に8倍して1.37Mbpsってことでいいのかな。SaaSesはユーザー全員で1Gbpsらしいから、Osukini側がネックという可能性もかなりあるなあ。
　BDPも気になったが、S3は直接pingを打っても返事が無く、EC2のインスタンスを立ち上げて調べるほどの気力も無いので、国内で調べた人の情報を漁ってみる。ふーむ。国外だとアメリカ西海岸がRTT的にはマシなのか。だが、Osukiniの許容BDPは126KBに設定されていて、東海岸でもRTTは200ms程度みたいだからBDPは35KBか。問題が出そうにもないなあ。
　という訳で、BDP対策はどうでも良かった予感。
　一応、別リージョンのバケットは作っておいたので、次のバックアップの時にそちらに送ってみようとは思う。

　yum updateしたらblogが見えなくなった。またか。
　まあ、どこのサーバだって落ちる時は落ちるよね、ってこないだ言われて少し気が楽になったけど（笑）。

　今回はどうやらAPCの調子が悪いようで、とりあえず止めたら復活した。その代わり、当然だが重くなった。参りましたなあ。そのうち設定とか色々いじってみるか。人の少なそうな時間帯に。いや、Osukiniの方でやればいいのか。
　ただ、エラーログを見てるとかなり変な物が出てるんで、設定でどうにかなるかは怪しい気もするが。eAcceleratorに乗り換えもありかもなあ。
　原因調査中、久々にApacheも起動したりした。起動しなくなってたけど。CentOS5.6の問題ってこれかな。proxy_ajp.confを潰したら復活したが。