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

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

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

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

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

MySQL の分散って大変？

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

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

テーブル分割手法（例 1 ）特定のカラムでの分割 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

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

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

テーブル分割手法（例 2 ）ハッシュテーブルでの分割 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

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

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

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 を移行したい場合はどうしよう。じゃあ実際に変更してみましょう。

実際のカラムってどうなります？想定システムは？ 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 先駆者になっておいて損は無いと思います。

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

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

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

最後に裏番組の告知です

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

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

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

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

More Related Content

What's hot

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

More from Akihiro Kuwano

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

Editor's Notes