2009年2月28日

ライブドアテクニカルセミナーに行ってきました

第一回 ライブドアテクニカルセミナーに行ってきました。
「ライブドアテクニカルセミナー」って何?は↓こちら
http://blog.livedoor.jp/techblog/archives/65077074.html


■講演1「プラクティカル Cicindela」
レコメンデーションエンジンの中身。
「この商品を購入した人は、この商品をチェックしています」みたいな。
導入事例
・ライブドアクリップ(はてぶみたいなもの)
・同人誌ダウンロードサイト
・結婚情報(見合い)サイト
「ライブドアクリック」では早さ(情報の鮮度)が重要なので、とにかく更新を速くする。
一次テーブルでユニークキー(シーケンス)のみ付加されたネタをとにかくため込む。
10分置きにバッチを起動して、シーケンシャルにフィルタリング、重み付け、関連づけして二次テーブルに集計する。
バッチ分を集計したら、前回集計した二次テーブルとリネームして交換する。(そういうことアリなのか)


■講演2「インサイド livedoor Blog」
ライブドアブログのサーバ構成など。
フロント Apache2.2+mod_proxy_balancer
バック   Apache1.3+mod_perl
という、ごく普通の構成
DRBDやLVSなどマニアックなことはしていない(…マニアックですか)
アプリサーバはストレージをNFSでマウントしている。
画像用イメージストレージにはWebDAVで接続、
読み出し(クライアントに見せる)ところは、squidでキャッシュ。
画像を速く処理する=Apacheモジュールmod_ldblog_mapper2で行っている。
アップロード:画像データを受け取る→DBストレージ上のパスを書き込む→ストレージにファイルとして格納する
ダウンロード:URLをストレージ上の格納パスに変換する(という情報をDBから読み出す)→ストレージからファイルを読み出して出力
(Apacheモジュールを書けるといろいろ面白そう。以前導入していたケータイのアクセス解析もApacheモジュールだった)


■講演3「ライブドアのネットワークとトラフィック」
もっとも関心が低いような空気だったプレゼン。
蛇口を捻れば水が出るのは当たり前ですけど…。技術系セミナーでもそんな反応ですか。orz
平日のトラフィック:
 12時から13時にピーク(昼休み)
 20時から24時にピーク(ゴールデンタイム)
 6時から7時に小さなピーク(メールチェック?)
休日のトラフィック:
 昼12時頃から日付が変わる頃までゆるやかに増える
トラフィックが少ない時間帯は、3時から4時。
ライブドアでもメンテは2時から5時頃に行っている。
特徴的なトラフィック:
 平日18時から20時に少し減る。プレゼンタは「飯食ってる?」と言っていたが、通勤時間じゃね?
 12月31日は「夜中のピーク」がなかった。(初詣に行ってる?)
 ライブドアがサービスしている某同人誌ダウンロードサイトは、休日は朝からトラフィック増
 ネットラジオは、特にピークはなく、終日だらだら推移している。(リアルのラジオ感覚で利用?)
ということが、トラフィックのグラフから分かるとのこと。
日付を見ると、その日が平日なのか休みなのか分かるとのこと。
オマケ的にIPv6の話。
ライブドアでは実証実験中。
「Tokyo6to4」でNATしてない固定IPならIPv4でIPv6の体験ができるので試してみて。


■ゲスト講演「配信の技術と法的問題」
winnyの中の人のプレゼン:
商用P2P skeedcastの話。
skeedcastはwinny+winny2の発展型。
書籍『P2Pの教科書』ぐらいを一読してないとついていけない。
P2Pの基本的な仕組みやノードって何?が分かってないと分からない。
セキュリティは、
・デジタル署名(実体はRSAによる公開鍵・秘密鍵)
 公開者が秘密鍵と公開鍵を作成し、公開鍵をノードに配る。公開鍵を持たないと(正当なノートでないと)ダウンロードできない
・ホワイトリストによるフィルタリング
 ブラックリスト(このノードとは?がない)は、winnyの頃からあったが、「このノードからのみ接続する」ホワイトリストは初めて実装した。
 実体は公開鍵の束。
・キャッシュにライフタイムを持たせる
 漏洩されたファイルがいつまでもノードに漂っているのがwinny。skeedcastでは「いつまで有効」を持たせて、期限を過ぎたファイルはダウンロードできても複合化できないようにしている。
で、対応。
「ライブドアさん、skeedcastで動画配信やりませんか?」
skeedcastの実体はプロキシ。クラサバで認証が済んで、ブラウザからダウンロードする際にサーバから落とすとみせかけて手近なノードから落とすようにしている。
動画配信は、ストリーミングなので、クライアントにキャッシュが残らない(そうか?)
コンテンツそのものの保護はDRMを利用

弁護士のプレゼン:
法廷では、"カラオケ法理"がネットのダウンロード行為まで拡大解釈されつつある。
米国のように、現状に合わせた見直しが必要。
それを見越してか、GoogleがyoutubeでJASRACと包括的許諾契約を結んだ。
が、先日、公取が「それってJASRACが独占してんじゃね?」と指摘した。よって、今後どうなるか分からない。
質疑応答にて:
Q. このまま制度が変わらなかったら日本はどうなっちゃうんでしょう?
A. 米国から「変えろ」と言われて終了です。
大型二輪免許のときのようにですね。わかります。


■雑感
プレゼンは、内容やスライドも良いのに、弁護士を除くプレゼンターの全員がしゃべるのが速い。
時間制限にもひっかかっていた。間に合わせようと余計早口に。
もったいない。
本人が「ゆっくりすぎる」と思うくらいで話せというのを思い出した。
しゃべりがもっとも巧かったのが、やはり弁護士。次は司会していた人w

0 件のコメント: