インフラエンジニアのためのcassandra入門

インフラエンジニアのための
cassandra 入門
株式会社サイバーエージェント　桑野　章弘

自己紹介

自己紹介
桑野　章弘
id: akuwano
twitter: @kuwa_tw
株式会社サイバーエージェント
インフラエンジニア
最近は自分でも何やってんのかわからなくなってきた

はじめに
Cassandra を知らない人向けに
どういうもので
どうやって使ったらいいの？
細かい部分ははしょっています

アジェンダ
MySQL の分散って大変？
そこで Cassandra ですよ
Cassandra を試すのは簡単
設定とか、管理とかってどうなの
MySQL->Cassandra への置換例
これからの話
まとめ

MySQL の分散って大変？

1 台ならいいけど
サービスが大きくなるにつれてサーバへの負荷は増えていきます
そこをケアするためにサーバを増やすわけですが、、、
Web 、 Ap サーバは主にロードバランサ等で分散します
DB サーバはシャーディングで分散します
例えば、、、

テーブル分割手法（例 1 ）
特定のカラムでの分割
UserID などで特定のレンジ毎にサーバを分割する

特定のカラムでの分割
DBMaster DBSlave1 DBSlave2 分散ルール 150000 175000 200000 50000 1 データ UserID B 200000 100001 A 100000 1 レンジ End レンジ Start テーブル UserID 50000 1 データ UserID 150000 175000 200000 データ UserID

メリット
データの管理は分かりやすい
デメリット
特定サーバへの偏り
一部障害の可能性
サーバ追加のタイミングとレンジルールのメンテナンス性

ハッシュテーブルでの分割
分散対象をハッシュ化してそのハッシュ値を元にサーバの分割を行う

ハッシュテーブルでの分割
DBMaster DBSlave1 DBSlave2 分散ルールハッシュ化 1->01 50000->01 15000->00 17500->00 200000->02 150000 175000 200000 50000 1 データ UserID B 02 B 01 A 00 テーブルハッシュ値 175000 150000 データ UserID 1 50000 200000 データ UserID

メリット
分散の粒度を細かくすればメンテナンスの手間は少ない
デメリット
特定サーバへの偏り
一部障害の可能性
特定データの受け持ち DB をトレースしないといけない

結構大変じゃないですか？
継続的に管理しないといけない
もちろん自動化とかするのもありだけど、サーバ追加とか分散ルールの変更とか。
負荷が増えてきた時にデータ移動とか。
1 台落ちると部分障害になったり。
それに対応してさらに複雑になったり。
増えれば増えるほどサーバの管理は大変になる、、、。
この辺り気にしない様になったら楽ですよね

そこで Cassandra ですよ

Cassandra って？
Cassandra は Facebook で作られた分散型 DB サーバ
Dynamo 的な大規模分散管理と、 HyperTable の様なカラム型データ構造を持った DB である

それ Cassandra で出来（ｒｙ
パフォーマンス
分散実装
冗長性
データ構造
全部確保できます

それ Cassandra で出来、、、
整合性の確保
カラム構造の動的変更
これはダメ。（出来るけど）

パフォーマンス
MySQL と比べてリードライトの性能が格段に良い
公式 Wiki より
write read 15ms 350ms 0.12ms 300ms Cassandra MySQL

分散実装
クラスタリング
各サーバには差異は無い。サーバ種別はノードサーバのみ。
Gossip プロトコルを使用した情報伝播
次ページ

Gossip プロトコル
直近ノード間でのみ情報をやり取りしつつ最終的にはノードの状態（ JOIN 、 DEAD 、 AVAIL など）を取得できる
トラフィック量が倍倍に増えていく事がない
即時性は無い

冗長性
各レンジ毎にレプリカをもつ
レプリカ数は設定可能、デフォルトは 1 （レプリカ無）
レプリカ先のサーバの決定方法はカスタマイズ可能
ランダム、 IP アドレスレンジ等でレプリカの場所を指定、など

データ構造
基本はカラム型
Key 、 Name とその Value
でも SuperColumn 等で柔軟なデータ構造が作れる

データ構造
Column
・・・ Key Key Name Value Name Value Name Value Name Value Name Value Name Value Name Value

