日野原です。

週をまたいでしまいましたが、先週末にlivedoor主催のテクニカルセミナーに参加してきました。
検索するとすでにいろいろな方のレポートが見つけられますね。月曜日は別に片付けなくてはいけない仕事があったので相当出遅れてしまいました。やっぱり週末に清書しておけば良かったかと反省しております。…いや、休日に仕事しちゃいけません。ああ悩ましい。
ということで、あまり遅くなってもつまらないのでセミナー中に取っていたメモを整形だけしてスピード優先で掲載します。
後日発表資料が公開されたら、資料と一緒に見ていただけるとよりわかりやすいかと思います。
なお、私が聞いて解釈したとおりに書いているので、間違ったことが書いてあっても発表内容が間違っていたとは限りませんので察してください。指摘をいただけるとさらに幸いです。

セミナーは社員の方の発表はバックエンドの話が中心で、非常におもしろかったです。また、ゲスト講演はWinnyの金子さんとその弁護団事務局長の壇さんで、普段聞けないような話が聞けて刺激的でした。

ただ、壇さんの講演に関しては専門外の法律の話である上に、普通の文字量のプレゼン資料を「高橋メソッド風に（本人談）」進められてしまったのでメモを取る方も追いつけず、十分な報告ができません。申し訳ありません。

