久しぶりの更新かつ、まったくPerlとは関係ありませんが、、
同僚の奥さんが、浦和にまつげエクステ専門サロンをオープンするそうです。
自宅サロンでゆっくり丁寧にカウンセリング、施術をしてくれるそうなので、興味のある方は是非チェックしてみてください!
まつげエクステ専門サロンmido
2008年6月5日木曜日
2008年1月25日金曜日
adsという文字列を動画のURLに入れてはいけない
ユーザーから動画が見れなくなったという問い合わせが来たので確認すると、自分達の環境では普通に見れる。原因がよくわからない。
詳しく聞いてみるとどうやらIE7 ProというIE 7のAdd-onを入れてから見れなくなったらしい。ということでそれを入れてみたところ見事に動画が再生されなくなった。
さらに詳しく調べていくと、IE7 ProのFlash広告をブロックする機能が、プレイヤーが取得しようとする動画を広告とみなしてブロックしてしまい、動画を取得できないため再生できないことがわかった。
ブロックされていた動画のURLがこれ。
http://www.flipclip.net/ads/logo_animation_a.flv
この広告ブロック、広告かどうかの判定をURLにテキストマッチをかける形で行っていて、「/ads/」という部分が判定にひっかかていたみたい。
原因がわかれば対応は簡単!
動画のURLを変更することで無事問題解決しました。
めでたしめでたし。
詳しく聞いてみるとどうやらIE7 ProというIE 7のAdd-onを入れてから見れなくなったらしい。ということでそれを入れてみたところ見事に動画が再生されなくなった。
さらに詳しく調べていくと、IE7 ProのFlash広告をブロックする機能が、プレイヤーが取得しようとする動画を広告とみなしてブロックしてしまい、動画を取得できないため再生できないことがわかった。
ブロックされていた動画のURLがこれ。
http://www.flipclip.net/ads/logo_animation_a.flv
この広告ブロック、広告かどうかの判定をURLにテキストマッチをかける形で行っていて、「/ads/」という部分が判定にひっかかていたみたい。
原因がわかれば対応は簡単!
動画のURLを変更することで無事問題解決しました。
めでたしめでたし。
2008年1月18日金曜日
「FFmpegで作る動画共有サイト」が発売されます!
動画共有サイトを作ってみたいという方向けの書籍「FFmpegで作る動画共有サイト」が1/29にに毎日コミュニケーションズさんから発売されます!
FFmpegとはというところから始まり、インストールから各言語でのFFmpegの使いかた、実際にサイトを構築するところまで入ったてんこ盛りな書籍です。
僕も4章のPerlでFFmpegを使うという部分を書きました。
僕が書いた部分ですが、まずはシンプルにsystem関数を使ってPerlからffmpegを実行する方法をサンプルスクリプトを使って紹介し、そのスクリプトをffmpegコマンドの実行結果を取得したり、タイムアウト処理をすることができるように拡張していくという内容になっています。
拡張していくにあたって、誰でも簡単に試せるよう、CPANモジュールは使わず、標準モジュールと組み込み関数のみを使うようにしました。
ただ、CPANモジュールの便利さも知ってもらいたかったので、ここまでに拡張したスクリプトをCPANモジュールを使って書くとどうなるか?というのを最後に紹介しています。
ここではmizzyさん作のFFmpeg::Commandを使ってサンプルコードを書きました。
今回CPANモジュールを使うコードと使わないコードを書いてみて、改めてCPANモジュールの便利さを痛感しました。
これを読んで、Perlっていいかも、ちょっと試してみようかなと思ってくれる方が少しでも増えたら幸いです。
FFmpegとはというところから始まり、インストールから各言語でのFFmpegの使いかた、実際にサイトを構築するところまで入ったてんこ盛りな書籍です。
僕も4章のPerlでFFmpegを使うという部分を書きました。
僕が書いた部分ですが、まずはシンプルにsystem関数を使ってPerlからffmpegを実行する方法をサンプルスクリプトを使って紹介し、そのスクリプトをffmpegコマンドの実行結果を取得したり、タイムアウト処理をすることができるように拡張していくという内容になっています。
拡張していくにあたって、誰でも簡単に試せるよう、CPANモジュールは使わず、標準モジュールと組み込み関数のみを使うようにしました。
ただ、CPANモジュールの便利さも知ってもらいたかったので、ここまでに拡張したスクリプトをCPANモジュールを使って書くとどうなるか?というのを最後に紹介しています。
ここではmizzyさん作のFFmpeg::Commandを使ってサンプルコードを書きました。
今回CPANモジュールを使うコードと使わないコードを書いてみて、改めてCPANモジュールの便利さを痛感しました。
これを読んで、Perlっていいかも、ちょっと試してみようかなと思ってくれる方が少しでも増えたら幸いです。
FFmpegで作る動画共有サイト
posted with amazlet on 08.01.18
月村 潤 本間 雅洋 堀田 直孝 原 一浩 足立 健誌 尾花 衣美 堀内 康弘 寺田 学
毎日コミュニケーションズ (2008/01/29)
売り上げランキング: 15883
毎日コミュニケーションズ (2008/01/29)
売り上げランキング: 15883
・予価:2,940円(税込)
・B5変型判 272ページ
・ISBN978-4-8399-2466-9
・発売日:2008年01月29日
■内容紹介
YouTubeやニコニコ動画など、最近のWebサービスでは動画共有サービスが大人気です。その多くのサイトで、動画投稿時の変換に利用されているのがオープンソースの動画変換ソフト(エンジン)「FFmpeg」です。
FFmpegは、様々な動画・音声形式の変換に対応しており、動画共有サービス立ち上げの際に必須の技術ですが、これまでまとまった解説書がありませんでした。本書は、動画共有サイトの開発を日常的に行っている著者による、FFmpegを利用して動画共有サービスを構築するための技術解説書になります。
本書では、動画に関する基本的な解説から、FFmpegのインストールや使い方、Perl、PHP、Python、Javaの4つのプログラム言語での利用方法、字幕を入れられるFlashを使った動画プレイヤーの制作方法、Pythonを使った動画共有サイトの構築まで、サンプルを交えて解説します。本書で解説するのは、比較的小規模での動画共有サイトの作り方となりますが、サーバサイドの工夫次第では、大規模な動画共有サイトにも発展させることも可能です。
動画共有サイトの開発環境は多岐に渡り、本書はそのエッセンスをまとめたもので、すべての環境や手順は解説してません。また、本書の開発環境は、著者が日常的に利用している環境で、必ずしも一般的な環境ではないかもしれません。ただ、実際に動画共有サイト構築のために、著者自身が試行錯誤しながら身につけた知識や技術は、FFmpegを利用した動画共有サイト構築の際に、必ず参考になると考えています。
著者:原一浩・寺田学・本間雅洋・足立健誌・堀内康弘・堀田直孝・月村潤・尾花衣美
2007年2月2日金曜日
FlipClipでクリップ検索用フィード公開しました。
最近どこもかしこもAPI公開なご時勢ですが、FlipClipもクリップ検索用のフィードをAPI第1段として公開しました。
FlipClip開発者向け情報のページ
http://www.flipclip.net/developer/
フィードと言うよりAPIといったほうが世間の受けはよさそうな気がしますが、フィードはフィードなんで、フィードという名前にしときました。
今のところ、以下のクリップを取得できます。
- 一般公開クリップ
- 特定ユーザーのクリップ
- 特定ユーザーの友だちのクリップ
- 特定ユーザーのお気に入りクリップ
フィードのフォーマットはAtomフィード、JSONフィード、RSS2.0を用意しました。
フォーマットの指定はクエリパラメータでできるんですが、別の方法として、Acceptヘッダを使った指定ができるようにしてあります。
リソースを取得するためのURLがあって、そのURLに対してこのフォーマットでくれというと、その形式で返す、というようにRESTっぽくしたかったので、つけました。
それと、絞り込み機能を充実させています。
タグやフリーワード、カテゴリ、撮影日時に位置情報など、対応できそうなのにはひととおり対応してみました。
また、ソートもいろいろな基準でできるようにしてあります。
フィードなんで基本日付以外でソートできるのは、よろしくないような気もしましたが、
使い勝手を考えて、再生回数とか投票の数などでソートできるようにしてあります。
もうひとつ、フィードの認証も実装してあります。
認証にはWSSEを採用しました。
フィードのリクエストの際にWSSEヘッダを付与してリクエストを送れば、
認証されたユーザの権限でクリップが取得できるようになります。
たとえば、自分のクリップなら、プライバシー設定に関係なくすべて取得できますし、
自分の友だちのクリップで友だち公開なクリップも取得できます。
使ってみて、気づいた点、使いにくい点などありましたら、お知らせいただけるとうれしいです。
FlipClip開発者向け情報のページ
http://www.flipclip.net/developer/
フィードと言うよりAPIといったほうが世間の受けはよさそうな気がしますが、フィードはフィードなんで、フィードという名前にしときました。
今のところ、以下のクリップを取得できます。
- 一般公開クリップ
- 特定ユーザーのクリップ
- 特定ユーザーの友だちのクリップ
- 特定ユーザーのお気に入りクリップ
フィードのフォーマットはAtomフィード、JSONフィード、RSS2.0を用意しました。
フォーマットの指定はクエリパラメータでできるんですが、別の方法として、Acceptヘッダを使った指定ができるようにしてあります。
リソースを取得するためのURLがあって、そのURLに対してこのフォーマットでくれというと、その形式で返す、というようにRESTっぽくしたかったので、つけました。
それと、絞り込み機能を充実させています。
タグやフリーワード、カテゴリ、撮影日時に位置情報など、対応できそうなのにはひととおり対応してみました。
また、ソートもいろいろな基準でできるようにしてあります。
フィードなんで基本日付以外でソートできるのは、よろしくないような気もしましたが、
使い勝手を考えて、再生回数とか投票の数などでソートできるようにしてあります。
もうひとつ、フィードの認証も実装してあります。
認証にはWSSEを採用しました。
フィードのリクエストの際にWSSEヘッダを付与してリクエストを送れば、
認証されたユーザの権限でクリップが取得できるようになります。
たとえば、自分のクリップなら、プライバシー設定に関係なくすべて取得できますし、
自分の友だちのクリップで友だち公開なクリップも取得できます。
使ってみて、気づいた点、使いにくい点などありましたら、お知らせいただけるとうれしいです。
2006年12月5日火曜日
mysqldumpで文字化けしないためのメモ
ローカルの開発環境で使っていたMySQLなんですが、何も考えずデフォルトの設定で使っていたら、mysqldumpした際に、データが文字化けして、ちょっとは待ったのでメモ。
MySQLのバージョンは4.1.20。
文字化けする原因は、mysqldumpがデフォルトでは、文字コードをUTF-8で出力するようになっていて、フィールドの型がUTF-8でない場合は、自動でUTF-8に変換するためのようです。
僕が使っていたDBは文字コードについて特に何も設定していなかったので、デフォルトの文字コードであるlatin1になっていました。
なので、これもmysqldumpするとlain1 -> UTF-8な変換が自動で行われ文字化けしたということのようです。納得。
この自動変換を行わないようにすれば解決するはず。ということで調べてみると、--default-character-setというオプションを使うとよいことがわかりました。これを使ってデフォルトの文字コードをDBの文字コードとあわせてやることで、自動変換が行われなくなり、文字化けしないようです。
で、結局以下のコマンドで文字化けせずdumpすることができました。
>
これでデータ自体は文字化けしなくなりますが、これをそのまま、UTF-8なDBに取り込むと、取り込んだデータが文字化けしてしました。
ダンプしたデータを見てみると、所々にSET NAMES latin1とかDEFAULT CHARSET=latin1のように「latin1]の文字が。。
これが原因だったようで、ワンライナーでlatin1をutf8に変更してからインポートしたところ、文字化けせずに取り込むことができました。
>
MySQLのバージョンは4.1.20。
文字化けする原因は、mysqldumpがデフォルトでは、文字コードをUTF-8で出力するようになっていて、フィールドの型がUTF-8でない場合は、自動でUTF-8に変換するためのようです。
僕が使っていたDBは文字コードについて特に何も設定していなかったので、デフォルトの文字コードであるlatin1になっていました。
なので、これもmysqldumpするとlain1 -> UTF-8な変換が自動で行われ文字化けしたということのようです。納得。
この自動変換を行わないようにすれば解決するはず。ということで調べてみると、--default-character-setというオプションを使うとよいことがわかりました。これを使ってデフォルトの文字コードをDBの文字コードとあわせてやることで、自動変換が行われなくなり、文字化けしないようです。
で、結局以下のコマンドで文字化けせずdumpすることができました。
>
<
mysqldump --default-character-set=latin1 -uroot --all-databses > db.dump
これでデータ自体は文字化けしなくなりますが、これをそのまま、UTF-8なDBに取り込むと、取り込んだデータが文字化けしてしました。
ダンプしたデータを見てみると、所々にSET NAMES latin1とかDEFAULT CHARSET=latin1のように「latin1]の文字が。。
これが原因だったようで、ワンライナーでlatin1をutf8に変更してからインポートしたところ、文字化けせずに取り込むことができました。
>
<
perl -pi -e 's/latin1/utf8/' db.dump
2006年11月25日土曜日
SledgeでもRESTfulなアプリケーションを書きたい!
今日参加した第9回XML開発者の日の川村さんによる「Ruby on RailsにみるRESTfulアプリケーションの方向性」の話を聞いて、SledgeでもRESTfulなコードを簡単に書きたいと思いたち、ちょっとパッチを書いてみました。
>
これを使って書いたPagesクラスのサンプルはこんな感じです。
>
MyProj::Pages::Itemsクラスがアイテムをあらわすリソースに対応していて、
各メソッドにあわせて、CRUDの操作を実行するという風に書けてすっきりする気がします。
ブラウザからはPUT,DELETEリクエストはできないので、_method=putまたはdeleteとクエリパラメータを使うことで代用しています。
こんなのいかがでしょうか?
>
<
--- Sledge/Pages/Base.pm.orig 2006-11-25 00:40:59.000000000 +0900
+++ Sledge/Pages/Base.pm 2006-11-25 09:27:50.000000000 +0900
@@ -8,6 +8,9 @@
use strict;
use base qw(Class::Accessor Class::Data::Inheritable);
+use vars qw($MethodQueryKey);
+$MethodQueryKey = '_method';
+
__PACKAGE__->mk_accessors(
'r', # Apache::Request or Sledge::Request::CGI
'session', # Sledge::Session
@@ -81,10 +84,16 @@
eval {
$self->init_dispatch($page);
$self->invoke_hook('BEFORE_DISPATCH') unless $self->finished;
- if ($self->is_post_request && ! $self->finished) {
+ if ( $self->is_put_request && ! $self->finished) {
+ my $putmeth = 'put_dispatch_' . $page;
+ $self->$putmeth() if $self->can($putmeth);
+ } elsif ( $self->is_delete_request && ! $self->finished) {
+ my $deletemeth = 'delete_dispatch_' . $page;
+ $self->$deletemeth() if $self->can($deletemeth);
+ } elsif ($self->is_post_request && ! $self->finished) {
my $postmeth = 'post_dispatch_' . $page;
$self->$postmeth() if $self->can($postmeth);
- }
+ }
unless ($self->finished) {
my $method = 'dispatch_' . $page;
$self->$method();
@@ -188,6 +197,16 @@
return $self->r->method eq 'POST';
}
+sub is_put_request {
+ my $self = shift;
+ return ($self->r->method eq 'PUT' || ($self->r->method eq 'POST' && lc($self->r->param($MethodQueryKey)) eq 'put'));
+}
+
+sub is_delete_request {
+ my $self = shift;
+ return ($self->r->method eq 'DELETE' || ($self->r->method eq 'POST' && lc($self->r->param($MethodQueryKey)) eq 'delete'));
+}
+
sub make_content {
my $self = shift;
# template output, then fillin forms
これを使って書いたPagesクラスのサンプルはこんな感じです。
>
<
package MyProj::Pages::Items;
use strict;
use base qw(MyPfoj::Pages);
sub dispatch_index {
my $self = shift;
my $item_id = int $self->r->param('id');
if ( $item_id ){
# アイテム単体を返すコードを記述
} else {
# アイテムリストを返すコードを記述
}
}
sub post_dispatch_index {
my $self = shift;
# アイテムを追加するコードを記述
}
sub put_dispatch_index {
my $self = shift;
# アイテムを更新するコードを記述
}
sub delete_dispatch_index {
my $self = shift;
# アイテムを削除するコードを記述
}
MyProj::Pages::Itemsクラスがアイテムをあらわすリソースに対応していて、
各メソッドにあわせて、CRUDの操作を実行するという風に書けてすっきりする気がします。
ブラウザからはPUT,DELETEリクエストはできないので、_method=putまたはdeleteとクエリパラメータを使うことで代用しています。
こんなのいかがでしょうか?
2006年10月23日月曜日
Akamaiで認証付きコンテンツを配信する方法
IPAに脆弱性として提出されていた、ミクシィにアップロードされた画像がURLを直接たたけばログインしていなくても閲覧できる件が技術的には改修せず、ヘルプにその旨を記載することで決着したという話題について、その理由のひとつに画像の配信は一部、CDN(akamai)を使っているため、そこに認証をかけるのが難しいのではというものを見かけました。
このakamaiなのですが、実は、僕が開発運用している動画共有サイトFlipClipでも、日ごとに増え続けるサーバへの負荷、トラフィックに対応すべく、動画の配信にこれを使えないかと検討してまして、先日akamaiの人にきていただいて話を聞いてみました。
このとき一番聞きたかったのがまさに今回のミクシィの件で話にでてきた「認証のかかったコンテンツをakamaiで配信できるのか?」という点でした。
というのもFlipClipでは動画・サムネールの配信はすべてmod_perlアプリケーションから動的に行っていて、動画に設定されたプライバシーからユーザのアクセス権を判定し、OKならば動画・サムネールを吐き出すという処理をおこなっているからです。
この質問に対してのakamaiの方からの回答は、3つの方法があるというものでした。
+ akamai-FlipClip間でルールを決めて作成したCookieを使ってアクセス権を制御する方法
+ akamai-FlipClpi間でルールを決めて作成したクエリパラメータを使ってアクセス件を制御する方法
+ akamaiはIf-Modifiedヘッダ付きのリクエストを毎回FlipClipに送りつけ、認証はFlipClipに任せる方法
1のCookieを使う方法と2のクエリパラメータを使う方法は、どちらもあらかじめakamaiとFlipClipの間で認証OKかNGかをakamaiが理解できるクッキー、クエリパラメータ生成ルールを決めておき、それを動画・サムネールのリクエストと一緒に送りつけると、それを元にakamaiが認証を行い、キャッシュがあればakamaiからコンテンツを返すという方法だそうです。
この方法の利点としては、
- akamaiが認証を行うので、動画のリクエストの際に、FlipClipまでリクエストが飛んでこず、FlipClipのサーバへの負荷はかなり減る
という点があげられるんですが、欠点として、
- 認証箇所が2箇所(akamaiでの認証だけでなく、FlipClipでもCookieやクエリパラメータを生成する際に認証が必要)になってしまうため、セキュリティ的にリスクが大きくなってしまう
- akamaiのためにそれ用の実装をしないといけない
- 仮にクエリパラメータがばれたら誰でもアクセスできることになる
- そもそもクエリパラメータをつけるなんてかっこ悪い
という点があり、ちょっと微妙な感じだなーと感じました。
3の毎回FlipClip側に認証を求める方法ですが、これは、akamaiは認証は行わず、akamaiに動画・サムネールのリクエストが送られてきたら、そのリクエストにIf-Modified-SinceヘッダをつけてFlipClipのサーバに転送してくれるという方法だそうです。
これの利点は、
- アクセス制御はFlipClip側1箇所で行うので、ここだけを考えればいい。
- 同じ動画・サムネールへのリクエストが多いという傾向があれば、キャッシュのヒット率があがり、FlipClipサーバからのトラフィックをぐんと軽減することが期待できる
欠点としては、
- FlipClip側がIf-Modified-Sinceヘッダを理解できるようにしないといけない
- 動画・サムネールへのアクセスがほどよく分散されているような傾向の場合は、キャッシュヒット率があまりあがらず、本サーバ側の負荷軽減は小さくなる
- リクエストごとにFlipClip側にリクエストが飛ぶので、クッキーやクエリパラメータを使った方法よりは、サーバの負荷がかかる
という点があげられますが、
1つ目の欠点は、すでにIf-Modified-Sinceは理解するようになっているので、問題なし。
2つ目の欠点は、FlipClipの動画の配信傾向を見ていると、パレートの法則にほぼ従っていて、1日に配信される動画のうち20%の動画の再生数が全体の再生数の約90%を占めているという状況なので、キャッシュのヒット率はかなり高くなりそうなので、問題なし。
3つ目の欠点はリクエストは毎回FlipClipのサーバまで飛んできますが、上記のとおりキャッシュがうまく働いてくれそうなので、FlipClipサーバはほとんど、302をレスポンスとして返すだけで済むはずで、負荷、トラフィックはかなり減らすことが期待できそうなので、まあ問題なし。
ということで、この方法はいいかもという感想でした。
このようにakamai経由でも認証付きコンテンツの配信はできそうなのですが、なぜミクシィがそれをできないのかというと単純にこの修正で影響を受ける箇所が多すぎて、直すに直せないってことなんじゃないかなーとか、静的に返していたコンテンツを動的にアプリケーションから吐き出すようにすると、パフォーマンスがでないと考えているのかなーとか考えちゃいますがほんとのところはどうなんでしょうねぇ。
via: スラッシュドット ジャパン | ミクシィ、画像に認可制御なしの欠陥を改修できず、ヘルプで弁解
このakamaiなのですが、実は、僕が開発運用している動画共有サイトFlipClipでも、日ごとに増え続けるサーバへの負荷、トラフィックに対応すべく、動画の配信にこれを使えないかと検討してまして、先日akamaiの人にきていただいて話を聞いてみました。
このとき一番聞きたかったのがまさに今回のミクシィの件で話にでてきた「認証のかかったコンテンツをakamaiで配信できるのか?」という点でした。
というのもFlipClipでは動画・サムネールの配信はすべてmod_perlアプリケーションから動的に行っていて、動画に設定されたプライバシーからユーザのアクセス権を判定し、OKならば動画・サムネールを吐き出すという処理をおこなっているからです。
この質問に対してのakamaiの方からの回答は、3つの方法があるというものでした。
+ akamai-FlipClip間でルールを決めて作成したCookieを使ってアクセス権を制御する方法
+ akamai-FlipClpi間でルールを決めて作成したクエリパラメータを使ってアクセス件を制御する方法
+ akamaiはIf-Modifiedヘッダ付きのリクエストを毎回FlipClipに送りつけ、認証はFlipClipに任せる方法
1のCookieを使う方法と2のクエリパラメータを使う方法は、どちらもあらかじめakamaiとFlipClipの間で認証OKかNGかをakamaiが理解できるクッキー、クエリパラメータ生成ルールを決めておき、それを動画・サムネールのリクエストと一緒に送りつけると、それを元にakamaiが認証を行い、キャッシュがあればakamaiからコンテンツを返すという方法だそうです。
この方法の利点としては、
- akamaiが認証を行うので、動画のリクエストの際に、FlipClipまでリクエストが飛んでこず、FlipClipのサーバへの負荷はかなり減る
という点があげられるんですが、欠点として、
- 認証箇所が2箇所(akamaiでの認証だけでなく、FlipClipでもCookieやクエリパラメータを生成する際に認証が必要)になってしまうため、セキュリティ的にリスクが大きくなってしまう
- akamaiのためにそれ用の実装をしないといけない
- 仮にクエリパラメータがばれたら誰でもアクセスできることになる
- そもそもクエリパラメータをつけるなんてかっこ悪い
という点があり、ちょっと微妙な感じだなーと感じました。
3の毎回FlipClip側に認証を求める方法ですが、これは、akamaiは認証は行わず、akamaiに動画・サムネールのリクエストが送られてきたら、そのリクエストにIf-Modified-SinceヘッダをつけてFlipClipのサーバに転送してくれるという方法だそうです。
これの利点は、
- アクセス制御はFlipClip側1箇所で行うので、ここだけを考えればいい。
- 同じ動画・サムネールへのリクエストが多いという傾向があれば、キャッシュのヒット率があがり、FlipClipサーバからのトラフィックをぐんと軽減することが期待できる
欠点としては、
- FlipClip側がIf-Modified-Sinceヘッダを理解できるようにしないといけない
- 動画・サムネールへのアクセスがほどよく分散されているような傾向の場合は、キャッシュヒット率があまりあがらず、本サーバ側の負荷軽減は小さくなる
- リクエストごとにFlipClip側にリクエストが飛ぶので、クッキーやクエリパラメータを使った方法よりは、サーバの負荷がかかる
という点があげられますが、
1つ目の欠点は、すでにIf-Modified-Sinceは理解するようになっているので、問題なし。
2つ目の欠点は、FlipClipの動画の配信傾向を見ていると、パレートの法則にほぼ従っていて、1日に配信される動画のうち20%の動画の再生数が全体の再生数の約90%を占めているという状況なので、キャッシュのヒット率はかなり高くなりそうなので、問題なし。
3つ目の欠点はリクエストは毎回FlipClipのサーバまで飛んできますが、上記のとおりキャッシュがうまく働いてくれそうなので、FlipClipサーバはほとんど、302をレスポンスとして返すだけで済むはずで、負荷、トラフィックはかなり減らすことが期待できそうなので、まあ問題なし。
ということで、この方法はいいかもという感想でした。
このようにakamai経由でも認証付きコンテンツの配信はできそうなのですが、なぜミクシィがそれをできないのかというと単純にこの修正で影響を受ける箇所が多すぎて、直すに直せないってことなんじゃないかなーとか、静的に返していたコンテンツを動的にアプリケーションから吐き出すようにすると、パフォーマンスがでないと考えているのかなーとか考えちゃいますがほんとのところはどうなんでしょうねぇ。
via: スラッシュドット ジャパン | ミクシィ、画像に認可制御なしの欠陥を改修できず、ヘルプで弁解
登録:
投稿 (Atom)