Cassandraの概要 - OracleCassandraはFacebookによっ て開発され、2008年にオープン...

ORACLE.COM/JAVAMAGAZINE ///////////////////// JANUARY/FEBRUARY 2014

JAVA TECH

34

COMMUNITY

JAVA IN ACTION

ABOUT US

blog

//java architect /

Apache Cassandra は、データ分散機能を備え、線形スケーラビリティがあり、一貫性レベルを調整できるNoSQL 永続化ソリューションです。高可用性と大容量への対が求められるアプリケーションに非常に適しています。CassandraはFacebookによって開発され、2008 年にオープンソース化されたのですが、元々は Bigtable および Dynamo に関するホワイト・ペーパーの影響を受けています。Cassandra のパーティションとレプリケーションの考え方はDynamoを参考としています。一方、Cassandra のログ構

造型の「カラム・ファミリ」データ・モデルは Bigtableとよく似ています。このデータ・モデルでは、スキーマは使用せずに、データとそのデータに関連するキーが保存されます。Cassandra は、Netflix、eBay、Twitter、redditなど、オンライン業界における多数の有力企業によって使用されています。

利点Cassandra をストレージ・ソリューションとして選択することには多くの利点がありますが、そのうち特に魅力的なのが実行速度です。

Cassandra は、書込み速度が非常に優れていることで知られていますが、読込みの速さも他に負けません。さらに、高可用性も持ち合わせています。非集中型のピアツーピア・アーキテクチャを採用し、シングル・ポイント障害となり得るマスター・コンポーネントは存在しません。そのため、特に複数のデータセンターにわたってノードを配置する場合に、フォルト・トレランスが非常に高くなります。 また、Cassandra は停止時間なく線形的にスケーリングします。つまり、x台のノードが y個のリクエストに対して必要な場合には、2x 台のノードで 2y 個のリクエストに対応できます。バージョン1.2での仮想ノードの導入により、容量増加時に通常起こる負荷増大はすべてのノードに分散され、負荷が高い状態でのスケーリングは問題となりません。スケールアップもスケールダウンも非常に簡単です。ほかにも、柔軟性という利点が

あります。この柔軟性は、アプリケーションのニーズに応じて各リクエストの一貫性レベルを調整で

きることから実現されます。 Cassandra には、Netflix やTwitterといった有力企業を含む活発なコミュニティがあり、このコミュニティによりオープンソース・ライブラリが提供されています。Cassandra は現在も活発に開発が進められているため、更新は頻繁に行われ、多くの改善が実施されています。

欠点適切なユースケースに対して使用する場合、Cassandra は非常に効果的で多くの利点をもたらしますが、万能薬ではありません。リレーショナル・データベース関連の経歴を持つ開発者にとって最大の課題となるのが、特にトランザクションにおいて、ACID 特性（原子性、一貫性、独立性、永続性）が欠如していることです。ACID 特性は、これまで多くの開発者が頼ってきた考え方であるからです。このような ACID 特性の欠如は Cassandra 特有の問題ではなく、分散データ・ストア共通の副作用となっています。開発者が効果的なデータ・モデルを設計するためには、保存される

Cassandra の概要Cassandra をストレージ・ソリューションとして選択することで得られる多くの利点について

KIM ROSS

著者の Kim Ross が、ソーシャル・ゲームの新興企業における特定のユースケースで Cassandra が適していた理由について説明します。

and JavaBig Data

Kim Ross ：スケーラビリティの課題があるサーバーサイドの Javaアプリケーションを専門とする開発者。テクノロジーに情熱を注ぎ、業界の最新の開発手法の調査に熱心。2002 年よりJava による開発に関わり、フロントエンド・システムとバックエンド・システムの両面において豊富な開発経験を持つ。

ORACLE.COM/JAVAMAGAZINE ///////////////////// JANUARY/FEBRUARY 2014

JAVA TECH

35

COMMUNITY

JAVA IN ACTION

ABOUT US

blog

//java architect /

