Ｃａｓｓａｎｄｒａのバックアップと運用を考える。

　 INTHEFOREST とみたかずたか

自己紹介

冨田　和孝　 (@railute)

肩書き：　株式会社ＩＮＴＨＥＦＯＲＥＳＴ 代表取締役社長Cassandra 商用サポート、 Cassandra コンサルティング他

Cassandra 勉強会主宰２か月に一度程度開催。現在、第 24 回まで開催。

職種：本職はＤＢ・インフラ系エンジニア以前、某レストランサーチのＤＢＡ高負荷・大容量・大規模の OracleRAC と PostgreSQL とMySQL に苦しめられ続けた経験あり。

NLP およびテキストマイニング始め〼た。（実はもともと言語学（日本語）専攻。）

Cassandraサポートサービス

サービス プラチナ ゴールド スタンダード

サポート※１ 無制限 月間 80 時間迄 月間 40 時間迄

サポート時間 24 x 365 平日 9 時 -5 時 平日 9 時 -5 時

Apache Cassandra への不具合報告

○ ○ ○

重大インシデント対応の緊急パッチ提供

○ × ×

障害切分け ○ × ×

環境構築支援 ○ ○ ×

運用支援 ○ ○ ×

※ １メール中心のサポートとなります。対応時間には問い合わせ対応、構築・運用支援に関する情報提供などが含まれます。

Cassandra トレーニング

対象者 Cassandra をこれから使用する方

期間 １日間（ 9:00-17:30 ）

バージョン 1.1,1.0(0.8 等も可 )

内容

•Cassandra の歴史•Cassandra のアーキテクチャ•Cassandra のインストールと起動停止方法•Cassandra の利用 ( 設定ファイル、ログの種類 )•Cassandra CLI

Cassandra 概要

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

Cassandra の前提各ノードは独立している

Cassandra は他のノードのステータスを「管理」はしない。

※Seeds は初期接続対象、ないしは Gossip の優先選択先なだけ。

初期接続時：スキーマ情報取得などGossip　　：毎回必ず Seedをゴシップ対象に加える

あのノード落ちてるらしい

よ

Cassandra の前提

Memtable

BloomFilter

SSTable

SSTable

SSTable

更新

Memtable

BloomFilter

SSTable

SSTable

SSTable

データの更新はMemtable へ

不整合発生

Memtable

BloomFilter

SSTable

SSTable

SSTable

SSTable

SSTable Ｍｅｒｇｅ

再構築

不要 SSTable削除

Memtable

BloomFilter

SSTable

SSTable

JVM の GC

通常時 不整合時

Compaction 時 SSTable削除時

※SSTable は常に作成時以外の更新処理は行われない。

SSTable は Write Once

監視をするということ

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

Cassandra は原則すべて JMX

JVM の握っているハードウェアリソースも取得できる

メモリCPUIO

etc……

監視をするということ

ステータス管理• Cassandra におけるダウンとは？

各ノードはお互いの停止時間の存在を前提とする。 「サーバーが戻ってこない」以外の障害はサービスに対する影響が少ない

リソース管理• Cassandra に必要なリソースとは？

• CPU• IO• ネットワーク• メモリ

Cassandra における監視の定義

監視をするということ

ステータス管理（障害検知）

ハード障害　⇒　 disk 障害、メモリ障害、システムボード障害等⇒ノード障害

※むしろ気さくにノード障害に

ノードダウンの要因

Out of Memory 　⇒　ヒープ不足、コンパクション遅延、フラッシュの遅延等⇒原因の特定とチューニングが必要

ネットワーク遅延⇒パケットロス、帯域不足等⇒データの不整合が発生する可能性があるので repair を検討

監視をするということ

リソース管理

何を抑えておくべきか

ノードが落ちるメモリ使用量

データが闇に消えかねないネットワーク系の不具合

Write heavy は CPU バンド

Read heavy はメモリ／ IO バンド

監視をするということ

メモリ使用量

Cassandra はメモリ喰い

GC が適切に行われているかCompaction が適切に行われているかFlush が適切に行われているか

