Yuが、大規模サービスのキャッシュにおいてRedisを活用する取組みについて紹介しています。Redisを採用している理由キャッシュだけで、ストレージとしては利用していない。主なところでは、Twitterのタイムラインで利用している。ホーム画面であれ、ユーザ画面であれ、タイムラインはTweetのインデックスなので、key/valueストア型のRedisを利用するケースとして最適。以前はmemcachedを使っていたが、問題になったのは、タイムラインでおきるread/writeは、(ユーザが閲覧している範囲に追加反映するということなので)比較的小さいが、オブジェクト自体、つまりタイムライン全体はユーザによっては、数百件、数千件となり、規模が大きいということ。この大きなサイズだとデータベースを直接見に行きたくはない(ので、キャッシュから取得しようとするが)。read-modify-writeをしようとすると、小さなタスクのために大きなオブジェクトを送らなければいけないというジレンマになる。これだと、コストがかかりすぎる。ネットワークをボトルネックにしたくない。ほとんどのキャッシュサービスはギガリンク経由だと、シンプルなread/writeだと100K/秒以上を処理できるが、オブジェクトの平均サイズが1Kとなると、ボトルネックはネットワークになる。次の問題としては、フレキシブルなスキーマを採用していて、対象のオブジェクトがもつ属性が存在するときもしないときもあるとする。各属性に別々のkeyを用意して、全てに対してリクエストを送らなくてはいけないが、都合よくキャッシュにあるかどうかはわからない。別の事例としては、時系列で取得していくメトリックス。どのメトリックスデータも同じ名称で、タイムスタンプの違いだけ。それをキャッシュに保存したら、長い共通のプレフィックスのデータを何度も繰り返し保存する作業をすることになる。それらのケースの場合、長い共通のプレフィックスで管理できると、スペースをもっと有効に活用できるようになる。インメモリkey/valueストアは、かなりCPUの負担が軽いことがわかった。ベンチマーク測定したところ、1%のCPU時間で、小さめのkey/valueであれば、1000件/秒以上のリクエストを処理できる。使用されているキャッシュメモリクラスタは、常にCPUをそれほどは使っていない。シンプルなkey/value構造にするとサーバサイドに大きく余裕ができるということ。よって、Redisは最適。IDのリスト、つまりintegerのリスト。Redisには、ziplistとlinkedlistという二種類のデータ構造がある。キーごとのオーバーヘッドが小さい。