ぱぱネット（仮）

_ [Linux][開発] 東日本大震災以来

あの地震と津波で、自宅でバックアップってことが 意味がないこともある。 という事実を、多分日本中の人が思い知ったと思うんだよね。つまり地政学的リスクというやつ。もうそろそろ風化しているのが悲しいが。

ローカルバックアップさえ行わなくてデータを飛ばし続けている俺が、いまさら地政学的リスクなどと言うと、一生ならぬ一笑にふされるであろうが.....最近自分より大事な人ができたので少し真面目に考えてみよう、というのが本稿の主旨である。なお、ここでの「一生」とは「あと高々30年」という前提にたつ。

_ [Linux][開発] Amazon Glacierを使おう

先に結論を書くと、2013年時点では、 Amazon S3とGlacierの自動連携を使うのが最適 という結論に達した。以下に理由を長々と述べる。

HDDはどうか？

この話では 自宅には1次変更先としてのHDDを残しておく のは前提としてある。それをRAID NASで残しておくのも一考に値する。

BUFFALO テラステーション ネットワーク対応HDD(NAS) 2TB TS-WX2.0TL/R1

しかしバックアップメディアとしては....20MBのSASIインタフェースHDDから20年以上HDDを使い続けているが、HDDはとにかく壊れる。 さらに「重くて持ち運びにくい」ので、震災はおろか単なる引っ越しでも壊れる可能性がある。

SDカードはどうか？

最近、俺の親も含めてメモリカードは壊れないものだと考えている人が多いようだが.....SDカードやパソコンのSSDで使われている フラッシュメモリは早ければ5年めくらいから揮発し始める。 ただ、最初からフラッシュメモリのチップには、ECCなどのエラー訂正回路が入っているので、多少抜けても訂正限界までは大丈夫というだけの話。たちの悪いことに、フラッシュメモリの微細化や多値化(SLC, MLC, TLC)にあわせてドンドン悪化する。だから今でもわざわざSLCチップ採用のSSDが売られているくらいだ。

誰もその日を迎えていないが30年は保たない構造だろう（もちろん途中で全コピーし直すと寿命は伸びる）。

光学メディアはどうか

どう考えても光学メディアは論外 だろう。だいたいDVD-R, BD-Rあたりは有機色素を採用しているので、日光を1日当てただけで半分は 分解 してしまうようなしろもの。BD-REやMOドライブなどの相変化メディアは100年くらい保つと言われているが「30年後、光学ドライブ手に入るのか？」で全て論破。なんせロジテックが2013年に「最後の出荷MOドライブ59800円」 をやったくらいである。今でもMOドライブを使い続けている人がいるのは、ひとえに「コピーが面倒くさい」に尽きると思うんだよね。一瞬で吸い出して業務システムごと移行できるなら誰でもやると思うんだ。

じゃあクラウドだ！

まあ、ネットにコピーしておけば、自宅が全壊しても大丈夫。逆に単体メディアにないデメリットは 「容量」「価格」「サービス継続性」 だ。ここではどうしても失いたくない個人データを400GB前後と定める。欲張るとキリがないわけだが、ぱぱネット（仮）でいうと、あいあんさん当たりはデジカメのデータだけで200GBはあるはず。

容量だけで料金を比較してみるとこうなる。

いやー...改めて表にするとDropbox高いね。その分、高性能の差分クライアント、ファイルの履歴管理で捨てたファイルでも戻せるとか、いろいろ特徴はあるのだが、バックアップ先としては中々キツい金額だ。30年間に料金は下がって行くだろうけど。

この中ではPogoplugが一番良さそうに見える。しかし、Pogoplugはサービスの改変を何度も繰り返して非常に分かりにくいサービスになっている（日本語のページも出来がよくない）のでまとめると....

• 純然たるクラウドストレージではない
• ユーザはPogoplugというデバイスを購入、外付けUSBHDDをつなぐ
• Pogoplug Family Proというクラウド契約をつけると、オフサイトバックアップストレージという機能が使える
• 家のHDDにコピーしておくと、しばらくしてAmazon Glacierというクラウドにバックアップされる

