アジェンダ

• ニコニコ動画について
• システム構成
• 歴史
• 体制
• 負荷対策
• 負荷の推移
• Web
• Msg
• DB
• チューニングへの姿勢

はじめに

• ドワンゴ初のPCサイトでした
• 負荷・XSSへの対応が大変でした
• 今日は我々が行った負荷対策についてお話します。
• まずは「ニコニコ動画開発プロジェクト」についてお聞きください

ニコニコ動画について

• 歴史
• システム構成
• 体制

ニコニコ動画について

• まだ浅いけど歴史
• 2006
• 10月下旬 … プロトタイプ開発 (3営業日で完成！)
• 11月中旬 … ひろゆき監修開始＆キックオフ的雰囲気
• 12月上旬 … プロトタイプベースで本開発開始 (2週間)
• 12月16日 … (仮)オープン
• 2007
• 1月16日 … (β)オープン
• 1月上旬 … 月間1億PV突破
• 2月下旬 … 3000万PV/日記録
• 2月中旬 … (γ)開発開始 (2週間)
• 2月24日 … DDoS攻撃 ＆ YouTubeからブロック → (β)終了
• 3月5日 … SMILEVIDEO＆(γ)開始
• 4月22日 … 再生回数2億突破・2600万PV/日突破←いまここ

ニコニコ動画について

• システム構成
• ソフトウェア
• いわゆるLAMP
• Linux2.6, Apache2, MySQL5, php5
• メッセージサーバはC++で書かれた独自デーモン (戀塚製)
• ハードウェア
• HP DL360 1Uサーバ (全サーバほぼいっしょ)
• コロケーション
• とあるデータセンタ

ニコニコ動画について

• 開発チーム体制 (4/25現在 7人)
• 鈴木(慎)
• 雑用/御用聞き/SE
• 06/12〜07/03 : web実装
• 戀塚
• プロトタイプ実装（全モジュール）
• メッセージサーバ実装 (C++)
• FLV Player実装 (swf)
• プログラマー他4人
• 内、2ちゃんねる面接人材が2人
• PCサイトデザイナー1人
• 右上のアイコンのあの人

負荷対策

• ピーク実績
• 対策
• (Web/メッセージサーバ/DB)

負荷対策 - ピーク実績

• アクセス数
• βピーク : 2300万PV/日
• 現在：2600万PV/日

負荷対策 - ピーク実績

• リソース平均負荷（4/24実績=きのう）
• 回線帯域
• 約430Mbps
• Web : 350 Mbps (1台50Mbps * 7台)
• Msg: 80Mbps (1台15Mbps * 6台)
• CPU
• Web : 50%
• Msg : 50%
• DB : Master:50% / Slave:50%

負荷対策 - Web編

• インフラ
• Apache最大接続数
• Apache2ならworkerをつかわないの？
• php5が現状thread safeではない
• 従って従来のプロセス起動 (prefork)となった
• コネクション増加はサーバの台数増加で対応
• さらにメモリを4Gに増加 (プロセス数=2000)
• 現在は7台で稼動
• 回線帯域削減
• mod_deflate導入 (40%削減)
• 回線そのものを独立予定

負荷対策 - Web編

• キャッシュ
• phpスクリプトキャッシュ
• 現在apcを利用
• eacceleratorは一部のPearライブラリで誤動作のため採用を見送り (pear/Services_YouTube)

負荷対策 - Web編

• キャッシュ
• データキャッシュ
• 2006年12月(仮)当初Pear/Cache_Liteを使用
• なにぶんファイルなので
• memcacheに変更 Webサーバmemcache(ローカル):動画リスト等
• 専用memcache (リモート):ユーザセッションデータ
• 現在は3分毎に動画データキャッシュ生成バッチが稼動
• DBからデータを読んでは加工してmemcacheへ

負荷対策 - メッセージサーバ編

• DB参照/更新バッファリング
• 最新コメントを書き込むクエリ（threadテーブルへのupdate)を最大10秒バッファリング
• 動画閲覧数カウンタのDB参照を4秒キャッシュ
• テーブルロックによる待ちの回避 (MyISAM時代)
• 現在はInnoDB

負荷対策 - メッセージサーバ編

• データファイルインデックス化
• コメントを格納するＣＳＶへのインデックスを作成
• ＣＳＶの読み込みの時間を削減
• 1000行に満たないデータはインデックス化しない
• 人気動画データファイルには有効だった

負荷対策 - DB編

• 更新/参照系DB分離
• レプリケーション
• db01を更新,db02,03…と参照系とした
• マスタも今後検索/ユーザ/動画と機能分割予定
• 参照系はアプリケーションロードバランス
• webサーバ自身のホストIDから、アクセスすべき参照DBサーバを決定
• MySQL Clusterとかどうかな

負荷対策 - DB編

• DBエンジン変更
• video, threadテーブルにて MyISAM を採用
• 閲覧数カウンタ増加のためUPDATEが頻発
• MyISAM＝テーブルロック
• レコードロック機構をもつInnoDBに変更
• Lock waitが減りました
• でもオートコミットしないとね
• 次のページへ！！

負荷対策 - DB編

• my.cnfパラメータチューニング
• innodb_flush_log_at_trx_commit
• ログバッファからディスクへの書き込み頻度
• 従来は1で運用していたが0にした
• 障害時に一貫性のとれたデータでなくなる可能性があるが、トランザクションを使っていない＆動画情報がなくなるリスクと速度のトレードオフを検討した結果、導入を決めた
• 値の意味
• 1 … トランザクション発行後フラッシュ
• 0 … 1秒に約1回フラッシュ

負荷対策 - DB編

• 検索
• 未来検索ブラジル社「senna」を採用
• FULLTEXT INDEXをハンドリング
• MySQLバインディング Tritonn やりたい
• ちなみにSQLのクエリはこの程度の違い
• 従来の検索
• SELECT * FROM video WHERE TITLE LIKE ‘%アニメ%’ AND ‘%ハルヒ%’
• FULLTEXT INDEX利用時
• MATCH〜AGAINST句
• SELECT * FROM video WHERE MATCH(title) AGAINST(‘+アニメ +ハルヒ’)

負荷対策 - 番外編

• アクセスログ集計
• Apacheアクセスログが6GB/日を突破
• 当初awstatsで集計していた
• 毎時集計が追いつかない
• Google Analyticsへ切り替え
• 当初より使用していた
• 数時間遅れで反映
• リアルタイムではない
• さらに独自でUrchinを使うかも

チューニングの姿勢

• 全体
• スケールアウトしやすい設計を心がける
• Web, DB, Msgそれぞれ容易に増やせること
• フロント
• DBへのアクセスはなるべく発生させないことにこしたことはない (webからのコネクション数＆クエリ発行数低減)
• 前述のmemcache等使いを数分毎に更新するだけでもサイトはリアルタイムに動いてるようにみえる。
• DB
• ログ系や、更新が行われないテーブルはMyISAM
• 更新の多いテーブルはInnoDB
• MySQLのJOINは避け、非正規化ロジックで対応

思ったこと

• 苦労＝当たり前の積み重ねだから
• 今回のチューニングノウハウは比較的既知な内容を行った
• なるべくシンプルに、おもしろいサイトをつくるのが命題
• プロトタイピングからの立ち上げ
• ベースがあったので追加開発し易かった
• 設計の見直しは都度行っている
• ブログ/2ちゃんねる
• 告知/ユーザの要望
• 今回は情報収集の場としてなじんだ
• 負荷試験
• やりたかったなあ･･･
• 体調管理
• 楽しいけど、やり過ぎない

1.仕組みざっくり

• システム構成
• Webサーバー
• メッセージサーバー
• DBサーバー
• プレーヤー
• 動画が見られるまで

1-1.システム構成
Webサーバー(apache 2, php5)

• メッセージサーバー(C++)
• DBサーバー(MySQL5)
• プレーヤー(Flash8)
• ユーザー(人間)

図1-1-1.システム構成図
1-2.動画が見られるまで
ブラウザでwww.nicovideo.jp/watch/...に接続

• プレーヤーが埋め込まれたページが返る
• プレーヤーがWebサーバーから情報取得
• 動画サーバーへ接続
• コメント取得！
• 再生
• コメント書き込みが可能

図1-2-1.ブラウザでwww.nicovideo.jpに接続
図1-2-2.プレーヤーが埋め込まれたページが返る
図1-2-3.プレーヤーがURL取得
図1-2-4.動画取得！
図1-2-5.コメント取得！
図1-2-6. 再生
図1-2-7. 書き込み
2.コンセプト設計と進化
コンセプト設計

• 進化

2-1.コンセプト設計
コンセプトは非同期実況

• しかもリアルタイム
• サーバーがコメントをpush
• 「現在5人が再生しています」などと通知
• システムはネットゲームだ!

2-1.コンセプト設計
コンセプトを満たすために

• Flash8のXMLSocket
• チャット用のメッセージサーバーを自前でつくる
• 既存のネットワークゲームサーバーを改造

2-1.コンセプト設計
データモデル

• video(DB)
• 動画情報を維持
• thread(DB)
• 動画ごとに複数持ち得る
• コメント (CSVファイル)
• コメント自体

2-1.コンセプト設計
メッセージサーバーの設計方針

• 情報伝達
• プレーヤーにできることはプレーヤーに任せる
• スレッドの実体を管理する
• DBにはサマリーのみ書き込む
• C++でデーモンとして実装(Linux)

2-1.コンセプト設計
プレーヤーの設計方針

• コメントこそがコンテンツである
• コメントしやすく
• 簡単入力、即時反映
• Flash 8

2-1.コンセプト設計

• プロトタイプが3営業日で完成

2-2.進化
公開向け準備 サーバー編

• 「このサービスは絶対うける」→スケーラビリティを考慮せよ
• 「HTTPしか通らないユーザーでも楽しめるようにせよ」令

2-2.進化
公開向け準備 プレーヤー編

• Flash付属の動画再生コンポーネントは、多機能で逆に面倒
• 使いやすいUIのコンポーネントを作成
• swfだけで完結
• 必要な機能のみ
• 高速で小さい

2.コンセプト設計と進化(まとめ)
最初のコンセプトである

• 非同期実況を(ほぼ)保ちつつ
• なんとかなった

３. もう少し詳しく
Webサーバー

• メッセージサーバー
• プレーヤー

3-1. Webサーバー
スケーラビリティ

• メッセージサーバーの増設に対応
• getflv: プレーヤーの通信先を一旦問い合わせることで設定変更を迅速に適用

3-2.メッセージサーバー
コードジェネレータ

• 通信方式
• 高速化

3-2-1.メッセージサーバー
コードジェネレータ

• パケット定義からサーバ/クライアントのコードを生成する
• 無矛盾で迅速な変更が可能

3-2-1.メッセージサーバー
図3-2-1.コードジェネレータ画面
3-2-2.メッセージサーバー
通信方式

• XMLSocket
• HTTP
• 双方向chunked content-transfer-encoding
• 下りのみchunked
• polling

3-2-3.メッセージサーバー
高速化

• DBアクセスを削減
• キャッシング
• スレッドの想定コメント数を拡大して再設計
• 全件読み込みから末尾のみの読み込みに変更

3-3.プレーヤー
画面レイアウト

• XGA想定
• 動画再生に同期したコメント表示
• コメントの細密充填 (特許出願中)
• マーキー/上下固定、弾幕など

図3-3-1.プレーヤー
図3-3-2. SWF逆コンパイラ
まとめ

• と思ったけど
• まだ、まとまらない(進化中)ので

感想

• ユーザーが満足するものにするためには、ユーザーが自分達で醸成するのを助けよ
• 実際の利用状況に合わせて改良する
• 高速なフィードバックが大きな効果
• 日々の蓄積が大事