データ構造
SuperColumn
・・・ Key Key Name Value Value Value Value Value Name Value Value Name Value Name Value Name Value Name Value Name Value Name Value Name Value Name に紐付く形で Column が入っている

整合性の確保
クラスタ台数が増えれば増えるほど整合性の即時確保は難しい
整合性レベル（ Consistency Level ）を指定することでクラスタにいきわたるまで待つ事も出来る

カラム構造の動的変更
現カレントバージョンでは動的変更は出来ない
やりたい場合は、 JSON エクスポート -> カラム変更 ->JSON 変更 ->JSON インポート　の手順が必要
全台
無理

Cassandra を試すのは簡単

手順
バイナリであればインストールは簡単
JDK の展開
バイナリの展開
ディレクトリ作成（データ、ログ）
設定ファイルはサンプルで動くのでそのまま起動
これだけ！

手順 ##### JDK インストールは割愛 ##### Cassandra インストール # cd /usr/local/src/cassandra # wget http:// ftp.riken.jp/net/apache/incubator/cassandra/0.6.1/apache-cassandra-0.6.1-bin.tar.gz # tar zxvf apache-cassandra-0.6.1-bin.tar.gz # mv apache-cassandra-0.6.1 /usr/local/ # ln -s /usr/local/apache-cassandra-0.6.1 /usr/local/cassandra ##### DATA ディレクトリ、 LOG ディレクトリの作成 # mkdir -p /var/log/cassandra # mkdir -p /var/lib/cassandra # chown -R cassandra. cassandra /var/log/cassandra # chown -R cassandra.cassandra /var/log/cassandra # chown -R cassandra.cassandra /usr/local/cassandra ##### Cassandra 起動テスト # su - cassandra $ cd /usr/local/cassandra/bin $ ./cassandra -f Listening for transport dt_socket at address: 8888 INFO - Saved Token not found. Using 65403833352419508191139141305783892154 INFO - Starting up server gossip INFO - Cassandra starting up... Ctrl+C で停止

設定とか、管理とかってどうなの？

設定の勘所ってどこ？
Seed
Port
KeySpace & ColumnFamily
ReplicaPlacementStrategy & ReplicationFactor
Partitioner
Memory, Disk, and Performance
Directories
殆ど全部じゃねぇか！、、、ので抜粋して。

Seed
クラスタのやり取りを行うサーバを設定する
サーバの情報のやり取りは Gossip 経由で行われるので全サーバを書く必要はありません
<Seeds> <Seed>cass-test01</Seed> <Seed>cass-test02</Seed> <Seed>cass-test03</Seed> </Seeds>

Port
他ノードとの通信用ポート
クライアントとの通信用ポート
 <ListenAddress> サーバの IP アドレス </ListenAddress> <StoragePort>7000</StoragePort> <ControlPort>7001</ControlPort>  <ThriftAddress>0.0.0.0</ThriftAddress> <ThriftPort>9160</ThriftPort>

KeySpace & ColumnFamily
カラムを定義する
データ種別の設定
SuperColumns
BytesType
AsciiType
UTF8Type
LongType
LexicalUUIDType
TimeUUIDType
詳しくは後述

ReplicaPlacementStrategy & ReplicationFactor
ReplicaPlacementStrategy はレプリカ作成の戦略
ReplicationFactor はレプリカの数を指定する
# 物理配置を気にしない <ReplicaPlacementStrategy> org.apache.cassandra.locator.RackUnawareStrategy </ReplicaPlacementStrategy> # レプリカの数 =2 <ReplicationFactor>2</ReplicationFactor>

Partitioner
データの分割方式の指定
基本的には RandomPartitioner を選択することで適切に分散してくれる
レンジでのデータ取得をしたい場合には OrderPreservingPartitioner を選択する必要があるが、その代わりノード毎に InitialToken を指定する必要がある
# ランダム分割 <Partitioner>org.apache.cassandra.dht.RandomPartitioner</Partitioner> # 分散箇所を指定する <Partitioner>org.apache.cassandra.dht.OrderPreservingPartitioner</Partitioner>

