Guide to Cassandra for Production Deployments

本番で使うためのCassandraガイド

Guide to “Cassandra” for Production Deployments

島田慶樹 (株)ケイビーエムジェイ2011/05/17　ソーシャルメディア、ソーシャルアプリが育てたNoSQL技術

～NoSQLセミナー

提　供

世界中の人々に愛されるインターネットサービスを創り続ける

株式会社ケイビーエムジェイ

アジェンダi. 自己紹介ii. NoSQLについてiii. Cassandraとはiv. 強み、弱み、落とし穴v. 開発のトレンドとマイルストーンvi. 使い方（設計、デプロイメント、運用）vii. まとめ


自己紹介● 氏名：島田慶樹 (SHIMADA Keiki)● Twitter: _shimada● 主にRuby on Railsを使ったWebシステムの開発に

従事● ここ１年程、大規模ASPシステムの保守、機能追加な

どの仕事をしている● 性能やスケーラビリティなど、非常に勉強になる現場● Cassandraとの出会い

はじめにアンケートさせて下さい

仕事で使っている言語は？● Java● C / C++● C#● PHP● Perl● JavaScript● Ruby● Pyhton● その他

仕事で使っているデータベースは？● MySQL● PostgreSQL● Oracle● DB2● SQL Server● MS Access● Sybase● その他

仕事でKVS / NoSQL使ってますか？● Memcache系● TokyoCabinet/Tyrant● MongoDB● Cassandra● HBase● okuyama● クラウド系(GAE, AWS, Azure, ...)● その他


NoSQLの位置づけ● A. 処理の入り口で使う　＝バッファ● B. 処理の出口で使う　　＝キャッシュ● C. 処理中に使う　　　　＝ワークエリア

システムの中核となるデータ（エンティティ）は、RDBMSに格納する※あくまで個人的な見解です

Core system

Work area

Buffer

Cache

Entity

入力

処理

出力

一般論としての情報システム

Core system

Work area

Buffer

Cache

Entity

入力

処理

出力

A. 処理の入り口で使う＝バッファ受け取った膨大なデータをとりあえずストアしておいて、あとで余裕のある時に処理する

Core system

Work area

Buffer

Cache

Entity

入力

処理

出力

B. 処理の出口で使う＝キャッシュ

同じパラメータで何度もリクエストが来る場合に、結果が変わらない間は最初に処理した結果をためておいて直接返す

Core system

Work area

Buffer

Cache

Entity

入力

処理

出力

C. 処理中に使う＝ワークエリア

大規模なデータ処理のための中間データを一時的にストアする

Core system

Work area

Buffer

Cache

Entity

入力

処理

出力

エンティティはRDBMSに

RDBMS!!


Cassandraのデータモデル

Cassandraのデータモデル● カラム指向データストア

● 行ごとに違うカラム（列）を自由に作れる柔軟なデータ構造

● ただし、サブクエリやテーブルJOINなどの機能がない

ネストしたHashTableみたいなものAddressBook2 = { "仕事": { "yamada taro": { "name": "山田太郎", "address": "東京都品川区＊＊＊＊", "phone": "03-xxxx-xxxx" } }, "プライベート": { "sato hanako": { "name": "佐藤花子", "address": "東京都墨田区＊＊＊＊", "mobile": "090-xxx-xxxx", "email": "[email protected]" } }};

Cassandraの分散アーキテクチャ

詳しいことは記事を参照「Cassandra実践入門」が

gihyo.jpにて公開中http://goo.gl/xOiKe


強み、弱み、落とし穴（１）● 勝手にシャーディング

● スケールアウトが容易● ただし、キーの設計を間違うと一ヶ所にデータが集

中● 勝手にレプリケーション

● ただし、反映にかかる時間はベストエフォート● スレーブが反映前のデータを返してしまうことも

– クライアントから見るとスレーブ／マスターの区別がない

強み、弱み、落とし穴（２）● 勝手にフェイルオーバー

● 落ちたノードへの書込みは自動的に他のノードが受け取り一時保管する

● ノードが復帰したらデータが書き戻される– 一時保管されたデータは、クライアントからは読み出せ

ないことに注意– 本来のノードがすべて落ちたらそのデータは読めなくな

る– 他のノードが担当を肩代わりしてくれるわけではない

強み、弱み、落とし穴（３）● スケールアウトと負荷分散

● ノードを新規追加すると、データ量が一番多いノードからデータを半分引き取ってくれる– 実データがどのノードに保存されているかブラックボッ

クスになっている

強み、弱み、落とし穴（４）● データの整合性（Consistency）

