1. Ｃａｓｓａｎｄｒａのバックアップと運
用を考える。
INTHEFOREST とみたかずたか

2. 自己紹介
冨田 和孝 (@railute)
肩書き： 株式会社ＩＮＴＨＥＦＯＲＥＳＴ 代表取締役社長
Cassandra商用サポート、Cassandraコンサルティング他
Cassandra勉強会主宰
２か月に一度程度開催。現在、第24回まで開催。
職種：本職はＤＢ・インフラ系エンジニア
以前、某レストランサーチのＤＢＡ
高負荷・大容量・大規模のOracleRACとPostgreSQLと
MySQLに苦しめられ続けた経験あり。
NLPおよびテキストマイニング始め〼た。
（実はもともと言語学（日本語）専攻。）

3. Cassandraサポートサービス
サービス プラチナ ゴールド スタンダード
サポート※１ 無制限 月間80時間迄 月間40時間迄
サポート時間 24 x 365 平日9時-5時 平日9時-5時
Apache Cassandraへの不
○ ○ ○
具合報告
重大インシデント対応
○ × ×
の緊急パッチ提供
障害切分け ○ × ×
環境構築支援 ○ ○ ×
運用支援 ○ ○ ×
※１メール中心のサポートとなります。対応時間には問い合わせ対応、構築・運用支援に関する情報
提供などが含まれます。

4. Cassandra トレーニング
Cassandra 概要
対象者 Cassandraをこれから使用する方
期間 １日間（9:00-17:30）
バージョン 1.1,1.0(0.8等も可)
•Cassandraの歴史
•Cassandraのアーキテクチャ
内容 •Cassandraのインストールと起動停止方法
•Cassandraの利用(設定ファイル、ログの種類)
•Cassandra CLI

5. Agenda
 Cassandraの前提
 監視をするということ
 バックアップをするということ

6. Cassandraの前提
各ノードは独立している
Cassandraは他のノードのステータスを「管
理」はしない。
※Seedsは初期接続対象、ないしはGossipの優先選択先なだけ。
初期接続時：スキーマ情報取得など
Gossip ：毎回必ずSeedをゴシップ対象に加える
あのノード落
ちてるらしい
よ

7. Cassandraの前提
SSTableは Write Once
通常時 不整合時
データの更新は
Memtableへ
Memtable Memtable
※SSTableは常に作
BloomFilter BloomFilter 不整合発生
成時以外の更新処 更新
理は行われない。
SSTable
SSTable
SSTable
SSTable
SSTable
SSTable
再構築
Memtable JVMのGC Memtable
BloomFilter BloomFilter
不要SSTable削除
SSTable
SSTable
SSTable
SSTable
SSTable
SSTable
SSTableＭｅｒｇ
ｅ
Compaction時 SSTable削除時

8. 監視をするということ
Cassandraは原則すべてJMX
Java Management Extensions（JMX）は、アプリケーションソフトウェア/シス
テムオブジェクト/デバイス（プリンターなど）/サービス指向ネットワーク
などの監視・管理のためのツールを提供するJavaプラットフォーム技術の一
種。これらのリソースは MBean（Managed Bean）と呼ばれるオブジェクト
で表現される。このAPIの面白い特徴として、クラス群を動的にロードして
インスタンス化できる。（Wikipediaより）
JVMの握っているハードウェアリソースも取得できる
メモリ
CPU
IO
etc……

9. 監視をするということ
Cassandraにおける監視の定義
 ステータス管理
• Cassandraにおけるダウンとは？
 各ノードはお互いの停止時間の存在を前提とする。
 「サーバーが戻ってこない」以外の障害はサービスに対する影
響が少ない
 リソース管理
• Cassandraに必要なリソースとは？
• CPU
• IO
• ネットワーク
• メモリ

10. 監視をするということ
ステータス管理（障害検
知）
ノードダウンの要因
ハード障害 ⇒ disk障害、メモリ障害、システムボード障害等
⇒ノード障害
※むしろ気さくにノード障害に
Out of Memory ⇒ ヒープ不足、コンパクション遅延、フラッシュの遅延
⇒原因の特定とチューニングが必要
ネットワーク遅延⇒パケットロス、帯域不足等
⇒データの不整合が発生する可能性があるのでrepairを検討

11. 監視をするということ
リソース管理
何を抑えておくべきか
 ノードが落ちるメモリ使用量
 データが闇に消えかねないネットワーク系の不具合
 Write heavy はCPUバンド
 Read heavy はメモリ／IOバンド

12. 監視をするということ
メモリ使用量
Cassandraはメモリ喰い
GCが適切に行われているか
Compactionが適切に行われているか
Flushが適切に行われているか
上記すべての要因が正常に行われていない
とメモリとディスクを圧迫する

13. 監視をするということ
ネットワーク系不具合
Cassandraはノード間のメッセージが10秒
帰ってこないとそのセッションを叩き落
とす
⇒書込みはリードリペアに後を託す
メッセージの欠損が発生している場合はrepairを検討
但しrepairは重い処理

14. 監視をするということ
Write Heavy はCPUバンド
Writeの処理はbloomfilterの演算・Flush・
Compactionなどが入るためCPUを使いまくります。
書
FlushWriter
Commitlog
MemTable
込
み
命
令
Compaction
bloomfilter
Manager
SSTable

15. 監視をするということ
Read heavy はIO・メモリバンド
読
込 MemTable
み Cache
命
令
bloomfilter
SSTable

16. 監視をするということ
Jconsole
• JMXの情報取得の基本
• JDKに付属している
• 目視監視であれば使いやすい

17. 監視をするということ
MX4J
Cassandra起動時にJarを読み
込ませることで使用可能。
ブラウザでJMXの情報取得や
操作が可能に。

18. 監視をするということ
OPSCenter
DataStax社謹製
Cassandraのみを扱う限りはとて
も使いやすい

19. 監視をするということ
Zabbix
2.0系からJMXをネイティブサポート
Cassandra以外も一括管理ができるた
め運用方法としてはよいかも。
※Nagios+RRDtoolもまだまだ使えると
思います。（好きなようにgraphを作
れるという意味ではRRDToolは捨てが
たい。）

20. 監視をするということ
監視まとめ
障害のレイヤーがRDBMSとは異なる
気軽にノード障害へ
OOMが出た場合は原因に注意
メッセージのドロップが出ていないかを常に監視

21. バックアップをするということ
バックアップの目的
 データリカバリー
 オペレーションリカバリー
 サーバー移行
 監査

22. バックアップをするということ
データの整合性に関する考え方
データはこのノードに保存される
ハッシュ化：場所確
定
データ
{KEY:VALUE}
Timestamp：世代確
定
逆説的にデータはこの各ノー
ドのデータがどれか一つあれ
ば取得できる。

23. バックアップをするということ
Cassandraのバックアップ
CassandraのバックアップはSSTableのコピー
※SSTableはWrite Onceなので書込み制限も行
わない
Memtable
BloomFilter
SSTable
SSTable
SSTable
ここをバックアップ

24. バックアップをするということ
データリカバリその１
クラスター内特定のノードのHDD欠損（バックアップなし）
Memtable
SSTable
BloomFilter
SSTable
SSTable
SSTable
Repairコマン
ド
Memtable 他のノードよりデータを取得
BloomFilter
することによりデータリカバ
SSTable
リ
SSTable
SSTable
SSTable
SSTableそのものをコピーする
ためネットワーク負荷増

25. バックアップをするということ
データリカバリその２
クラスター内特定のノードのHDD欠損（バックアップあり）
Memtable
SSTable
SSTable
BloomFilter
SSTable
SSTable
SSTable
Memtable
BloomFilter バックアップSSTableより復旧
古いデータをReadRipairもし
SSTable
くはrepairコマンドにより復
Memtable
旧
BloomFilter
SSTable
SSTable
SSTable
SSTable

26. バックアップをするということ
データリカバリその３
キーがストアされてい バックアップSSTableが存在しな
るレプリカ分のクラス い場合は復旧不可
ター内のHDD全滅
バックアップSSTableにFlushされ
ていないデータはロスト

27. バックアップをするということ
オペレーションリカバリ
1. 指定のキーで指定のバージョンが格納
されているバックアップSSTableを取得
2. 他のクラスターにリカバリ
3. 希望データを取得
指定のキーが入っ 期待のバージョン
ているノードを特 が入っている
定 SSTableのバック リストア
Memtable
BloomFilter アップを取得
SSTable
SSTable
SSTable
SSTable

28. バックアップをするということ
サーバー移行
1. 最新バックアップSSTableを取得
2. 他のHWにリカバリ
3. IPを差し替え
4. repair
サーバー移行
最新SSTableのバッ
対象ノード
Memtable
クアップを取得 リストア
BloomFilter
SSTable
SSTable
SSTable
SSTable

29. バックアップをするということ
監査
1. バックアップSSTableを取得
2. S3あたりに流し込みましょう
最新SSTableのバッ
Memtable
クアップを取得
BloomFilter
S3
SSTable
SSTable
SSTable
SSTable

30. まとめ
バックアップ
 データのある場所を抑える
 ノード間でバックアップタイミングをずらしデータの確保を行う
 必要なところだけ取得することも可能