Memory, Disk, and Performance
各種カラムのキャッシュ
リード、ライトのスレッド数
Memtable のフラッシュタイミング、バッファ容量
作成したカラムの構成によって変更する必要がある

設定の勘所ってどこ？  <SlicedBufferSizeInKB>64</SlicedBufferSizeInKB>  <FlushDataBufferSizeInMB>32</FlushDataBufferSizeInMB> <FlushIndexBufferSizeInMB>8</FlushIndexBufferSizeInMB>  <ColumnIndexSizeInKB>64</ColumnIndexSizeInKB>  <MemtableSizeInMB>64</MemtableSizeInMB>  <MemtableObjectCountInMillions>0.1</MemtableObjectCountInMillions>  <MemtableFlushAfterMinutes>60</MemtableFlushAfterMinutes>

設定の勘所ってどこ？  <ConcurrentReads>8</ConcurrentReads> <ConcurrentWrites>32</ConcurrentWrites>  <CommitLogSync>periodic</CommitLogSync>  <CommitLogSyncPeriodInMS>10000</CommitLogSyncPeriodInMS>  <GCGraceSeconds>864000</GCGraceSeconds>  <BinaryMemtableSizeInMB>256</BinaryMemtableSizeInMB>

Directories
ディスクの使い道としては、 [SStable:/usr/lib/cassandra/data][Commitlog:/usr/lib/cassandra/commitlog] の 2 つ
その 2 つに関してパーテション等を分けて I/O 分散した方が良い

管理はどうやるの？
データ操作
バックアップ／リストア
サーバ追加
データ再配置
サーバ監視

データ操作
cassandra-cli コマンドで行えます
プログラムから読みたい場合は Thrift インターフェースで雛形が出せるのでそれを使いましょう

サーバ追加
クラスタに参加しているサーバを Seed で追加して立ち上げればクラスタに入る
全サーバを Seed に書く必要はありません。

サーバ追加
RingA RingB RingC ここがハブになる形でも可

管理はどうやるの？ #### 状態確認 $ ./nodeprobe -host cass-test01 ring Address Status Load Range Ring 124039723817946554142311632841015584374 cass-test03 Up 1.5 GB 54726667172133563740938363913892816149 |<--| cass-test02 Up 767 MB 85116141055809869248935675462381407463 | | cass-test01 Up 643.61 MB 124039723817946554142311632841015584374 |-->| #### 設定追加 $ vi ../conf/storage-conf.xml <Seeds> <Seed>cass-test01</Seed> </Seeds> #### サーバ起動 $ ./cassandra -p ./cassandra.pid INFO - Replaying /var/lib/cassandra/commitlog/CommitLog-1269269853066.log INFO - Log replay complete INFO - Saved Token not found. Using 97147856872319332778007596849029295064 INFO - Starting up server gossip #### 状態確認 $ ./nodeprobe -host cass-test01 ring Address Status Load Range Ring 124039723817946554142311632841015584374 cass-test03 Up 1.5 GB 54726667172133563740938363913892816149 |<--| cass-test02 Up 767 MB 85116141055809869248935675462381407463 | | cass-test04 Up 1.47 KB 97147856872319332778007596849029295064 | | cass-test01 Up 643.61 MB 124039723817946554142311632841015584374 |-->|

データ再配置
nodetool コマンドで出来るよ
loadbalance コマンド
データ展開
他ノードへのデータ移動
を自分の受け持ちレンジ毎にじわじわ行う

データ再配置
##### 　データ再配置 $ /usr/local/cassandra-0.6.1/bin/nodetool -h localhost loadbalance

サーバ監視
nodetool コマンドで出来ますよ
tpstats コマンド
##### 　スレッドの遷移統計 $ /usr/local/cassandra/bin/nodetool -host localhost tpstats Pool Name Active Pending Completed FILEUTILS-DELETE-POOL 0 0 18 STREAM-STAGE 0 0 0 RESPONSE-STAGE 0 0 4947787 ROW-READ-STAGE 0 0 314 LB-OPERATIONS 0 0 0 MESSAGE-DESERIALIZER-POOL 0 0 14089762 GMFD 0 0 309642 LB-TARGET 0 0 0 CONSISTENCY-MANAGER 0 0 0 ROW-MUTATION-STAGE 0 0 11206334 MESSAGE-STREAMING-POOL 0 0 0 LOAD-BALANCER-STAGE 0 0 0 FLUSH-SORTER-POOL 0 0 0 MEMTABLE-POST-FLUSHER 0 0 76 FLUSH-WRITER-POOL 0 0 76 AE-SERVICE-STAGE 0 0 1 HINTED-HANDOFF-POOL 0 0 8

