Vol. 0

情報処理学会論文誌

No. 0

1959

読み出し性能と書き込み性能を両立させるクラウドストレージ
中 村 俊 介†首 藤 一 幸†既存のクラウドストレージは読み出し性能または書き込み性能のいずれか一方を重視した設計がなされている．この性能の性質は分散のための機構とは独立しており、ストレージエンジンに大きく依存する．我々はこの点に注目し，同一のシステム内でストレージエンジンの選択が可能でモジュラーなクラウドストレージ MyCassandra を開発してきた．しかし，MyCassandra は既存のクラウドス
トレージと同様に読み出しと書き込みの性能を両立させるということはできていない．
そこで本研究では，読み出し性能と書き込み性能の両立が可能なクラウドストレージ MyCassandra
Cluster を提案する．MyCassandra Cluster は、異なるストレージエンジンの MyCassandra ノードを組合せたクラスタを構成する. そして，それぞれの各ノードが得意とするリクエストを同期的に処理し，得意でないリクエストを非同期で処理するように，プロキシで割り振る．これにより読み出
し性能と書き込み性能を両立させるクラウドストレージが構築可能である．
元の Cassandra と比較したところ，Cassandra と同等の高い書き込み性能を保ちつつ，読み出しの遅延は最小 11.6%， 全体のスループットは最大 6.53 倍となることを確認した．

A Cloud Storage Supporting both ReadIntensive and Write-Intensive Workloads
Shunsuke Nakamura† and Kazuyuki Shudo†
A cloud storage with persistence shows solid performance only with a read-heavy or writeheavy workload. There is a trade-oﬀ between read-optimized and write-optimized design ofa cloud storage. It is dominated by the storage engine, which is a software component managing stored data on memory and disk. A storage engine is an independent component andit can be pluggable with an adequate software design though today’s cloud storages are notalways modular. We have developed a modular cloud storage MyCassandra to demonstratethat a cloud storage can be read-optimized and write-optimized by a modular design. Various
types of storage engines can be introduced into MyCassandra and they determine with whatworkload the cloud storage performs well. MyCassandra proved that such a modular design
enables a cloud storage to adapt to workloads.
In this paper, we present a method to build a cloud storage performing well with both readheavy and write-heavy workloads. A MyCassandra Cluster consists of MyCassandra nodes
with diﬀerent types of storage engines, read-optimized, write-optimized and on-memory (readand-write-optimized). A query is routed to nodes which process the query eﬃciently. A cluster
maintains consistency between data replicas with a quorum protocol. A MyCassandra Cluster
showed comparable performance with the original Cassandra with write-heavy workloads, andit showed considerably better performance with read-heavy workloads. In comparison with
Cassandra, its read latency was 11.6% and its read throughput was 6.53 times.

従来の RDBMS と比べてデータモデルやクライアン

1. は じ め にト側の機能を制限し，また整合性についての条件を緩

RDBMS が満たしきれない要求に応える分散データめることで，負荷の分散を比較的容易にし，ノード数ストアとして NoSQL，key-value store，document1)

oriented database ，GraphDB

2)をスケールアウトさせやすいという点である．

といったクラウド

しかしながら、それぞれのクラウドストレージはストレージが注目されている．これらの共通の特徴は様々な点で異なっている．例えば，データモデルには

key-value 形式や多次元マップ形式があり，分散の構成は master/worker 型，ツリー型，非集中分散型が† 東京工業大学
Tokyo Institute of Technology

あり，データを全てメモリ上で保持するものや永続化
1

先進的計算基盤システムシンポジウム (SACSIS2011) 論文集, pp.171-180, 2011年5月

情報処理学会論文誌

2

1959

が可能なもの，複製の配置方法やそれを同期/非同期で行うかなどというように様々な設計方針がある．
また，従来のクラウドストレージは書き込み性能重視のものと読み出し性能重視のものがある．例えば，Apache Cassandra3)4) や Apache HBase5) は書
き込み性能重視であるが，一方，Yahoo Sherpa6) や

sharded MySQL7) (MySQL の sharding 構成) は読
み出し性能重視である．この性質の違いは，分散のための機構には依存せず，システム内のストレージエン
ジンに大きく依存する．我々はこの点に注目し，前者と後者にモジュール化し，同一システム内で後者のス

図 1 Consistent hashing
Fig. 1 Consistent hashing

トレージエンジン部分を選択可能な分散データストア

MyCassandra8) を開発し，実際にストレージエンジンの選択によって，書き込み性能と読み出し性能が大きく変わることを確認してきた．

にトレードオフがある．
このようなトレードオフを考慮した上で，同一のク
ラウドストレージ内で読み出し/書き込み性能の両立

しかし，MyCassandra も読み出しと書き込みのどを図るためには，それぞれの処理に最適化されたスト

ちらか一方の性能しか重視できていないという点では，レージエンジンを持つノードの組合せによって，クラ

