redisソート済みセット型を利用した

タイムラインのリアルタイム生成

アーキテクチャ

スマートフォンコミュニティグループ

寺本 隆彦

2012年 2月 29日

概要 アメブロフェイスというスマートフォン向けのブラウザベースのサービスを

リリースした。アメブロフェイスは、自分のタイムライン上にフォローした芸

能人の顔写真のみが表示されるというサービスである。タイムライン形式のイ

ンターフェースを実現するにあたり、一般的なアーキテクチャを採用すると、

つながり数が多くなるにつれてレスポンスタイムが遅くなる問題や、データ量

の増加に起因して運用コストが高くなる問題、ディスクへの書き込みがボトル

ネックになってコンテンツの反映が遅延する問題などが起きることが想定され

た。アメブロフェイスでは、これらの問題を解決すべくresisのソート済みセット

型を利用してリアルタイムにタイムラインを生成するアーキテクチャを考案し

て実装した。本稿では、このアーキテクチャの詳細と、パフォーマンス面での

評価を行う。

第第第第1章章章章 はじめにはじめにはじめにはじめに

1 背景 アメブロフェイスというスマートフォン向けのブラウザベースのサービスを

リリースした。アメブロフェイスは、アメーバの 1万人を超える芸能人ブロガ

ーから、好きな芸能人をフォローすることで自分のタイムライン上にフォロー

した芸能人の顔写真のみが表示されるというサービスである。アメブロフェイ

スのタイムラインには、特定のブロガーの顔写真のみを見ることができるブロ

ガータイムライン、ユーザーがフォローした複数のブロガーの顔写真を見るこ

とができるユーザータイムラインの２種類がある。図 1.1、図 1.2にブロガータ

イムライン、ユーザータイムラインの画面イメージを示す。このうち、ユーザ

ータイムラインは、複数のブロガーのコンテンツが時系列順に並んで表示され

ている。

アメブロフェイスに限らず、昨今のSNSやコミュニティ系サービスの中には、

コンテンツを時系列順に並べて表示するタイムライン形式のインターフェース

を備えたものが多く見られる。その多くが、アメブロフェイスのブロガータイ

ムラインのように単一投稿者のコンテンツを時系列で表示するタイムラインと、

ユーザータイムラインのように複数投稿者のコンテンツを混在させて表示する

タイムラインの２種類を用意している。例えば、Twitterやアメーバなうでも、

単一投稿者のつぶやきだけを集めたタイムラインと、ユーザーがフォローして

いる複数投稿者のコンテンツを集めたタイムラインが存在する。

2 本研究の目的

本稿では、便宜的に、前述の２種類のタイムラインを、単一投稿者タイムラ

イン、複数投稿者タイムラインと呼ぶ。後述するように、サーバー側において、

複数投稿者タイムラインに一般的なアーキテクチャを採用した場合、レスポン

スタイムの遅延、投稿データの反映までの遅延、データ量の増加などの問題が

発生することが分かっている。そこで本稿ではこれらの問題が発生しない、も

しくは問題の程度を軽減するアーキテクチャの構築を目的とする。また、実際

に実用に耐えうるアーキテクチャであることを確認するため、パフォーマンス

面での検証・評価を行う。

図 1.1 ブロガータイムラインの例(投稿者は 1人のみ)

図 1.2 ユーザータイムラインの例(投稿者は複数)

第第第第2章章章章 複数投稿者タイムラインの複数投稿者タイムラインの複数投稿者タイムラインの複数投稿者タイムラインの一般一般一般一般

的な的な的な的なアーキテクチャアーキテクチャアーキテクチャアーキテクチャ 1 一般的なアーキテクチャ候補 複数投稿者タイムラインを実現するために、一般的なアーキテクチャ候補とし

て「リアルタイム生成アーキテクチャ」、「事前生成アーキテクチャ」が挙げ

られる。ここではそれぞれについて、例を挙げて説明する。

なお、この例ではロールとして投稿者、閲覧者を定義する。複数の投稿者がコ

ンテンツを投稿し、投稿されたコンテンツは、コンテンツテーブルに格納され

る。また、コンテンツの閲覧者は、フォロー、友達申請などの行為を通じて、

コンテンツの投稿者との間に何らかのつながりができる。このつながりの情報

は、つながりテーブルに保持されることとする。

(A) リアルタイム生成アーキテクチャ

