#garagekidztweetz

#garagekidztweetz

id:garage-kid@76whizkidz のライフログ・ブログ!

Cassandra Summit JPN 2014 にいってきた(午後編)

スポンサーリンク

f:id:garage-kid:20140124230106p:plain

では、Cassandra Summit JPN 2014 にいってきた(午前編)に引き続いて、id:oranie さん@サイバーエージェントによる 100 node 運用の話が一番聞きごたえがあった 午後編です。

ほとんどこのイベントに関するツイートがなかったので、後日、各スピーカーの方がスライドを公開してくれるといいんですが、見つけられたら、そのスライドへのリンクを追記したいと思います。

id:oranie さんのスライドは、ご自身のブログでCassandra summit JPN 2014でスピーカーしてきました。 - iをgに変えるとorangeになることに気づいたoranieの日記 公開されていました- 2014-01-27 16:25 追記

では以降からが午後の各セッションのメモです。


会場 (A): Cassandra's Tunable Consistency (DataStax) 登壇者:Al Tobey (@Altobey) 氏

  • Apache Cassandra オープンソースエヴァンジェリスト
    • なぜ Cassandra を選ぶのか?
    • 日本には 1.4 億台の携帯電話、通信ができなくなるというのは大きなダメージとなる
    • インターネットは必要不可欠、日本では億を超えるユーザ
    • インターネットは眠らない 24/7
    • 一方でトラブルも常に起こっている
*****
  • オンラインシステムの概要
    • Client/Server 型、現在は陳腐化している (MWなし) じょうろ型のシステム
    • このパターンをみつけて避けるということがひとつの解決法
    • それに MW サーバを足し、 DB に slave を足し、 cache を足したりしていった
    • そして、 Cassandra のシステムの一般的なシステム構成の概要図 (図なので資料公開をみたい)
*****
  • Read-Modify-Write これはアンチパターン
    • 読んで、変更して、書くという方法
    • どんなテクノロジーでもトレードオフがある
    • これを分散処理でやろうとすると、整合性を保つのが大変むずかしい (Eventual Consistency)
  • Avoiding Read-Modify-Write (上記のアンチパターンをさけるためにできること)
    • Overwrites
    • Key/Value
    • Journal/Logging/Time-series
    • → 一番重要だと考えてる, bucket, partition の考慮が大切, UTC を使うこと, ntp が正しく機能していることを確認しておくことも大切。
    • Content-addresable-storage
    • Cassandra Collection Types
    • Cassandra Lightweight Transactions
  • それぞれの例をスライドで紹介
*****
  • In Practice
    • RMW is sometimes unavoidable
    • recent version of Cassandra supports RMW
    • Use them only when necessary
    • or when performance hit is
*****
  • Cassandra Collection の話
    • Nested Collection
    • Map を使った例
*****
  • Lightweight Transactions (速いかどうかよりもできるかどうかがまずは問題)
    • LWT based on Paxos
    • Paxos is a distributed consensus protocol
    • Given a constraint Cassandra ensure correct ordering
*****
  • Conclusion
    • Businesses are scaling furthur and faster than ever
    • Data models and apps architectures need to change to keep up
    • Avoiding Read-Modify-Write makes high performance easier
    • Cassandra excels at time-series and other write-mostly workloads
    • Cassandra provides tools for safe RMW when you need it
*****
QA
  • Is there any reason not much touch with Triggers in your story.
    • Trigger is still in bata. so currenct recommendation is not using triggers
*****
  • ファントムリード、ファジーリードについてはどうなっているか?
    • Transaction Isolation level issue.
    • SERIAL level をサポート

所感:

  • 個人的には、 Paxos について paper を読んでみようと思った。

    • SERIALIZABLE での実装をしているように聞こえた(SERIAL level をサポートと言ってたのがそういう意味なのかどうか…)が paper 読むのが速そう。

会場 (A): Cassandra100台クラスタを運用して (株式会社サイバーエージェント) 登壇者:oranie(成田 俊) 氏

スライドはこちら
  • 100 nodes cluster admin ops. admin 向け、 1.1 についてカバーする
  • スライド回しが速かったので、資料の公開を期待している
*****
  • 運用してるシステムについて
    • サイバーエージェントスマートフォンプラットフォーム
    • 今のシステムではサービス規模、データ量から Cassandra
  • パッチ当てて使ってる
    • 1.1.5-2 。 1.1.6 のバグにあたりたくなかったのでパッチをあてた