データの内容だけではなく、そのデータの発生頻度やアクセス・パターンについても慎重に検討する必要があります。データ・アクセスを効率化するために、通常は、読取り方法に準じて複数のカラム・ファミリにデータを書き込みます。このような非正規化は、パフォーマンス向上の目的でよく利用される一方で、該当するすべての場所にあるデータを確実に更新するという新たな責任を開発者に課すことになります。データ・モデルの考察が足りず、アクセスの仕方が悪い場合は、実行速度が非常に低下します。必要なデータ・アクセス方法（たとえば分析システムの場合に、どのような状況で古いデータに関する新しいビューが必要になるか）がわからない場合は、Cassandra を Hadoop などのMapReduceテクノロジーと組み合わせる必要があります。Cassandra は、既知のキーを使用して特定のデータにアクセスするという状況にもっとも適しています。Cassandra は比較的新しいテクノロジーであり、非常に安定してはいるものの未熟であるため、経験豊富な人材を見つけることが困難です。しかし、情報は豊富にあり、各種カンファレンスのビデオがオンラインで公開されているため、Cassandra のスキルは容易かつ迅速に習得できます。そのため、未熟であるという理由でやる気を失うことはありません。

また、Cassandraでは、運用のための管理作業は少なく、1週間に1回程度、リペアを確実に実行するだけで済みます。リペアによって、該当するすべてのノードで、すべてのデータが確実に同期されます。

構造次に、Cassandra の構造について確認します。データは複数のノード内に保存され、複数のノードにレプリケートされます。ノードという言葉は、かつては Cassandra インスタンスをホストするサーバーを指していました。しかし、仮想ノードの導入により、現在は 1台のサーバーに複数の（仮想）ノードが搭載されます。また、データを重複して保存するノードの個数は、レプリケーション・ファクタと呼ばれます。ノードは 1

つのトークン・リングに沿って分散され、トークン・リング上のどのノードにデータを保存するかは、キーのハッシュによって決定されます。 Cassandraではさまざ

まなレプリケーション戦略を使用できます。レプリケーション戦略とスニッチの組み合わせによって、データのレプリケート先が決定されます。スニッチは、ノードに関する情報を調査します。その後、この情報をレプリケーション戦略が利用して、データを適切なノードにレプリケートします。たとえば、

NetworkTopologyStrategyでは、データセンターごとにレプリケーション・ファクタを指定します。そのため、複数のデータセンターにわたってデータがレプリケートされ、1つのデータセンター全体が停止したとしても可用性を確保できます。

データ構造キースペースとは、カラム・ファミリが定義される名前空間のことであり、概念的にはデータベースに相当します（図1）。レプリケーション・ファクタおよびレプリケーション戦略はキースペース・レベルで定義されます。 カラム・ファミリは複数の行で構成されます。各行には行キーによるインデックスが付けられ、各行はカラムのコレクションで構成されます。各カラムは、カ

ラム名、値、タイムスタンプで構成されます。ここで注意すべき点として、各行に格納できるのは、完全に一意のカラムのコレクションです。 1 行におけるカラムの順序は重要です。最適なパフォーマンスを実現するためには、互いに近くにあるカラムを一緒に読み取ってディスクのシーク時間を最小限に抑える必要があります。カラムの順序と各カラム名のデータ型は、コンパレータによって指定します。また、各カラムの値のデータ型はバリデータによって指定します。カラムが自動的に有効期限切れになるように、カラムに有効期限（TTL）を設定することも可能です。TTL の期間が過ぎた後のカラムは自動的に削除されます。また、特殊なカラム型やカラム・ファ

ミリ型がいくつかあります。「Counter」

大容量に対応 Cassandra は、データ

分散機能を備え、線形

スケーラビリティがあ

り、一貫性レベルを調

整できるNoSQL永続化

ソリューションです。高

可用性と大容量への対

応が求められるアプリ

ケーションに非常に適

しています。

図1

Keyspace

Column Family

Column Column

Column Column

row key 2

row key 1namevaluetime stamp

namevaluetime stamp

namevaluetime stamp

namevaluetime stamp

...

...

...

ORACLE.COM/JAVAMAGAZINE ///////////////////// JANUARY/FEBRUARY 2014

JAVA TECH

36

COMMUNITY

JAVA IN ACTION