● トランザクション、ロールバック、アトミックな更新の機能がない

● 整合性の強さをAPIで定義（整合性レベル）– 整合性レベル＝読み書きの時に通信するノードの数– 整合性と速度はトレードオフ

整合性レベル（≒対象ノード数）

整合性: 弱い強い

ANY ONE QUORUM ALL

速度: 速い遅い

読み込み時に指定する整合性レベルレベル動作ONE 読み込み要求に対して最初にレスポンスされてきた

データを返すQUORUM レプリケーションファクタ値の過半数(N/2+1)か

らのレスポンスが返ってきた時点で、タイムスタンプが最も新しいデータを返す

ALL データを持つすべてのノードからのレスポンスを待ち、タイムスタンプが最も新しいデータを返す

“Quorum” /kwɔ́ːrəm/（会議成立などに必要な）定足数, 必要員数

書き込み時に指定する整合性レベルレベル動作ANY どこかで1回書き込みされたことが通知されるまで

待ってから処理を返す。本来担当すべきノードがダウンしている場合は最寄りの別のノードがデータを一時保管し、本来のノードへの伝達はキューイングされる

ONE 1つのノードでの書き込み成功が通知されてから処理を返す

QUORUM レプリケーションファクタ値の過半数(N/2+1)からのレスポンスが返ってきた時点で、タイムスタンプが最も新しいデータを返す

ALL レプリケーションファクタで指定されたすべてのノードの書き込みに成功するのを待ってから処理を返す

強み、弱み、落とし穴（５）● 読み書きのパフォーマンス

● 読み出しよりも書き込みの方が速い– 読み出し：ランダムアクセスあり– 書き込み：ランダムアクセスなし

● コミットログ書き出し＋メモリ内テーブルの書換えで実現

● ディスクへの書き込みは別スレッドで非同期に処理

読み込みと書き込みの性能比Host Load

(GB)Read Count Read

Latency (ms)

Write Count

Write Latency (ms)

Read / Write

host1 8.30 11,112,703 0.19211 24,771,377 0.02160 8.89host2 2.47 3,409,255 0.37081 6,037,249 0.01796 20.65host3 6.52 8,690,713 0.18386 19,387,158 0.02272 8.09host4 5.50 7,187,823 0.14506 18,943,157 0.01827 7.94

読み込み:書き込みの速度比、書込みが約8倍ほど速い

まとめ：Cassandraとは● 大量のデータを大量のサーバでさばく

● レプリケーション＆シャーディング● 一部で障害が起きても全体としては動き続ける● 書き込みの速度に焦点を置いている● データの整合性を犠牲にして速度を稼ぐことが

できる

フィットするパターン● 大量のデータが一斉に飛んでくる

● 大規模クラスタで負荷分散しつつ受け止めたい● 大量データを統計処理に使いたい

● ごく一部のデータが欠損しても全体には影響がない

● 気象、交通などセンサーデータの収集、解析● Webサービスでのログ／ビーコンなど● その他、リアルタイムな統計的処理など


情報収集について● 一次情報

● ML– http://www.mail-archive.com/[email protected]/

● JIRA– https://issues.apache.org/jira/browse/CASSANDRA

● Wiki (English)– http://wiki.apache.org/cassandra/

● 二次情報● Wiki(Japanese)

– http://wiki.apache.org/cassandra/FrontPage_JP● ユーザー会ML(cassandra-ja)

[email protected]

Cassandra - ASF JIRA

現在のプロジェクト状況● v0.6系の最新は0.6.13● v0.7系の最新は0.7.5● v0.8系の最新は0.8.0-beta2

0.6系から0.7系への変化(1)● スキーマをオンラインで変更

● [CASSANDRA-44]– It is difcult to modify the set of ColumnFamliies in

an existing cluster● カラムにttl(生存期間)を指定して自動expire

● [CASSANDRA-699]– Add (optional) expiration time for column

● インデックスをはったカラムの値でRowを検索● [CASSANDRA-749]

– Secondary indices for column families

0.6系から0.7系への変化(2)● 設定ファイルを一新／スキーマの定義をサーバの設定

ファイルから分離● [CASSANDRA-1133]

– utilities for schema import-from/export-to yaml.● [CASSANDRA-990]

– Replace cassandra.xml with cassandra.yaml● コマンドラインクライアントの機能向上

● データ内容の確認、更新、スキーマ定義、ファイルからのコマンド読み込みなど– [CASSANDRA-1088], [CASSANDRA-1583], [CASSANDRA-1616], [CASSANDRA-1653], [CASSANDRA-1687], ...

