30days Album はどのようにして画像にアクセス認証をかけているか

30days Album は画像の URL にもアクセス認証を入れています - 刺身☆ブーメランのはてなダイアリー の技術的な解説。基本的に 関西オープンソース 2008 30days Albumの裏側 のとおり。

ミドルウェアはこのスライドのときと比べてけっこう様変わりしている。 Perlbal は相変わらず使ってるけど。

• リバースプロキシは nginx
• バックエンドに Apache (Passenger) と Perlbal
• 静的ファイルは nginx が配信
• 画像の URL は Perlbal にプロキシ
  • 画像認証用の Perlbal Plugin がセッションストレージの Kyoto Tycoon に認証情報があるか問い合わせ
  • それ以外にも提携している外部サービスのために特定の IP アドレスは素通りさせたりしている
  • 画像ストレージは MogileFS なので X-REPROXY-URL などでよしなに配信
• それ以外の URL は Passenger (Rails) にプロキシ
  • アルバムを閲覧するときは、
    1. Rails 側でログイン処理時にセッションストレージに認証フラグをたてる
    2. Perlbal はフラグをみてレスポンスを出し分ける

現状把握している問題点

• ログイン認証なしで閲覧できるアルバムの場合は「最初にアルバムを閲覧したとき内部的にログインと同じ処理をする」のでアルバムの URL を一度も訪問してないと認証かけなくていい画像の URL も直リンクで閲覧できないまま（ブログとか外部サイトに貼り付けられない）
  • いまのところアドホックに「このアルバムは特別に許可」とかやってるけど oEmbed とかでちゃんと解決したい
  • アルバムじゃなくてフォトストレージのほうはインターネット全体に公開することも可能（新しく公開用の画像 URL ができる）

あと、規模的な話。 30days Album にある画像は MogileFS 調べで五億枚くらい (オリジナル画像だけじゃなくてリサイズしたサムネイル画像、あと一括ダウンロード用の ZIP ファイルも含む) なので、 Facebook, Picasa, mixi などと比べるとおそらく二桁か三桁、ひょっとすると四桁くらい少ないと思う（参考: はてなで約 41 億）その規模になっても今のような仕組みで画像へのアクセス認証の仕組みを維持できるかはわからない（このままではスケールしないと思うので）まぁ当然だけどこれをもって Facebook などより優れていると言うつもりはない。

こういう話も機会があればまた紹介したいですね。図を描くのが面倒だけど。