ABOUT US

blog

//java architect /

カラム・ファミリはカウンタ・カラムのみで構成されます。カウンタとは64ビットの符号付き整数であり、原子的なインクリメント操作やデクリメント操作を実行できるため便利です。カウンタ・カラムに対して実行できる操作はほかに、読取りと削除しかありません。カウンタ・カラムは、カラムのデータに対して原子的な操作を実行できる唯一のカラム型です。そのため、データが一貫性レベル「ONE」で書き込まれない限り、カウンタ・カラムのインクリメントには通常のカラムの更新よりも時間がかかります。スーパーカラム・ファミリに格納でき

るのはスーパーカラムのみです。スーパーカラムとはカラムのカラムのことです。ネストされたデータを格納できます（図 2）。たとえば、「home」スーパーカラムであれば、「street」、「city」、「postcode」などのカラムで構成されるでしょう。スーパーカラムには、ネスト可能なレベルが 1つのみという制限があります。さらに動的なネストが必要な場合は、コンポジット・カラムを使用する必要があります。 コンポジット・カラムとは、カラム名が重複のない複数のコンポーネントで構成される通常のカラムのことです（図 3）。これらの名前に対して部分一致の問合せを実行できます。順序を保証するために、コンパレータのコンパレータを使用します。コン

ポジット・カラムを使用すれば、カラムを任意の深さにまでネストできます。この任意の深さへのネスト機能があること、および Cassandra の初期バージョンではスーパーカラムよりもコンポジット・カラムの方がパフォーマンスに優れていたことから、現在はスーパーカラムではなくコンポジット・カラムが、ネストされたデータの標準形式となっています。

削除操作の分散削除操作の分散には難しい問題が伴います。仮に、Cassandra がデータを単純に削除するとすれば、削除操作がすべてのノードに伝播されない可能性があります（停止中のノードがある場合など）。その場合にリペアを実行すれば、削除されなかったデータが最新のデータと見なされ、該当するノードに再度レプリケートされるため、削除されたデー

タが復活してしまいます。 そのため、Cassandra

では、データを削除するのではなく、トゥームストーンによりマークします。リペアを実行すると、トゥームストーンでマークされたデータが最新のデータと見なされます。そのため、削除操作の実行時に停止していたノードに対して、そのトゥームストーンがレプリケートされます。 トゥームストーンとその関連データは、デフォルトでは 10日後、コンパク

ション処理中に削除されます。したがって、リペア（手動プロセス）の実行頻度をコンパクション処理（通常は週に 1回）よりも高くして、トゥームストーンがクリーンアップされる前に、該当するすべてのノードにレプリケートされるようにすることが重要です。

一貫性Cassandra は一貫性レベルを調整でき

るにもかかわらず、よく「結果整合性を持つデータ・ストア」と表現されます。データベースは、読取り操作により確実に最新のデータが返される場合に一貫性があると見なされます。 注：Cassandra を使用する際に重要になるのが、CAP 定理を理解することです。CAP 定理にあるとおり、一貫性、可用性、分断耐性の 3つの要素のうち、同時に実現できるのは最大 2つです。

...

...

......

Super 2

row key 1

Person 2

Subcolumn 1

value value

home

street

Baker Street London EC1 4GA

city postcode

value value value

Subcolumn 2 Sub 1 Sub 2 Sub 3

Supercolumn name 1

図2

...

...

...row key 1

Person 2

name1part1:part2

value value

home:street

Baker Street London EC1 4GA

home:city home:postcode

name2part1:part2

図3

線形スケーラビリティCassandra は、スケーラ

ブルかつ大容量のデー

タ・ストアが必要な場合

に使用できる優れたツー

ルです。ほとんど負荷の

コストをかけずに線形ス

ケーラビリティを確保で

きるため、トラフィック

が急増したときにも問題

なく対応できます。

ORACLE.COM/JAVAMAGAZINE ///////////////////// JANUARY/FEBRUARY 2014

JAVA TECH

37

COMMUNITY

JAVA IN ACTION

ABOUT US

blog

//java architect /

