cassandraの最近のブログ記事

ほぼ一年ぶりの更新になってしまいました。もう少し更新しないとですね。

さて、先日からCassandraSummit2013及びHBaseConに参加するためにサンフランシスコに来ています。
アメリカのイベントは活気があっていいですね。取り急ぎの初日の速報としてCassandraSummit2013の報告をしたいと思います。内容に関しては自分の英語にそれなりに難有りと思っていますので、認識違いがあると思います。ですので、後日公開されるビデオなどを参考にしてください。ビデオが公開されたら改めて確認して詳細を書きたいと思います。なお今年は2日間5トラック参加登録数1200人以上と有料カンファレンスにもかかわらず去年の800名を大幅に超え巨大なカンファレンスになっていました。全体的なトラックもビジネス寄りのものが増え参加者も年齢層が高めになった印象です。来年はどうなることやら。

  • 基調講演

  • CEOは今年は案内に徹していて余りぶっ放さなかったなという印象 CTOの基調講演は1.2の新機能と7月に出る予定の2.0の新機能のお話。 基本的にはすでに表沙汰になっている機能ばかりなので驚きは余りありませんでした。 TwitterにそのままメモしていたJonathanが語った内容に関しては以下の通り。

    各nosqlのパフォーマンス比較:HBaseやRedisなどとのパフォーマンス比較。
    CQL3の解説: Account Authorization:今までも簡易的には存在していましたが、アカウント認証がCreate User文で出来るようになりました。
    Native drivers : CQL3用のNativeDriverが続々作成されています。
    Cassandraのメモリの使い方:JVMヒープ以外のメモリにbloomfilterを展開してメモリの効率的に使用しています。
    Compaction throttling:Compaction時のIOの使用方法を調整して効率的な。
    Dse3:
    Casの話:Paxosプロトコルが実装されました。CQL3上でWhere句にif文を追加することにより条件分岐でUPDateが可能になりました。
    Triggerの話:

  • What were they thinking?

  • アクセンチュアの話 EnterpriseITを使うのかCassandraを使うのか?

    得ることを判断としますか?
    失うことを判断としますか?

    Cassandraを使うのはいつ?
    今でしょ?

    のお話。

    最初何が言いたいか解らずなんでこのセッションがここにあるのかなと思っていましたが 要約すると上記のとおりでした。内容に関しては近いうちに公開されるビデオを参照してみてください。 これはこれで面白いですよ。

  • Big Architectures for Big Data

  • DaaS(Data as a Service)のお話 SimpleReachのデータプラットフォームの設計方法、 ITアーキテクチャの概要など。 Cassandraのスキーマ設計が聞けるのかなと思っていたらちょっと違いました。 去年のDisneyもそうだったのですがやっぱりMongoと併用させてますよね。

  • Ground Traffic Control - Logistics with Cassandra

  • 壮絶に期待していたいのですが、前の自分の参加したセッションが押してしまい 5分遅れで行った処、15分しかプレゼンをしてくれなかったので10分程度しか聞けませんでした。 内容もCassandraの特徴とAWSの特徴を話していただけの印象が。 こちらはビデオ公開がされたら改めて内容を確認したいですね。

  • Real-time Analytics using Cassandra, Spark and Shark

  • CassandraでAnalyticsを行うためのプラットフォームの解説。 HiveQL互換の記述方法でCassandra上でアグリゲーションを行うのに有効ですとのこと。 SparkがMRフレームワークでSharkがその上で動くHive互換フレームワーク。 特徴としては中間ファイルをマテリアルビューとしてメモリ上に保持しているので バク速ですよとの事。ClouderaのImparaをどう考えるかがこのツールの肝のような気がしています。

  • Suicide Risk Prediction Using Social Media and Cassandra

  • 題名が題名だったので方法論などに期待していたのですがシステムアーキテクチャのお話でした。 これはこれで非常に重要なんですけどね。 一番大事な所はブラックボックスの中でゴニョゴニョと。そこが聞きたいのに。

  • Hardware Agnostic: Cassandra on Raspberry Pi

  • 今回もっともGeekよりの内容。結構動かすまでに苦労しますねという印象。 64ノードクラスターで$2,000とか32ノード作ったとか楽しいですね。 OracleJDKとOpenJDKでかなりの差がでたとのこと。 こういう話は楽しくてイイですね。 思わず日経さんからでたRaspberry Pi付きムックをそのまま注文してしまいました。再現実験は後日。

  • When Bad Things Happen to Good Data: A Deep Dive Into How Cassandra Resolves Inconsistent Data

  • リペアのお話。どのようにデータを復帰させているかや、ノード障害時のデータ整合性の担保の仕方を内部アーキテクチャを詳細に説明しながら解説してくれました。内部アーキテクチャに関して自分の勘違いしていた部分もあったりしたのでこのセッションはビデオが出次第改めて確認したいと思います。

