GAEのログに警告出まくりに追記。別の警告が出るようになったのでソース修正。
今までは過去記事の書き換えは避けて、新しい記事を作って訂正してたけど、今となっては検索で直接読む人の比率も非常に高いと思われるので、どちらから見ても困らないようにしたくはあるなーと。うるさくならない程度に。
技術
BackWPupの転送先でちょっと迷った
WordPressのバックアップ関係の悩みがまとめて解決しそうな感触のこのプラグインだが、またしてもS3のリージョンで迷う。今回は深く考えずに東京に置いたが、例の重要データと同じように考えるなら、こいつも東海岸に置いた方がいいのかなあ。試しに東海岸に即時バックアップを掛けさせてみよう。7.52MBの転送を東京が一瞬で終わらせているところ、東海岸だと72秒か。マジで重いな。つーか東京だけ異様に軽いんだな。うーむ。
そこで思い出したのだが、このblogのサーバロケーションは大阪だったような。東西で分散してりゃ十分ではなかろーかと。うむ。所詮は俺のblogだし。
それにしても、ほんのちょっと使う程度でいいならS3最高かもなあ。対応してるソフトも多いし。個人用の丈夫で小さい金庫みたいな使い方なら一円未満で済みそうだし。触れ込み通りの丈夫さは期待してないけど、この価格帯の大抵のサーバと比べて同等以上くらいなら期待していい気はする。
つっても、金庫と違ってアレなデータとかは暗号化しても置きたくないな。それはどこのサーバでも変わらんが。つーかアレ系はふつー巨大だからオンラインとか無理だろー。
それより、これって少額の課金はどうなってるんだろうなあ。ちゃんと調べてみようか。ふむふむ。公式な告知ではないけど、1セント程度の少額ならシステム的に表示されても実際には請求しないっすよ、とあるな。そりゃそうか。請求しても金融機関しか得しないもんな。実質タダで使える範囲は思ったより広そうだ。くそー。Amazon嫌いのこの俺がー。
ただ怖いのは、青天井の従量課金なので、何かのミスなりバグなりで膨大なデータでも突っ込んだらえらいことになるであろうということ。特に東京リージョンは高速なので怖い。課金の上限設定も見当たらないしなあ。BackWPupのスケジューリングは激しく自由だから、毎分フルバックアップとかうっかり設定したらたまらん訳で。いやまあ、現状で8MB程度だから、えーと、毎分putを一ヶ月間やったら337.5GBの転送だから2700円くらいか。あれ。計算ミスってないか俺。この程度ならどーでもよくね？
あとはまあ、プラグイン自体のバグが怖いくらいか。ここは自己責任だよなあ…。
という訳で、S3の東京リージョンに月次バックアップ二世代、ローカルに毎日バックアップ二世代、という最初の設定を維持しそうではあった。こないだと同じだな。考えて試して結局変えないオチ。
しかし、月次バックアップ先をOsukiniに変える手はありかもしれない。FTPは使いたくないが、ローカルのバックアップを自前のスクリプトでscpすればいいのだ。そこまでS3を恐れることは無い気もしますが。
追記:
結局S3に送るのはやめた。この程度の用途なら、DropboxやSugarSyncのように上限のある世界の方が気楽だった。
Amazon S3の色々なリージョンを少しだけ試す
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は分割アップロードを実装していないので、使えなくなると厳しいなー。自前で書くのも出来れば避けたいけど。
Amazon S3のバケットの移動を検討する
リージョンを決める時、あまり深く考えずにデフォのアメリカ東海岸にしていた。移動したくなったとしても、バックアップする時点でコピー先を変えるようにすれば追加コストも発生しないだろう、と踏んでいたので。
具体的に言うと、バックアップ先を別バケットに変えて、バックアップ終了時点で旧バケットの中身を消去、である。古いバケットから新しいバケットに直接転送とかする訳ではないので、データ転送料金も変わらない。二回やれば、名前をキープしたままリージョン移動も出来る。
一時的にデータがダブるので容量も二倍食うが、これもさほど高くは付かないはずだ。何バイトを何時間保持したか、という課金形態っぽいので。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対策はどうでも良かった予感。
一応、別リージョンのバケットは作っておいたので、次のバックアップの時にそちらに送ってみようとは思う。
APCが死んでて重い
yum updateしたらblogが見えなくなった。またか。
まあ、どこのサーバだって落ちる時は落ちるよね、ってこないだ言われて少し気が楽になったけど（笑）。
今回はどうやらAPCの調子が悪いようで、とりあえず止めたら復活した。その代わり、当然だが重くなった。参りましたなあ。そのうち設定とか色々いじってみるか。人の少なそうな時間帯に。いや、Osukiniの方でやればいいのか。
ただ、エラーログを見てるとかなり変な物が出てるんで、設定でどうにかなるかは怪しい気もするが。eAcceleratorに乗り換えもありかもなあ。
原因調査中、久々にApacheも起動したりした。起動しなくなってたけど。CentOS5.6の問題ってこれかな。proxy_ajp.confを潰したら復活したが。