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 のほうがいいかも

＊＊＊＊＊