上記すべての要因が正常に行われていないとメモリとディスクを圧迫する

監視をするということ

ネットワーク系不具合

Cassandra はノード間のメッセージが 10秒帰ってこないとそのセッションを叩き落とす

⇒書込みはリードリペアに後を託す

メッセージの欠損が発生している場合は repair を検討但し repair は重い処理

監視をするということ

Write Heavy は CPU バンドWrite の処理は bloomfilter の演算・ Flush ・Compaction などが入るため CPU を使いまくります。

書込み命

令

Comm

itlog

Mem

Table

FlushWriter

bloomfilter

SSTableCom

pactionM

anager

監視をするということ

Read heavy は IO ・メモリバンド

読込み命

令 MemTable

bloomfilter

SSTable

Cache

監視をするということ

Jconsole

• JMX の情報取得の基本• JDK に付属している• 目視監視であれば使いやすい

監視をするということ

MX4J

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

監視をするということ

OPSCenter

DataStax 社謹製Cassandra のみを扱う限りはとても使いやすい

監視をするということ

Zabbix

2.0 系から JMX をネイティブサポートCassandra 以外も一括管理ができるため運用方法としてはよいかも。

※Nagios+RRDtool もまだまだ使えると思います。（好きなように graph を作れるという意味では RRDTool は捨てがたい。）

監視をするということ

監視まとめ

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

バックアップをするということ

バックアップの目的

データリカバリーオペレーションリカバリーサーバー移行監査

バックアップをするということ

データの整合性に関する考え方

データ{KEY:VALUE}

ハッシュ化：場所確定

Timestamp ：世代確定

データはこのノードに保存される

逆説的にデータはこの各ノードのデータがどれか一つあれば取得できる。

バックアップをするということ

Cassandra のバックアップ

Memtable

BloomFilter

SSTable

SSTable

SSTable

ここをバックアップ

Cassandra のバックアップは SSTable のコピー※SSTable は Write Once なので書込み制限も行わない

バックアップをするということ

データリカバリその１クラスター内特定のノードの HDD欠損（バックアップなし）

Memtable

BloomFilter

SSTable

SSTable

SSTable

Memtable

BloomFilter

SSTable

SSTable

SSTable

Repair コマンド

SSTable

SSTable

他のノードよりデータを取得することによりデータリカバリSSTableそのものをコピーするためネットワーク負荷増

バックアップをするということ

データリカバリその２クラスター内特定のノードの HDD欠損（バックアップあり）

Memtable

BloomFilter

SSTable

SSTable

SSTable

Memtable

BloomFilter

SSTable

SSTable

SSTable

SSTable

SSTable

バックアップ SSTable より復旧古いデータを ReadRipair もしくは repair コマンドにより復旧

SSTable

Memtable

BloomFilterSSTabl

e

バックアップをするということ

データリカバリその３キーがストアされているレプリカ分のクラスター内の HDD全滅

バックアップ SSTable が存在しない場合は復旧不可バックアップ SSTable に Flushされていないデータはロスト

バックアップをするということ

オペレーションリカバリ

Memtable

BloomFilter

SSTable

SSTable

SSTable

指定のキーが入っているノードを特

定

期待のバージョンが入っている

SSTable のバックアップを取得

SSTable

1. 指定のキーで指定のバージョンが格納されているバックアップ SSTable を取得

2. 他のクラスターにリカバリ3. 希望データを取得

リストア

バックアップをするということ

サーバー移行

Memtable

BloomFilter

SSTable

SSTable

SSTable

サーバー移行対象ノード 最新 SSTable のバッ

クアップを取得

SSTable

1. 最新バックアップ SSTable を取得2. 他の HW にリカバリ3. IP を差し替え4. repair

リストア

バックアップをするということ

監査

Memtable

BloomFilter

SSTable

SSTable

SSTable

最新 SSTable のバックアップを取得

SSTable

1. バックアップ SSTable を取得2. S3 あたりに流し込みましょう

S3

まとめ

バックアップ

データのある場所を抑える

ノード間でバックアップタイミングをずらしデータの確保を行う

必要なところだけ取得することも可能