0.7系から0.8系への変化● CQL(Cassandra Query Language)

● [CASSANDRA-1703]– CQL 1.0

● カウンター専用のカラム型サポート● [CASSANDRA-1072]

– Increment counters● 目玉のCQL以外に新機能はあまり多くない

● 56 fixed bugs● 39 improvements● 7 new features

Cassandra Query Language● SQLライクな独自のクエリ言語● Thrift / Avroの生のAPIを叩く必要がなくな

る● 各プログラミング言語からのI/Fを統一

● JDBCドライバなどの開発● 最終的にはRPCライブラリ(Thrift / Avro)から離れてCQL独自の通信層を実装したい？

Cassandra Query Language● データの取得SELECT (FROM)? <CF> [USING CONSISTENCY.<LVL>] WHERE <EXPRESSION> [ROWLIMIT X] [COLLIMIT Y] [ASC|DESC]

Cassandra Query Language● データの格納／変更UPDATE <CF> [USING CONSISTENCY.<LVL>]SET <cname1> = <cvalue1>, <cname2> = <cvalue2>, ... WHERE KEY=<key>

※UPDATEはINSERTを兼ねる模様

Cassandra Query Language● データの削除DELETE (FROM)? <CF> [USING CONSISTENCY.<LVL>] WHERE <EXPRESSION>

Vector clockを巡る議論● 発端（没） [CASSANDRA-580]

● vector clock support● 採用 [CASSANDRA-1072]

● Increment counters ● 没 [CASSANDRA-1421]

● An eventually consistent approach to counting

● 没 [CASSANDRA-1546]● (Yet another) approach to counting


クラスタ設計● クラスタの規模は？● データセンターを分けるか？● データの冗長度は？

クラスタの規模● ノードは後から簡単に追加できる● 少ないノードでもオーバーヘッドが少ない● 小さなクラスタから少しずつ育てることも可能

● 数ノードから始めて、負荷に応じて随時追加

データセンターを分ける？● “placement_strategy”

● レプリケーション先を決めるアルゴリズム● レプリカを必ず別のDCに書く、などの設定が可能

● クラスタを設計する時に決めておくべき● 国内では東日本と西日本の2箇所、とか● おそらくサービスを提供する企業の「事業継続計画(BCP)」「災害時復旧計画(DRP)」レベルで考慮すべき事項

データの冗長度● “replication_factor”● データをいくつのノードに書き込むか？● ノードが何台まで落ちても耐えられるか？● ⇔ ディスク容量● ⇔ 情報伝播の速度（整合性）● ⇔ Consistency Level

データの分散アルゴリズム(Partitioner)

● RandomPartitioner● キーのハッシュ値(md5)によってランダムに振り分け

る● ByteOrderedPartitioner

● キーのバイト値によって順番に振り分ける● CollatingOrderPreservingPartitioner

● キーを文字列として辞書順に振り分ける

● クラスタ単位で設定→クラスタ設計に必須

データの分散アルゴリズム(Partitioner)

● データを均等に分散したい● RandomPartitioner

● キーの範囲をレンジスキャンしたい● ByteOrderedPartitioner● CollatingOrderPreservingPartitioner

● RandomPartitionerはキーを範囲指定してアクセスする処理ができない

● OrderedPartitionerはノードごとのデータが偏りがち→負荷分散が難しい

一貫性レベルConsistency Level

RF= 1 2 3 4 5 6

CL= ANY 0 0 0 0 0 0

ONE 1 1 1 1 1 1

QUORUM 1 2 2 3 3 4

ALL 1 2 3 4 5 6

Replication FactorとConsistency Levelによって書き込まれるノード数の違い

効果が変わらない非現実的

クラスタ設計（まとめ）● クラスタの規模は？

– データ量と負荷に応じて決める– スケールアップ可能

● データセンターを分けるか？– 提供するサービスレベルによって決める

● データの冗長度は？– 提供するサービスレベルによって決める

● その他のパラメータ– アプリケーションの要件によって決める

スキーマ設計の注意点● データをモデリングしてはいけない

● リレーションという概念がない● トランザクションやロールバックがない

● Cassandraにエンティティを保存してはいけない● 整合性や一貫性、検索性の低さ

● バッファ、ワークエリア、キャッシュとして使う● 処理の単位を中心においた「ユースケース駆動」の設計

をすべき

エンティティはRDBに● Cassandraが必要なくらい大規模なプロジェ

クトで、データの入れ物としてRDBMSがないというケースはあり得ない

● 全部をまかなえるほどCassandraは万能ではない

