Cassandra導⼊事例と現場視点での苦労したポイント

Created by ⽻⽑⽥ 敦

(株)ぐるなび 企画第2部⾨ ビジネスソリューショングループ

Cassandra Summit 2014 JPN

2014/01/24

アジェンダ⾃⼰紹介、会社紹介

Cassandra利⽤の経緯、事例紹介

Cassandraのメリット、デメリット

⾃⼰紹介⽻⽑⽥ 敦 （はけた あつし）

SIerにて6年間クラウド関連サービスの研究開発を担当

ぐるなびには2013年4⽉に⼊社し、

Webページを⽀える基盤システムの開発に携わる

Cassandra触り始めて１年程度

現在、主にトラッキング管理システムの開発と運⽤を担当

会社紹介

レストラン検索サイト運営

総掲載店舗数：約50万店

詳細情報掲載店舗数：13万9,000店（以上 2013 年 12⽉末現在）

⽉間アクセス数：10億1,000万PV（2013 年 12⽉末現在）

⽉間ユニークユーザ数：4,200万⼈（2013 年 12⽉末現在）

ぐるなび会員数：1,133万⼈（2014 年 1⽉ 1⽇現在）

Cassandra利⽤の経緯・事例紹介

利⽤のきっかけ以前はレストラン情報保管に

RDBやXMLファイルを利⽤していた

⇒遅い

レストラン⼀部情報保有に

サーバ2台でmemcachedを利⽤(2010年初め)

しかし…

データ量増加アクセス数増加データ永続性などの拡張性を懸念

これらの要件を満たすデータストアの検証を開始

データストア検証

2010年からCassandra検証開始(Version 0.6)

当時はScalaris、Flare、Tokyo Tyrantと⽐較検証

要件満たす機能と、Facebook・Twitter(仮)の実績から

Cassandraを採⽤

Cassandra利⽤スタート

2010年7⽉〜本番環境での利⽤開始

16ノード構成

Version 0.6.1

レストラン情報の他に携帯端末情報やQRコード情報などを管

理（最⼤4個のKeySpace管理)

2012年11⽉ Version 1.1.5にアップデート

同⼀Cassnadra環境でKeyspace分割して管理

Cassandraの本格利⽤①

レストラン基本情報管理システム

2013年6⽉〜レストランの基本情報をCassandraに集約

3データセンタ、70ノード構成

基本データ⽤：42ノード

画像・ファイル⽤：18ノード

バックアップ⽤：10ノード

Version 1.1.10

以前の構成(静的)

問題点

情報のリアルタイム性

データの柔軟性

耐障害性(シングルポイント)

現在の構成(動的)

動的なページ変更や柔軟な部分更新

データの分散と耐障害性

⾼負荷アクセスに耐えるシステム

マルチデータセンタ構成

遠隔地へのバックアップをしています

Cassandraの本格利⽤②

トラッキング情報管理システム

ユーザのアクセス履歴を管理するシステム

⼩さいデータの頻繁なWriteが特徴

2014年3⽉〜データストアをMySQLからCassandraに変更

2データセンタ、18ノード構成

本番⽤：12ノード

バックアップ⽤：6ノード

Version 1.2.12

データストア検証

バックエンド⽐較 (2012年12⽉)

Cassandra、MySQL Cluster、VoltDB、Riak…etcを⽐較

永続性、耐障害性、スケーラビリティ、性能…etcを検証

利⽤実績やWriteの速さからCassandraを採⽤

Cassandra採⽤によって

⼤容量データの管理

- 5億件、約1TBのデータを保存

⾼負荷アクセスへの対応

- 秒間1500アクセスに対応

無停⽌スケールアウト

Cassandra 利⽤事例まとめ様々なシステムのデータストアとして利⽤

主な選定理由

耐障害性(SPOFなし)

柔軟なテーブル定義

無停⽌スケールアウト

⼤量データ/⼤量アクセスへの適⽤

マルチデータセンタでのバックアップ

Cassandra使ってみてメリット/デメリット

メリットトラッキング情報管理システムを例に…

以前の問題点

MySQLの容量逼迫

- トラッキングデータ件数：５億件(約1TB)

MySQLスケールアップでのサービス停⽌

- 共通基盤システムのため、様々なシステムに影響が出る

Cassandra利⽤で変化

複数サーバでの⼤量データ管理

システム無停⽌でのスケールアウト

⾼頻度アクセスでも⾼速レスポンス(数msec)

デメリット(困ったこと)1. トランザクション制御(排他制御)できない

2. 削除まわりが難しい

トランザクションはあきらめるとしても、

排他制御くらいはしたい

排他制御について

CassandraはCAP定理のAPを採⽤

⇒整合性は取れない

⇒トランザクション制御出来ない

ZooKeeperの利⽤分散環境でのソフトウェア管理を助けるツール。

共有設定管理、分散ロック、分散キューなどの機能がある。

ZooKeeperロックで排他制御が可能

排他制御の仕組み

ZooKeeperロックでの排他制御の仕組み

もう少し詳しく

ロック待ちとロック取得

ZooKeeperにはこんな使い⽅も

クライアント時刻ずれの問題

ZooKeeperにはこんな使い⽅も

ただし…ZooKeeperはさむので遅くはなる(パフォーマンス検証必要)

ZooKeeperの構成上リーダーとフォロワーがあり、

リーダーのヒープ障害が単⼀障害点(SPOF)になりかねない

…という問題もある

よって監視が必須

他の排他制御