既存のクラウドストレージと同じである．そこで，我々スタを構成すれば良いと考えられる．

はこの欠点を補う為に，MyCassandra Cluster を提そもそも，既存のクラウドストレージにはストレー

案する．すなわち，異なるストレージエンジンの My-

ジエンジンを選択するという自由度は無く，固定されCassandra ノードを組合せたクラスタを構築し，読みた設計がなされている．そこで，我々はストレージエ

出し性能または書き込み性能に最適化されたストレー

ンジンの選択が可能であるモジュラーなクラウドスト

ジエンジンへ適切なリクエストの振り分けを行わせる

レージ MyCassandra を開発してきた．本研究ではこことで，同一クラウドストレージ内で読み出しと書きの MyCassandra をベースとして，読み出し/書き込み

込み両方の性能を両立できることを示す．

性能を両立させる MyCassandra Cluster を提案する．

本稿の構成は以下のとおりである．２章で研究背景

以下では，実装のベースに用いた Apache Cassan-

として，開発に用いた Apache Cassandra と開発しdra，MyCassandra を説明する.

た MyCassandra を説明する．３章で MyCassandra

2.1 Apache Cassandra

Cluster について提案する．４章で性能評価に用いた

Apache Cassandra は ，Facebook 社 が 開 発 し ，

ベンチマーク YCSB について述べた後に，性能測定

Apache Project としてオープンソース化したクラウの結果を示して考察する．５章で性能面以外について

ドストレージである．複数のデータセンターにまたが議論する．６章で本研究に関連する研究を挙げる．７

る数百台で運用可能なスケーラビリティや，非集中で章で本研究の貢献と今後の課題をまとめる．

単一故障点の無いことによる高い可用性を特徴とする．

2.1.1 Consistent Hashing

2. 研 究 背 景Cassandra は consistent hashing を用いてノードにクラウドストレージを用いる大規模なシステムでは，

対してデータの割り当てを行う．具体的には，リング

次にどのデータが参照・更新されるかを予測すること

状の ID 空間（図 1）を考え，ノードとデータの双方には難しい．そのため，全てのデータがメモリ上に収まID を割り当てる．例えば，リクエストのキー (key1)

らない限りは読み出し時にディスクへのランダム I/Oのハッシュ値が Q である場合は，ID 空間上で Q からが発生してしまう．書き込み時にランダム I/O を行

時計回りに最もノード ID が近いノード V がプライマ

うよりも，ディスクへのシーケンシャル I/O のみで書

リノードとなり，リクエストに対して応答する．また

9)

き込み処理を済ませるログ記録方式の方が，高いス

ループットを実現できるが， 一方このような方式でこのとき，任意のノードがリクエストのプロキシとなり，クライアントのリクエストに答える．

は，読み出し時はログから一連の更新結果を拾い集め

consistent hashing の利点は ハッシュ関数によりる必要があるために効率が悪い．つまり，既存のクラ各ノードの担当データ数が均等になり易く，負荷分散

ウドストレージには読み出し性能と書き込み性能の間が容易であることと，データの担当範囲を集中管理す先進的計算基盤システムシンポジウム (SACSIS2011) 論文集, pp.171-180, 2011年5月

Vol. 0No. 0

読み出し性能と書き込み性能を両立させるクラウドストレージ3

図 2 Cassandra の書き込みの流れ
Fig. 2 Write process in a Cassandra node

図 4 MyCassandra の Storage Engine Interface
Fig. 4 Storage Engine Interface of MyCassandra

答可能である点である．一方，欠点は，読み出し時に，
指定 key の差分データを複数の SSTable から読み出
してマージする処理が必要となる為に複数回のランダ
ム I/O が発生してしまい，読み出し性能が犠牲になる点である．データは必ず Commit Log か SSTable
図 3 Cassandra 読み書き性能
Fig. 3 Write/Read performance for Cassandra

上にデータがあるため，永続性は保たれる．
図 3 は Cassandra 6 台に対し，読み出しと書き込
みを同一頻度で，それぞれ 50 万回クエリを発行した

るサーバーが存在しないので，単一故障性が無く，高際の応答時間の分布である．上述した通り，書き込みい可用性を提供できることである．各ノードは gossipの方が読み出しよりも大幅に速いことが確認できる．

プロトコルによる定期的な情報交換により他の全ノー

2.1.3 レプリケーション

ド ID と IP アドレスを把握することで，任意のノーCassandra の複製は，リング状の ID 空間においてドがプロキシとしてクライアントの要求に応じる．

プライマリノードの時計回り方向 N − 1 ノードに配2.1.2 Bigtable のストレージエンジン置される．例えば図 1 において，レプリカ数 3 の場

Cassandra のストレージエンジンは Log Structured

合はハッシュ値 Q のデータは１つのプライマリノー

Merge Tree10) を採用した Google Bigtable11) のそれ

ド V と２つのセカンダリノード F，N に配置される．

