cassandra調査レポート

23,143 views

Published on

個人的な興味からcassandraについてしらべてみました。
間違っている部分など、指摘や質問などあればお知らせいただけるとうれしいです。

0 Comments
55 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
23,143
On SlideShare
0
From Embeds
0
Number of Embeds
222
Actions
Shares
0
Downloads
0
Comments
0
Likes
55
Embeds 0
No embeds

No notes for slide

cassandra調査レポート

  1. 1. 分散 DB「Cassandra」に関する調査/検証 <日付 2010/03/23> 桑野 章弘 1
  2. 2. はじめに................................................................................................................................. 3 概要........................................................................................................................................4 特徴........................................................................................................................................5 ソフトウェアアーキテクチャ................................................................................................6 ハードウェア要件................................................................................................................11 検証......................................................................................................................................13 総評......................................................................................................................................28 疑問点..................................................................................................................................29 参考文献...............................................................................................................................30 2
  3. 3.  はじめに 現在 RDB が使われてきている部分に関して、 RDB 以外では出来ないのかを模索する noSQL(NotOnlySQL)と言う流れが急速に加速している。 特に Web アプリケーションにおいては RDB は冗長である傾向があり、 での sharding も RDB 限界がある。 そこで Facebook 社が開発した分散 DB「cassandra」について、実際どの程度使えるのかを 調査/検証してみた。 3
  4. 4.  概要 Cassandra は Facebook で作られた分散型 DB サーバである。 Dynamo 的な大規模分散管理と、HyperTable の様なカラム型データ構造を持った DB となっ ており、高可用性と冗長性を併せ持つ。 目標としては、これらを上手く利用することで今まで MySQL で行っているレプリケーショ ンとテーブル分割でサーバをスケールアウトしていく方法を、サーバ追加のみを考えて運 用する形に変えていけるようになる事、となる。 機能に関しては次の項で説明する。 4
  5. 5.  特徴 Cassandra の特徴として、以下の物があげられる。 1. 大規模データ 元々大規模データを扱えるように設計しており、実際の事例としても 150 台のサーバ で 100TB のデータを管理している物がある。 2. 分散処理 全ノードが同一のサーバとなっており、管理ノードなどは存在せず各サーバが相互に 通信しあって処理を行う。そのためネットワークボトルネックが無ければ SPOF も無い ということになる。 3. 冗長性 データは各ノードに自動でレプリケーションが行われる。 レプリケーションをデータセンタ毎に分けて DR を行うことも可能。 4. 高可用性/柔軟性 性能はノードの数によってリニアに増えていくことができ、ノードの追加、削除もダ ウンタイムなしで行うこともできる。 Consistency のレベルを決めることもできる、書き込みを保障しないレベルや 強固な 整合性の確保まで。だが当然パフォーマンスにも影響する。 5. 一貫性 cassandra では可用性の確保のため結果整合性モデルで一貫性の確保を行っている。  結果整合性とは DNS などに見られる、整合性に一部条件をつける1ような整合性である。 この場合成功した書き込みが必ず最新の状態で読み出せることを約束しない。   6. データ構造 Key、Value の組だけではなく、カラム型のデータ構造を持ち、ColumnFamily や 、 SuperColumn を使用することで単純な KVS では出来ない複雑なデータの管理も行うこと が出来る。 1 即時反映ではなく、反映までに時間がかかるなど 5
  6. 6.  ソフトウェアアーキテクチャ  次にこれらの機能を実現するためのソフトウェアアーキテクチャを説明する。 1. replication casandra はキーレンジごとにレプリカを持つ。(セカンダリ、ターティアリ ・ ・ ・。 ) プライマリのレプリカは各ノードが所持しているメタデータ内の token ring により 決定される。 レプリカに関しては決定方法が多く存在しており、以下の様なアルゴリズムで決定さ れる様である。 ・ RackUnaware の場合 ring 内の N-1 ノードにレプリカを行う ・ RackAware の場合違うデータセンタに存在する ring 内のノードにレプリカを 行う ラック、データセンタの判定に関しては、 アドレスの第 3 オクテット、 2 オクテッ IP 第 トまでが同一であることが条件。このため、VLAN などで NW 構築を行っている場合は判定 にムラが出る可能性はある。 2. Gossip Gossip とは、ノード間の情報をやり取りすることによって最終的なノードの状態 (JOIN、DEAD、AVAIL など)をクラスタ内のすべてのノードが知ることが出来る様になる アルゴリズムである。 Cassandra はこの仕組みで結果整合性の確保を行っている。 具体的には、Generation と、Version と呼ばれる単位でノードとデータの鮮度を判断 して、自分より新しい情報をどこに持っているかを近隣のノード経由で徐々に伝播して いく。 6
  7. 7. 概要図 図1:Gossip の概要図 3. Column ・ Column 構造 Cassandra のデータ構造の基本はカラム型になっており、JSON 図示にすると以下の様 に表される。この Column 構造を組み合わせて複雑なデータ構造を持つことも出来る。 (後述) { "name": "FirstName", "value": "Akihiro", "timestamp": 123456789 } 図 2:Column の JSON 構造 ・ SuperColumn  SuperColumn はソートされた Colume のリストを Value としてもつ特別な Column 構 造である。 7
  8. 8. { "Key1": { //Key "CFamily1": { //column family "SColumn1": { //SuperColumn //Column list "data1": {"data1": "Value1", "timestamp":"1234567890"}, "data2": {"data2": "Value2", "timestamp":"1234567890"}, "data3": {"data3": "Value3", "timestamp":"1234567890"} . . (snip) . } } } } 図 3:SuperColumn の JSON 構造 ・ ColumnFamily ColumnFamily とは複数の row からなる Column の集合であり、Cassandra でデータを管 理する際には ColumnFamily の作成が必要となる。そして同一の ColumnFamily に属する データは同一の SSTable(後述)にソートされた状態でおかれることとなる。 ColumnFamily は 作 成 時 に デ ー タ 型 を 決 定 す る 必 要 が あ り 、 現 在 は ASCII 、 UTF-8、Long、 UUID (lexical or time)の4種類が用意されている。 8
  9. 9. { "Key2":{ //Key "CFamily2":{ //Column Familiy //Column "emailAddress":{"name":"emailAddress", "value":"hoge@example.com", "timestamp":"1234567890"}, "webSite":{"name":"webSite", "value":"http://hoge.example.com", "timestamp":"1234567890"} } } "Key3":{ //Key "CFamily2":{ //Column Familiy //Column "emailAddress":{"name":"emailAddress", "value":"fuga@example.com", "timestamp":"1234567890"}, "webSite":{"name":"webSite", "value":"http://fuga.example.com", "timestamp":"1234567890"} } } } 図 4:ColumnFamily の JSON 構造 4. CommitLog Cassandra にデータが書き込まれた時は、Commitlog へ書き込みされる。 Commitlog に書かれた物から後述する memtable へとデータが書き込まれていく。 このデータはもし不慮のサーバダウンやネットワークダウンなどで memtable にしか ないデータが失われないよう、サーバ再起動時などはこのファイルからデータの復旧を 行う。 5. Memtable Memtable は、CommitLog から書き込まれた Key と Value のペアをメモリに保存してい る領域。直近で使われている大多数のデータは Memtable に存在することになるが、一定 時間使われていない( LRU Like?)データに関しては SSTable へと書き出される (Compaction 処理)。 9
  10. 10. 6. SSTable SSTable(Sorted Strings Table)は Key と Value のペアを Key でソートして格納し ているファイル。 ファイルの種類は、   ・ DATA ファイル(Key、Valuue が含まれるファイル:Key でソートされている) ・ INDEX ファイル(Key、と Offset の値が入っているファイル) ・ FILTER ファイル(BloomFilter2のデータが入っているファイル) の3種類で構成されている。 7. Thrift Facebook 社でつくられた RPC 通信用のフレームワーク、Cassandra ではクライアン トからの通信や、ノード間の通信に Thrift を使用している。 今回の検証でも、テスト用のスクリプトは Thrift を使用した python スクリプトで 行っている。 2 bloomfilter はノード間のキーの検索に使用しており、必要以上のトラフィックを流さない実装にするた めに必要な物である。 10
  11. 11.  ハードウェア要件  続いて、Cassandra を動かすのに必要なハードウェア要件について説明しておく。 その際の想定 OS に関しては Linux で想定している。  なお、この条件は構築するシステムによって必要な条件は異なるのであくまで目安とな る。 1. サーバ数 すべてのノードは同一キャパシティで構築しないとパフォーマンスに影響がでる。 おそらく基本の通信がノード間通信になるので、スペックのギャップが他のノードに 与える負荷が高いことによるボトルネックが発生するのだと想像できる。 スペックアップするのであれば台数を足した方がよい。 2. メモリ ほとんどのデータは memtable と呼ばれている領域(=メモリ)に存在している。が、 古いデータに関しては定期的に Compaction 処理でディスク(SSTable)に書き出され る。それらのデータは OS のバッファキャッシュに保存されている。 ただし、メモリが多いに越したことはないが、理由がない限りは 4GB 以上のメモリは 必要ない。 0.5 で実装された KeyCache や、今回は検証していないが 0.6 で実装されている ROWCache を使用することでさらにパフォーマンス的に有利となる。 3. CPU 大量のワークロードの場合メモリバウンドの前に CPU バウンドになる。そのため 4 or 8 core 以上の早い CPU が必要。 クラウド等や、仮想サーバだと CPU バウンドが発生する。 4. HDD 基本的には CommitLogDirectory と DataFileDirectories があればいい。 ディスクの使い方は以下の 2 種類。 ・ コミットログ ・ SSTable(ディスクへの保存) コミットログは MySQL ならバイナリログと似たような物。書き込みデータの保護、ク ラッシュ時などの復旧に使用される。コミットログが書き出されるディスクでは容量は いらないが、書き出し、読み出しは十分に早いディスクで行う。 SSTable は前述したが古いデータなどを保存していくファイルである。定期的な Compaction 処理で Memtable から SSTable へデータを書き出していき、SSTable への書き 11
  12. 12. 出しまで終わった物が CommitLog から削除される。 ディスクスペック的には容量もデータが入る分はもちつつ、早さも Compaction 処理 に影響を及ぼさないレベルで早い物がもとめられる。 メモリへの書き込み クライアントアクセス CommitLog データの書き込み Compact ion Memtable SSTable 図 5:データの書き込みの流れ 5. ファイルシステム ファイルシステムは、SSTable やコミットログなどの単一の大きなファイルが作成さ れる関係上パフォーマンス的には ext3 などよりも xfs の方がよい。 12
  13. 13.  検証  ここまでで Cassandra に関しての基本的な説明を終わり、実際の検証で現状の確認を試み る。 1. 実施環境 実施環境は以下の通り。 機種名 自作 台数 最大 4 台 CPU Atom D510 Memory 4GB HDD 250GB 2.5Inch HDD * 1 ディストリビューシ CentOS 5.4 ョン Partition 構成 /boot – 512MB ext3 swap - 2048MB / - 残り ext3 ソフトウェアバージ Cassandra 0.51 ョン Thrift 0.2.0 JVM jdk1.6.0_18 既に考慮される問題点として、 ・ CPU の性能 ・ HDD の性能 ・ ファイルシステムの選択3 が考えられるが、環境が用意できていないためこの辺りを加味した上で検証を行う。 2. インストール インストールの手順。今回は時間の関係上と、安定版4の最新ということで、Cassandra は 0.5.1 のバイナリを使用している。 3 前述した xfs の方がパフォーマンスがよいと言う話。 4 0.XX で安定版も何もないですが 13
  14. 14. ○ソースディレクトリ作成 # mkdir /usr/local/src/cassandra # cd /usr/local/src/cassandra ○JDK インストール [JDK の入手方法は割愛] # ./jdk-6u18-linux-x64.bin (snip) Do you agree to the above license terms? [yes or no] yes # mv jdk1.6.0_18 /usr/local/jdk1.6.0_18 # ln -s /usr/local/jdk1.6.0_18 /usr/local/java ○Java の環境変数設定 # useradd -m cassandra # su - cassandra $ vi /home/cassandra/.bash_profile (環境変数追加) # User specific environment and startup programs JAVA_HOME=/usr/local/java PATH=$PATH:$HOME/bin:$JAVA_HOME/bin export PATH JAVA_HOME $ source /home/cassandra/.bash_profile 14
  15. 15. ○Cassandra インストール # cd /usr/local/src/cassandra # wget http://ftp.riken.jp/net/apache/incubator/cassandra/0.5.1/apache-cassandra-0.5.1-bin.tar.gz # tar zxvf apache-cassandra-0.5.1-bin.tar.gz # mv apache-cassandra-0.5.1 /usr/local/ # ln -s /usr/local/apache-cassandra-0.5.1 /usr/local/apache-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/apache-cassandra ○hosts ファイル変更 # vim /etc/hosts 192.168.0.91 cass-test01 192.168.0.99 cass-test02 192.168.0.97 cass-test03 192.168.0.94 cass-test04 ○Cassandra 起動テスト # su - cassandra $ cd /usr/local/apache-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 で停止 15
  16. 16. 以上で、起動までの確認がとれた。 3. 設定 設定項目の説明。 一般的に触ると思われる設定を抜粋して説明する。 ○クラスタ、データ構造関連の設定 <!-- クラスタ名 --> <ClusterName>ClusterName</ClusterName> <!-- KeySpace,ColumnFamily の要素をここに書く --> <Keyspaces> <Keyspace Name="KsName1"> <KeysCachedFraction>0.05</KeysCachedFraction> <ColumnFamily CompareWith="BytesType" Name="CfByte1"/> <ColumnFamily CompareWith="UTF8Type" Name="CfUTF82"/> </Keyspace> </Keyspaces> <!-- ノードリスト。必要なノードはここに書くこと --> <Seeds> <Seed>cass-test01</Seed> <Seed>cass-test02</Seed> <Seed>cass-test03</Seed> <!-- <Seed>cass-test04</Seed> --> </Seeds> ○IP,ポート関連の設定 16
  17. 17. <!-- 他のノードとの通信のための IP,Port --> <ListenAddress>test-01</ListenAddress> <StoragePort>7000</StoragePort> <ControlPort>7001</ControlPort> <!-- Thrift Interface の IP,Port --> <ThriftAddress>0.0.0.0</ThriftAddress> <ThriftPort>9160</ThriftPort> ○バッファ関連の設定 17
  18. 18. <!-- Column を読む際のバッファ。よく実行されるColumn サイズにするべき。これを増やす時は ColumnIndexSizeInKB も増やす --> <SlicedBufferSizeInKB>64</SlicedBufferSizeInKB> <!-- memtable から SSTable に Flush するさいのバッファ。リソースが許すのであれば大きい方が よい --> <FlushDataBufferSizeInMB>32</FlushDataBufferSizeInMB> <FlushIndexBufferSizeInMB>8</FlushIndexBufferSizeInMB> <!-- Column の Value が非常に大きい場合や、数が多い場合はこの値を増やすこと --> <ColumnIndexSizeInKB>64</ColumnIndexSizeInKB> <!-- memtable に Store しておける最大容量 --> <MemtableSizeInMB>64</MemtableSizeInMB> <!-- memtable に Store しておける最大 Column 数 --> <MemtableObjectCountInMillions>0.1</MemtableObjectCountInMillions> <!-- memtable から compaction するまでの分指定 --> <MemtableFlushAfterMinutes>60</MemtableFlushAfterMinutes> <!-- リードとライトの並列数 --> <ConcurrentReads>8</ConcurrentReads> <ConcurrentWrites>32</ConcurrentWrites> <!-- CommitLog を同期する周期、periodic は一定期間ごとに、batch は明示的に CommitLog を書 き出す --> <CommitLogSync>periodic</CommitLogSync> <!-- periodic の場合の周期設定。 --> <CommitLogSyncPeriodInMS>10000</CommitLogSyncPeriodInMS> <!-- オブジェクトに GC の削除マーカーをつける時間 --> <GCGraceSeconds>864000</GCGraceSeconds> <!-- memtable の最大値( MB ) --> <BinaryMemtableSizeInMB>256</BinaryMemtableSizeInMB> 18
  19. 19. ○今回の設定 <storage-conf.xml.txt> を参照。 基本的には、どれがどのように働くか見るためと、機能検証を行うためまずデフォルト 値メインで設定している。 4. 機能検証 以下の項目について、機能検証を行う。 ・ クラスタ導入 ・ データ操作(投入、更新、削除) ・ ノード追加(とその後のデータの配置され方について) ・ バックアップ/リストア ・ 監視関連 ・ クラスタ導入 まず、本番サーバとして起動を行う。 ○Cassandra 起動(Daemon 起動) # su - cassandra $ cd /usr/local/apache-cassandra/bin $ vim /usr/local/apache-cassandra/bin/cassandra.in.sh # ヒープ領域を 3GB へとあげる $ diff /usr/local/apache-cassandra/bin/cassandra.in.sh.org /usr/local/apache- cassandra/bin/cassandra.in.sh 45c45 < -Xmx1G --- > -Xmx3G $ ./cassandra -p ./cassandra.pid まず、3台起動したらクラスタが組めているのかを確認。 19
  20. 20. $ ./nodeprobe -host localhost ring Address Status Load Range Ring 124039723817946554142311632841015584374 192.168.0.97 Up 0 bytes 54726667172133563740938363913892816149 |<--| 192.168.0.99 Up 0 bytes 85116141055809869248935675462381407463 | | 192.168.0.91 Up 0 bytes 124039723817946554142311632841015584374 |-->| このようにクラスタが組めていることがわかる。 ・ データ操作(投入、更新、削除) バックアップだが、SSTable のバックアップを JSON 形式で IMPORT/EXPORT するツール が用意されている 。 。 ・ データ操作(投入、更新、削除) データ操作用に cassandra-cli というコマンドラインツールが存在している。 20
  21. 21. $ $ ./cassandra-cli Welcome to cassandra CLI. Type 'help' or '?' for help. Type 'quit' or 'exit' to quit. cassandra> cassandra> get KsName1.CfByte1['test807837'] => (column=testdata1, value=807837, timestamp=1269433560) Returned 1 results. # データ取得 cassandra> get KsName1.CfByte1['test807837'] => (column=testdata1, value=807837, timestamp=1269433560) Returned 1 results. # データ書き込み .cassandra> set KsName1.CfByte1['testtest']['CfByte1'] = '123456' Value inserted. cassandra> get KsName1.CfByte1['testtest'] => (column=CfByte1, value=123456, timestamp=1269587633646) Returned 1 results. # データ上書 cassandra> set KsName1.CfByte1['testtest']['CfByte1'] = '1234567' Value inserted. cassandra> get KsName1.CfByte1['testtest'] => (column=CfByte1, value=1234567, timestamp=1269587649878) Returned 1 results. ・ ノード追加(とその後のデータの配置され方について) クラスタに存在しているサーバの追加も行ってみた。 まず、新しいサーバ 4 台目の storage-conf.xml を以下のように seed の設定に 4 台目 を追加してクラスタに参加させてみた。 21
  22. 22. $ vi ../conf/storage-conf.xml <Seeds> <Seed>cass-test01</Seed> <Seed>cass-test02</Seed> <Seed>cass-test03</Seed> <Seed>cass-test04</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 192.168.0.97 Down 1.5 GB 54726667172133563740938363913892816149 |<--| 192.168.0.99 Up 767 MB 85116141055809869248935675462381407463 | | 192.168.0.94 Up 1.47 KB 97147856872319332778007596849029295064 | | 192.168.0.91 Up 643.61 MB 124039723817946554142311632841015584374 |-->|  この結果から、すべてのサーバに対して seed の設定を行わなくとも Gossip 経由での 情報伝達が行われることがわかった。  追加検証としてその後に 100 万件のデータ追加をしてみてどのような動きをするか を確認してみた。 22
  23. 23. $ ./nodeprobe -host cass-test01 ring Address Status Load Range Ring 124039723817946554142311632841015584374 192.168.0.97 Up 1.9 GB 54726667172133563740938363913892816149 |<--| 192.168.0.99 Up 1.02 GB 85116141055809869248935675462381407463 | | 192.168.0.94 Up 120.55 MB 97147856872319332778007596849029295064 | | 192.168.0.91 Up 768.39 MB 124039723817946554142311632841015584374 |-->|  この結果を受けると、特にサーバを追加したことによりそのサーバに負荷が集中する ことはないが、今までのデータの再配置の様な物も行われないため、先に追加したサー バのキャパが先に枯渇する様なことがありうる。 ・ バックアップ/リストア SSTable を JSON 形式で IMPORT/EXPORT するツールが用意されている 。 。 ○バックアップ # su - cassandra $ cd /usr/local/apache-cassandra/bin $ ./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]], "test768227": [["746573746461746131", "373638323237", 1269433388, false]], "test784089": [["746573746461746131", "373834303839", 1269433462, false]], (snip) "test851643": [["746573746461746131", "383531363433", 1269433743, false]] } $ 23
  24. 24. ○リストア $ ./json2sstable -K KsName1 -c CfByte1 CfByte1-36-Data.json /var/lib/cassandra/data/KsName1/CfByte1-36-Data.db $ スクリプトなどは書く必要はあるだろうが、定期的にとる事は可能である。 考えうる問題は memtable 上にあるデータについての問題だろうが、noteprobe コマン ドで明示的に compaction の実行が行えるため、[アクセスの停止(方法は問わない)]- >[compaction 実行]->[SSTble のバックアップ]-> [アクセス再開]で実行可能である。 ・ 監視関連 現状の状態監視なども nodeprobe コマンドで行える。 リアルタイムの KeyName 事のクエリ数などの情報は、cfstat を使用、各スレッドの状 態遷移の統計を見たい場合は tpstat を使用する。 これらのツールを使用することで監視設定などに利用できると思われる。 24
  25. 25. ○cfstat # su - cassandra $ cd /usr/local/apache-cassandra/bin $ ./nodeprobe -host localhost cfstats Keyspace: system(これは cassandra のシステム領域用の KeySpace) (snip) ---------------- Keyspace: KsName1 Read Count: 0 Read Latency: NaN ms. Write Count: 559 Write Latency: 0.038 ms. Pending Tasks: 0 Column Family: CfByte1 Memtable Columns Count: 307 Memtable Data Size: 12894 Memtable Switch Count: 8 Read Count: 0 Read Latency: NaN ms. Write Count: 307 Write Latency: 0.032 ms. Pending Tasks: 0 Column Family: CfUTF82 Memtable Columns Count: 308 Memtable Data Size: 21252 Memtable Switch Count: 8 Read Count: 0 Read Latency: NaN ms. Write Count: 309 Write Latency: 0.049 ms. Pending Tasks: 0 ---------------- 25
  26. 26. ○tpstat # su - cassandra $ cd /usr/local/apache-cassandra/bin $ ./nodeprobe -host localhost tpstats Pool Name Active Pending Completed FILEUTILS-DELETE-POOL 0 0 1 MESSAGING-SERVICE-POOL 1 0 4395686 STREAM-STAGE 0 0 0 RESPONSE-STAGE 1 0 4114000 ROW-READ-STAGE 0 0 158 LB-OPERATIONS 0 0 0 COMMITLOG 1 0 1266183 GMFD 0 0 985576 MESSAGE-DESERIALIZER-POOL 0 0 4421666 LB-TARGET 0 0 0 CONSISTENCY-MANAGER 0 0 63 ROW-MUTATION-STAGE 0 0 1245215 MESSAGE-STREAMING-POOL 0 0 0 LOAD-BALANCER-STAGE 0 0 0 FLUSH-SORTER-POOL 0 0 22 MEMTABLE-POST-FLUSHER 0 0 22 COMPACTION-POOL 0 0 33 FLUSH-WRITER-POOL 0 0 22 AE-SERVICE-STAGE 0 0 0 HINTED-HANDOFF-POOL 0 0 80 5. 障害検証 ・ サーバダウン時のデータロスト ReplicationFactor が1の場合は、 台のサーバがダウンした時点で、 1 データのロスト がみとめられた。これはレプリケーションの設定が ReplicationFactor/2 + 1 = 1.5 の データを持つと言うことから、レプリケーションとしてもつデータの個数 の整数値部 分がデータの個数であると考えられる。 そこで ReplicationFactor を 2(2/2 + 1 = 2)にあげて再度テストしてみた結果、 台 1 26
  27. 27. のサーバダウンでもデータのロストは無くなった。 なお、ReplicationFactor が1の場合でもサーバの再起動により、クラスタに復帰し た後は正常に読み込むことが出来ていた。 6. 性能検証  簡易的な性能検証のとして、スクリプトを自作したもので、100 万件のデータの書き 込みを ・ 単一サーバ ・ 複数サーバ(2台) ・ 複数サーバ(3台) で行うものを作成して、台数でまともなスケールするのかどうかについてまとめてみ た。 並列数 読み込み(min) 書き込み(min) 1 97 m 127 min 2 52 m 28 min 3 17 m 22 min 図 8:実行時間 サーバ負荷に関しても CPU 負荷、IOWAIT も問題になる程度ではなかった。 項目 CPU USER CPU I/O SYS CPU I/O WAIT 値 10 % 10 % 5~10 % 図 9:CPU 負荷平均 27
  28. 28. 並列 1 並列 2 並列 3 図 10:CPU 負荷グラフ が、今回に関してはハードウェア等が実際に使用する物とはかけ離れているため、スケ ールするという部分の確認にとどめている。  総評  まずは Cassandra のサーバのアーキテクチャについての調査から入り、アーキテクチャ が想定どおり動くのであれば可用性も耐障害性もある。強固なリアルタイム性が求めら れない一般的な Web アプリケーションであればどこでも使用できる柔軟性もあると言う 印象を再認識した。 パフォーマンステストとしては、十分な物ではなかったが、台数でスケールするという 所と、耐障害性は確保されているのは確認できている。 今回はひとまずと言った形のテストに終始してしまったが、これから調査を進めてい き使用できそうなところには積極的に使用していきたい。 28
  29. 29.  疑問点  最後に今回の調査であがった疑問点に関してあげていく。  これらは今後調査していきたい。 1. 重複した ring Gossip を使用した情報伝達で下図にしめした構成はどの程度成り立つのか。 もしくはこのような構成をとる必要性があるか、ないか。   この場合ringAとringBの情報はやりとりされるのか? ringA ringB 図 11:重複した ring の構成 ->これはノード追加テスト時に ring の情報が伝達していることは確認できたので構成 自体はおそらく組める。有用かどうか(トラフィック分散などに役立つのか)は要追検 証。 2. Gossip CL が0の時などの、Network 遅延などの理由で同一 Version が出来た時の状況。 ->そもそもできるのか。 3. SSD の使用 読み込みはほぼメモリで、書き込み時の問題だけなのであれば SLC の SSD などを使用し た構成であればもう少しパフォーマンスが期待できるかもしれない。 4. FS 検討 29
  30. 30. xfs の方がよいと言う結果は出ている様だが、 を実装している ZFS、 CoW btrfs5、それ以外 でも ext4、などの FS を使用することでの変化6の検討。 5. HW 検討 今回調査した結果を元に、最適な構成7の HW で大規模な検証(負荷試験、大規模を想定し た構成検討)を行ってみたい。 6. クライアント側の分散実装 各サーバに同じように負荷がくる状態が理想的な状態なのは間違いない。 しかし見た限り kumofs で言う所の kumo-gateway 的な物はないため、分散実装をクラ イアント、サーバのレベルで行う必要がある。 他の事例などでどのような実装を行うべきか確認したい。 7. サーバ追加時のデータの再配置 今回の検証ではノード追加時にデータの再配置などは行われていなかった。これだと ノード追加に対してスケールしなくなるタイミングがでてしまう。 均一にデータを再配置する方法に関して調査する必要がある。  参考文献 ・ The Apache Cassandra Project 内のドキュメント ・ Apache-Cassanra-0.5.1 のソースコード 5 開発の今後が不安ではあるが 6 おそらく遅いと思われる 7 性能的にも、コストパフォーマンス的にも 30

×