おお！これは良さそうじゃないか！........と思いますよね。基本は自宅にデータがある、というモデルにも沿っているし、何よりクラウドの維持費が安い。しかし....30年と言わず

という激しい疑問がある。このサービスを、Linuxデバイスの派生品としてPogoplug Classicの頃から眺めていた俺の正直な感想。10年後、津波に流された後で、同じデバイスが手に入り、間違いなくデータを復旧できる、という確信が持てない。

いっそ それならAmazon Glacierを直接使えばいいんじゃね？ という結論にたどり着く。

_ [Linux][開発] Amazon Glacierを使う

Amazon GlacierというのはAmazon が提供しているバックアップ用のサービス。 グレイシャー(Glacier)とは氷河のこと。そこに貯蔵庫(Vault)を作ってデータを貯める。アーカイブの平均年間耐久性が 99.999999999% となるように設計され、北米、北欧、日本のリージョンに多重バックアップされる。料金は計算が難しいが、 400GBを貯めるだけなら年間4650円($48) である。

99.99.......%ってあんた、間違いなく俺が手違いで消す確率の方が高いわ！

ただ、デメリットもあって....

• 取り出し時、データが用意されるまで数時間〜数日かかる
• 取り出しにお金がかかる(特急料金)
• バックアップ時にファイル名などのメタデータが失われ、16進数の羅列のチケット(ID)が帰ってくる

ということ。まあ最初の2つはいいけど、くせ者は最後だなあ。 実は、Pogoplugをはじめ、Glacierを簡単に使えるサービスが売られているのだが、どんな名前のファイルをいつバックアップしたか？というメタデータが(Pogoplug社に)牛耳られるってこと。だからサービスの継続性が問題になるわけ。

ここで、あえて利便性を捨て、面倒でもAmazonを直接使うというのは、サービス継続性ではAmazon単体を使うのが一番ベターな解だなあと思う。 Amazonは既に「本のオンラインストア」ではなく、東京証券取引所やNASDAQも使っている、Amazon Web Servicesという世界最大のネットサービスを運営する企業であるから。 そして、そのネットワービスを外部に解放し、自社は自社サービスとして積極的に活用（ドックフードを食う、と呼ばれる）しているのだから。

長くなったので使い方は明日以降。

• リコー、オンラインストレージ「クオンプ」サービスを終了
• “ソラ箱”が終了 - 窓の杜
• 窓の杜 - 【NEWS】“ZumoDrive”が5月1日でサービス終了
• 本当に使えない：HP Upline、開始早々にサービス停止
• ソニーのライフログサービス「Life-X」終了

_ .....というわけで死屍累々の状況であった。 正直何の技術的工夫もない「ソラ箱」あたり はすぐに死ぬと思っていたけどクライアントアプリきちんと作ってた ZumoDriveまで終わるとは思ってなかった。オンラインストレージは淘汰が進んでいる。

別に永遠に保つ必要はないんだが(乗り換えるので)、 少なくとも自サーバの寿命よりはサービスの寿命の方が長くないとなあー。

_ [Linux][開発] 写真をAmazon S3+Glacierで永遠に保存する

Amazon AWS

アカウント作成の流れ(http://aws.amazon.com/jp/register-flow/)を 参照して、AWSのアカウントを作成する。最低限必要なのは、

• メールアドレス
• 電話番号
• クレジットカード

身元確認は面倒だが仕方がない。

AWS Management Console

マネジメントコンソール(http://aws.amazon.com/jp/console/)にアクセス。 Amazon S3のアイコンをクリックする。最初はバケット(フォルダのようなもの)が ないと思うので適当に名前をつける。ここではto.papa.homeとした。

ライフサイクルルールの設定

元々S3はWebサーバとしても使えるストレージなので、特定のバケットに対して Glacierに凍結貯蔵するというルールを追加する。

1. バケットを選択
2. 右上のPropertiesが選択されていると右ペインにプロパティが出るのでLifecycleを選択
3. Add ruleというボタンが出てくるのでクリック。
4. Lifecycle Ruleというパネルが出てくるので、Nameを適当に入力
5. 続いてApply to Entire Bucketをチェックし、Prefixは空のままにする
6. 続いて+Move to Glacierボタンをクリックして、Time Periodに1を入力
7. Saveして終了

今回の設定ではS3にコピーしてから1日(*)くらいは自由に出し入れできるが、 それ以上経つとGlacierに凍結されるという設定にした。

なお、Expirationは一定日時経ったら削除する、というルールなので 絶対に設定しないように。これは例えば増え続けるアクセスログを溜め込みすぎないように 古いものから捨てるときに使うもの。

一旦S3にコピーすることでS3のストレージ料金がかかることが考えられるが、 正直誤差の範囲内であろう。それよりもAmazon本体にファイルのメタデータの 管理を委譲できる利益の方が遥かに大きい。Amazonさえ潰れなければ データを取り出すことはできるという１点において。

ファイルコピー

バケットを選択してUploadボタンをクリックするとダイヤログが出てきて、 ブラウザからファイルをアップロードすることができるが、ファイルが 多いとやっていられないと思うので外部クライアントを使う方法を紹介。

AWSはクライアントに直接アカウントとパスワードを指定せず、 アクセスキーとシークレットキーを書き込むことでアクセスできるようになる。

アカウントアクティビティ⇒ セキュリティ証明書⇒アクセス証明書とたどり( https://portal.aws.amazon.com/gp/aws/securityCredentials) アクセスキータブからアクセスキーIDとシークレットアクセスキーをコピペすればOK。

• Windows: クラウドベリー(http://www.cloudberrylab.com/free-amazon-s3-explorer-cloudfront-IAM.aspx)
• Mac: 3Hub(http://www.3hubapp.com/)
• Linux: s3cmd(http://s3tools.org/s3cmd)

あたりが有名なクライアント。

Storage Class

どうも私の場合はきっかり1日ではなく、 1日半くらいしてからStorage ClassがStandardからGlacierに変更された。 ちょっとヤキモキしたのは事実だ....

_ [Linux][開発] 気になる料金

みんなが一番気になる料金。今回使ったS3/Glacierは完全にS3に統合されているので、 GlacierではなくS3の料金表をみてみる(http://aws.amazon.com/jp/s3/pricing/)。

PUT、COPY、POST、または LIST リクエスト	$0.005 1,000 リクエスト当たり
Glacier アーカイブおよび復元リクエスト	$0.05 1,000 リクエスト当たり

つまり、ファイルを1000個アップロードすると$0.01かかる計算に。 個人の写真アーカイブなど高々10万枚くらいだろうから$1ってこと。 でも 10万個に復元リクエスト出して5時間待ってダウンロード は あんまりやりたくないので(汗；)ある程度の単位でtar.gzなどで固めておくのが セオリーかと思います。 どうせなら写真の重複等も取り除いておいた方がよろしいでしょうな。

私は結婚式の写真とiPhotoのoriginalを圧縮したものをアップロードし、 61GiBほどになりました。ここで Glacier料金表(http://aws.amazon.com/jp/glacier/pricing/)をみてみる。

ストレージ料金表 $0.01 GB あたり/月

61GiB置いておくだけなら毎月$0.61 = 57.95円で済む .....はずなのですがはてさて(^^;

_ [Linux][開発] photomgr.plの概要

photomgrは、写真の重複を削除し日付ベースのファイル名にコピーし直すコマンドラインツールです (ダウンロード:photomgr_20130620.tgz) 使用について起きたファイル喪失、装置の故障などの損失について、私は一切責任をもちません。 まあ使う人もいないでしょうが、必ずバックアップをとってから実行してね。

_ [Linux][開発] 動作環境

• データベースTokyoCabinetが必要です。
• Imagemagickのconvertコマンドが必要です。
• Perlが必要です。
• PerlモジュールのImage::ExifTool, Imager, TokyoCabinet, DateTime, Digest::SHA1が必要です。

_ [Linux][開発] 実行

コマンドライン

% perl photomgr.pl [-srcdel] [-lazy 0.8 .. 1.0] 入力ファイルリスト 出力ディレクトリ

• 対応ファイルは, *.jpg, *.png, *.mov, *.avi, *.mod, *.mpg, *.mp4です
• 入力ファイルリストはfind 写真のあるディレクトリ -type fした結果（ファイルのリスト)です
• 出力ディレクトリにはoutput_j(JPEG), output_m(MOVIE), output_p(PNG), db(DATABASE), trash(ゴミ箱)が作られます
• オプション-srcdelをつけると入力リストのファイルを処理後に削除します(注意！)
• オプション-lazyは画像比較アルゴリズム用のしきい値です。デフォルトは1.0(最大)です

アルゴリズム

1. 入力ファイルのSHA1(ハッシュ)を計算します
2. 既存ファイルにSHA1が一致する場合は無条件にスキップします
3. 既存ファイルにSHA1が一致しない場合は出力ディレクトリにコピーします
4. コピーファイルの名前は写真の撮影日(ExifのCreateDate,またはその他の時刻情報)からYYYYMMDD_hhmmss.拡張子に加工します
5. コピーファイル同士が衝突した場合は、衝突ファイル同士で画像ヒストグラムによる類似度を計算します
6. 類似度(MIN:0, MAX:1)がしきい値lazyと同じか大きい場合は「同じファイルである」と判定してコピーしません
7. 類似度がしきい値lazy未満の場合はYYYYMMDD_hhmmss_DP数字.拡張子というファイル名でコピーします
8. 類似度(MIN:0, MAX:1)がしきい値lazyと同じか大きい場合で、かつオリジナル(YYYYMMDD_hhmmss.拡張子)の方が小さい画像の場合は、オリジナルと_DP番号付きのファイルを入れ替えます

_ [Linux][開発] 作った経緯

そうだ！写真を整理しよう！ と思って、 自分好みの命名方法になるようなソフトを探しましたが、無かったので作りました。

• 今までWindows, Macで色々な写真管理ソフトを渡り歩いてファイルの命名方法がまちまち
• 「大事な写真だから」と分散したディレクトリに、同じファイルがたくさん重複している
• ブログのアップ用の縮小画像や、縦横回転した写真まで同じディレクトリに混じっている
• Amazon S3+Glacierに写真を突っ込む場合、ある程度の固まりでアップロードできるように年単位で整理したい
• 今使ってるiPhotoは、ムービーファイルも写真と同様に管理にされてしまい、ディレクトリを分けたかった

なお、画像比較アルゴリズムはこちらのブログをコピペしました(http://blog.vg4.net/archives/1318891.html)。 ヒストグラムのみの比較なので全然違う画像が類似度1.0と判定されることがあるので、 今回は撮影日が衝突したもの同士のみを比較しています。 Perl Imagerが死ぬほど遅いので画像の縮小だけconvertを使っています。

_ [Linux][開発] Twitterアイコン画像検索icon.papa.toをリリースしました

http://icon.papa.to/

1. 右上のリロードボタンを押すとランダムにアイコンが出てきます
2. 探したい人のアイコンに「似ている」アイコンを選択するとフリップします
3. 別人だった場合はscreen_name(papanda1234,みたいな)をクリックします
4. すると...そのユーザのアイコンに「似ている」アイコンが出てくるので後は芋ずるで！
5. name(ぱぱんだGNU/Linux,みたいな)をクリックすると別窓でプロフィールに遷移します
6. 検索ボックスに「自分のscreen_name」を入力すると運が良ければパクリも見つけられるでしょう

• 個人の趣味なので突然終了含め一切の責任はとりません（とれません)
• 犯罪とかに使わないでね(思いつかないけど)
• 推奨ブラウザはPC用のChromeです（それ以外の環境ではテストしていません)
• 画像の類似度アルゴリズムは混合ヒストグラム法です
• バックエンドは大規模データベースMongoDBです
• 現状は33万人分のプロフィールデータを収集しています
• 一応200万人くらいまで対応できるように開発しました
• でもWebの負荷分散はしていないのでクロールしないでください

_ [Linux][開発] 開発の背景と動機

顔ツイってなくなっちゃったんですかね？