Partakeは「あえて全部Cassandraでやってみた」というネタ実験プロジェクト

ユースケース駆動のCF設計● ユーザーがサービスを利用するという意味ではない● アプリケーションがストレージを利用する場面という意味

× このエンティティはどういうプロパティを持っているか？○ この処理において読み書きしたいのはどういうデータの塊か？

Core system

Work area

Buffer

Cache

Entity

入力

処理

出力

Cassandraの使いどころ● ボトルネックになっている箇所をスケールさせ

るために使う● 必要なデータの塊に対応するCFを作る● 一度の読み書きをひとつのCFで完結させる

ノード分散を考慮したキー設計● 悪い例：

キー= “2010-12-25”

● その日のデータはすべて一つのノードに集中● スケールアウトしない！

ノード分散を考慮したキー設計● 改善案：

キー= “2010-12-25:user-id-1”

● ユーザーごとに格納先が変わるので分散する

集計前または集計済のデータを載せる● トランザクションやロックの機能がない● Check & Setができない● レースコンディションに弱い

Get() ⇒ 5 5+10=15 Set(15)

Get() ⇒ 5 5-1=4 Set(4)

5 15

キーの細分化● 1セッションでのI/Oが別セッションに割り込

まれないように● 例：キーをユーザー単位に分割する

Super Columnの罠● スーパーカラム

＝２段にネストしたHashTable型のCF● Sub columnにはインデックス情報がない● Sub columnをひとつだけ読込もうとしても全てのデータがメモリ上に取り出される

Super Columnの罠● 悪い例：サービス別ユーザー別行動履歴

UserActivity: { service-id-1: { user-id-1: { timestamp: activity1 timestamp: activity2 timestamp: activity3 : } user-id-2: { timestamp: activity1 : } service-id-2 { }}

Super Columnの罠● 悪い例：サービス別ユーザー別行動履歴

● 特定のactivityだけを取得しようとしても、user-id-1に含まれるデータがすべてメモリ上に展開される

● → Out of memory!

Get UserActivity[12][35][20110305112233]

Super Columnの罠● 改善案：

● タイムスタンプ＋行動種別で分割● カラム数が有限個に収まるようにする

UserActivity: { service-id-1$user-id-1: { timestamp$activity-type: { timeuuid: activity1 timeuuid: activity2 timeuuid: activity3 } }}

アプリケーション側のポイント● 上位層は抽象化しておく● とにかく逐一ログに書き出す● Cassandraを信用しない

上位層を抽象化しておく

Cassandra

Get() / Set()

Get() / Set()

App

UserHistory

とくかく逐一ログに書き出す

Cassandraを信用しない

本番システムへの適用● ポイント(1)

● Cassandraがなくても動くように作る● ポイント(2)

● 範囲を絞って使えるようにする● ポイント(3)

● すぐに切り戻せるようにする

Cassandraがなくても動くように

範囲を絞って使えるようにApp

Shard-1 Shard-2

Cassandra-1

Admin

Group-1 : read from [Shard-1]

Group-2 : read from [Cassandra-1]

書き込み処理は必ずDBとCassandra両方に書き込む管理画面からの設定で、グループ毎にDBから読込むかCassandraから読込むかを切り替える

不具合があればすぐ切り戻すApp

Shard-1 Shard-2

Cassandra-1

Admin



書き込み処理は必ずDBとCassandra両方に書き込む管理画面からの設定で、グループ毎にDBから読込むかCassandraから読込むかを切り替える

障害検知について● アプリ側を監視していても、ノードが一つ二つ落ちて

いることに気づけない● 1台だけ生き残っていてHinted Handofを受け取り続

けていた……ということもありえる● 障害によってデータの欠損が起こったかどうか、運用側から発見が困難

● どの段階で復旧の可否を判断するか？

● P2Pベースの自律分散システム＝便利だけど管理が難しい

バックアップとリストア(1)● ある時点のスナップショット、という概念がな

い● ノードごと、SSTableごとにJSONにダンプ／

リストアする機能があるだけ● 各ノードごとに受け持ちのデータ範囲が違う● ひとつノードを停めてバックアップしている間

に別のノードがレプリカを更新してしまう

バックアップとリストア(2)● サービスを停めないと整合性のとれたバック

アップはとれない→設計段階から織り込んでおく必要がある→「エンティティを保存しない」の理由の一つ


Cassandraはとてもエクストリーム(極端)

なデータベース

Core system

Work area

Buffer

Cache

Entity

用法・用量を守って正しくお使いく

ださい

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

Technology

Guide to Cassandra for Production Deployments