を模しており，Commit Log，MemTable，SSTable

ラックやデータセンターを考慮した複製の配置方法もから構成される．

選択できる．

書き込み処理の流れ (図 2) を以下に示す．

(1)
(2)

まず，永続化の為にディスク上の Commit Log

MyCassandra は，Cassandra をベースとし，「分散に行に対する差分をシーケンシャルに書きこむのための機構」と「ストレージエンジン」に分離した

次に，読み出し性能の為にメモリ上のマップでクラウドストレージである．これにより，ストレージある MemTable を更新し，クライアントに応エンジンの選択を可能とした．

答する

(3)

2.2 MyCassandra

MemTable が保持するデータ量または未フラッ

図 4 に，Cassandra と MyCassandra での各ノード
内でのデータの読み書きに関係する部分を示す．My-

シュ時間についての閾値を超えた場合に，古いCassandra は，Cassandra のリクエストを受理する部

データをディスク上に SSTable として書きだ

分と各ストレージエンジンとの間に Storage Engine

す (フラッシュする)．この際，書きだしたデーInterface を設けている．このインタフェースが規定

タは，Commit Log から削除するする関数 (connect, put, get) を実装することで My-

この方式の利点は，ディスクへの書き込みが常にCassandra のストレージエンジンとして追加できる．

シーケンシャルで高速である点と，一度ディスク上に

現在，MyCassandra は Bigtable，MySQL，Redis

書かれた内容は変更されないため，ディスクに対するという性質の異なる３つのストレージエンジンを備書き込みロックが不要となり，常に書き込み要求に応える．

先進的計算基盤システムシンポジウム (SACSIS2011) 論文集, pp.171-180, 2011年5月

情報処理学会論文誌

4

図 5 ストレージエンジンごとの書き込み遅延
Fig. 5 Write latency for each storage engine

1959

図 6 ストレージエンジンごとの読み出し遅延
Fig. 6 Read latency for each storage engine

図 5, 図 6 は，これらのストレージエンジンについて読み出しと書き込みの回数の比率を変化させて，ベンチマーク YCSB (4.1 節参照) を実行した際の遅延結果を表している．これは 6 ノードでの結果である．

Bigtable は書き込みが速く，MySQL は読み出しが速いことが分かる．また，Redis は全てのデータをメ

図 7 MyCassandra Cluster の概念
Fig. 7 Basic idea of MyCassandra Cluster

モリ上に保持する為に，容量に制限はあるが，読み出
しと書き込み両方の性能が高いことが分かる．

2.2.1 ストレージエンジン
MyCassandra で選択可能なストレージエンジンについて述べる．

３種類のノード，すなわち，書き込み性能重視，読み出し性能重視，メモリベースのノードから構成される．
データの複製をこれら３種類のノードに配置し，書き込みリクエストは書き込み性能が高いノードに振りBigtable ストレージエンジンは，2.1.2 で紹介した分け，読み出しリクエストは読み出し性能が高いノーCassandra のログ構造のクラウドストレージをそのまドに振り分ける．例えば、図 7-(a) のように、書き込み

ま用いている．

クエリは書き込み性能重視のストレージエンジンノー

MySQL ストレージエンジンへのアクセスにはドに同期的に割り振り，読み出し性能重視のノードにJDBC を使用する．本研究では，MySQL 内ストレーは非同期で割り当てる．これにより書き込み性能と読ジエンジンとして InnoDB を用いた．また，ストアド

み出し性能の両立を達成できる．

プロシージャを用いて，ストレージエンジンとしては不要である SQL 文のパースを回避している．

この手法で問題となるのは，元の Cassandra と同じくらいの複製間の一貫性をできるだけ保つことであRedis12) ストレージエンジンは memcached のようる．複製間の整合性は，quorum (多数決) protocol でに key/value のペアをメモリ上に保持するメモリベー保つ．これは元の Cassandra が提供する機能である．

スの key-value store である．スナップショットをディMyCassandra Cluster は，3 種類のノードに複製を置

スクに非同期で書きこむ永続化機能や，メモリによる

くので，複製数 N は 3 以上である必要がある．そし制限を緩和する仮想メモリ機能をもつ. ただし，本研究て例えば N=3 の場合は，読み出しの合意数 R と書きではこれらの機能は使わず，単純なメモリベースのス込みの合意数 W が 2 以上であれば，quorum プロト

トレージエンジンとして用いる．アクセスには Redis

コルを満たす．つまり，MyCassandra Cluster は読み

固有の API を用いる．

出しと書き込み両方を同期的に処理するノードが必要

3. 提案手法・設計であるため，本手法では，メモリベースのノードを用いる．節 2.2.1 で述べたように，メモリベースのノー本研究では，読み出し/書き込み性能の両立が可能な

ドは読み書き両方に優れている．例えば，図 7-(b) のクラウドストレージ MyCassandra Cluster を提案す

ように，書き込みは書き込み性能重視とメモリベース

る．本節ではその手法と設計について説明する．My-のストレージエンジンノードに同期的に行い，読み出Cassandra Cluster は，ストレージエンジンの異なる

し性能重視のノードには非同期で行う．もちろん，メ

先進的計算基盤システムシンポジウム (SACSIS2011) 論文集, pp.171-180, 2011年5月

Vol. 0No. 0

読み出し性能と書き込み性能を両立させるクラウドストレージ5

図 8 リング上のホスト・ノード・ストレージエンジンの配置方法
Fig. 8 Host, node and storage engine placement on thering

モリベースのストレージエンジンを使うことのトレードオフは幾つかあるので，これについては 5 章で議論する．

3.1 ノード配置と負荷分散
MyCassandra は ，Cassandra 同 様 ，consistenthashing を用いてデータの担当ノードを決める (2.1.1，
2.1.3)．今回の実験ではデータ量を均等に分散させる

図 9 読み出しと書き込みの流れ (N=3 の場合)
Fig. 9 Flows of read and write processes (in case of N =3)

ためにノード ID を等間隔に固定して割り当てる．デー
タの複製は，リング状 ID 空間においてプライマリノー

際，異なるホスト上に配置された N ノードを選ぶよ

ドから時計回りに N ノードを選択して配置する．そうにする．具体的には，プライマリノードから時計回の際，ストレージエンジンの異なる 3 種類のノードがり N ノードを選ぶ際，既に選択済みノードと同一ホ

ひと通り含まれるように，N ノードを選択する．

ストに配置されるノードをスキップする．

また，物理ホストへのノード，ストレージの配置の3.2 メンバーシップ管理

選択肢は様々あり，それぞれにトレードオフがあると

MyCassandra Cluster では，クライアントが接続考えられる．図 8 に３つのノード配置方法を示す．本

した任意のノードがプロキシとしてストレージエンジ

手法では，図 8-(3) のように，負荷を均一にするためンを考慮した適切なリクエストの振り分けを行う仕組に１台のホストに書き込み性能重視，読み出し性能重みが必要となる．そのため全ノードが全ノードのスト

視，メモリベースの 3 つの MyCassandra ノードを配レージエンジンの種類を把握する必要がある．

置する方針をとる．つまり、各ホストはいずれかの種

そこで，本実装では Cassandra のメンバーシップ管類のプライマリノードと，それとはストレージエンジ

理に用いられる gossip プロトコルを利用する．Cas-

ンの種類が異なる 2 つの複製ノードを配置する．これ

sandra では，gossip プロトコルを用いてハートビー

は，各ホストに図 8-(1) のように，1 ノードずつ配置

トを含んだメッセージを他のノードと定期的に交換すするナイーブな方法では，1) ワークロードによって負ることで，メンバーシップ管理を行う．MyCassandra

荷が不均一になってしまい，また 2) 資源を十分に生Cluster では，このメッセージにストレージエンジン

かすことができないからである. 1) は，例えば読み出の種類を加えることで，互いにこの種類を把握できる

しの比率が多いワークロードの場合は，読み出しに割ようにしている．

り振られるノードに負荷が集中してしまう．2) は，全

3.3 読み出しと書き込み

データをメモリベースのノードのディスクが使われず，

図 9 に MyCassandra Cluster の読み出しと書き込

資源が無駄となる．また，図 8-(2) のように，1 ノー

みの流れを示す．書き込み/読み出し性能を両立させ

ドに複数のストレージエンジンを持たせ，その種類ごるために，書き込みリクエストは書き込み性能が高いとにリング状 ID 空間に仮想ノード13) として，割りノードに振り分け，読み出しリクエストは読み出し性

当てる設計方針も考えられるが，ストレージエンジン

能が高いノードに振り分ける．データの整合性を保ちの起動・削除といった運用の容易さから別プロセスとながら性能を確保するために，quorum プロトコルとして動かすべきと考えた．

いう多数決による手段を用いる．以下，N は複製数，

1 台のホストに複数のノードを置く際，同一のホス

W は書き込み合意数，R は読み出し合意数を表す．

トに複数の複製が配置されないようにする必要がある．

具体的な書き込み/読み出し処理の流れを説明する.

つまり，プロキシが，複製を配置するノードを決める

書き込み処理の流れを以下に示す．

先進的計算基盤システムシンポジウム (SACSIS2011) 論文集, pp.171-180, 2011年5月

情報処理学会論文誌

6１） 任意のプロキシノードがデータ担当ノードに書き込み要求をブロードキャスト

1959

dra はネットワーク近接性に応じて順序付けを行い、リクエストを送信する順番を決めるが、MyCassandra

２） データ担当ノードのうち，書き込み性能重視のCluster では gossip プロトコルで取得した担当ノード

ノードとメモリベースのノードの合計 W ノーのストレージエンジンで順序付けする．つまり，書きドに書きこんで，成功すれば ACK をクライア

込み処理時には書き込み性能重視，メモリベース，読ントに知らせる

み出し性能重視の順で，読み出し処理時には読み出し

３-a） 成功した場合，読み出し性能重視の N − W
ノードには非同期で書きこむ３-b） 失敗した場合，読み出し性能重視のノードも含めた合計 W ノードからの書き込みも待ってから ACK をクライアントに知らせる
手順２の書き込みが失敗しなければ，読み出し性能重性能重視，メモリベース，書き込み性能重視の順で，リクエストの送信先を順序付ける．

4. 性 能 評 価
MyCassandra Cluster が読み出しと書き込みの性能が両立できることを性能評価する．

視なノードへの書き込み遅延は全体の書き込み性能に評価に用いるストレージエンジンを以下に示す．

は影響を与えない為，遅延は書き込み性能重視なノー• 書き込み性能重視: Bigtable (Cassandra 0.6.2)

ドのものに抑えられる．

• 読み出し性能重視: MySQL (6.0.10-alpha)

読み出し処理の流れを以下に示す.
１） 任意のプロキシノードがデータ担当ノードに読み出し要求をブロードキャスト
２） データ担当ノードのうち，読み出し性能重視のノードとメモリベースの合計 R ノードからデータを取得し，整合性を確認する
３-a) もし，読み出しが成功し，整合性がとれていれ
ば，データをクライアントに返す• メモリベース: Redis (2.0.4)
性能測定には Yahoo!’s Cloud Serving Benchmark(YCSB)14) を用いる．
4.1 YCSBYCSB は，様々なクラウドストレージを公平に評価することを目的として，Yahoo! Research が開発した
オープンソースのベンチマークフレームワークである．
実アプリに近いコアワークロードが用意されている．

３-b） もし，読み出しの失敗または整合性がとれて

YCSB では，読み出し処理と書き込み処理の回数のいなければ，書き込み性能重視も含めて合計 R

比率をユーザが指定できる．YCSB がクラウドスト

ノードの整合性の取れたデータを待ち，データ

レージに対して読み出しと書き込みを実行し，ワークをクライアントに返す

ロード全体のスループットと，各処理に要した時間，

４） 残りの N − R ノードのデータの取得を待ち，もし整合性のとれていない古いデータを保持する

つまり遅延を集計する．

YCSB が行う処理は次の 3 フェーズから成る．

ノードがあれば，そのノードへの更新を非同期(1)load phase: 初期データをロードで行う（元の Cassandra の ReadRepair 機能）(2)

warmup phase: ワークロードを実行してデー

手順２の読み出しが失敗しなければ，書き込み性能重視なノードへの読み出し遅延は全体の読み出し性能には影響を与えない為，遅延は読み出し性能重視なノータストアのキャッシュをウォームアップ(3)transaction phase: ワークロードを実行してス
ループットと遅延を計測・集計

ドのものに抑えられる．整合性がとれない原因の多く

表 1 に，今回の測定で用いる 4 種類のワークロードを

は，読み出し性能重視のノードから得たデータのバー示す．書き込み比率が高い Write-Only，Write-Heavy，

ジョンが古く，メモリベースのノードのデータと整合

読み出し比率が高い Read-Only，Read-Heavy を用性が取れていないことに起因する．この場合でも，非意し，各ワークロードに対応する実アプリの例と，読同期に整合性の修正を行うため，次回以降のアクセス

み出しと書き込みの比率を表している．Write-Only，には書き込み性能重視のノードからの応答を待つこと

Read-Only とはそれぞれ読み出し，書き込みがバッなく，結果を返すことが出来る．データ整合性を保ち

クグラウンドで行われ，性能には影響を与えない．各つつも，読み出し遅延を基本的には読み出し性能重視

ワークロードにおいて，アクセス対象データの分布とのノードの遅延，最悪でも元の Cassandra と同じ大して Zipf 分布を用いる．Zipf 分布は，データ鮮度ときさの遅延で読み出せると期待できる．

は関係なく人気によってアクセス頻度が決まるような

このような操作を行うためには，プロキシがリクエ

アプリのデータアクセス分布を模した確率分布であり，ストを適切なノードへ転送する必要がある．Cassan-

一部のデータへのアクセス頻度が常に高く，大部分の先進的計算基盤システムシンポジウム (SACSIS2011) 論文集, pp.171-180, 2011年5月

Vol. 0

読み出し性能と書き込み性能を両立させるクラウドストレージ

No. 0

7

表 1 YCSB ワークロード
Table 1 YCSB workloads

Workload
Write-Only
Write-Heavy
Read-Heavy
Read-Only

App．Ex．
Log
SessionPhoto Tagging
Cache

Read
0%
50%
95%
100%

Write
100%
50%
5%
0%

データへのアクセス頻度は低くなる．
表 2 に実験パラメータを，表 3 に実験環境を示す．
複製数 N =3 として，MyCassandra Cluster は前述の

図 10 ワークロードごとの書き込み遅延
Fig. 10 Write latency for each workload

通り，1 台に 3 ノード立ち上げるので 3 × 6=18 ノード，Cassandra は実マシン 6 台上にそれぞれ 1 ノード
計 6 ノードとした．

4.2 実験結果と考察
図 10，図 11 にクライアント数を調整して１秒あたり 5,000 回のクエリを発行した際の読み出しと書き込みの平均遅延をワークロードごとに示す．書き込
み遅延は，MyCassandra Cluster はいずれのワーク
ロードにおいても，元の Cassandra と同等に小さい．
一方，読み出し遅延は，MyCassanra Cluster は Cas-

図 11 ワークロードごとの読み出し遅延
Fig. 11 Read latency for each workload

sandra よりも小さく，Read-Heavy のワークロードでは Cassandra の 14.8%，Read-Only のワークロード

クロードでは，元の Cassandra の方が MyCassandra

では 11.5%であるという結果が得られた．

Cluster よりも高い性能を発揮した．Write-Heavy の図 12 にクライアント数を 40 として負荷をかけた

ワークロードでは，書き込み遅延は MyCassadra Clus-

ときの全体のスループットをワークロードごとに示す．

ter の方が小さいが，読み出し遅延は Cassandra の方

こちらの結果でも，MyCassandra Cluster は Write-が小さい．このことから MySQL において，非同期のOnly のワークロードでは Cassandra と同等の高い

大量の書き込み処理が，並行して行われる同期的な読スループットを達成している．一方，読み出しの比率

み出し処理に影響を与え，結果として読み出し遅延のの高いワークロードでは，MyCassandra Cluster は劣化となっていると考えられる．

Cassandra よりも高く，Read-Heavy のワークロード

この点の改善方法として，現在はリクエストの種類

では 1.49 倍，Read-Only のワークロードでは 6.53 倍とストレージエンジンの種類でリクエストを固定してのスループットを達成した．

振り分けているが，この結果から 1) リクエストの振ところで，Write-Heavy (read:write=50:50) のワー

り分けの際のアクセス負荷の考慮，2) 各ストレージエ
ンジンにおける参照の局所性を生かしたリクエストの表 2 実験パラメータ
Table 2 Experiment parameters
ノード
クライアント
ロードレコード件数
quorumkey サイズvalue サイズ

実マシン× 6 台
実マシン× 1 台
1,000 万件
(N ,W ,R)=(3,2,2)
最大で長さ 10 の文字列
100Byte × 10 カラム 計 1KB

表 3 実験環境
Table 3 Machine conﬁgurations

OS
CPU
MemoryDisk
JVM

Linux 2.6.35.6-48.fc14.x86 64
2.40 GHz Xeon E5620 × 2
32GB RAM
1TB SATA HDD × 2 (表 4.2 と同じ)
Java SE 6 Update 21

振り分けが必要であると考えられる．つまり，読み出し性能重視のノードのアクセス負荷が大きく，データを書きこんですぐ読み出す場合は書き込み性能重視のノードから同期的に読みだした方が性能が良くなると考えられる．

4.3 SSD を用いた場合の性能
クラウドストレージではディスクへのランダム I/Oが性能のボトルネックとなる．ここまでは HDD を用いて実験を行ってきた. 一方，クラウドストレージで用いるディスク装置として，SSD が急速に普及しているため，SSD を用いた際の性能を確認した．
表 1 に HDD と SSD の諸元とディスク I/O ベンチ

先進的計算基盤システムシンポジウム (SACSIS2011) 論文集, pp.171-180, 2011年5月

情報処理学会論文誌

8

1959

図 13 Cassandra のスループット (HDD/SSD)
Fig. 13 Throughput for Cassandra on HDD vs. SSD

図 12 ワークロードごとのスループット
Fig. 12 Throughput for each workload

表 4 HDD と SSD の環境
Table 4 Disk conﬁgurations

vendermodel
capacityseq. write
seq. readrand. write
rand. read

HDD

SSD

Western Digital
WDC WD1002FBYS
1TB
86,277 qps
108,914 qps
2,485 qps
926 qps

CrucialCTFDDAC128MAG
128GB
96,401 qps
216,099 qps
29,045 qps
21,751 qps

図 14 MyCassandra Cluster のスループット (HDD/SSD)
Fig. 14 Throughput for MyCassandra Cluster on HDD
vs. SSD

マーク IOzone15) による逐次アクセスとランダムアク

ReadRepair は非同期に不整合を解決する Cassandra

セスのスループットを示す．各マシンにこの SSD を 2の機能である．つまり、メモリベースのストレージエ台搭載した．Cassandra では CommitLog，SSTable

ンジン上の失われたデータは永続的なストレージエン

を別のディスクに配置し，MyCassandra Cluster では

ジンのノード上のデータを使って復元される．これはランダム I/O が頻繁に発生する Bigtable の SSTable

プロキシノードが後者から受け取り、前者へ非同期でと MySQL を別のディスクに配置した．

送信する．メモリベースのストレージエンジンノード

YCSB の４つのワークロードのスループットをはそれ自身が一つのキャッシュノードとして動作する．

図 13，図 14 に示す．結果としては，Cassandra でたとえメモリベースのノードが故障しても，他のノーは，Read-Only のワークロードにおいて SSD が HDD

ドに残っているデータを使って復元することができる．

の 3.37 倍のスループットを得られた．MyCassandra

この復元までの間，MyCassandra Cluster は Hint-

Cluster では，Read-Heavy 時に SSD が HDD の 1.50

edHandoﬀ を行って，複製数を保つ．HintedHandoﬀ

倍のスループットが得られた．読み出し比率が高いワー

は，故障中のノードの代わりに他のノードにデータのクロードでの性能は，SSD による向上は大きく，特に変更点を格納する機能である．

Cassandra での性能向上が大きい．一方，書き込み比

また，メモリベースのノード上のデータがメモリか率が高いワークロードでの性能は，HDD と SSD でほら溢れた場合，解決手段としては 1) ストレージエンジ

ぼ同じとなった．これは Bigtable の書き込みはシーンに備わる永続化機能を用いるか，2)ReadRepair に

ク性能が低いディスク装置でも高い性能を発揮できる

よって他の永続ストレージエンジンから取得する方法

ように設計されているためであると考えられる．

がある．ただし、いずれも性能上のペナルティがある．

5. 議

論

本節では MyCassandra Cluster の設計に関する得失について議論する．

5.1 メモリベースのストレージエンジンの使用

5.2 ディスク/メモリの使用率
本手法が性能を発揮するには，各ホストが複数台のディスクを搭載することが望ましい．例えば、Bigtable
ストレージエンジンが逐次 I/O での書き込みを行うには，それ専用のディスクが必要となる．

ノード停止時でも，Cassandra の機能である Read-

また，メモリに関してはホスト 1 台のリソースを 3

Repair と HintedHandoﬀ によって複製数は保たれる．

ノードで分割して用いているが，これは，ストレージ

先進的計算基盤システムシンポジウム (SACSIS2011) 論文集, pp.171-180, 2011年5月

Vol. 0

読み出し性能と書き込み性能を両立させるクラウドストレージ

No. 0

9

エンジンに対するデータとアクセスの分散が均等であり入れることで，MyCassandra がより多様なワークる場合に，実験結果に表れている通り，元の Cassan-

ロードに対応できる可能性がある．

dra と同等，もしくはそれ以上の性能が得られている．
一方，不均等の場合の性能評価は，今後の課題である．

本研究では，クラスタ内で複数種類のストレージエ

6. 関 連 研 究

ンジンを組み合わせることで，読み出し/書き込み性

モジュラーなクラウドストレージと読み出し性能と書き込み性能の両立に関する関連研究を挙げる．

Anvil

16)

7. まとめと今後

は，細粒度のコンポーネント dTable を組

み合わせて構成するデータストアである．アプリケー

能を両立できるようなクラウドストレージの提案と実装を行った．元の Cassandra と同等の高い書き込み
スループットを達成しつつ，読み出し性能でも高い性能を達成した．以下に，今後の課題を挙げる．

ションのデータアクセスパターンに応じたデータスト

Amazon EC2 などの大規模なクラスタを用いて本アを構成できる．データストアをモジュラーに構成す

手法のスケーラビリティの検証を行う．ただし，Cas-

るという点は本研究と共通しているが，分散データス

sandra の構造ではプロキシ/データノード 1 台のアク

トアを対象としていない．

セスパスは変わらないため，ノード数の影響は受けな

Cloudy17) は，クラウドストレージをモジュラーにいと考えられる．

構成しようという提案である．ストレージエンジン以

ラックやデータセンターとのネットワーク近接性を外にも，ルーティング処理やロードバランスの方式も考慮しつつも，ノードごとに読み出し/書き込み性能

コンポーネント化し，選択可能とすることを提案してのどちらに優れるのか考慮して，複製を配置する．

いる．性能は報告されていない．

Amazon Dynamo

13)

アプリケーションの読み書きの比率に対して，最高は，Amazon 社がウェブサー

ビス向けに開発した key-value store である．ストレーのスループットが得られるようなストレージエンジンの構成比率を検討する．

ジエンジンとして BDB，MySQL，メモリ上のバッファクラウドストレージの性能は読み書きの比率によっの選択ができる．これらを選択する際の指標の例としてのみ決まるものではない．書き込まれたデータがどて，格納データのサイズを挙げている．Dynamo で用れくらいの頻度や間隔でアプリケーションから読み出いることのできるストレージエンジンでは，読み出し

されるかに依存する面もある．例えば，MyCassandra

性能と書き込み性能を調整はできない．

Cluster において書き込んですぐ読み出す必要がある

MyCassandra8) は読み出し性能重視と書き込み性場合はデータの同期的な読み出しを結果がまだ反映さ能重視の選択が可能であり，分散環境での定量的な評れていない読み出し性能重視なノードからではなく，価を行えている．また，本研究ではこの MyCassandra

書き込み性能重視なノードから行った方が遅延を小さをベースとして読み出し性能重視，書き込み性能重視

く抑えられると考えられる．このようにデータアクセの選択だけでなく，その両方の性能を両立している．

スの特性を考慮する．

書き込み性能と読み出し性能の両立する索引アルゴ
18)

リズムの研究はなされている．FD-Tree

は，SSD 上における効率的な索引アルゴリズムであり，B+-tree
並の検索速度と LSM-tree 並の更新速度という成果が得られている．対象が SSD に限られている．また，クラウドストレージへの適用が期待される．

Fractal-Tree は MySQL の新しいストレージエンジ
ン TokuDB19) に実装されている索引アルゴリズムである．従来の B-Trees の場合，データの書き込み時にディスクへのランダム I/O が必要となるが，Fractal-

Tree ではこのランダム I/O を効率的に逐次 I/O に変換することで，書き込み処理をより高速に行うことができる．Fractal-Tree，B-Trees，LSM-Tree など様々な索引アルゴリズムには，それぞれに向いたワーク
ロードがある．これらをストレージエンジンとして採謝辞 本研究は科研費（22680005）の助成を受けたものである．

参考文献1) 10gen: MongoDB, http://www.mongodb.org/(2009).
2) Neo Technology: Neo4j, http://neo4j.org/(2010).
3) The Apache Software Foundation: Cassandra,
http://cassandra.apache.org/ (2010).
4) Lakshman, A. and Malik, P.: Cassandra A Decentralized Structured Storage System,
Proc. LADIS ’09 (2009).
5) The Apache Software Foundation: HBase,
http://hadoop.apache.org/hbase/ (2010).
6) Cooper, B. F., Ramakrishnan, R., Srivastava,U., Silberstein, A., Bohannon, P., Jacobsen, H.,

先進的計算基盤システムシンポジウム (SACSIS2011) 論文集, pp.171-180, 2011年5月

10情報処理学会論文誌

Puz, N., Weaver, D. and Yerneni, R.: PNUTS:Yahoo!’s Hosted Data Serving Platform, Proc.
VLDB ’08 (2008).
7) Oracle: MySQL, http://www.mysql.com/.
8) 中村俊介, 首藤一幸: 読み出し性能と書き込み性能を選択可能なクラウドストレージ, 情報処理学
会研究報告, 2011-OS-116(-10) (2011).
9) Sears, R., Callaghan, M. and Brewer, E.:
Rose: compressed, log-structured replication,
Proceedings of the VLDB Endowment, Vol. 1(1), pp. 526–537 (2008).
10) O’Neil, P., Cheng, E., Gawlick, D. and O’Neil,E.: The Log-Structed Merge-Tree (LSM-Tree),Acta Informatica, Vol. 33 (2), pp. 351–385(1996).
11) Chang, F., Dean, J., Ghemawat, S., Hsieh,
W. C., Wallach, D. A., Burrows, M., Chandra, T., Fikes, A. and Gruber, R. E.: Bigtable:
A Distributed Storage System for Structured
Data, Proc. OSDI ’06 , Vol. 7, pp. 205–218(2006).
12) Redis: Redis, http://redis.io/ (2010).
13) DeCandia, G., Hastorun, D., Jampani, M.,
Kakulapati, G., Lakshman, A., Pilchin, A.,
Sivasubramanian, S., Vosshall, P. and Vogels,
W.: Dynamo: Amazon’s Highly Available Keyvalue Store, Proc. SOSP ’07 (2007).
14) Cooper, B. F., Silberstein, A., Tam, E., Ramakrishnan, R. and Sears, R.: Benchmarking Cloud Serving Systems with YCSB, Proc.
SOCC ’10 (2010).
15) Don Capps: IOzone Filesystem Benchmark,
http://www.iozone.org/.
16) Mammarella, M., Hovsepian, S. and Kohler,E.: Modular Data Storage with Anvil, Proc.
SOSP ’09 (2009).
17) Kossmann, D., Kraska, T., Loesing, S.,
Merkli, S., Mittal, R. and Pfaﬀhauser, F.:
Cloudy: A Modular Cloud Storage System,
Proc. VLDB ’10 (2010).
18) Li, Y., He, B., Yang, R. J., Qiong, L. and Ke,
Y.: Tree Indexing on Solid State Drives, VLDB
’10 (2010).
19) Tokutek: TokuDB, http://tokutek.com/ (2011).

先進的計算基盤システムシンポジウム (SACSIS2011) 論文集, pp.171-180, 2011年5月

1959