*****
  • 普段どんなことをやっているか
*****
  • 構築
    • chef + fabric + jenkins
*****
  • 監視
    • joklokia JMX 監視
    • push notification (im.kayaku.com)
  • トレンド監視
    • Proteus-monitor (cyberagent 製 OSS)
*****
  • Cassandra monitor
    • Opscenter (node 100 こえるとグラフを出しきれなくなる)
    • GrowthForecast + yohoushi (各ノードの細かいところをみたいときに)
    • Pending Checker (cyberagent の公式ブログにかかれてるらしい)
*****
  • Cassandra Ops (ただし 1.1 だということを了承してほしい)
    • nodetool cmd、これにかぎる
*****
  • 障害の対応
*****
  • バックアップ
*****
  • バッドノウハウ的なもの
    • node 復旧時に repair を実行した際の失敗例
    • なぞの JVM FUll GC
    • 連続稼働によるレイテンシの悪化→再起動しかない
    • 安定性の高い Disk を利用すべき理由→鬼の哭くシステムのスライドの話 これがCassandra
*****
  • ここが困るよ Cassandra
    • repair が重い + データの肥大が大きくなる
    • MySQL みたいな slow query log がない
    • nodetool の出力が微妙にバージョンによって変えられてしまった→自作のツールが動かなくなった
    • nodetool cfstat 、 JSON で出したりするオプションほしい
    • mysqldump みたいないっきにバックアップはとれない
*****
  • バッドノウハウから得た主観的なクラスタ設計
    • 1クラスタ 50 node (repair , node 追加の実行時間、バックアップなどを配慮)
    • 1node のデータ量 100-200GB (ops (repair + ... ) を考慮)
    • 1node 1CF 50GB でクラスタ分割を考えたほうがいいかも
    • wide row は NG (最大でも数十 MB におさめるように)
    • Cassandra の向くところ→アーカイブやヒストリ系なんじゃないか
*****
  • 今後やっていきたいこと
    • 2.0, 2.1 系への移行
    • NW topology strategy の導入
    • 監視系の統合 (netflix が出している各種ツールの検証をしてみたりしたい)
*****
  • 苦しいけど、いいところもたくさんあるよ、 Cassandra
    • 2.0 からは CQL が強化されたり
    • データ操作、 CAS 、 Lightweight Transaction
*****
  • 運用することは重々考えて Casssandra を使おう
*****
QA
  • replication factor 3
    • どれくらい同時にサーバが倒れたときのことを
    • simple strategy 。隣接ノードが 2 台以上おちないことを想定。 HW 障害ではそういうことはそうそう起きないだろうという想定。
*****
  • データ肥大化したときに Cluster 分割するのは?
    • node がふえるとバージョンアップが苦しくなる
    • サービスの運営スケジュール上、一回一回の作業が重くなってしまう
    • 1台では 5 分でも全体で 500 分とかになってしまう
*****
  • 1台あたり 350GB のデータ量
    • HW 障害時にリペアにどれくらいかかるか
*****
  • どういったデータをストアしているのか?
    • どこまでいっていいかわからないのでオフレコ
*****
  • ノード間の帯域がボトルネックになったことはあるか?
    • ボンディングで分散してるのでいまのところない
*****
  • FusionIO は?
    • FusionIO は使ってない。今のところそう効果はないだろうと disk IO で問題起きてないから。
*****
  • Gossip のところでタイムアウトがでることはあった
    • 聞き取りきれなかったがパラメタで回避したよう
*****
  • 長時間動くバッチはどんなバッチを動かしているのか?
    • あるユーザグループにたいする処理をちょくちょくやってると思ってもらえたら。

所感:

発表は時間の関係もあってか早回しだったので、ゼヒ、スライドをみて復習したい。 1.1 ベースの話ということだったが、かなり勉強になる内容だった。


会場 (B): CQL3 Data Modeling (DataStax) 登壇者:森下 雄貴 氏

  • ここ最近の Cassandra のテーマとして、開発者に使いやすくしたいというのがあるため、 CQL3 を紹介するプレゼンを今日はするとのこと。
  • 本来は compaction などの裏側を開発している。
*****
  • 二部構成