• 開会の挨拶(伊勢さん）
• Practical Cicindela 実践ちちんでら（井原さん）
• ライブドアブログ公式攻撃マニュアル（井原さん）
• インサイド livedoor Blog（垣内さん）
• ライブドアのネットワークとトラフィックパターン（市川さん）
• P2Pコンテンツ配信技術の現状（金子さん）
• デジタルコンテンツ配信の法的問題（壇さん）
• 閉会の挨拶（出澤さん）

開会の挨拶

livedoor テクニカルセミナー 2009 Open & Share
株式会社ライブドア技術部会

司会 伊勢さん
足下の悪い中ありがとうございます。

アンケートにご協力ください。

「Open & Share」だから撮影や録音はご自由にどうぞ。でもうるさくて迷惑なのはやめてください。
ブログに書いてもオーケーです。
ちなみにねとらじで生中継中なので、質問などオフレコにしたければその旨言ってください。
何かあったら黒いストラップの社員まで。

「Practical Cicindela 実践ちちんでら」

メディア事業部 ブログビジネスユニット 井原さん

最近edgeラボで公開したレコメンデーションエンジン。
実際に運用中で実践経験豊富なので、その運用例を紹介する。

井原さんは「ちちんでら」と呼んでいるけれど、社内では「ししんでら」と呼ばれている。

レコメンデーションは脇役なので、応答速度が重要。
新しいデータがすぐに反映されるかも重要なので夜間バッチ処理とかはよくない。
その辺を考慮した作りになっている。

入力はいったんバッファに入れられ、バッチ処理で一次テーブルに入る。
これは入力の処理を軽くするためで、一次テーブルに後からいろいろ情報を足していく。
集計はできる限りバッチでやって中間集計テーブルを作る。
その後、現在使用中のテーブルと中間集計テーブルをrenameして入れ替える。

応答時間は平均数ミリ秒、ちょっと複雑な処理でも20～30ミリ秒で返すことができている。

livedoorクリップでの事例

一日1万2千件くらいの記事がクリップされる。
ひとつのページに4、5件のクリップがついたころが一番見られるので、そのころまでにレコメンドを準備する。

最新1時間、通常のレコメンド（このページをクリップした人はこのページもクリップしています）、タグを考慮したレコメンド（このタグはこのページにも付いています）の3段階に分けてレコメンドを作る。

「～のトップページ」とか、いかにもクリップされがちなページはレコメンドしない。

同人ダウンロード販売サイトでの事例

同人ダウンロード販売サイトではレーティングに基づいたレコメンドや、独特の配慮をしている。
たとえばほかの作家を薦めすぎないとか、一般向け商品のページで成人向け商品を薦めないとか。

レーティングの得点を正規化したり、フィルタリングをしたりという処理が入る。

レコメンド経由の販売が4%くらいあるらしい。

you bride（結婚情報サービス）での事例

アクションをまったくしない人同士をつなげる工夫をしている。

たとえば、「Eさんを選んでいる男性はDさんを選んでいる」のほかに、「同じ属性の同姓が選んでいる異性と、同じ属性の異性」を薦める。

具体的には、何もアクションを起こさないCさんと同じような属性の人たちが選んだ女性Eさんと同じ属性のFさんをCさんに薦める。

この方式の採用により申し込みが6.5%アップ、交際率が2～4%アップした。

ストレートなレコメンドを採用したときには3割とか1割とか上がってるので、それに比べると地味だけど。

伊勢さんより補足。

livedoorのedge ラボで公開しているから使ってね!

質疑

• Aさん
  • 中間結果の数は制限かけているか?
    • フィルタリングのときにパフォーマンスの目的でlimitをかけることはある。
  • ランダム要素はあるか?
    • レコメンドの結果にランダム要素はないけれど、10件出た中からランダムで2件薦めるとかで一見ランダムに見える工夫はしている。
• Bさん
  • ニュースのおすすめに使ってる。apacheのログベースでやっているけどドキュメントがまだ無い。
    • ごめんなさい。
  • IPアドレスをユーザとしてみているけど、なんかいいやり方は無いか?
    • mod_usertrackでcookieベースでやっている。これだとcookieが文字列で入ってくるが、それをintに変換して性能向上の工夫をしている。
  • 特にモバイルだとIPが同じになるが何か良い方法はないか。
    • モバイルではやってないので「こうすればいい」というのはない。アプリ側でセッションIDを使うとかするのかな。
  • HTTPだと遅いかと思ってDB直でたたこうとしてるけど、どうしてる？
    • livedoorでもHTTPでやっている。

「ライブドアブログ公式攻撃マニュアル」

引き続き井原さん。

2chのコピペブログへの無差別DOS攻撃があった際、社内勉強会で話した内容から。

2008/3/7 22:00攻撃が開始された。

しかしすでに対策済みで、10秒くらい連続アクセスするとアク禁になるようにしてあった。

そのとき、LDブログチームは送別会中だった。

結果、2chでほめられた。

どうすれば落ちるかの部分は社外秘のため発表できません！

まとめ

• ブログでお金儲けたっていいじゃないか。
• livedoorのブログサーバはそんなに簡単に落ちるほど単純じゃない。

伊勢さんより補足。

去年の2008/07号の日経SYSTEMSでコラムになっているので読んでください。

「インサイド livedoor Blog」

メディア事業部 ブログビジネスユニット 垣内さん

agenda

• サーバ構成
• apache独自モジュール
• 管理画面
• 新サービス

2003年11月オープンで、5年ちょっと経つ。
キャッシュとかを抜いて16TBのデータがある。

サーバ構成

構成図をこんなに細かく出していいのかな。
（発表資料が無いとこのあたりは意味不明です、すみません）
この構成図からは検索サーバ等は省いてる。
CMSは管理画面

portal/cmsはlivedoor標準な構成になっている

blog側（攻撃をうけやすいところ）
blog-wwwではApache2.2 mod_ldblog_mapper2 mod_include (SSI)を使っている。

blog-app （コメント、トラバを受ける場所）
apache2.2 mod_proxy_balancerも使っている。後はsledge。

DB
mysql
user-cluster DB
user単位のパーティショニングで1～2万ユーザ×150クラスタ。
クラスタリングは手動で、運用でカバーしている。

ストレージ
商用でNFSマウント。
DBの内容をhtmlに変換した静的ファイルをキャッシュとしておいてる。

イメージストレージ
容量を安く増やすために自作している。
WebDAVでアクセスする。
どのサーバに何のファイルがあるかをapache + 自作module + mysqlで解決している。
解決の部分とかreplicationはapache moduleだから強い。
ほかのサービスで新版を試験運用中。

サーバ構成のまとめ

• OSはBSDとかLinuxとかばらばら。
• 回数の多い処理はmoduleにして性能を上げている。

独自モジュール

mod_counter
画像カウンタ。

mod_ldblog_mapper2
URLからNFSマウントされたストレージのパスを計算する。
memcachedやDBから引いた結果を環境変数に入れている。
キャッシュがあれば mod_rewrite でキャッシュに飛び、無ければblog-appに行く。
キャッシュがあればほとんどApacheで完結するのでDDOS攻撃とかに強い。
ストレージに入った画像はgzipで圧縮されるけれど、その辺もの処理もフロントでやっている。

静的ファイルキャッシュについて
htmlファイルを全部いっぺんにキャッシュしてしまうとよく変更される部分（新着記事、新着コメント）にキャッシュ再構築の頻度が依存する。
→個別ファイルにしてmod_includeでSSIしている。

キャッシュの再構築はファイルを消すだけ。作るのはアクセスがあったとき。

お知らせメールなどqueueの必要な処理には、TheSchwartzを使っている。

新管理画面

今までEUC-JPだったのをUTF-8にした。
蓄積データも新規ユーザはUTF-8。

文字コード多重化
blog単位でcharsetを切り替えられる様になっている。
マルチブログで二つのblogを持ってる場合、EUCとUTF-8と共存したりできる。
複雑になったので、ORMでアクセサを切り替える仕組みを仕込んだ。

URL変更
シングルサインオンをlivedoor.comと分離するのが目的。
OpenID連携にした。
新サービスの準備のため。

新サービス

livedoor Blog ASP

ブログのドメイン名を変えられる。
既存のlivedoor Blogのいろいろな機能と素直に連携できるのが売り。

OpenIDについて
RPをやるわけではないが、裏で使っている。

AXでいろいろ情報を交換している。sregではなくAXを使ったのは、sregだとuser_idをうまく取れなかったため。

IEのURL長の制限の対策もしている。

パートナー募集中。

質疑

• Cさん
  • 画像のサーバが別になっていることに関して、blogと一緒に投稿された画像には公開範囲の限定があると思うけど、mod_accesstokenを使っているか？
    • blogではmod_accesstokenは使ってない。
  • mod_accesstokenの導入事例はある？
    • コスプレサイトのCure
    • 会社で見るときには注意してください。ファンクラブに登録すると効果がわかります。
• Dさん
  • 守るマニュアル教えてください。
    • 資料中にもあったように、10秒の連続アクセスで防御される（mod_dos_detectorみたいなもの）
    • 他にはYAPC ASIA2008 で発表したスパムチャンプルーも使ってる。
    • 詳細には言えない。ごめんなさい。
• 伊勢さん
  • blog ASPはいつから？
    • 4月から

「ライブドアのネットワークとトラフィックパターン」

ネットワーク事業部コアネットワークグループ 市川さん

agenda

• DATAHOTEL（データセンター）ネットワーク概要
• iDC ISPの立場から見た傾向
• 最近の話題
• IPv6

概要

DATAHOTELではiDC（データセンター）、公衆無線LAN、企業向けISP（ライブドアBB）とトランジットサービスをやっている。

サービスごとに別に接続してるのでどれかに障碍があってもほかには影響しない。

DATAHOTEL内の冗長化はメッシュ型だが、ライブドアBBは拠点が離れてて難しいのでリング型になっている。

トラフィックの傾向

一般的なプロバイダのトラフィックはユーザへの下りがメイン。
平日

• 20時から始まり24時がピークで、そこから減少。
• 朝のメールチェック時に小さなピークがある。
• 昼休みにもちょっとピーク。

休日

• 昼の12時から増え始めて24～25時がピーク。

P2Pのトラフィック

• 上りと下りがほぼ同じ。
• livedoorでは帯域制限は基本的にかけていない。

iDC（データセンター）のトラフィック

• ISPと逆になる。
• ピークになる時間帯は同じ。

ルータのメンテナンスをするのはトラフィックの落ち込む2時から5時くらい。

休日は一日中ネットをやっているユーザが多いらしい。
「土日」じゃなくて「休日」。

トラフィックの例：コンテンツダウンロード販売系のラック

「これがピーク」と言う時間帯が無い。一番少ない時間帯でもそこそこの量が流れている。
アキバ系は強い。
ピークで1G弱。

トラフィックの例：ポータル系のトラフィック

livedoor Blog

• 0時過ぎの落ち方が緩やか。ユーザに夜更かしする若者が多いのか?

livedoor ねとらじ

• お昼休みピークが無い。
• 就業時間後にまた下がる。
• 仕事中にBGMとして聴いてるのかな?
• 夜に最大値を迎えるのは変わらない。

インターネットのトピック

1/31～2/1にかけてGoogleが正常なサイトをフィッシングと誤認する障碍が発生したが、livedoorのトラフィックにはほとんど影響はなかった。

年末年始、12/31～1/1には夜中の大きなピークが無い。0時前後に「あけおめ」書き込みか？という小さなピークがある程度。

2/17 01:30～02:30ごろにインターネットに障害。
上位回線で回線が切断されたりしたらしい。
livedoorの上流では幸い影響なかったが、インターネットって意外と脆弱だという印象を受けた。

IPv6に関して

実験だからお客さんには出してないが、WIDEとつながっている。

２ちゃんのIPv6板を運用している。IPv6がreachableな人は書き込みができるから書いてみてください。

IPv6のトラフィックは少ない。20kとか1Mとか、バックボーンでは考えられない量。

Tokyo6to4というprojectに参加してみてね。

伊勢さんより補足

• ネットユーザって初詣行くんだね。意外と信心深いのかな。
• DLサイト、平日は少なくて休日は多いってことから同人ファンはサラリーマンが多いってのがわかるね。

質疑

• 伊勢さん
  • 18:00-20:00のトラフィックの落ち込みの原因はわかる?
    • ご飯?
  • 正解。「飯落ち」と呼ばれる現象。
  • blogのトラフィックってお昼にキューンとあがる。みんな見ているんですね。

「P2Pコンテンツ配信技術の現状」

金子さん

自己紹介
（株） Dreamboat 技術顧問
コンテンツ配信システムSkeedCastの開発中。

agenda

• P2Pの紹介
• WinnyとSkeedCast
• SkeedCast

P2Pの紹介

P2P（型ファイル共有ソフト）の発展
第一世代 Napsterなど
→ハイブリッド（P2Pなのはデータ転送のみ）
第二世代 Gnuteraなど
→pure P2P（検索もP2P）
第三世代 Winnyなど
→キャッシュ型（転送キャッシュ）
第四世代
→商用（P2P教科書（インプレス）による）
インプレスによる分類は技術的な分類ではない。
金子さんによると第四世代にはSkeedCastやWinny2が該当し、ノード群をサーバとみなしてクラサバ的挙動をする

Winny→SkeedCast

Winny1
→ファイル共有ソフト
Winny2
→もっと汎用的なものを目指した。BBSをP2Pでやる。BBS部分だけ第4世代的。

Winny2ははるかな高みを目指していた。
Winny1の落穂ひろいにWinny2の要素を入れていったのがSkeedCast

SkeedCastの特徴

P2Pノードがサーバになる→分散サーバとP2Pのハイブリッド

Winnyにも速度による上下関係はあったが、SkeedCastではもっっとノードの役割を意識している。

アップローダ（投入ノード)、中継（共有ノード)、ダウンローダ（レシーバ）の3つがあり、ダウンローダは中継もできる。

投入ノードは課金とかDRMとかを考えてる。
共有ノードはUNIX、レシーバはWindowsで動く。

共有ノードはコントロールノードからコントロール可能。
キャッシュコントロールとか。
ある人気コンテンツを優先的にキャッシュに入れるとかもできる。

P2Pは不安定という弱点があるので、サーバのトラフィックが予定外に増えすぎたときにユーザノードを中継ノードとして動かしてしのげる。P2Pのいいところ。

SkeedCastはファイル共有ではなくコンテンツ配信のシステムなので、普段はCDN的に動作して、サーバが大変なときにP2P的に動作して凌ぐ。

特徴
Winnyはハッシュを多用していたが、SkeedCastは代わりにデジタル署名を多用する。
ホワイトリストのフィルタリングやキャッシュのライフタイム管理に使う。

コンテンツにデジタル署名をする。
コンテンツプロバイダが秘密鍵を持ち、流通段階で署名をチェックして問題があれば流通させないといったコントロールが可能。
公開鍵をホワイトリストとして使う（後述）

流通フィルタリング
Winnyはダウンロードフィルタ、無視フィルタ（ブラックリスト）の二つのフィルタがあった。
SkeedCastはダウンロードフィルタ、無視フィルタ、許可フィルタ（ホワイトリスト）の三つのフィルタを持つ。
許可フィルタは公開鍵の束なので偽装は不可能。

再中継の制御
Winnyはどこかにキャッシュがあると再中継可能だが、SkeedCastは投入ノードがコントロール可能。

レシーバ（PCに入れるソフト）
Webと連携する。
ブラウザでリンクをクリックすると起動する。
SkeedReceiverはWebサーバとして動作し、裏でCacheとしてダウンロードする。
また、SkeedReceiverがストリーミングサーバになって、メディアプレーヤで視聴する。ストリーミングだけどローカルにあるからシークもできる。

展開可能フラグがたってればCacheをファイルに展開することもできるよ。

視聴のコントロールにはDRMを使う。

言ってみれば巨大なProxyになる。

（株）Dreamboatではほかにもいろいろやってるから使ってください。
社内ネットワークでの配信もできる。

質疑

• 伊勢さん
  • receiverはプラグイン？ デーモン？
    • 常駐はしない。ブラウザのプラグイン経由で必要なときに起動して、終わったら終了する。タスクバーにも出るので、気になったら消すこともできる。
  • ヒントをもらった。ありがとうございます。ストリーミングサーバのランニングコストは馬鹿にならないから。
• Eさん
  • ダウンロード可能性は投入ノードで管理といってたけど、ダウンロード済みのものをレシーバでストリーミングするかどうかはチェックするのか？
    • ダウンロード済みの物はWinny的な感じで処理している。詳細は想像してください。

「デジタルコンテンツ配信の法的問題」

壇さん
金子さんの弁護団の事務局長

P2P教科書は私も書いているので買って読んでください。

cocologでblogを書いています。

Livedoorには壇さんを誹謗中傷するwikiがある。

ネットのせいでコンテンツ産業は損害を受けてるってホント!?

CDやレコードはの売り上げは落ちてるけど、着うたとか増えてるから消費シフトと見るべきではないか。
映画の興行収入は年ごとに上がったり下がったりしている。
結論：ネットは関係無いんじゃないか? むしろうまく使えば利益もたらすんじゃないか。

著作権について

厳密には著作権と言う名前の権利は無い。
いろいろな法律で規定されてるいろいろな権利をまとめて著作権と総称してる。

Winnyは大容量コンテンツの配信を可能にした。
それまでは映画一本流すなんてできなかった。

（以下、追いつけなかった部分はキーワードのみで失礼します。）
プロバイダ責任制限法
カラオケ法理とか
私的目的での複製
著作権侵害はP2Pに固有の問題ではない。ニコ動とか。
アメリカ：セーフハーバーとかDMCAとか
クラブキャッツアイ事件
カラオケ法理がP2Pのファイルローグに適用された。

開発者、提供者が刑事事件の当事者になったのは日本、韓国、台湾のみ。
有罪になってるのは金子さんと台湾の1件（Kuro事件）のみ。
金子さんは確定してないので最高裁まででひっくり返すよ!

Winny事件地裁判決における幇助成立の基準
証拠として提出されたWinnyの利用状況がなぜかアンケート結果。

よくある誤解
Winnyに匿名性があるから有罪？
→匿名性は関係ない。
金子さんの目的が著作権侵害蔓延だったから有罪？
→そんなことのためにわざわざソフトを開発するわけ無い。

IP-TVのニーズ
海外で日本の番組を見たい
東京ローカルを地方で見たい。
しかし地方免許制度の枠組みでしか見られない。

IP-TVの訴訟
録画ネットと選撮見撮は著作権者側が勝っているけど、まねきTVとロクラクはサービス提供者側が勝っている。

著作権の問題
カラオケ法理の適用範囲
非親告罪化
ダウンロード違法化
日本版フェアユース（ぜひとも立法化すべき）
ただし裁判所の判断にゆだねることになるので危険性はある

質疑

• Aさん
  • 日本の著作権関連団体は強い主張を繰り返していて、徐々にその主張に引きずられている気がするが、彼らの言うような方向にこのまま行ったらどうなる？
    • アメリカから制度変えろといわれて終わるんじゃないか。
• 伊勢さん
  • SkeedCastと連携しろなんてあったけどメディア事業部の担当役員さん、どう思う?
    • やりたい。

閉会の挨拶

代表取締役社長 出澤さん

みなさん、雨の中ありがとうございます。
金子さん、壇さん、ありがとうございます。
新規サービス（最後の質疑のSkeedCastの連携）も決まってうれしいねｗ

Open & Shareという企業理念でやっています。

今後ともがんばるのでよろしくお願いします。

Tags: livedoor, seminor