ニコニコ生放送での利用

ニコニコ生放送システムの特徴

ニコニコ生放送は，リアルタイムの映像配信と，「⁠ニコニコ動画」特有のコメントシステムを組み合わせたサービスです。

ニコニコ動画との特性上の大きな違いは，リアルタイム性が高く求められることにあります。フロントエンドは一般的なWebアプリケーションの構成ですが，バックエンドでは，映像配信サーバーをはじめ，座席管理サーバー，コメントサーバー，ボットサーバーなど，様々なシステムがリアルタイムに連動しており，あらゆるデータが刻一刻と変化しています。

特に，話題性の高い公式の番組では，開場の瞬間に数万人のユーザが殺到することもあり，視聴データの更新が一瞬に集中するため，極端な高頻度参照・高頻度更新になります（開発チームではこれを「突入負荷」と呼んでいます⁠）⁠。

Redisの導入

様々な最適化を積み重ねた結果，番組タイトルや説明文などの更新頻度の低い情報や，ポイント関連の情報などは従来通りMySQLで管理し，視聴者数のカウントや最新番組一覧などの高頻度で更新される情報はインメモリベースのmemcachedに格納するという構成に落ち着きました。

しかし，この構成にも限界があったのです。memcachedはシンプルなキー・バリューであるが故，巨大な構造化データ（例えば，特定の番組を観た数万人のユーザIDのリスト）を扱うことが難しく，実装できる機能が制限されていました。

また，データ消失の恐れがあるため，視聴集計などの重要なデータを扱う場合には，別途MySQLやファイルにバックアップする機構を用意しなければならない点も問題でした。

これらの課題をクリアしつつ，しかもmemcached並に高速なソリューションを探していた折，まさに「インメモリ」「⁠永続化」「⁠データ構造サーバー」の特徴を持つRedisの存在を知り，迷わず導入を決めました。

利用例

2010年の6月の導入以来，システムの至るところに使われていますが，ここではその一端をご紹介します（開発中も含みます⁠）⁠。

フロントエンド

• 視聴者数カウンタ
• 番組タグリスト
• 番組タグの使用頻度順リスト
• カテゴリ別の最新番組リスト
• サイトリニューアル時のA/Bテスト集計

バックエンド

• セグメント別ユニーク視聴者数集計
• 番組間の視聴ユーザIDの集合演算による分析システム
• リアルタイムイベントログの集約
• サブシステム間の更新通知キュー
• 分散バッチ処理の中間データの集約，ソート機構

まとめ

今回は，Redisの概要からニコニコ生放送での導入経緯までを駆け足でご紹介しました。memcachedと比較されることが多いRedisですが，大まかにその違いと利点がお分かりいただけたのではないでしょうか。次回は，Redisのインストールから基本操作までをご紹介します。