Cassandra導入事例と現場視点での苦労したポイント cassandra summit2014jpn
-
Upload
haketa -
Category
Technology
-
view
5.887 -
download
1
description
Transcript of Cassandra導入事例と現場視点での苦労したポイント cassandra summit2014jpn
![Page 1: Cassandra導入事例と現場視点での苦労したポイント cassandra summit2014jpn](https://reader033.fdocument.pub/reader033/viewer/2022042521/548db8a9b47959190d8b65eb/html5/thumbnails/1.jpg)
Cassandra導⼊事例と現場視点での苦労したポイント
Created by ⽻⽑⽥ 敦
(株)ぐるなび 企画第2部⾨ ビジネスソリューショングループ
Cassandra Summit 2014 JPN
2014/01/24
![Page 2: Cassandra導入事例と現場視点での苦労したポイント cassandra summit2014jpn](https://reader033.fdocument.pub/reader033/viewer/2022042521/548db8a9b47959190d8b65eb/html5/thumbnails/2.jpg)
アジェンダ⾃⼰紹介、会社紹介
Cassandra利⽤の経緯、事例紹介
Cassandraのメリット、デメリット
![Page 3: Cassandra導入事例と現場視点での苦労したポイント cassandra summit2014jpn](https://reader033.fdocument.pub/reader033/viewer/2022042521/548db8a9b47959190d8b65eb/html5/thumbnails/3.jpg)
⾃⼰紹介⽻⽑⽥ 敦 (はけた あつし)
SIerにて6年間クラウド関連サービスの研究開発を担当
ぐるなびには2013年4⽉に⼊社し、
Webページを⽀える基盤システムの開発に携わる
Cassandra触り始めて1年程度
現在、主にトラッキング管理システムの開発と運⽤を担当
![Page 4: Cassandra導入事例と現場視点での苦労したポイント cassandra summit2014jpn](https://reader033.fdocument.pub/reader033/viewer/2022042521/548db8a9b47959190d8b65eb/html5/thumbnails/4.jpg)
会社紹介
![Page 5: Cassandra導入事例と現場視点での苦労したポイント cassandra summit2014jpn](https://reader033.fdocument.pub/reader033/viewer/2022042521/548db8a9b47959190d8b65eb/html5/thumbnails/5.jpg)
レストラン検索サイト運営
総掲載店舗数:約50万店
詳細情報掲載店舗数:13万9,000店(以上 2013 年 12⽉末現在)
⽉間アクセス数:10億1,000万PV(2013 年 12⽉末現在)
⽉間ユニークユーザ数:4,200万⼈(2013 年 12⽉末現在)
ぐるなび会員数:1,133万⼈(2014 年 1⽉ 1⽇現在)
![Page 6: Cassandra導入事例と現場視点での苦労したポイント cassandra summit2014jpn](https://reader033.fdocument.pub/reader033/viewer/2022042521/548db8a9b47959190d8b65eb/html5/thumbnails/6.jpg)
Cassandra利⽤の経緯・事例紹介
![Page 7: Cassandra導入事例と現場視点での苦労したポイント cassandra summit2014jpn](https://reader033.fdocument.pub/reader033/viewer/2022042521/548db8a9b47959190d8b65eb/html5/thumbnails/7.jpg)
利⽤のきっかけ以前はレストラン情報保管に
RDBやXMLファイルを利⽤していた
⇒遅い
![Page 8: Cassandra導入事例と現場視点での苦労したポイント cassandra summit2014jpn](https://reader033.fdocument.pub/reader033/viewer/2022042521/548db8a9b47959190d8b65eb/html5/thumbnails/8.jpg)
レストラン⼀部情報保有に
サーバ2台でmemcachedを利⽤(2010年初め)
しかし…
データ量増加アクセス数増加データ永続性などの拡張性を懸念
これらの要件を満たすデータストアの検証を開始
![Page 9: Cassandra導入事例と現場視点での苦労したポイント cassandra summit2014jpn](https://reader033.fdocument.pub/reader033/viewer/2022042521/548db8a9b47959190d8b65eb/html5/thumbnails/9.jpg)
データストア検証
2010年からCassandra検証開始(Version 0.6)
当時はScalaris、Flare、Tokyo Tyrantと⽐較検証
要件満たす機能と、Facebook・Twitter(仮)の実績から
Cassandraを採⽤
![Page 10: Cassandra導入事例と現場視点での苦労したポイント cassandra summit2014jpn](https://reader033.fdocument.pub/reader033/viewer/2022042521/548db8a9b47959190d8b65eb/html5/thumbnails/10.jpg)
Cassandra利⽤スタート
2010年7⽉〜本番環境での利⽤開始
16ノード構成
Version 0.6.1
レストラン情報の他に携帯端末情報やQRコード情報などを管
理(最⼤4個のKeySpace管理)
2012年11⽉ Version 1.1.5にアップデート
![Page 11: Cassandra導入事例と現場視点での苦労したポイント cassandra summit2014jpn](https://reader033.fdocument.pub/reader033/viewer/2022042521/548db8a9b47959190d8b65eb/html5/thumbnails/11.jpg)
同⼀Cassnadra環境でKeyspace分割して管理
![Page 12: Cassandra導入事例と現場視点での苦労したポイント cassandra summit2014jpn](https://reader033.fdocument.pub/reader033/viewer/2022042521/548db8a9b47959190d8b65eb/html5/thumbnails/12.jpg)
Cassandraの本格利⽤①
![Page 13: Cassandra導入事例と現場視点での苦労したポイント cassandra summit2014jpn](https://reader033.fdocument.pub/reader033/viewer/2022042521/548db8a9b47959190d8b65eb/html5/thumbnails/13.jpg)
レストラン基本情報管理システム
2013年6⽉〜レストランの基本情報をCassandraに集約
3データセンタ、70ノード構成
基本データ⽤:42ノード
画像・ファイル⽤:18ノード
バックアップ⽤:10ノード
Version 1.1.10
![Page 14: Cassandra導入事例と現場視点での苦労したポイント cassandra summit2014jpn](https://reader033.fdocument.pub/reader033/viewer/2022042521/548db8a9b47959190d8b65eb/html5/thumbnails/14.jpg)
以前の構成(静的)
問題点
情報のリアルタイム性
データの柔軟性
耐障害性(シングルポイント)
![Page 15: Cassandra導入事例と現場視点での苦労したポイント cassandra summit2014jpn](https://reader033.fdocument.pub/reader033/viewer/2022042521/548db8a9b47959190d8b65eb/html5/thumbnails/15.jpg)
現在の構成(動的)
動的なページ変更や柔軟な部分更新
データの分散と耐障害性
⾼負荷アクセスに耐えるシステム
![Page 16: Cassandra導入事例と現場視点での苦労したポイント cassandra summit2014jpn](https://reader033.fdocument.pub/reader033/viewer/2022042521/548db8a9b47959190d8b65eb/html5/thumbnails/16.jpg)
マルチデータセンタ構成
遠隔地へのバックアップをしています
![Page 17: Cassandra導入事例と現場視点での苦労したポイント cassandra summit2014jpn](https://reader033.fdocument.pub/reader033/viewer/2022042521/548db8a9b47959190d8b65eb/html5/thumbnails/17.jpg)
Cassandraの本格利⽤②
![Page 18: Cassandra導入事例と現場視点での苦労したポイント cassandra summit2014jpn](https://reader033.fdocument.pub/reader033/viewer/2022042521/548db8a9b47959190d8b65eb/html5/thumbnails/18.jpg)
トラッキング情報管理システム
ユーザのアクセス履歴を管理するシステム
⼩さいデータの頻繁なWriteが特徴
2014年3⽉〜データストアをMySQLからCassandraに変更
2データセンタ、18ノード構成
本番⽤:12ノード
バックアップ⽤:6ノード
Version 1.2.12
![Page 19: Cassandra導入事例と現場視点での苦労したポイント cassandra summit2014jpn](https://reader033.fdocument.pub/reader033/viewer/2022042521/548db8a9b47959190d8b65eb/html5/thumbnails/19.jpg)
データストア検証
バックエンド⽐較 (2012年12⽉)
Cassandra、MySQL Cluster、VoltDB、Riak…etcを⽐較
永続性、耐障害性、スケーラビリティ、性能…etcを検証
利⽤実績やWriteの速さからCassandraを採⽤
![Page 20: Cassandra導入事例と現場視点での苦労したポイント cassandra summit2014jpn](https://reader033.fdocument.pub/reader033/viewer/2022042521/548db8a9b47959190d8b65eb/html5/thumbnails/20.jpg)
Cassandra採⽤によって
⼤容量データの管理
- 5億件、約1TBのデータを保存
⾼負荷アクセスへの対応
- 秒間1500アクセスに対応
無停⽌スケールアウト
![Page 21: Cassandra導入事例と現場視点での苦労したポイント cassandra summit2014jpn](https://reader033.fdocument.pub/reader033/viewer/2022042521/548db8a9b47959190d8b65eb/html5/thumbnails/21.jpg)
Cassandra 利⽤事例まとめ様々なシステムのデータストアとして利⽤
主な選定理由
耐障害性(SPOFなし)
柔軟なテーブル定義
無停⽌スケールアウト
⼤量データ/⼤量アクセスへの適⽤
マルチデータセンタでのバックアップ
![Page 22: Cassandra導入事例と現場視点での苦労したポイント cassandra summit2014jpn](https://reader033.fdocument.pub/reader033/viewer/2022042521/548db8a9b47959190d8b65eb/html5/thumbnails/22.jpg)
Cassandra使ってみてメリット/デメリット
![Page 23: Cassandra導入事例と現場視点での苦労したポイント cassandra summit2014jpn](https://reader033.fdocument.pub/reader033/viewer/2022042521/548db8a9b47959190d8b65eb/html5/thumbnails/23.jpg)
メリットトラッキング情報管理システムを例に…
![Page 24: Cassandra導入事例と現場視点での苦労したポイント cassandra summit2014jpn](https://reader033.fdocument.pub/reader033/viewer/2022042521/548db8a9b47959190d8b65eb/html5/thumbnails/24.jpg)
以前の問題点
MySQLの容量逼迫
- トラッキングデータ件数:5億件(約1TB)
MySQLスケールアップでのサービス停⽌
- 共通基盤システムのため、様々なシステムに影響が出る
![Page 25: Cassandra導入事例と現場視点での苦労したポイント cassandra summit2014jpn](https://reader033.fdocument.pub/reader033/viewer/2022042521/548db8a9b47959190d8b65eb/html5/thumbnails/25.jpg)
Cassandra利⽤で変化
複数サーバでの⼤量データ管理
システム無停⽌でのスケールアウト
⾼頻度アクセスでも⾼速レスポンス(数msec)
![Page 26: Cassandra導入事例と現場視点での苦労したポイント cassandra summit2014jpn](https://reader033.fdocument.pub/reader033/viewer/2022042521/548db8a9b47959190d8b65eb/html5/thumbnails/26.jpg)
デメリット(困ったこと)1. トランザクション制御(排他制御)できない
2. 削除まわりが難しい
![Page 27: Cassandra導入事例と現場視点での苦労したポイント cassandra summit2014jpn](https://reader033.fdocument.pub/reader033/viewer/2022042521/548db8a9b47959190d8b65eb/html5/thumbnails/27.jpg)
トランザクションはあきらめるとしても、
排他制御くらいはしたい
排他制御について
CassandraはCAP定理のAPを採⽤
⇒整合性は取れない
⇒トランザクション制御出来ない
![Page 28: Cassandra導入事例と現場視点での苦労したポイント cassandra summit2014jpn](https://reader033.fdocument.pub/reader033/viewer/2022042521/548db8a9b47959190d8b65eb/html5/thumbnails/28.jpg)
ZooKeeperの利⽤分散環境でのソフトウェア管理を助けるツール。
共有設定管理、分散ロック、分散キューなどの機能がある。
ZooKeeperロックで排他制御が可能
![Page 29: Cassandra導入事例と現場視点での苦労したポイント cassandra summit2014jpn](https://reader033.fdocument.pub/reader033/viewer/2022042521/548db8a9b47959190d8b65eb/html5/thumbnails/29.jpg)
排他制御の仕組み
ZooKeeperロックでの排他制御の仕組み
![Page 30: Cassandra導入事例と現場視点での苦労したポイント cassandra summit2014jpn](https://reader033.fdocument.pub/reader033/viewer/2022042521/548db8a9b47959190d8b65eb/html5/thumbnails/30.jpg)
もう少し詳しく
![Page 31: Cassandra導入事例と現場視点での苦労したポイント cassandra summit2014jpn](https://reader033.fdocument.pub/reader033/viewer/2022042521/548db8a9b47959190d8b65eb/html5/thumbnails/31.jpg)
ロック待ちとロック取得
![Page 32: Cassandra導入事例と現場視点での苦労したポイント cassandra summit2014jpn](https://reader033.fdocument.pub/reader033/viewer/2022042521/548db8a9b47959190d8b65eb/html5/thumbnails/32.jpg)
ZooKeeperにはこんな使い⽅も
クライアント時刻ずれの問題
![Page 33: Cassandra導入事例と現場視点での苦労したポイント cassandra summit2014jpn](https://reader033.fdocument.pub/reader033/viewer/2022042521/548db8a9b47959190d8b65eb/html5/thumbnails/33.jpg)
ZooKeeperにはこんな使い⽅も
![Page 34: Cassandra導入事例と現場視点での苦労したポイント cassandra summit2014jpn](https://reader033.fdocument.pub/reader033/viewer/2022042521/548db8a9b47959190d8b65eb/html5/thumbnails/34.jpg)
ただし…ZooKeeperはさむので遅くはなる(パフォーマンス検証必要)
ZooKeeperの構成上リーダーとフォロワーがあり、
リーダーのヒープ障害が単⼀障害点(SPOF)になりかねない
…という問題もある
よって監視が必須
![Page 35: Cassandra導入事例と現場視点での苦労したポイント cassandra summit2014jpn](https://reader033.fdocument.pub/reader033/viewer/2022042521/548db8a9b47959190d8b65eb/html5/thumbnails/35.jpg)
他の排他制御
もしくは、Cassandra内でロック⽤テーブルを定義しても
良いかもしれない
![Page 36: Cassandra導入事例と現場視点での苦労したポイント cassandra summit2014jpn](https://reader033.fdocument.pub/reader033/viewer/2022042521/548db8a9b47959190d8b65eb/html5/thumbnails/36.jpg)
他の排他制御
Cassandra内でロック⽤テーブルを使った場合
TTL以上経過でロック⾃動無効
同⼀データの連続ロックで、処理遅延の傾向あり
![Page 37: Cassandra導入事例と現場視点での苦労したポイント cassandra summit2014jpn](https://reader033.fdocument.pub/reader033/viewer/2022042521/548db8a9b47959190d8b65eb/html5/thumbnails/37.jpg)
排他制御についてまとめ
Cassandraはトランザクションや排他制御できない(はず)
ZooKeeperロック利⽤で排他制御は実装可能
Cassandra内でロックデータ管理する独⾃ロック機能も
実装可能
どちらも完璧とは⾔えないため、どのような実装が好ましいか
システム要件に合わせて検討すべき
![Page 38: Cassandra導入事例と現場視点での苦労したポイント cassandra summit2014jpn](https://reader033.fdocument.pub/reader033/viewer/2022042521/548db8a9b47959190d8b65eb/html5/thumbnails/38.jpg)
デメリット(困ったこと)1. トランザクション制御(排他制御)できない
2. 削除まわりが難しい
![Page 39: Cassandra導入事例と現場視点での苦労したポイント cassandra summit2014jpn](https://reader033.fdocument.pub/reader033/viewer/2022042521/548db8a9b47959190d8b65eb/html5/thumbnails/39.jpg)
削除の概要
Cassandraでは2段階でデータを削除する
1. tombstone(墓⽯)という論理削除フラグ登録
2. SSTable(ディスク)から物理削除
![Page 40: Cassandra導入事例と現場視点での苦労したポイント cassandra summit2014jpn](https://reader033.fdocument.pub/reader033/viewer/2022042521/548db8a9b47959190d8b65eb/html5/thumbnails/40.jpg)
データ内容を確認してみました(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": []}
![Page 41: Cassandra導入事例と現場視点での苦労したポイント cassandra summit2014jpn](https://reader033.fdocument.pub/reader033/viewer/2022042521/548db8a9b47959190d8b65eb/html5/thumbnails/41.jpg)
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.
![Page 42: Cassandra導入事例と現場視点での苦労したポイント cassandra summit2014jpn](https://reader033.fdocument.pub/reader033/viewer/2022042521/548db8a9b47959190d8b65eb/html5/thumbnails/42.jpg)
データ削除に関する問題点
1. 削除データが復活する
2. 古いデータの物理削除に時間がかかる
![Page 43: Cassandra導入事例と現場視点での苦労したポイント cassandra summit2014jpn](https://reader033.fdocument.pub/reader033/viewer/2022042521/548db8a9b47959190d8b65eb/html5/thumbnails/43.jpg)
データ削除の問題① 復活
多重障害発⽣によって削除したデータの復活があり得ます前提: レプリケ数3、QUORUMのRead・Write
※この後Aを起動しても、Dataは復活した状態のまま
![Page 44: Cassandra導入事例と現場視点での苦労したポイント cassandra summit2014jpn](https://reader033.fdocument.pub/reader033/viewer/2022042521/548db8a9b47959190d8b65eb/html5/thumbnails/44.jpg)
削除復活が発⽣しないよう、
gc_graceまでに全ノードへ削除伝播が必要
↓
gc_graceまでにrepairの実施が必要
↓
よって、運⽤において定期的なrepairは重要です。
![Page 45: Cassandra導入事例と現場視点での苦労したポイント cassandra summit2014jpn](https://reader033.fdocument.pub/reader033/viewer/2022042521/548db8a9b47959190d8b65eb/html5/thumbnails/45.jpg)
データ削除の問題② 消えない
デフォルトのCompaction Strategy(SizeTieredCompaction)では同
じ位のサイズのSSTableが4つ出⼒されたら
Compactionを発⽣する
![Page 46: Cassandra導入事例と現場視点での苦労したポイント cassandra summit2014jpn](https://reader033.fdocument.pub/reader033/viewer/2022042521/548db8a9b47959190d8b65eb/html5/thumbnails/46.jpg)
⼀旦⼤きなSSTableが出⼒されると、
それがCompactionの対象になるには時間がかかる
![Page 47: Cassandra導入事例と現場視点での苦労したポイント cassandra summit2014jpn](https://reader033.fdocument.pub/reader033/viewer/2022042521/548db8a9b47959190d8b65eb/html5/thumbnails/47.jpg)
例えば、 1⽇に1個⼩さいSSTableを吐くシステムで、
データは64⽇後に削除する仕様だった場合
物理削除可能になってから実際には182⽇かかる
![Page 48: Cassandra導入事例と現場視点での苦労したポイント cassandra summit2014jpn](https://reader033.fdocument.pub/reader033/viewer/2022042521/548db8a9b47959190d8b65eb/html5/thumbnails/48.jpg)
古いデータ消すには
ひたすら待つほどディスク余裕無いし…
Major Compactionは推奨されて無いようだし…
Leveled Compactionはファイル数が膨⼤になりそうだし…
![Page 49: Cassandra導入事例と現場視点での苦労したポイント cassandra summit2014jpn](https://reader033.fdocument.pub/reader033/viewer/2022042521/548db8a9b47959190d8b65eb/html5/thumbnails/49.jpg)
古いデータ消すには
Cassandra 1.2からの新機能にTombstone Compactionがある
![Page 50: Cassandra導入事例と現場視点での苦労したポイント cassandra summit2014jpn](https://reader033.fdocument.pub/reader033/viewer/2022042521/548db8a9b47959190d8b65eb/html5/thumbnails/50.jpg)
Tombstone Compaction検証
Tombstone Compaction検証のためこんなことしてみました。
(Version 1.2.6)
【初めの数⽇】
データ作成⇒古いデータへのremove実施
⇒待ったり、flushしたり、⼩さなCompactionおこしたり
…単⼀SSTableのCompaction確認できず
![Page 51: Cassandra導入事例と現場視点での苦労したポイント cassandra summit2014jpn](https://reader033.fdocument.pub/reader033/viewer/2022042521/548db8a9b47959190d8b65eb/html5/thumbnails/51.jpg)
なるほど、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.
![Page 52: Cassandra導入事例と現場視点での苦労したポイント cassandra summit2014jpn](https://reader033.fdocument.pub/reader033/viewer/2022042521/548db8a9b47959190d8b65eb/html5/thumbnails/52.jpg)
Tombstone Compaction検証
TTLを設定したデータの単独Compaction発⽣は確認できた!
↓の設定でinsertぶん回したら、単独Compaction発⽣
gc_grace: 600sec
tombstone_threshold: 0.0001
tombstone_compaction_interval: 1
TTL: 600sec
![Page 53: Cassandra導入事例と現場視点での苦労したポイント cassandra summit2014jpn](https://reader033.fdocument.pub/reader033/viewer/2022042521/548db8a9b47959190d8b65eb/html5/thumbnails/53.jpg)
⇒この機能ちゃんと利⽤するにはもう少し検証が必要そう。
Tombstone Compaction検証
でも、通常のremoveでは確認できず。
ソースコードもチェックしたが、どうやら↓で取得する値が0の
ため、単独Compationが起きない模様
org.apache.cassandra.sb.compaction.AbstractCompactionStrategyのline182あたり
double droppableRatio = sstable.getEstimatedDroppablTombstoneRatio(gcBefore);
![Page 54: Cassandra導入事例と現場視点での苦労したポイント cassandra summit2014jpn](https://reader033.fdocument.pub/reader033/viewer/2022042521/548db8a9b47959190d8b65eb/html5/thumbnails/54.jpg)
データ削除の問題 まとめデータ復活の可能性がある
定期的なrepairが⼤事
古いデータの物理削除には時間かかる
ディスク容量に余裕を持たせることが⼤事
最新機能も検証は必要だが使えそう
(本⾳は)削除が不要なシステムがベスト
![Page 55: Cassandra導入事例と現場視点での苦労したポイント cassandra summit2014jpn](https://reader033.fdocument.pub/reader033/viewer/2022042521/548db8a9b47959190d8b65eb/html5/thumbnails/55.jpg)
まとめぐるなびでのCassandra活⽤
様々なシステムへの適⽤
耐障害性と⼤量アクセスへの適応に着⽬
マルチデータセンタでバックアップ
Cassandraのメリット/デメリット
耐障害性と無停⽌スケーラビリティ、かつ⾼速なことは
魅⼒的
適切にポイントをつぶせば、厳しい要件でも⼗分使える
排他制御にはZooKeeper
削除には定期repairや新機能の利⽤
![Page 56: Cassandra導入事例と現場視点での苦労したポイント cassandra summit2014jpn](https://reader033.fdocument.pub/reader033/viewer/2022042521/548db8a9b47959190d8b65eb/html5/thumbnails/56.jpg)
Any Questions ?
![Page 57: Cassandra導入事例と現場視点での苦労したポイント cassandra summit2014jpn](https://reader033.fdocument.pub/reader033/viewer/2022042521/548db8a9b47959190d8b65eb/html5/thumbnails/57.jpg)
ご清聴ありがとうございました