図2.1に複数投稿者タイムラインのリアルタイム生成アーキテクチャの概要を

図示する。コンテンツの投稿時、正規化した形でデータを格納し、その後複数

投稿者タイムラインの参照時に、つながり情報を基に、タイムラインをリアル

タイムで生成する手法である。表2.1、表2.2に、リアルタイム生成アーキテクチ

ャにおけるコンテンツの投稿時と、複数投稿者タイムラインの参照時の処理を

示す。また、表2.3にコンテンツテーブル、つながりテーブルの例を示す。

図2.1 リアルタイム生成アーキテクチャ

表2.1 コンテンツ投稿時の処理

項番 処理内容

1 コンテンツは投稿した投稿者ユーザーIDに紐づけた形でコンテンツテ

ーブルに格納する

表2.2 複数投稿者タイムライン参照時の処理

項番 処理内容

1 閲覧者のユーザーIDを基に、つながりテーブルから複数投稿者タイム

ラインに表示すべき投稿者のユーザーIDを取得する

2 取得した投稿者のユーザーIDを基に、全ての投稿者のコンテンツをコ

ンテンツテーブルから取得する

3 取得したコンテンツを時系列でソートする

4 ソート済みのコンテンツを最新順に表示数分返す

表2.3 コンテンツテーブル、つながりテーブルの例

(B) 事前生成アーキテクチャ

続いて、図2.2に複数投稿者タイムラインの事前生成アーキテクチャの概要を

図示する。コンテンツの投稿時、コンテンツテーブルに格納すると共に、つな

がり情報を基に、事前に非同期で複数投稿者タイムラインを生成しておく手法

である。参照時は生成済みの複数投稿者タイムラインを参照するのみであるた

め、参照時のレスポンスタイムの面で有利である。表2.4にコンテンツテーブル、

つながりテーブル、タイムラインの例を示す。タイムラインについては、KVS

などを利用してデータの順序付けが可能なデータ形式で保持することで参照時

のソートが不要になる。表2.5、表2.6に、事前生成アーキテクチャにおけるコン

テンツの投稿時と、複数投稿者タイムラインの参照時の処理を示す。

図2.2 事前生成アーキテクチャ

表2.4 コンテンツテーブル、つながりテーブル、タイムラインの例

表2.5.コンテンツ投稿時の処理

項番 処理内容

1 コンテンツは投稿した投稿者ユーザーIDに紐づけた形でコンテンツテ

ーブルに格納する。

2 非同期でそのユーザーをフォローしている全ユーザーのタイムライン

にコンテンツを追加する

表2.6. 複数投稿者タイムライン参照時の処理

項番 処理内容

1 事前に作成されたタイムライン情報を順番に表示する

2 一般的なアーキテクチャの課題 以上、一般的なアーキテクチャとして、リアルタイム生成アーキテクチャ、事

前生成アーキテクチャの説明をしたが、どちらもシステム上の課題を抱えてい

る。表2.7、表2.8にリアルタイム生成アーキテクチャの課題を示す。

表2.7. リアルタイム生成アーキテクチャの課題

No 内容

1 参照時に複数のユーザーのコンテンツ情報をソートして、リアルタイム

でタイムラインを生成するため、つながり数が増えるほどレスポンスが

遅くなる。そのため、現実的な時間でレスポンスするためには、つなが

り数に一定の制限が必要となる。

表2.8. 事前生成アーキテクチャの課題

No 内容

1 コンテンツを投稿したユーザーとつながりのある全ユーザーのタイム

ラインに非同期書き込みが発生するため、芸能人などのつながり人数が

多いユーザーが投稿した際に、書き込みに時間がかかり、投稿がタイム

ラインに反映されるまで遅延が発生する。

2 普段タイムラインへのアクセスが発生しない休眠状態のユーザーの分

も含めて、全ユーザーのタイムライン情報を非正規化して保持するた

め、データ量の増加が大きい。

各々の性能特性を一言で表すと、リアルタイム生成アーキテクチャは参照ボ

トルネック、事前生成アーキテクチャは更新ボトルネックと言える。構築する

サービスが、参照、更新のどちらが多いサービスになるかを見極めた上でアー

キテクチャを選択する必要がある。通常は、更新よりも参照の方が圧倒的に多

く、また、リアルタイム生成アーキテクチャは、タイムライン上に表示する投

稿者の数が増加するほど、パフォーマンス上問題になるため、事前生成アーキ

テクチャが採用されていることが多い。例えば社外ではTwitter、社内ではAmeba

なうなども事前生成アーキテクチャを採用している。

3 アメブロフェイスにおけるアーキテクチャの選択 アメブロフェイスでは、コンテンツの閲覧は、全てのユーザーが可能であるの

に対して、コンテンツ（ブログ画像）の投稿は、芸能人ブロガーのみに制限し

ている。結果、投稿者1人当たりがフォローされている人数は、一般人と比較し

て非常に多くなることが想定される。そのため、事前生成アーキテクチャのデ

メリットである書き込み遅延の影響を特に受けやすいサービスといえる。遅延

を防ぐために、Fusion-ioを導入するなどの解決策も考えられるが、ハードウェア

に頼った高コストな対応は避けたいと考えた。また、データの増加は、データ

分割や再配置などが発生し、長期的に運用上の負荷が高く問題となってくるた

めこちらも回避したいと考えた。

そこで、アメブロフェイスでは、リアルタイム生成アーキテクチャを改良し

たredisのソート済みセット型を利用するアーキテクチャを考案した。

第第第第3章章章章 redis のソート済みセット型を用のソート済みセット型を用のソート済みセット型を用のソート済みセット型を用

いたリアルタイム生成アーキテいたリアルタイム生成アーキテいたリアルタイム生成アーキテいたリアルタイム生成アーキテ

クチャクチャクチャクチャ 1 redisソート済みセット型

redisとは、オープンソースのキーバリューストアである。データは基本的に

全てメモリ上に展開しているため、読み込み、書き込みともに非常に高速であ

る。また、バリューとして格納できるデータに型を持たせているのを特徴とし

ており、文字列型、ハッシュ型、リスト型、セット型、ソート済みセット型を

格納することができる。そのため、redisはデータ構造サーバーと呼ばれること

もある。

この中でソート済みセット型は、重複のない文字列のコレクションである。

格納される要素はメンバーと呼ぶ。ソート済みセット型の全てのメンバーは、

スコアと呼ばれる順序付けのための数値を持っており、スコアの値が最小のも

のから、最大のものまでを予めソートして格納しておくことができる。

スコアに投稿日時を設定することで、コンテンツを時系列順に格納すること

ができる。この特徴のため、redisはタイムライン形式のデータを保持させるの

に適しているとされる。実際に、アメーバなうでも、redisのソート済みセット

型を利用している。

2 redisソート済みセット型を用いたリアルタイム生

成アーキテクチャ アメブロフェイスでは、redisのソート済みセット型を利用してタイムライン

をリアルタイムで生成するアーキテクチャを考案・採用した。このアーキテク

チャは、事前生成アーキテクチャのデメリットを受けず、また、通常のリアル

タイム生成アーキテクチャのデメリットを軽減する。

このアーキテクチャは、コンテンツの投稿時に、単一投稿者タイムラインを

redisのソート済みセット型として格納しておき、複数投稿者タイムラインへの

参照が発生した時点で、単一投稿者タイムラインをマージして複数投稿者タイ

ムラインを生成する。生成した複数投稿者タイムラインは、一定時間キャッシ

ュとして保持しておき、キャッシュが存在する場合は生成済みの複数投稿者タ

イムラインから結果を返す。redisがオンメモリのデータストアであること、単

一投稿者タイムラインが事前にソート済みであることから、通常のリアルタイ

ム生成処理と比較して高速な処理が期待できる。図3.1に、アーキテクチャの概

要を示す。また、表3.1に、単一投稿者タイムライン、複数投稿者タイムライン

の例を示す。

図3.1 redisのソート済みセット型を用いたリアルタイム生成アーキテクチャ

表3.1 単一投稿者タイムライン、複数投稿者タイムラインの例

3 複数投稿者タイムライン生成の具体的な処理方法 複数投稿者タイムライン生成の具体的な方法について説明する。ソート済み

セット型は、予め時系列順にソートされており、以下のコマンドによって、指

定した範囲のデータセットを高速に取得することができる。

表3.2 ZREVRANGEBYSCOREコマンド

項目 内容

コマンド名 ZREVRANGEBYSCORE

構文 ZREVRANGEBYSCORE key max min [WITHSCORES] [LIMIT

offset count]

処理内容 max, minで指定された範囲内のスコアのメンバーをスコアの降

順で返す

計算量 O(log(N)+M)

N：キーに含まれるメンバー数、M：返すメンバー数

※LIMIT オプションなどで返すメンバー数が固定されている場

合、O(log(N))と見なすことができる。

このコマンドを利用することで、以下の処理を実施する。

表3.3 複数投稿者タイムライン参照時の処理

項番 処理内容

1 つながりテーブルから、参照する複数投稿者タイムラインに含まれ

る投稿者を取得する

2 1人目の単一投稿者ブロガーのタイムラインから、複数投稿者タイム

ラインに保持させる最大件数分のメンバーを最新順に取得する。

3 取得したメンバーのうち、一番古いスコアを取得する

4 2人目の単一投稿者タイムラインから、3で取得したスコアより新し

いメンバーを取得する

5 2と4で取得したメンバーを、マージして再度スコア順にソートする

6 5でソートしたメンバーのうち、一番古いスコアを取得する

7 3人目の単一投稿者タイムラインから、6で取得したスコアより新し

いメンバーを取得する。

8 以下、1で取得した全投稿者分、処理を繰り返す

9 1～8で生成されたタイムラインの情報を一定時間の間キャッシュす

る

10 生成したタイムライン情報をクライアントに返す

11 以後、タイムラインへの参照時に生成済みのタイムラインがキャッ

シュとして存在する場合、キャッシュ情報を返す

このアーキテクチャは、リアルタイム生成アーキテクチャ、事前生成アーキ

テクチャが抱えていた課題を回避、もしくは軽減する。具体的には、以下のよ

うな特徴になる。

表3.4 reedisソート済みセット型を利用したリアルタイム生成アーキテクチャの

特徴

項番 処理内容

1 コンテンツの投稿時には、投稿したユーザーのタイムラインのみにデ

ータを追加すれば良いため、事前生成アーキテクチャのデメリットで

あった書き込み遅延は発生しない。複数投稿者タイムラインにアクセ

スした時点での最新のデータが反映される。

2 ユーザータイムラインは、参照時に生成して、一定時間キャッシュ後

に消去する方式のため、データ量の増加は単一投稿者タイムラインの

分だけとなる。

3 つながり人数が増えると複数投稿者タイムラインの生成に時間がかか

るが、単一のユーザーのタイムラインは時系列にソート済みの状態で

保持されているため、単純なリアルタイム生成アーキテクチャと比較

して処理時間は短くなる。

第第第第4章章章章 パフォーマンス評価パフォーマンス評価パフォーマンス評価パフォーマンス評価 1 評価方法 考案したアーキテクチャが実用に耐えるかどうかの確認のため、実際にAPIを

備えたWebアプリケーションを作成し、JMeterを用いた負荷テストを行った。用

意したAPIは以下の3つである。なお、(1)の複数投稿者タイムライン生成APIが、

最もCPUを使用し、レスポンスタイムも懸念されるため、この処理の負荷、レ

スポンスタイムを検証する必要がある。

(1)複数投稿者タイムライン生成API

単一投稿者タイムラインを本稿で考案した手法でマージして、複数投稿者タイ

ムラインを生成する処理。

(2)キャッシュ済み複数投稿者タイムライン参照API

複数投稿者タイムライン生成APIで生成後、キャッシュとして保持された複数投

稿者タイムラインの参照処理。

(3)単一投稿者タイムライン参照API

事前に構築済みの単一投稿者タイムラインを参照する処理。

想定負荷

以下の想定で負荷をかける。

表4.1 想定負荷量(負荷テストにおける負荷量)

トランザクション量 API タイプ

回/日 回/時間 回/分 回/秒

複数投稿者タイムライン生成

API 参照/更新 500,000 41,667 694 12

キャッシュ済み複数投稿者タ

イムライン参照 API 参照 5,000,000 416,667 6,944 116

単一投稿者タイムライン参照

API 参照 1,000,000 83,333 1,389 23

2 スループット スループットの測定結果は、表 4.2 の通りとなった。想定値に基づいて単位時

間当たりに発行したトランザクション量が、ほぼそのままスループットとなっ

ていることが分かる。即ち、想定量の負荷を問題なく捌いており問題ないとい

える。

表 4.2. スループット測定結果

スループット API タイプ

回/日 回/時間 回/分 回/秒

複数投稿者タイムライン生成

API 参照/更新 502,175 41,848 697.5 11.6

キャッシュ済み複数投稿者タ

イムライン参照 API 参照 4,900,265 408,355 6,805.9 113.4

単一投稿者タイムライン参照

API 参照 993,202 82,767 1,379.4 23.0

3 レスポンスタイム レスポンスタイムの測定結果は、表 4.3、図 4.1の通りとなった。

複数投稿者タイムライン生成 API に一番時間がかかっていることが分かる。ま

た、図 4.1より複数投稿者タイムライン生成 API の平均レスポンスタイムは、ユ

ーザーの平均つながり数に単純比例していることが読み取れる。ここで、ユー

ザーの平均つながり数と、レスポンスタイムの関係は、線形近似により以下の

式で求められる。

y = 1.455x + 95.7

レスポンスタイム(ミリ秒)： y

ユーザーの平均つながり数： x

このままスケールすると仮定すると、つながり数 500で、約 0.82秒、つながり

数 1,000で、約 1.6秒のレスポンスタイムとなる。複数投稿者タイムライン生成

API が呼ばれるのは、キャッシュが存在しない状態でアクセスした場合のみであ

るため、ユーザー１人当たりの最大つながり数を 1,000程度に制限すれば、レス

ポンスタイムも実用上は特に問題ないといえる。

表 4.3 平均レスポンスタイム測定結果

レスポンスタイム

API

ユーザー

の平均つ

ながり数 Average Median

90%

Line Min Max

20 116 110 135 81 474

40 163 156 193 105 500

60 185 176 221 117 483

80 216 207 262 133 532

複数投稿者タイムライン

生成 API

100 235 229 263 145 1410

20 37 34 52 20 332

40 38 35 51 20 435

60 37 35 48 20 283

80 37 34 47 19 345

キャッシュ済み複数投稿

者タイムライン参照 API

100 41 37 54 21 1380

20 33 29 44 19 242

40 34 29 45 18 431

60 31 29 40 18 250

80 33 30 42 19 293

単一投稿者タイムライン

参照 API

100 34 31 48 18 222

0

50

100

150

200

250

20 40 60 80 100

ユーザーの平均つながり数

平均

レス

ポン

スタ

イム

(ミ

リ秒

)

複数投稿者タイムライン生成API

キャッシュ済み複数投稿者タイムライン参照API

単一投稿者タイムライン参照API

図4.1 平均レスポンスタイム測定結果

4 WAP サーバーCPU使用率 表4.4, 図4.2に、WAPサーバーのCPU使用率を示す。全体のCPU使用率は約30%

で、4CPUで適切に並列処理されていることが分かる。なお、検証マシンのスペ

ックを表4.5に示す。ユーザーの平均つながり数は100である。

表4.4 WAPサーバーのCPU使用率

CPU %user %sys %iowait %idle

All 27.86 2.47 0.22 64.72

0 21.27 1.83 0.67 75.81

1 20.2 2.37 0.13 76.8

2 47.85 3.31 0 34.2

3 22.11 2.37 0.09 72.07

WAP CPU使用率内訳

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

all 0 1 2 3

CPU

CP

U使

用率 %idle

%iowait

%sys

%user

図4.2 WAPサーバーのCPU使用率

表 4.5 検証に使用したマシンのスペック

項目 内容

機種 DELL R310

CPU Intel(R) Xeon(R) CPU

※クアッドコア

5 redisサーバーCPU使用率 表4.6、図4.3にredisサーバーのCPU使用率を示す。検証マシンのスペックを表4.7

に示す。

表4.6 redisサーバーのCPU使用率

CPU %user %sys %iowait %idle

all 32.63 1.38 0 64.21

0 65.27 2.76 0 28.41

1 0 0 0.02 99.98

redis CPU使用率内訳

0%

20%

40%

60%

80%

100%

all 0 1

CPU

CPU

使用

率 %idle

%iowait

%sys

%user

図4.3 redisサーバーのCPU使用率

表 4.7 検証に使用したマシンのスペック

項目 内容

機種 DELL R300

CPU Intel(R) Core(TM)2 Duo CPU E6405 @ 2.13GHz

メモリ 12GB

全体のCPU使用率は約34%であるが、内訳を見るとCPUは1つしか使っていない

ことが分かる。これは、redisがシングルスレッド動作であることが理由である。

なお、redisは複数CPUを効率的に使用するために、同一サーバー内に複数インス

タンスを立ち上げ、別のサーバーとして動かすことを推奨している

（http://redis.io/topics/faq）。そのため、同一ノード内に作成するインスタンス数

以上のCPUは、使用されないため注意が必要である。

アメブロフェイスでは、実際のリリース時に、表4.8で示すように合計3ノードを

用意し、各ノード内にAOF、SNAPSHOTという別の設定を施した ※( )インスタン

スを2つずつ作成した。

※( ) AOF…全データが永続化されるため、データロストは発生しない。

SNAPSHOT…非同期でディスクに書き出す。タイミングによってはデータロ

ストする。

表4.8 アメブロフェイスにおけるredisインスタンスの構成

ノード 用途 種別 インスタンス数

AOF 1 1 マスター

SNAPSHOT 1

AOF 1 2 スレーブ1

SNAPSHOT 1

AOF 1 3 スレーブ2

SNAPSHOT 1

第第第第5章章章章 考察考察考察考察 1 WAP サーバーCPU使用率 本稿で考案したアーキテクチャでは、WAPサーバーの負荷が高くなる。実際の

測定結果も、複数投稿者タイムライン生成API の実行回数が多くなると、WAP

のCPU使用率も高くなることが見て取れた。しかしながら、そのCPU使用率は

WAPの追加などによって対応できる範囲の現実的な値であることが分かった。

アメブロフェイスでは、リリース時点で16コアCPU WAPサーバーの2台構成とし

ている。リリース前に別途実施した負荷テストでは、目標である2億PV※( )を達

成した時点の負荷をかけたが、WAPサーバーのCPU使用率は6%程度であり、実

用上全く問題のない結果であった。

※( )全ての画面、APIへのリクエストを含めた目標である。複数投稿者タイムラ

イン生成APIのみへのリクエスト数ではない。

2 redis上に保持するデータ量 前述したようにredisは、基本的に全てのデータをメモリ上に展開することを

特徴としている(※)。そのため、メモリサイズ以上のデータを扱う場合は、デー

タをシャーディングしてサーバーを分割することが前提となってしまう。この

ため、ユーザーの増加にともなって単純比例的にデータ量が多くなる事前生成

アーキテクチャとは相性が悪い。例えば、アメーバなうでは実際にユーザーの

増加に伴って定期的にサーバーの増設と、データの再配置を行っているが、こ

れが運用上の負荷となっているとのことである。

※( )redis2.4系までは、Virtual Memoryと呼ばれるRAMより大きいサイズのデー

タを扱うための機構が用意されていたが、2.6以降この機能は廃止される。

本稿で提案したアーキテクチャにおいては、redis上に単一投稿者タイムライ

ンのみを生成しておけば良いのだが、アメブロフェイスではコンテンツの投稿

を芸能人に制限しているため、単一投稿者タイムラインのデータ量は1～2GB程

度と非常に少ない。今後においても、芸能人ブロガーの投稿数増加によるデー

タ量の増加はありえるが、一般ユーザーの増加によるデータ量の増加はほぼ発

生しない。そのため、今後ユーザー数が増加したとしても、redisインスタンス

の追加やそれに伴うデータの再配置などは不要とすることができた。非常にコ

ンパクトで運用しやすいシステムを構築できたと考える。

第第第第6章章章章 結論・まとめ結論・まとめ結論・まとめ結論・まとめ 本稿では、アメブロフェイスで採用した複数投稿者タイムラインの生成アー

キテクチャについて述べた。redisのソート済みセット型を利用して、タイムラ

インをリアルタイムで生成するアーキテクチャを考案し、実際にパフォーマン

ス評価を行った。また、実際に本稿で考案したアーキテクチャを実装し、2012

年2月21日にサービスとして無事にリリースした。リリース後、2012年2月28日

現在まで特に問題なく稼動している。

本稿で提案したアーキテクチャは、つながり数に一定の制限を加える必要が

ある反面、データ量の増加を最小限に抑え、つながり数の多い投稿者による書

き込み遅延の影響も受けないという特徴を持っている。今後、タイムラインア

プリケーションのアーキテクチャの選択肢として参考にしてもらえると幸いで

ある。

参考文献 [1] Tiago Macedo and Fred Oliveira, Redis Cookbook, O’Reilly Media Inc, (2011)

[2] redis, http://redis.io/