サーバ監視
nodetool コマンドで出来ますよ
cfstats コマンド
$ /usr/local/cassandra/bin/nodetool -host localhost cfstats ---------------- Keyspace: <KeySpace> Read Count: 314 （ snip ） Key cache capacity: 1157568 Key cache size: 310 Key cache hit rate: 0.0 Row cache capacity: 10000 Row cache size: 72 Row cache hit rate: 0.7707006369426752 Compacted row minimum size: 228 Compacted row maximum size: 1357548 Compacted row mean size: 313 ----------------

だから n （ｒｙ
snapshot コマンドで実行
clearsnapshot で削除
##### Memtable の書き出し $ /usr/local/cassandra/bin/nodetool -h localhost flush <KeySpace> ##### Snapshot の作成 $ /usr/local/cassandra/bin/nodetool -h localhost snapshot snapshottest ##### Snapshot が出来ているのを確認 $ ls /var/lib/cassandra/data/<KeySpace>/snapshots/1273757807243-snapshottest/ ##### Snapshot の削除 $ /usr/local/cassandra/bin/nodetool -h localhost clearsnapshot

json <-> SStable でエクスポート、インポート出来る tool もあります
##### エクスポート $ ./sstable2json -f CfByte1-36-Data.json /var/lib/cassandra/data/KsName1/CfByte1-36-Data.db INFO - Sampling index for /var/lib/cassandra/data/KsName1/CfByte1-36-Data.db $ cat CfByte1-36-Data.json { "test843352": [["746573746461746131", "383433333532", 1269433709, false]], (snip) "test851643": [["746573746461746131", "383531363433", 1269433743, false]] } ##### インポート $ ./json2sstable -K KsName1 -c CfByte1 CfByte1-36-Data.json /var/lib/cassandra/data/KsName1/CfByte1-36-Data.db $

MySQL->Cassandra の移行例

実際のカラムってどうなります？
設定方法はわかったけどじゃあ MySQL を移行したい場合はどうしよう。
じゃあ実際に変更してみましょう。

実際のカラムってどうなります？
想定システムは？
SNS のコミュニティのシステムの一部。
コミュニティの新着更新情報
実際のテーブル構造はこんな感じで。

テーブル構造
2 テーブルで構成します。
ユーザマスタコミュニティマスタコミュニティが更新されたら更新日時を UPDATE Mac ユーザ B Solaris ユーザ C FreeBSD ユーザ D Solaris ユーザ A Linux ユーザ B Windows ユーザ C Plan9 ユーザ C Windows ユーザ A Linux ユーザ A コミュニティ ID UserID 1970/01/01 00:00:01 Plan9 2010/05/13 17:59:00 Solaris 2010/05/12 17:59:00 FreeBSD 2010/05/14 17:59:00 Linux 2010/05/10 01:00:00 Mac 2009/01/01 00:00:01 Windows 更新日時コミュニティ ID

参照クエリの処理
ユーザマスタとコミュニティマスタをコミュニティ ID でリレーション
コミュニティマスタの更新日時でソート

テーブル構造
ユーザ A のカラムをとってきた場合
ユーザマスタコミュニティマスタ更新日時でソートして表示 Solaris Windows Linux コミュニティ ID 2010/05/13 17:59:00 ユーザ A 2009/01/01 00:00:01 ユーザ A 2010/05/14 17:59:00 ユーザ A 更新日時 UserID Linux Solaris Windows コミュニティ ID 2010/05/14 17:59:00 ユーザ A 2010/05/13 17:59:00 ユーザ A 2009/01/01 00:00:01 ユーザ A 更新日時 UserID

これを Cassandra で置き換える
カラム構造
こちらも 2 つの CF で表現