*****
  • Accessing Data Stored in Apache Cassandra
    • Thrift API (従来、いまも)
      • Not developer friendly
      • Too low level
      • hard to add new features (and maintain backward compatible)
    • CQL3
      • Cassandra Query Language Ver.3
      • SQL like.
      • CREATE INDEX
      • CREATE USER and GRANT/REVOKE
      • But
      • No JOINs
      • No subqueries
      • No aggregation, yet (but have a plan)
      • (基本的に High performance を目指しているので、 JOIN, SUBQUERIES は今後もサポートの予定はなし)
      • Built on top of Cassandra Storage Engine
      • (Storage Engine と CQL3 での名称の重複等を区別できるようにしていっている row を storage engine では partition と呼び変えるようにしたり)
*****
  • Try CQL3
    • cqlsh を使うことで簡単に使える (対話型)
    • カラムの色付け等もしてくれる
    • タブで自動補完もしてくれる
  • DataStax DevCenter (for free)
    • Windows User 向け
    • Query auto complete
    • Schema/Resultset browser
    • support both 1.2/2.0(limited functionality)
*****
  • Writting Apps Using CQL3 (modeling examples)
  • Example: the app, music app
    • users can browse/edit album info
  • Album info
    • sequence (mysql でいうと auto increment ) のようなものはないので、 app で自己実装する必要がある
  • Album info with tag
    • Cassandra は join はできないけど、テーブルを非正規化することで、ネストした情報をもてるようになる
    • ALTER TABLE album ADD tags set ;
  • Collections には 3 種類
    • set
    • list
    • map
    • ただし、
    • serialization が必要
    • No access to items in collection from CQL3. (ひとつひとつの collection の要素にはまだ CQL からはアクセスできない)
  • Play history の実装
    • Time-series data を使って実装
    • PK がキモ。
    • first part of PK become "partition key"
    • each event is a new "Cell" in a wide partition
  • Time-series Data
    • 1st part of PK is used to distribute data
    • Clustering column
    • Dont go to wide.
  • Play history - updated version
    • Use composite partition key to devide partition
    • Use CLUSTERING ORDER BY to specify order (昇順と降順のコントロールができるようになる)
  • Album Info Update
    • 2人以上がひとつの album 情報を更新してもいいような実装。
    • Lightweight Transaction (Use Paxos to ensure exclusive access)
  • Light Weight Transaction
    • 使い所は限られる。
    • 整合性を担保する分、当然遅くなる
    • Datastax のブログにジョナサン氏の書いた記事がある、詳細はそちらを
    • ジョナサン氏がいっていたとおり Paper があるので、そちらが一番詳しい
  • CREATE INDEX on collection
    • create index on keys instead for map type
    • key と value いずれかにしか現状 index ははれない
  • User-defined TYPEs
    • CREATE TYPE 文でつくれる
    • 実際につくった TYPE にデータをいれるときは JSON に似た syntax を用いることになる
*****
  • WrapUp
    • 一言で言えば、時代は CQL3 !
    • 是非、使ってください!
    • (ただし、パフォーマンスを出すためには、 Cassandra そのもののアーキテクチャの理解は必要)
*****
QA
  • CQL で count 文を実行すると、件数が多いと timeout になるんだが…
    • パーティションの中でのアクセスは速いが、またがると遅くなる
    • なかなか実はこれは難しいところ
    • 今の実装だとどうしてもスピードはでない
    • それに対するいい答えはない
    • Offline で MR のほうがいいかも
*****
  • column 指定してデータコピーするときも件数多いと timeout するんだが…
    • column を指定してもデータの格納の仕方としては同パーティション内になかったりする
    • いい方法がすぐに思いつかないので、質問をくれた方に直接いい案があれば連絡する
*****
  • Super Column は使わないほうがいい?
    • Super Column はもう存在しないと思ってもらった方がいい
*****
  • 例に出てきたテーブル設計に関する確認の質問
    • 聞き取れなかった
*****
  • Collection 型、 User 定義型、各要素に対する更新は Atomic に更新されるのか?
    • されなかったと思う
    • →調べて折り返す
*****
  • パーティションキーのレンジを先に決めてしまう
*****
  • conditional update はあるけど delete がないのはなぜか?
    • CQL3 の文法的なところでは実装はまだない
*****
  • pycassa はあまりメンテされてない

2014 年、最初の勉強会参加からなかなか濃ゆいものにでれました。 とりあえず、個人的には Paxos はまず Paper を読むだけ読んでみようと思っているのと、自社の環境で CQL3 とか少し触ってみようかな、といったところです。

では、今回はこんなところで。

関連記事