取り急ぎの初日のレポートは以上になります。二日目もすぐに上げたいと思いますが明日帰国なので飛行機上でかけたらと思いますので今暫くお待ちください。

尚、次回のCassandra勉強会にてCassandra Summit 2013の報告会を行いたいと思いますのでもし良かったらご参加ください。申込は以下となります。

第26回Cassandra勉強会

参加お待ちしています。

昨日に引き続きCassandra Summitのレポートです。


Buy It Now, Cassandra at eBay
eBayにおけるCassandraの使用方法のレポートです。
ソーシャルシグナル(いいねボタンなど)のデータを直接投入しているしているとのことです。
このデータを使用してリアルタイムレコメンデーションを実現しているとのこと。
データモデルの提示もありかなり有効なセッションでした。


End-to-end Analytic Workflows with Cassandra
HadoopファミリーととCassandraを用いたアナリティクスの入門でした。
Cassandra + Oozie の話が興味深かったです。

Hastur: Open-Source Scalable Metrics with Cassandra (Noah Gibbs)
Cassandraを用いたモニタリングシステムの解説でした。
データ設計方法が詳細に語られていますでこれも参考になると思います。

Big Data at Disney

ディズニーにおけるデータ運用方法の全体像の報告です。
ディズニーのもつ全てのデータ、(ムービーやテレビ番組、ディズニーランドの情報など)を一元管理するための仕組みとのことです。「Data as a Sservice」という言葉がこの設計の壮大さを表しているなと。正直、激しく壮大な話なので直接的にこのセッションが参考になる所も少ないとは思いますがデータ活用方法の一つの局地としてみると非常に興味深かったです。

Changing the Game, Cassandra + Solr

普通にDataStaxEnterpriseにおけるSolrの使用方法でした。
(正直、Cassandraあまり関係ないやんというツッコミがなくも無いですが)
最近、業務絡みでDataStaxEnterpriseを調査しているのですがAll in one パッケージとして非常に優れていますのでとても有効なプロダクションであると思っています。


Technical Deep Dive: Data Modeling
かなり濃ゆいCassandraにおけるデータ設計方法の解説でした。
非常に役に立ちますのでCassandraを使用してみようとしている方はスライド及びビデオ必見です。自分も改めてもう一度見直す予定です。

セッション全体を通して実用例、モデリング方法、運用方法など色々な情報が詰め込まれており非常に楽しく且つ役に立つセッションが多かった印象です。ビデオも公開されているので、聞き逃したセッションもみておこうかなと考えています。

Summit終了後のAfter-party at Computer History Museumの様子はまた、明日書きます。

ほぼ一ヶ月たってしまいましたが先月参加したCassandraSummitの報告をしたいと思います。

因みに自分の英語はズタボロなので内容の正確性は保証できかねますのでそのあたりは差っ引いてください。

因みにCassandraSummit2012の様子はここから一部見ることが可能です。Cassandra Summit 2012 Presentations

参加して一番感じたのはアメリカでのCassandraの勢いです。

有料のカンファレンスに登録800名との事。大きなホテルのカンファレンスフロア全てを借りきって4トラックのセッションを一日埋める。すごいですね。

全体的な印象としては前日のプレカンファレンスに参加しても感じたのですがCassandraをアナリティクスに用いている場合が多いかなと。DataStaxEnterpriseを用いるだけでなく独自でもトラッキング情報をCassandraに放り込んで後で解析するなどです。また、DataStaxEnterpriseとCassandraの話がシームレスに交じるのでDataStaxEnterpriseをある程度知ってないと混乱するかもと思いました。
(SolrandraはCassandraの機能ではありません。)

アナリティクスは自分もそちらのほうが親和性高いかなとも感じますのでCassandra自身そちらの方に進むかもしれないなと感じています。