カラム構造
2 つの SuperColumn で構成します。
コミュニティマスタコミュニティと、その所属ユーザの関連付け Plan9 Solaris FreeBSD Linux Mac Windows コミュニティ ID ユーザ B ユーザ A 所属ユーザ

カラム構造
2 つの SuperColumn で構成します。
ユーザマスタコミュニティの更新日時をキーにする事でソートを考慮する必要が無くなるユーザ D ユーザ B ユーザ C ユーザ A UserID Linux 2010/05/14 17:59:00 Solaris 2010/05/13 17:59:00 Windows 2009/01/01 00:00:01 コミュニティ ID 更新日時

設定ファイル
ColumnFamily としてはこのように書きます。
これだけｗ
<ColumnFamily Name=" コミュニティマスタ " ColumnType="Super" CompareWith="BytesType" CompareSubcolumnsWith="BytesType" /> <ColumnFamily Name=" ユーザマスタ " ColumnType="Super" CompareWith="BytesType" CompareSubcolumnsWith="TimeUUIDType" />

何が違う？
RDBMS ではリレーションを使っているが、 Cassandra はリレーションは行えない
RDBMS ではユーザ * 参加コミュニティ数分のレコード数が必要になるが、 Cassandra では必要ないのでシンプルな構成
Cassandra ではキーのソートが保障されているのでソートを考慮する必要がない。
でも同じような事が Cassandra でもできました

これからの話

今後のロードマップ
0.7
NameSpace 毎に Partitioner の指定
動的カラム変更
Avro 対応
0.8
index 実装
VectorClock 実装

現在の問題
動作が一部安定していない
高負荷時に落ちる場合がある
ソフトウェアの安定度は MySQL に及ばない
バグは踏む前提でｗ

現在の問題
クライアントの冗長／分散は要ります
kumo-gateway みたいな実装ではないので、 Thrift で特定サーバに繋ぎに行けなかった時には別のサーバに繋げるようにする必要があります。

現在の問題
仕様が大胆に変わる
現在の Trunk は設定ファイルで初期 ColumnFamily を設定できない。読まない。前述のカラムの動的変更の余波。
0.7 から設定ファイルが XML から YAML に変わっている
XML->YAML 変換ツールは付属。でもそもそもの設定項目名が変わってたりしてるのであんま意味内

まとめ

Cassandra 自体は現在も開発が活発に進んでいて機能追加も凄いスピードでされている状態です。

、、、正直インフラエンジニアとしてはまだプロダクトへの利用は怖いかなーと思いますﾎﾞｿｯ

要するに
まだプロダクトにはいれてないよー。
検証中だよー。
　　　　　　　　　　　　　　　　　ですｗ

ですが、非常に魅力的な物には違いないですので、人柱 ^H^H 先駆者になっておいて損は無いと思います。

特に実際にプロダクトで使用した問題点がでてくるのはこれからだと思います。

みなさん使ってみましょう！そして語り合いましょう！語り合いたいですｗ

以上、ご清聴ありがとうございました。

最後に裏番組の告知です

Cassandra Web Console

こんな話もやっている、アメーバ技術勉強会！

今やってます！

ハッシュタグ #techameba にアクセス！

ustream もやっているので是非見て頂ければと思います。録画もある（はずだ）よ！

http://www.atmarkit.co.jp	7456
http://www.publickey1.jp	2483
http://d.hatena.ne.jp	1474
http://www.slideshare.net	428
http://webcache.googleusercontent.com	36
http://pre-www.atmarkit.co.jp	15
http://kat.or.tl	6
http://aitcms-w.atmarkit.co.jp	6
http://presenyuzuru.posterous.com	4
http://wiki.onakasuita.org	2
http://linyo.ws	2
http://www.iweb34.com	2
http://translate.googleusercontent.com	2
http://a0.twimg.com	1
http://static.slideshare.net	1
http://publickey1.jp	1
https://si0.twimg.com	1

インフラエンジニアのためのcassandra入門

by Akihiro Kuwano on May 14, 2010

Accessibility

Categories

Tags

Upload Details

Usage Rights

17 Embeds 11,920

Statistics

インフラエンジニアのためのcassandra入門 — Presentation Transcript