もしくは、Cassandra内でロック⽤テーブルを定義しても

良いかもしれない

他の排他制御

Cassandra内でロック⽤テーブルを使った場合

TTL以上経過でロック⾃動無効

同⼀データの連続ロックで、処理遅延の傾向あり

排他制御についてまとめ

Cassandraはトランザクションや排他制御できない(はず)

ZooKeeperロック利⽤で排他制御は実装可能

Cassandra内でロックデータ管理する独⾃ロック機能も

実装可能

どちらも完璧とは⾔えないため、どのような実装が好ましいか

システム要件に合わせて検討すべき

デメリット(困ったこと)1. トランザクション制御(排他制御)できない

2. 削除まわりが難しい

削除の概要

Cassandraでは2段階でデータを削除する

1. tombstone(墓⽯)という論理削除フラグ登録

2. SSTable(ディスク)から物理削除

データ内容を確認してみました(Version 1.2.6)

xx-Data.dbに対してsstable2json実⾏してデータを確認

1. まずはデータ登録

set student_table['id100']['name']='Yamada';

2. データ論理削除

del student_table['id100'];

⇒Deleteしたよという情報がinsertされるイメージ

{"key": “id100","columns": [[“name",“Yamada",1373511538239000]]}

{"key": "id100","metadata": {"deletionInfo": {"markedForDeleteAt":1373511662967000,"localDeletionTime":1373511662}},"columns": []}

3. gc_grace_second(猶予期間)待つ

4. Compaction発⽣（データ追加＆nodetool flushによるMinor Compaction）

⇒Compaction発⽣で新しく出⼒されたSSTableには該当rowKey

データは存在しない 。ログからも容量減少は確認できる。

⇒物理削除完了

INFO [CompactionExecutor:31] 2013-07-08 17:18:32,864 CompactionTask.java (line 230) Compacted to [/xxxxx/xxxxx-Data.db,]. 383 to 143 (~37% of original) bytes for 4 keys at 0.011365MB/s. Time: 12ms.

データ削除に関する問題点

1. 削除データが復活する

2. 古いデータの物理削除に時間がかかる

データ削除の問題① 復活

多重障害発⽣によって削除したデータの復活があり得ます前提： レプリケ数3、QUORUMのRead・Write

※この後Aを起動しても、Dataは復活した状態のまま

削除復活が発⽣しないよう、

gc_graceまでに全ノードへ削除伝播が必要

↓

gc_graceまでにrepairの実施が必要

↓

よって、運⽤において定期的なrepairは重要です。

データ削除の問題② 消えない

デフォルトのCompaction Strategy(SizeTieredCompaction)では同

じ位のサイズのSSTableが4つ出⼒されたら

Compactionを発⽣する

⼀旦⼤きなSSTableが出⼒されると、

それがCompactionの対象になるには時間がかかる

例えば、 1⽇に1個⼩さいSSTableを吐くシステムで、

データは64⽇後に削除する仕様だった場合

物理削除可能になってから実際には182⽇かかる

古いデータ消すには

ひたすら待つほどディスク余裕無いし…

Major Compactionは推奨されて無いようだし…

Leveled Compactionはファイル数が膨⼤になりそうだし…

古いデータ消すには

Cassandra 1.2からの新機能にTombstone Compactionがある

Tombstone Compaction検証

Tombstone Compaction検証のためこんなことしてみました。

(Version 1.2.6)

【初めの数⽇】

データ作成⇒古いデータへのremove実施

⇒待ったり、flushしたり、⼩さなCompactionおこしたり

…単⼀SSTableのCompaction確認できず

なるほど、JMXから監視してみた。

どうやらTTL設定したデータだと

DroppableTombstoneRatioが0より⼤きくなりそう

Tombstone Compaction検証

Stack Overflowに投稿

⇒なんとJonathan Ellisから回答が！

You probably don't have enough data in the sstable

for Cassandra to guess the tombstone ratio. You

can use the getDroppableTombstoneRatio method

from ColumnFamilyStoreMBean over JMX to

check.

Tombstone Compaction検証

TTLを設定したデータの単独Compaction発⽣は確認できた！

↓の設定でinsertぶん回したら、単独Compaction発⽣

gc_grace: 600sec

tombstone_threshold: 0.0001

tombstone_compaction_interval: 1

TTL: 600sec

⇒この機能ちゃんと利⽤するにはもう少し検証が必要そう。

Tombstone Compaction検証

でも、通常のremoveでは確認できず。

ソースコードもチェックしたが、どうやら↓で取得する値が0の

ため、単独Compationが起きない模様

org.apache.cassandra.sb.compaction.AbstractCompactionStrategyのline182あたり

double droppableRatio = sstable.getEstimatedDroppablTombstoneRatio(gcBefore);

データ削除の問題 まとめデータ復活の可能性がある

定期的なrepairが⼤事

古いデータの物理削除には時間かかる

ディスク容量に余裕を持たせることが⼤事

最新機能も検証は必要だが使えそう

（本⾳は）削除が不要なシステムがベスト

まとめぐるなびでのCassandra活⽤

様々なシステムへの適⽤

耐障害性と⼤量アクセスへの適応に着⽬

マルチデータセンタでバックアップ

Cassandraのメリット/デメリット

耐障害性と無停⽌スケーラビリティ、かつ⾼速なことは

魅⼒的

適切にポイントをつぶせば、厳しい要件でも⼗分使える

排他制御にはZooKeeper

削除には定期repairや新機能の利⽤

Any Questions ?

ご清聴ありがとうございました