データの書込みまたは読取りの際には、データ・リクエストのたびに一貫性レベルを設定できます。一貫性レベルには、「ONE」、「TWO」、「ALL」、「QUORUM」などがあります。 ここで、レプリケーション・ファクタが3の例を考えます。一貫性レベル「ONE」で書込みや読取りを行う場合は、読取りを行うノードが、それまでに発生していた書込み操作による更新が行われておらず、古いデータが読み取られる可能性があります。レベル「ONE」で書き込む場合、データが 1つのノードにのみ書き込まれるという意味ではないことに注意してください。Cassandra は常に、該当するすべてのノードへの書込みを試みます。レベル「ONE」が意味することは、1つのノードへの書込みが成功した直後に、操作の制御が返されるということです。 一貫性レベル

「QUORUM」は、レプリケーション・ファクタの 2分の1に 1を加算したレベルです。たとえば、レプリケーション・ファクタが3の場合、QUORUMは 2になります。 一貫性レベル「QUORUM」で読取りや書込みを行った場合は、データ一貫性が保証されます。たとえば、データがノードAとノードBに書き込まれ、ノードCには書き込めなかった場合に、そ

のデータをノードBとノードCから読み取るとします。この場合、Cassandra はデータに関連付けられたタイムスタンプを利用して、最新のデータがノードBにあると判断し、そのデータを返します。一貫性レベル「QUORUM」では一貫性が確保されるのに加え、1つのノードが

停止状態になってもリクエストには影響を及ぼしません。 一貫性レベルが「ALL」の場合、読取りと書込みの一貫性は確保されますが、1つのノードが停止状態に陥った状況を処理できません。また、覚えておくべきこととして、指定した一貫性レベルを達成するためにアクセスする必要のあるノード数が増えるほど、Cassandra の処理速度は低下します。レプリケーション・ファクタを3とした場合に、一貫性レベル「QUORUM」で読取りを行うと、実行速度は最速から2番目のノードと同一になります。一方、一貫性レベル「ALL」の場合は、実行速度が一番遅いノードの応答を待つ必要があります。そのため、ユースケー

スの一部で古いデータを許容できるかを検討する価値があります。

Cassandra へのアクセスCassandra には cqlshというコマンドライン・インタフェースがあります。この

インタフェースを使用して、データ・ストアに直接アクセスできます。cqlshでは、SQLと非常によく似た CQL 言語によるコマンドを実行できます。しかし、構文上似ているからと言って、バックグラウンドの処理も同じであると思い込まないようにしてください。 Java（およびその他の言語）からCassandra にアクセスするための各種ライブラリが存在します。たとえば、Datastax が開発した、CQLを受け入れる Javaドライバがあります。このドライバの開発以前は、Thrift API を経由するしか Java からCassandra にアクセスする方法はありませんでした。Thrift APIをサポートするライブラリは数多くあり、Hector、Astyanax がその一部です。現在は、Thrift APIと Javaドライバの両方がサポートされます。

まとめCassandra は、スケーラブルかつ大容量のデータ・ストアが必要な場合に使用できる優れたツールです。ほとんど負荷のコストをかけずに線形スケーラビリティを確保できるため、トラフィックが急増したときにも問題なく対応できます。短期間で稼働状態まで設定することも

比較的簡単ですが、データを適切にモデリングできるように、アクセス・パターンを把握する時間をかける必要があります。Cassandra には、詳細調査を行う十分な価値があります。そうすることで、最適な利用パターンについて良い情報が得られるためです。今日の増え続けるデータの要件を考慮すれば、Cassandraはあらゆる開発者がツールキットに加え

るべき価値あるツールと言えます。</article>

LEARN MORE• 『 Cassandra Data Modeling Best Practices, Part 1』

• 『 Cassandra Data Modeling Best Practices, Part 2』

• 『Virtual Nodes in Cassandra 1.2』

卓越した速度Cassandraをストレージ・ソリューションとして選択することには多くの利点がありますが、そのうち特に魅力的

なのが実行速度で

す。Cassandra は、

書込み速度が非常

に優れていることで

知られていますが、

読込みの速さも他

に負けません。

and JavaBig Data

MORE ON TOPIC: