Cassandra Summit 2014 の発表資料です。

1. Cassandra導⼊事例と
現場視点での苦労したポイント
Created by ⽻⽑⽥ 敦
(株)ぐるなび 企画第2部⾨ ビジネスソリューショングループ
Cassandra Summit 2014 JPN
2014/01/24

2. アジェンダ
⾃⼰紹介、会社紹介
Cassandra利⽤の経緯、事例紹介
Cassandraのメリット、デメリット

3. ⾃⼰紹介
⽻⽑⽥ 敦 （はけた あつし）
SIerにて6年間クラウド関連サービスの研究開発を担当
ぐるなびには2013年4⽉に⼊社し、
Webページを⽀える基盤システムの開発に携わる
Cassandra触り始めて１年程度
現在、主にトラッキング管理システムの開発と運⽤を担当

4. 会社紹介

5. レストラン検索サイト運営
総掲載店舗数：約50万店
詳細情報掲載店舗数：13万9,000店（以上 2013 年 12⽉末現在）
⽉間アクセス数：10億1,000万PV（2013 年 12⽉末現在）
⽉間ユニークユーザ数：4,200万⼈（2013 年 12⽉末現在）
ぐるなび会員数：1,133万⼈（2014 年 1⽉ 1⽇現在）

6. Cassandra利⽤の経緯・事例紹介

7. 利⽤のきっかけ
以前はレストラン情報保管に
RDBやXMLファイルを利⽤していた
⇒遅い

8. レストラン⼀部情報保有に
サーバ2台でmemcachedを利⽤(2010年初め)
しかし…
データ量増加
アクセス数増加
データ永続性
などの拡張性を懸念
これらの要件を満たすデータストアの検証を開始

9. データストア検証
2010年からCassandra検証開始(Version 0.6)
当時はScalaris、Flare、Tokyo Tyrantと⽐較検証
要件満たす機能と、Facebook・Twitter(仮)の実績から
Cassandraを採⽤

10. Cassandra利⽤スタート
2010年7⽉〜本番環境での利⽤開始
16ノード構成
Version 0.6.1
レストラン情報の他に携帯端末情報やQRコード情報などを管
理（最⼤4個のKeySpace管理)
2012年11⽉ Version 1.1.5にアップデート

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

12. Cassandraの本格利⽤①

13. レストラン基本情報管理システム
2013年6⽉〜レストランの基本情報をCassandraに集約
3データセンタ、70ノード構成
基本データ⽤：42ノード
画像・ファイル⽤：18ノード
バックアップ⽤：10ノード
Version 1.1.10

14. 以前の構成(静的)
問題点
情報のリアルタイム性
データの柔軟性
耐障害性(シングルポイント)

15. 現在の構成(動的)
動的なページ変更や柔軟な部分更新
データの分散と耐障害性
⾼負荷アクセスに耐えるシステム

16. マルチデータセンタ構成
遠隔地へのバックアップをしています

17. Cassandraの本格利⽤②

18. トラッキング情報管理システム
ユーザのアクセス履歴を管理するシステム
⼩さいデータの頻繁なWriteが特徴
2014年3⽉〜データストアをMySQLからCassandraに変更
2データセンタ、18ノード構成
本番⽤：12ノード
バックアップ⽤：6ノード
Version 1.2.12

19. データストア検証
バックエンド⽐較 (2012年12⽉)
Cassandra、MySQL Cluster、VoltDB、Riak…etcを⽐較
永続性、耐障害性、スケーラビリティ、性能…etcを検証
利⽤実績やWriteの速さからCassandraを採⽤

20. Cassandra採⽤によって
⼤容量データの管理
- 5億件、約1TBのデータを保存
⾼負荷アクセスへの対応
- 秒間1500アクセスに対応
無停⽌スケールアウト

21. Cassandra 利⽤事例まとめ
様々なシステムのデータストアとして利⽤
主な選定理由
耐障害性(SPOFなし)
柔軟なテーブル定義
無停⽌スケールアウト
⼤量データ/⼤量アクセスへの適⽤
マルチデータセンタでのバックアップ

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

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

24. 以前の問題点
MySQLの容量逼迫
- トラッキングデータ件数：５億件(約1TB)
MySQLスケールアップでのサービス停⽌
- 共通基盤システムのため、様々なシステムに影響が出る

25. Cassandra利⽤で変化
複数サーバでの⼤量データ管理
システム無停⽌でのスケールアウト
⾼頻度アクセスでも⾼速レスポンス(数msec)

26. デメリット(困ったこと)
1. トランザクション制御(排他制御)できない
2. 削除まわりが難しい

27. 排他制御について
CassandraはCAP定理のAPを採⽤
⇒整合性は取れない
⇒トランザクション制御出来ない
トランザクションはあきらめるとしても、
排他制御くらいはしたい

28. ZooKeeperの利⽤
分散環境でのソフトウェア管理を助けるツール。
共有設定管理、分散ロック、分散キューなどの機能がある。
ZooKeeperロックで排他制御が可能

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

30. もう少し詳しく

31. ロック待ちとロック取得

32. ZooKeeperにはこんな使い⽅も
クライアント時刻ずれの問題

33. ZooKeeperにはこんな使い⽅も

34. ただし…
ZooKeeperはさむので遅くはなる(パフォーマンス検証必要)
ZooKeeperの構成上リーダーとフォロワーがあり、
リーダーのヒープ障害が単⼀障害点(SPOF)になりかねない
…という問題もある
よって監視が必須

35. 他の排他制御
もしくは、Cassandra内でロック⽤テーブルを定義しても
良いかもしれない

36. 他の排他制御
Cassandra内でロック⽤テーブルを使った場合
TTL以上経過でロック⾃動無効
同⼀データの連続ロックで、処理遅延の傾向あり

37. 排他制御についてまとめ
Cassandraはトランザクションや排他制御できない(はず)
ZooKeeperロック利⽤で排他制御は実装可能
Cassandra内でロックデータ管理する独⾃ロック機能も
実装可能
どちらも完璧とは⾔えないため、どのような実装が好ましいか
システム要件に合わせて検討すべき

38. デメリット(困ったこと)
1. トランザクション制御(排他制御)できない
2. 削除まわりが難しい

39. 削除の概要
Cassandraでは2段階でデータを削除する
1. tombstone(墓⽯)という論理削除フラグ登録
2. SSTable(ディスク)から物理削除

40. データ内容を確認してみました(Version 1.2.6)
xx-Data.dbに対してsstable2json実⾏してデータを確認
1. まずはデータ登録
set student_table['id100']['name']='Yamada';
{ky:“i10,clms:[“nm"“Ymd"17513290]}
"e"
d0""oun" [ ae, aaa,33158300]
2. データ論理削除
del student_table['id100'];
{ky:"d0""eaaa:
"e" i10,mtdt"
{dltoIf" {mreFreeet:33162600
"eeinno: "akdoDltA"17516970,
"oaDltoTm"17516},clms:[}
lcleeinie:33162}"oun" ]
⇒Deleteしたよという情報がinsertされるイメージ

41. 3. gc_grace_second(猶予期間)待つ
4. Compaction発⽣
（データ追加＆nodetool flushによるMinor Compaction）
⇒Compaction発⽣で新しく出⼒されたSSTableには該当rowKey
データは存在しない 。ログからも容量減少は確認できる。
IF [opcinxctr3]21-70 1:83,6 CmatoTs.aa(ie20
NO CmatoEeuo:1 030-8 71:284 opcinakjv ln 3)
Cmatdt [xxxxxxDt.b] 33t 13(3%o oiia)btsfr4ky
opce o /xx/xx-aad,. 8 o 4 ~7 f rgnl ye o
es
a 0016M/. Tm:1m.
t .135Bs ie 2s
⇒物理削除完了

42. データ削除に関する問題点
1. 削除データが復活する
2. 古いデータの物理削除に時間がかかる

43. データ削除の問題① 復活
多重障害発⽣によって削除したデータの復活があり得ます
前提： レプリケ数3、QUORUMのRead・Write
※この後Aを起動しても、Dataは復活した状態のまま

44. 削除復活が発⽣しないよう、
gc_graceまでに全ノードへ削除伝播が必要
↓
gc_graceまでにrepairの実施が必要
↓
よって、運⽤において定期的なrepairは重要です。

45. データ削除の問題② 消えない
デフォルトのCompaction Strategy(SizeTieredCompaction)では同
じ位のサイズのSSTableが4つ出⼒されたら
Compactionを発⽣する

46. ⼀旦⼤きなSSTableが出⼒されると、
それがCompactionの対象になるには時間がかかる

47. 例えば、 1⽇に1個⼩さいSSTableを吐くシステムで、
データは64⽇後に削除する仕様だった場合
物理削除可能になってから実際には182⽇かかる

48. 古いデータ消すには
ひたすら待つほどディスク余裕無いし…
Major Compactionは推奨されて無いようだし…
Leveled Compactionはファイル数が膨⼤になりそうだし…

49. 古いデータ消すには
Cassandra 1.2からの新機能にTombstone Compactionがある

50. Tombstone Compaction検証
Tombstone Compaction検証のためこんなことしてみました。
(Version 1.2.6)
【初めの数⽇】
データ作成⇒古いデータへのremove実施
⇒待ったり、flushしたり、⼩さなCompactionおこしたり
…単⼀SSTableのCompaction確認できず

51. 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.
なるほど、JMXから監視してみた。
どうやらTTL設定したデータだと
DroppableTombstoneRatioが0より⼤きくなりそう

52. Tombstone Compaction検証
TTLを設定したデータの単独Compaction発⽣は確認できた！
↓の設定でinsertぶん回したら、単独Compaction発⽣
gc_grace: 600sec
tombstone_threshold: 0.0001
tombstone_compaction_interval: 1
TTL: 600sec

53. Tombstone Compaction検証
でも、通常のremoveでは確認できず。
ソースコードもチェックしたが、どうやら↓で取得する値が0の
ため、単独Compationが起きない模様
ogaah.asnr.bcmato.btatopcintaey ie8あたり
r.pcecsadas.opcinAsrcCmatoSrtgのln12
dul dopbeai =stbegtsiaeDopbTmsoeai(ceoe;
obe rpalRto sal.eEtmtdrpalobtnRtogBfr)
⇒この機能ちゃんと利⽤するにはもう少し検証が必要そう。

54. データ削除の問題 まとめ
データ復活の可能性がある
定期的なrepairが⼤事
古いデータの物理削除には時間かかる
ディスク容量に余裕を持たせることが⼤事
最新機能も検証は必要だが使えそう
（本⾳は）削除が不要なシステムがベスト

55. まとめ
ぐるなびでのCassandra活⽤
様々なシステムへの適⽤
耐障害性と⼤量アクセスへの適応に着⽬
マルチデータセンタでバックアップ
Cassandraのメリット/デメリット
耐障害性と無停⽌スケーラビリティ、かつ⾼速なことは
魅⼒的
適切にポイントをつぶせば、厳しい要件でも⼗分使える
排他制御にはZooKeeper
削除には定期repairや新機能の利⽤

56. Any Questions ?

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