さて、自分が参加した参加したセッションに関してコメントしていきたいと思います。


KeyNote
オープニングが和太鼓から始まって多少面食らいましたがなかなか楽しかったですね。
異国で見る和の雰囲気はなんか嬉しいです。

Billy Bosworth(DataStax CEO)

盛大にHBaseをディスっていて楽しかったです。(笑)
先日行われたHBaseConは600人しか集められなかったけどCassandraSummitは800人集めたぜハッハーとか、ビジネスにおけるパイの大きさが全然違うぞとかなどなど。
HBaseConを見ていないので本当の所はわかりませんがこの辺にも勢いを感じました。



Jonathan Ellis(DataStax CTO)

JonathanのKeyノートは普通にDataStaxEnterpriseの宣伝でしたね。Cassandraの内容が半分とDataStaxEnterpriseの内容が半分でその境目がシームレス。これは誤解を生むようなと感じました。内容としては1.2で導入予定のバーチャルノードやJBODが気になりましたね。Cassandraは高性能のハードで運用するとリソースを使い切れないのが現状なので擬似的に複数ノードに分けることによりハードウェア性能を使いきろうという考えです。JBODに関しては現行のCassandraが複数台のハードディスク搭載していてもその一本が飛ぶことによりノードダウンと同じ状態になるので全てのディスクを束ねてRAID0にする方が良いという本末転倒な状況だったのでその対応が入ったというのは大きいと思います。


We Messed Up, So You Don't Have to (Jason Brown, Ed Capriolo, Matt Dennis, Matt Pfeil)

使用者による運用に関するトークセッションです。
先日Cassandra勉強会でもお話ししていただいたJason Brownさんが参加されるので半分会いに行くという目的もあったのですが内容としては、正直自分の英語力では少し厳しかったです。このセッションの為に公開ビデオを待っていたくらいです。結構細かいCassandraの運用Tipsが盛り込まれているのでビデオは割と必見かもしれません。自分も改めて見なおしています。

 

続きはまた明日書きます。

現在、Cassandra Summit 2012に参加するためにサンタクララに来ています。 明日が本番当日なのですが今日は無謀にもpre-conferenceに突入してきました。

ここまで英語が拙いにも関わらずお話に
お付き合いいただいたエンジニアには感謝感激です。
(しかも帰りのタクシーの呼び方が解らなかったから呼んででもらってしまいました。)

嬉しいことにアメリカのCassandra熱は日本と違ってかなり高いですね。
明日のCassandra Summit 2012には800人もエントリーしているとのことです。

話を色々聞いてみて結構アナリティクスに利用している人が多い感じがしました。
やっぱりそういった方向に走っているのかなぁ。

恥も外聞も捨てて突入してみるとやはり収穫は大きいですね。
嬉しい限りです。でももう少し英語を勉強しないと。
(半年間この為に英会話学校に通っていたりしたのですが。
くそ度胸がついたのだけは収穫かもです。)

明日は再度詳細をリポートします。

 

 

O'reilly Japan 「Cassandra」を訳者の一人である小林さんより献本頂きました。
御礼申し上げます。

日本語唯一と行っていいほどのCassandraの底本です。


そもそもCassandraはドキュメントそのものが少なく、更に日本語情報となると
更に 輪をかけて減ってしまうため、まとまった日本語資料に当たることは
難しいのですが、とりあえずこれからCassandraを使おうと思う、もしくは
Cassandraの運用を行う必要があり情報に当たりたいと思う方は必携の書と思います。


章立てとしては各章が独立しており後から字引替わりの参考資料としても使えます。
これからCassandraを始める人であれば1章、3章、7章、8章、13章、付録Aは必読、
現在Cassandraを使用していて困っている人であれば、7章、9章、(10章※1)、11章が
必読になると思います。
※110章に関しては基本的にツールの実態が事実上JMXを叩いているだけなので
9章を理解していればそれほど必要にはなりません。


ただ、本書における注意点があります。
Cassandraのバージョン更新が早いのと翻訳元の底本がでた時期がかなり前であることも
影響しているのですが、各章に於いてそれぞれどのバージョンベースのものかが記載されていません。
底本の関係により0.6系をベースに記述されている部分も多くあります。
さすがに現状0.6系を選択することも無いと思いますので、実際に操作する際には内部実装が
かなり変わっている部分も多いので注意する必要があります。
(例えば、運用を開始して必ず立ちはだかるStream関連は、各バージョンごとに
かなり実装が異なるため運用の手順も異なります。)


ちなみに0.7系、0.8系、1.0系は外部インターフェースはそれほど変更されていないので
アプリケーションの移行はそれほど大変ではないのですが、内部実装が激変しているので
DBA系の運用者は特に注意が必要です。
残念ながら内部実装のまとまったドキュメントは現状無いため自力で対応していくより
他無いのですが、それ以外の部分は綺麗にまとまった本書が非常に大切になると思います。


軽くCassandraに触れてみたい人も、がっつりCassandraに触れてみたい人も
ぜひ手にとって読んでみてください。

尚、内部実装とがっつり取っ組みあってみたい人はCassandra勉強会に
来てみてください。 割と内部実装のお話していたりします。
次回は1.0系のCompactionに取り組む予定です。

Twitterの方では流しましたがfluent-plugin-cassandraをリリースしました。

FluentとはTreasureDataの古橋さんが作成されたプラガブルなイベントログ収集ツールです。

自分も、ログ収集ツールを探していて、flumeにするかscribeにするかなど悩んでいたのですが

flumeは重いし面倒だし、scribeは敷居高いし面倒だしなどピンとこない状態が続いていました。

Cassandraにデータを入れたかったのもあって接続が大変というのもありました。

そこに丁度という感じで先日Fluentが発表されてこれは良いなと感じたわけです。

発表の場にいたので、Cassandraのプラグインは?と聞いてみたのですが書いてーとの返事だったのでこれはやるしか無いかなと。

Python使いとしてはrubyは結構遠くて手こずりましたがどうにか公開にこぎつけました。

書き方が悪いとかそういうツッコミは直接いくらでもください。rubyのお作法解らないし。

github からかもしくは

gem install fluent-plugin-cassandra

でどうぞ。

尚、構造としては受け取ったJSON毎にそのままCassandraのColumnFamilyに流し込んでいます。

ですのでJSONの構造は単純なKey-Valueのペアか、SuperColumnFamilyを作成して

二元ハッシュにしてください。キーはイベントタグにイベント取得時間を単純にくっつけていkeyにしています。

想定としてはイベントをCassandraに放り込んだ後に上にbriskを乗せるですかねぇ。(要するに後からマップ・レデュースで解析)

apache-cassandraインストール

環境としては以下を使用。


OS:Debian Lenny on Xen 3.4.3
準仮想環境にてDom0に1G割り当て
DomUのメモリを1024MBに。
(DomUのメモリを512Mに制限したらCassandraがまともに起動しませんでした。)

ベースHW
Intel CoreDuo 2core 1CPU
メモリ6G

   1. 環境設定
          * JDKインストール
          * antインストール
          * JSVCインストール
      cassandraをインストールするにあたってソースからビルドする為の2つのパッケージと起動用に一つのパッケージが必要となるためこれらをインストールします。

      $sudo apt-get install sun-java6-jdk
      $sudo apt-get install ant
      $sudo apt-get install jsvc

      ※趣味的な問題で non-free の sun-javaを使用していますが通常のopenjdk-6-jdkで問題無いと思います。


   2. cassandraのビルド
          * ソース取得
          * 展開
          * ビルド
          * jar作成
      apache cassandraソースの取得
      0.7を取得。近々0.7がリリースされるそうです。(でもまだRC2)

      $wget http://www.ring.gr.jp/archives/net/apache/cassandra/0.7.0/apache-cassandra-0.7.0-rc2-src.tar.gz

      ソースの展開

      $tar xvfz ../src/apache-cassandra-0.7.0-rc2-src.tar.gz

      ビルド
      ソースのビルドを行います。

      $cd apache-cassandra-0.7.0-rc2-src
      $ant

      jar 作成
      jar ファイルを作成します。

      $ant jar

   3. インストール
          * インストール
          * 起動設定
          * 起動確認
      インストール
      ビルドした各ファイルを各ディレクトリに配置。
      make installなんてないので自力で配置。
      debianの場合、配置の場所がdebian/cassandra.installに
      あるのでこれを元に以下の様なシェルを書いてみました。
      cassandra.install.sh

      #!/bin/sh
      mkdir -p /usr/share/cassandra
      mkdir -p /etc/cassandra
      cp -ipr conf/cassandra.yaml /etc/cassandra
      cp -ipr conf/cassandra-env.sh /etc/cassandra
      cp -ipr debian/cassandra.in.sh /usr/share/cassandra
      cp -ipr bin/cassandra /usr/sbin
      cp -ipr bin/cassandra-cli /usr/bin
      cp -ipr bin/nodetool /usr/bin
      cp -ipr bin/clustertool /usr/bin
      cp -ipr bin/json2sstable /usr/bin
      cp -ipr bin/sstable2json /usr/bin
      cp -ipr bin/sstablekeys /usr/bin
      cp -ipr bin/schematool /usr/bin
      cp -ipr lib/*.jar /usr/share/cassandra
      cp -ipr build/apache-cassandra-0.7.0-rc2-SNAPSHOT.jar /usr/share/cassandra/apache-cassandra-0.7.0-rc2.jar
      cp -ipr lib/licenses /usr/share/doc/cassandra
      cd /usr/share/cassandra
      ln -s apache-cassandra-0.7.0-rc2.jar apache-cassandra.jar
      chmod 755 /usr/sbin/cassandra
      chmod 755 /usr/bin/cassandra-cli
      chmod 755 /usr/bin/nodetool
      chmod 755 /usr/bin/clustertool
      chmod 755 /usr/bin/json2sstable
      chmod 755 /usr/bin/sstable2json
      chmod 755 /usr/bin/sstablekeys
      chmod 755 /usr/bin/schematool
      chmod 755 /etc/init.d/cassandra

      起動設定
      起動スクリプトの修正
      debianの場合基本的にdebian/initの起動シェルがそのまま使えるので
      これを流用しています。(0.6の頃手動修正していた箇所が殆ど治っていて素敵。)
      一ヶ所だけ修正しています。(IPv4強制設定)

      *** cassandra   Wed Dec 22 10:34:26 2010
      --- /home/works/build/apache-cassandra-0.7.0-rc2-src/debian/init        Tue Dec  7 02:28:07 2010
      ***************
      *** 123,129 ****
                -errfile "&1" \
                -outfile /var/log/$NAME/output.log \
                -cp `classpath` \
      -         -Djava.net.preferIPv4Stack=true \
                -Dlog4j.configuration=log4j-server.properties \
                $JVM_OPTS \
                org.apache.cassandra.thrift.CassandraDaemon
      --- 123,128 ----

      設定ファイルの変更     

      設定ファイルがyamlに変更になっています。
      人として見やすくなったと思うかは分かれると頃かなと。
      個人的にはyamlは結構好きです。
      デフォルトからの変更箇所は以下のとおりです。

      $vim /etc/cassandra/cassandra.yaml


      クラスター名:ノード認識の要なのでわかりやすい用に。
                  別段デフォルトのままでも構いませんが。
      cluster_name: 'Intheforest Cluster

      オートブートストラップ:起動時にデータのリバランシングを行うか。
                            クラスターに突っ込むのでtrueに変更しています。
                            単体ではいりません。
      auto_bootstrap: true

      データファイルディレクトリ:データストア用のディレクトリです。
                                任意の場所に。
      data_file_directories:
          - /db/cassandra/data

      コミットログディレクトリ:コミットログ用のディレクトリです。
      commitlog_directory: /db/cassandra/commitlog

      キャッシュ保存ディレクトリ:キャッシュ保存用です。
      saved_caches_directory: /db/cassandra/saved_caches

      検索ノード:最初にゴシップを投げる会話相手です。
                 クラスターに突っ込む為変更しています。
      seeds:
          - 192.168.1.12

      Cassandra通信アドレス:Cassandraのノード間通信用のListenAdressです。
      listen_address: 192.168.1.13

      RPCの接続アドレス:Thrift通信用のListenAdressです。
      rpc_address: 192.168.1.13

      keyspaces以下:別ファイルに保存後、削除

      ※ 単体運用を行う限りデフォルトから変更が必須な物は無いので
         そのままでよい方はそのままで。

      $mkdir -p /db/cassandra/commitlog
      $mkdir -p /db/cassandra/data
      $mkdir -p /db/cassandra/aved_caches

      init設定
      OS再起動時に自動で立ち上がるように起動設定を行います。

      # update-rc.d cassandra defaults
       Adding system startup for /etc/init.d/cassandra ...
         /etc/rc0.d/K20cassandra -> ../init.d/cassandra
         /etc/rc1.d/K20cassandra -> ../init.d/cassandra
         /etc/rc6.d/K20cassandra -> ../init.d/cassandra
         /etc/rc2.d/S20cassandra -> ../init.d/cassandra
         /etc/rc3.d/S20cassandra -> ../init.d/cassandra
         /etc/rc4.d/S20cassandra -> ../init.d/cassandra
         /etc/rc5.d/S20cassandra -> ../init.d/cassandra

      起動スクリプトから起動

      #/etc/init.d/cassandra start


      起動確認

      $cassandra-cli --host 192.168.1.6
      Connected to: "Intheforest Cluster" on 192.168.1.6/9160
      Welcome to cassandra CLI.

      Type 'help;' or '?' for help. Type 'quit;' or 'exit;' to quit.
      [default@unknown]      


      以上が表示されればOK 表示されない場合、接続できない場合は
     「/var/log/cassandra」にある「output.log」「system.log」を確認。


ブログを書くまでが勉強会です。
とどなたかが言ったのでblogを書くまでやってみます。

 

本日はCasanndra勉強会を開催してきました。
本当は自分は今日はスピーカではなくて裏方周りのUst担当をしようかなと
思っていたのですが、本日急に本来のスピーカーが参加できなくなり急遽自分が
発表することになりました。結局機材もない、何より実況用のPCが発表に
使われることもありUstは中止。期待していた方済みません。

本日話してきた内容はCassandraの構造シリーズから「ConsistencyLevel」
局所的な話では合ったのだけれども質疑応答も含めて
色々濃い話ができて楽しかったです。一応発表したスライドを載せておきます。

次回は6/3を予定しています。
詳細が決まり次第告知しますのでよろしくお願いします。

とりあえずやってみたレベルでしたのでつたない部分も多かったかと思いますが
自分自身楽しめたのでよかったとします。
また次回よろしくお願いします。


複数の書き込みに対応する環境を作る。


「複数ノード立ち上げたApache Cassandraの環境にて
どのようにデータを分割するか?」
という問いに対しては

「基本的によしなにしてくれるのであまり意識しなくてもよい。」
との回答になります。

つまりはどのノードに繋いでも変わらないとということです。

Cassandraがリクエストを必要に応じてプロキシしてくれるので
「最終的に」しかるべき場所に格納してくれるという動きをしてくれます。

極端な話、接続先のノードを一つに絞ってすべてのリクエストを
そこに集中させると言う方法もありです。

もっとも、そのままそのアクセスポイントが
SPF(Single Point of Failure/シングルポイント障害)に
なってしまいます。

この点に関して、Apache Cassandraでは以下の四つの方法を提示してくれています。

  1. クライアントにおいて接続先を管理し適切な接続ノードに振り分ける。
  2. 要するにアプリケーションを作り込めと言うことですね。

  3. DNSラウンドロビンを使う。
  4. 接続先をFQDNで管理し同一名に複数のIPを割り当て特定のFQDNにアクセスさせる方法を使用する方法です。
    Cassandraはこの方法を推奨しています。ただ、DNSラウンドロビンは負荷分散としては機能的に足りない所が多いので
    自分はお勧めしません。(致命的なのが接続先ノードのステータスを管理しないこと。)

  5. ThriftのAPI、client.get_string_propertyを使用してCassandraノードからノードリストを取得する。
  6. このAPIを使うとこんなJSONが帰ってきます。

    {
    "72360816833403413813516172818645147903":"192.168.1.104",
    "53716703941129153059732412441632990819":"192.168.1.6",
    "4368941974377008489670679703283346037":"192.168.1.106",
    "123621947362397555094783433836216926846":"192.168.1.108"
    }
    レンジとIPですね。これを使って振り分けるアプリケーションを作るとの事です。
    やはりノードのステータスを見ていないので自分としてはお勧めしません。

  7. ロードバランサやプロキシを使う。
  8. LVSなどですね。Thriftのポート(デフォルト:9160)に対するセッションを捌けばよいのでわりと楽かなと。



という訳でLVSを使用した負荷分散環境を構築してみました。
イメージはこんな感じです。

lvs.png

4台ノード構成の真ん中にLVSサーバを挟んでいます。
LVSはわざわざNATにする必要もないのでDR(Direct Routing)を使用。
設定はkeepalivedを使用しています。

とりあえずはaptでkeepalivedとlvsadminをインストールします。
/etc/keepalived/keepalived.confの設定は以下の通り

 

virtual_server_group csdr9160 {
  192.168.1.105  9160
}

virtual_server group csdr9160 {

  delay_loop  3
  lvs_sched   lc
  lvs_method  DR
  protocol TCP

  real_server  192.168.1.6  9160 {

    weight 1
    inhibit_on_failure

    TCP_CHECK {
      connect_port 9160
      connect_timeout 30
    }
  }


  real_server  192.168.1.104  9160 {

    weight 1
    inhibit_on_failure

    TCP_CHECK {
      connect_port 9160
      connect_timeout 30
    }
  }

  real_server  192.168.1.106  9160 {

    weight 1
    inhibit_on_failure

    TCP_CHECK {
      connect_port 9160
      connect_timeout 30
    }
  }

  real_server  192.168.1.108  9160 {

    weight 1
    inhibit_on_failure

    TCP_CHECK {
      connect_port 9160
      connect_timeout 30
    }
  }
}

本来であればVRRPを使用して複数台立てるのが正しいのですが、単純に箱がなかったので単体構成です。

各ノードで

#iptables -t nat -A PREROUTING -d 192.168.1.105 -j REDIRECT

を実行しLVSのDRが稼働するようにします。
これで負荷分散環境は整いました。192.168.1.105:9160をた叩けば任意の
cassandraノードに書き込んでくれるようになりました。


ようやく準備が整いました。次回以降検証を行っていきたいと思います。
次はConsistencyLevelの検証を予定です。

 

間が開いてしまいましたが引き続き複数ノードの話を書いていきたいと思います。
※この間、0.6はbetaからリリースにステータスが変わりました。
さっくり入れ替えてみましたが今のところ単純にバイナリ入れ替えで問題は出ていません。

cassandraを複数ノードで立ち上げる為、「storage-conf.xml」を以下の設定に変更しました。

簡単に解説をつけていきたいと思います。
複数ノード可に関連して変更した箇所は赤色で表示します。
青色はそれ以外の為の変更です。

<Storage>


<ClusterName>Intheforest Cluster</ClusterName> ----------------(1)
<AutoBootstrap>true</AutoBootstrap>----------------------------(2)


<Keyspaces>
<Keyspace Name="TimeStampSimpleTrees">
<ColumnFamily Name="SimpleTrees" CompareWith="BytesType" />
<ColumnFamily Name="SimpleTree-node"
ColumnType="Super"
CompareWith="BytesType"
CompareSubcolumnsWith="BytesType" />


<ReplicaPlacementStrategy>
org.apache.cassandra.locator.RackUnawareStrategy
</ReplicaPlacementStrategy>
<ReplicationFactor>1</ReplicationFactor>
<EndPointSnitch>org.apache.cassandra.locator.EndPointSnitch</EndPointSnitch>

</Keyspace>
</Keyspaces>

<Authenticator>
org.apache.cassandra.auth.AllowAllAuthenticator
</Authenticator>
<Partitioner>org.apache.cassandra.dht.RandomPartitioner</Partitioner>
<InitialToken></InitialToken>

<CommitLogDirectory>/db/cassandra/commitlog</CommitLogDirectory>
<DataFileDirectories>
<DataFileDirectory>/db/cassandra/data</DataFileDirectory>
</DataFileDirectories>


<Seeds>
<Seed>192.168.1.104</Seed>-----------------------------(3)
<Seed>192.168.1.106</Seed>
<Seed>192.168.1.107</Seed>
</Seeds>


<RpcTimeoutInMillis>10000</RpcTimeoutInMillis>
<CommitLogRotationThresholdInMB>128</CommitLogRotationThresholdInMB>


<ListenAddress>node1</ListenAddress>-----------------------------(4)

<StoragePort>7000</StoragePort>


<ThriftAddress>0.0.0.0</ThriftAddress>-----------------------------(5)

<ThriftPort>9160</ThriftPort>
<ThriftFramedTransport>false</ThriftFramedTransport>



<DiskAccessMode>auto</DiskAccessMode>
<RowWarningThresholdInMB>512</RowWarningThresholdInMB>
<SlicedBufferSizeInKB>64</SlicedBufferSizeInKB>
<FlushDataBufferSizeInMB>32</FlushDataBufferSizeInMB>
<FlushIndexBufferSizeInMB>8</FlushIndexBufferSizeInMB>
<ColumnIndexSizeInKB>64</ColumnIndexSizeInKB>
<MemtableThroughputInMB>64</MemtableThroughputInMB>
<BinaryMemtableThroughputInMB>256</BinaryMemtableThroughputInMB>
<MemtableOperationsInMillions>0.3</MemtableOperationsInMillions>
<MemtableFlushAfterMinutes>60</MemtableFlushAfterMinutes>

<ConcurrentReads>8</ConcurrentReads>
<ConcurrentWrites>32</ConcurrentWrites>

<CommitLogSync>periodic</CommitLogSync>
<CommitLogSyncPeriodInMS>10000</CommitLogSyncPeriodInMS>

<GCGraceSeconds>864000</GCGraceSeconds>
</Storage>

 

(1):ClusterName:
クラスター識別用の名前。このクラスターネームが同じCassandraノードが存在した場合、対象ノードをクラスタの一員として認識します。同一ネットワークにあるクラスタ名が同じクラスタノード間でデータの共有を行います。

(2):AutoBootstrap:
起動時の同一クラスター内のデータ同期を行うかどうかの設定。trueに設定してあると起動時に自動的にデータの同期を開始します。トークンを指定していない場合はトークンもよしなにしてくれます。注)一番最初にクラスタを作成する際にすべてのノードのAutoBootstrapをtrueにしているとお互いにデータを取得しにいくのでノードが立ち上がりません。最初の一代目はマスターノードとしてfalseにするのが正しいようです。

(3):Seeds:
起動時に検索しに行くクラスターノードのIPアドレス。ringの形成には影響無いようです。複数指定可。

(4):ListenAddress:
外部とのやりとりを行うため外部から検索可能なIPに紐付けられている正引きできるホスト名。IPアドレスでも構わないのですがホスト名を指定する方が望ましいようです。デフォルトはループバックアドレスに紐付けられているlocalhost。今回は自分のホスト名を自分のアドレス「192.168.1.6」として「/etc/hosts」に書いて指定する方法を選択。正引きできればDNSでも可。

(5):ThriftAddress:
Thriftアプリケーションが外部から接続する際にその接続元を指定するアドレスを記述。デフォルトは自分自身以外からは受け付けない「localhost」。今回はどこからでも接続出来るように「0.0.0.0」を指定。

 

その他、データディレクトリとデータ構造は変更しています。このstorage-conf.xmlを用いて起動します。

起動環境は前回の手順を参照、複数ノードの起動手順としては次の通り

1.1ノード目の/etc/cassandra/storage-conf.xmlを書き換える。但し「AutoBootstrap」は「false」。

2.1ノード目を起動スクリプトで起動。

3.2ノード目の/etc/cassandra/storage-conf.xmlを書き換える。「AutoBootstrap」は「true」。

4.2ノード目を起動スクリプトで起動。

5.3ノード目の/etc/cassandra/storage-conf.xmlを書き換える。「AutoBootstrap」は「true」。

6.3 ノード目を起動スクリプトで起動。

7.4ノード目の/etc/cassandra/storage-conf.xmlを書き換える。「AutoBootstrap」は「true」。

8.4 ノード目を起動スクリプトで起動。

9.1ノード目のcassandraを停止。

10.1ノード目の「AutoBootstrap」を「true」に書き換える。

9.1 ノード目を起動スクリプトで起動。

これで無事同期が始まります。
しばらくすると下のようにリングが確認できるようになります。

$ nodetool --host 192.168.1.104 ring
Address Status Load Range Ring
123621947362397555094783433836216926846
192.168.1.106 Up 21.06 MB 4368941974377008489670679703283346037 |<--|
192.168.1.6 Up 10.33 MB 53716703941129153059732412441632990819 | |
192.168.1.104 Up 3.85 MB 72360816833403413813516172818645147903 | |
192.168.1.108 Up 10.54 MB 123621947362397555094783433836216926846 |-->|

ウェブページ