Suche senden
Hochladen
これがCassandra
•
Als PPTX, PDF herunterladen
•
82 gefällt mir
•
95,080 views
Takehiro Torigaki
Folgen
Diashow-Anzeige
Melden
Teilen
Diashow-Anzeige
Melden
Teilen
1 von 25
Jetzt herunterladen
Empfohlen
トランザクションをSerializableにする4つの方法
トランザクションをSerializableにする4つの方法
Kumazaki Hiroki
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行
Akihiro Suda
Cassandraのしくみ データの読み書き編
Cassandraのしくみ データの読み書き編
Yuki Morishita
本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話
Kumazaki Hiroki
Elasticsearchを使うときの注意点 公開用スライド
Elasticsearchを使うときの注意点 公開用スライド
崇介 藤井
PostgreSQL 15の新機能を徹底解説
PostgreSQL 15の新機能を徹底解説
Masahiko Sawada
Javaコードが速く実⾏される秘密 - JITコンパイラ⼊⾨(JJUG CCC 2020 Fall講演資料)
Javaコードが速く実⾏される秘密 - JITコンパイラ⼊⾨(JJUG CCC 2020 Fall講演資料)
NTT DATA Technology & Innovation
Unified JVM Logging
Unified JVM Logging
Yuji Kubota
Empfohlen
トランザクションをSerializableにする4つの方法
トランザクションをSerializableにする4つの方法
Kumazaki Hiroki
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行
Akihiro Suda
Cassandraのしくみ データの読み書き編
Cassandraのしくみ データの読み書き編
Yuki Morishita
本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話
Kumazaki Hiroki
Elasticsearchを使うときの注意点 公開用スライド
Elasticsearchを使うときの注意点 公開用スライド
崇介 藤井
PostgreSQL 15の新機能を徹底解説
PostgreSQL 15の新機能を徹底解説
Masahiko Sawada
Javaコードが速く実⾏される秘密 - JITコンパイラ⼊⾨(JJUG CCC 2020 Fall講演資料)
Javaコードが速く実⾏される秘密 - JITコンパイラ⼊⾨(JJUG CCC 2020 Fall講演資料)
NTT DATA Technology & Innovation
Unified JVM Logging
Unified JVM Logging
Yuji Kubota
インフラエンジニアのためのcassandra入門
インフラエンジニアのためのcassandra入門
Akihiro Kuwano
ツール比較しながら語る O/RマッパーとDBマイグレーションの実際のところ
ツール比較しながら語る O/RマッパーとDBマイグレーションの実際のところ
Y Watanabe
トランザクションの設計と進化
トランザクションの設計と進化
Kumazaki Hiroki
分散システムについて語らせてくれ
分散システムについて語らせてくれ
Kumazaki Hiroki
コンテナネットワーキング(CNI)最前線
コンテナネットワーキング(CNI)最前線
Motonori Shindo
スケールアウトするPostgreSQLを目指して!その第一歩!(NTTデータ テクノロジーカンファレンス 2020 発表資料)
スケールアウトするPostgreSQLを目指して!その第一歩!(NTTデータ テクノロジーカンファレンス 2020 発表資料)
NTT DATA Technology & Innovation
Metaspace
Metaspace
Yasumasa Suenaga
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
mosa siru
MongoDBが遅いときの切り分け方法
MongoDBが遅いときの切り分け方法
Tetsutaro Watanabe
Vacuum徹底解説
Vacuum徹底解説
Masahiko Sawada
PostgreSQL 12は ここがスゴイ! ~性能改善やpluggable storage engineなどの新機能を徹底解説~ (NTTデータ テクノ...
PostgreSQL 12は ここがスゴイ! ~性能改善やpluggable storage engineなどの新機能を徹底解説~ (NTTデータ テクノ...
NTT DATA Technology & Innovation
PlaySQLAlchemy: SQLAlchemy入門
PlaySQLAlchemy: SQLAlchemy入門
泰 増田
できる!並列・並行プログラミング
できる!並列・並行プログラミング
Preferred Networks
iostat await svctm の 見かた、考え方
iostat await svctm の 見かた、考え方
歩 柴田
冬のLock free祭り safe
冬のLock free祭り safe
Kumazaki Hiroki
ストリーム処理を支えるキューイングシステムの選び方
ストリーム処理を支えるキューイングシステムの選び方
Yoshiyasu SAEKI
IoT時代におけるストリームデータ処理と急成長の Apache Flink
IoT時代におけるストリームデータ処理と急成長の Apache Flink
Takanori Suzuki
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
Takafumi ONAKA
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行
Kohei Tokunaga
Java 18で入ったJVM関連の(やや細かめな)改善(JJUGナイトセミナー「Java 18 リリース記念イベント」発表資料)
Java 18で入ったJVM関連の(やや細かめな)改善(JJUGナイトセミナー「Java 18 リリース記念イベント」発表資料)
NTT DATA Technology & Innovation
Cassandraバージョンアップ&移設
Cassandraバージョンアップ&移設
Takehiro Torigaki
Elasticsearch as a Distributed System
Elasticsearch as a Distributed System
Satoyuki Tsukano
Weitere ähnliche Inhalte
Was ist angesagt?
インフラエンジニアのためのcassandra入門
インフラエンジニアのためのcassandra入門
Akihiro Kuwano
ツール比較しながら語る O/RマッパーとDBマイグレーションの実際のところ
ツール比較しながら語る O/RマッパーとDBマイグレーションの実際のところ
Y Watanabe
トランザクションの設計と進化
トランザクションの設計と進化
Kumazaki Hiroki
分散システムについて語らせてくれ
分散システムについて語らせてくれ
Kumazaki Hiroki
コンテナネットワーキング(CNI)最前線
コンテナネットワーキング(CNI)最前線
Motonori Shindo
スケールアウトするPostgreSQLを目指して!その第一歩!(NTTデータ テクノロジーカンファレンス 2020 発表資料)
スケールアウトするPostgreSQLを目指して!その第一歩!(NTTデータ テクノロジーカンファレンス 2020 発表資料)
NTT DATA Technology & Innovation
Metaspace
Metaspace
Yasumasa Suenaga
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
mosa siru
MongoDBが遅いときの切り分け方法
MongoDBが遅いときの切り分け方法
Tetsutaro Watanabe
Vacuum徹底解説
Vacuum徹底解説
Masahiko Sawada
PostgreSQL 12は ここがスゴイ! ~性能改善やpluggable storage engineなどの新機能を徹底解説~ (NTTデータ テクノ...
PostgreSQL 12は ここがスゴイ! ~性能改善やpluggable storage engineなどの新機能を徹底解説~ (NTTデータ テクノ...
NTT DATA Technology & Innovation
PlaySQLAlchemy: SQLAlchemy入門
PlaySQLAlchemy: SQLAlchemy入門
泰 増田
できる!並列・並行プログラミング
できる!並列・並行プログラミング
Preferred Networks
iostat await svctm の 見かた、考え方
iostat await svctm の 見かた、考え方
歩 柴田
冬のLock free祭り safe
冬のLock free祭り safe
Kumazaki Hiroki
ストリーム処理を支えるキューイングシステムの選び方
ストリーム処理を支えるキューイングシステムの選び方
Yoshiyasu SAEKI
IoT時代におけるストリームデータ処理と急成長の Apache Flink
IoT時代におけるストリームデータ処理と急成長の Apache Flink
Takanori Suzuki
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
Takafumi ONAKA
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行
Kohei Tokunaga
Java 18で入ったJVM関連の(やや細かめな)改善(JJUGナイトセミナー「Java 18 リリース記念イベント」発表資料)
Java 18で入ったJVM関連の(やや細かめな)改善(JJUGナイトセミナー「Java 18 リリース記念イベント」発表資料)
NTT DATA Technology & Innovation
Was ist angesagt?
(20)
インフラエンジニアのためのcassandra入門
インフラエンジニアのためのcassandra入門
ツール比較しながら語る O/RマッパーとDBマイグレーションの実際のところ
ツール比較しながら語る O/RマッパーとDBマイグレーションの実際のところ
トランザクションの設計と進化
トランザクションの設計と進化
分散システムについて語らせてくれ
分散システムについて語らせてくれ
コンテナネットワーキング(CNI)最前線
コンテナネットワーキング(CNI)最前線
スケールアウトするPostgreSQLを目指して!その第一歩!(NTTデータ テクノロジーカンファレンス 2020 発表資料)
スケールアウトするPostgreSQLを目指して!その第一歩!(NTTデータ テクノロジーカンファレンス 2020 発表資料)
Metaspace
Metaspace
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
MongoDBが遅いときの切り分け方法
MongoDBが遅いときの切り分け方法
Vacuum徹底解説
Vacuum徹底解説
PostgreSQL 12は ここがスゴイ! ~性能改善やpluggable storage engineなどの新機能を徹底解説~ (NTTデータ テクノ...
PostgreSQL 12は ここがスゴイ! ~性能改善やpluggable storage engineなどの新機能を徹底解説~ (NTTデータ テクノ...
PlaySQLAlchemy: SQLAlchemy入門
PlaySQLAlchemy: SQLAlchemy入門
できる!並列・並行プログラミング
できる!並列・並行プログラミング
iostat await svctm の 見かた、考え方
iostat await svctm の 見かた、考え方
冬のLock free祭り safe
冬のLock free祭り safe
ストリーム処理を支えるキューイングシステムの選び方
ストリーム処理を支えるキューイングシステムの選び方
IoT時代におけるストリームデータ処理と急成長の Apache Flink
IoT時代におけるストリームデータ処理と急成長の Apache Flink
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行
Java 18で入ったJVM関連の(やや細かめな)改善(JJUGナイトセミナー「Java 18 リリース記念イベント」発表資料)
Java 18で入ったJVM関連の(やや細かめな)改善(JJUGナイトセミナー「Java 18 リリース記念イベント」発表資料)
Ähnlich wie これがCassandra
Cassandraバージョンアップ&移設
Cassandraバージョンアップ&移設
Takehiro Torigaki
Elasticsearch as a Distributed System
Elasticsearch as a Distributed System
Satoyuki Tsukano
MapR アーキテクチャ概要 - MapR CTO Meetup 2013/11/12
MapR アーキテクチャ概要 - MapR CTO Meetup 2013/11/12
MapR Technologies Japan
事例で学ぶApache Cassandra
事例で学ぶApache Cassandra
Yuki Morishita
cassandra調査レポート
cassandra調査レポート
Akihiro Kuwano
Guide to Cassandra for Production Deployments
Guide to Cassandra for Production Deployments
smdkk
Jvm operation casual talks
Jvm operation casual talks
oranie Narut
Boston Viridis - Carxeda EnergyCore SoC (ARM Cortex A9) based cluster applian...
Boston Viridis - Carxeda EnergyCore SoC (ARM Cortex A9) based cluster applian...
Atsushi Suzuki
Meetup 2104 my_homenutanixce_mizuta
Meetup 2104 my_homenutanixce_mizuta
Yusuke Mizuta
Hadoopのシステム設計・運用のポイント
Hadoopのシステム設計・運用のポイント
Cloudera Japan
Db tech showcase 2016
Db tech showcase 2016
datastaxjp
Bind 9.8 feature overview
Bind 9.8 feature overview
Tomonori Takada
GPUアクセラレータと不揮発性メモリを考慮したI/O性能の予備評価
GPUアクセラレータと不揮発性メモリを考慮したI/O性能の予備評価
Koichi Shirahata
ビッグデータ×IoT時代のデータベースのアーキテクチャとメカニズムの比較
ビッグデータ×IoT時代のデータベースのアーキテクチャとメカニズムの比較
griddb
CPUの同時実行機能
CPUの同時実行機能
Shinichiro Niiyama
BOSTON Viridis for Hadoop by ELSA Japan
BOSTON Viridis for Hadoop by ELSA Japan
Atsushi Suzuki
Windows Azure の中でも動いている InfiniBand って何?
Windows Azure の中でも動いている InfiniBand って何?
Sunao Tomita
DNSキャッシュサーバ チューニングの勘所
DNSキャッシュサーバ チューニングの勘所
hdais
20171122 altair converge2017publish
20171122 altair converge2017publish
Hiroshi Tanaka
[db tech showcase Tokyo 2015] E35: Web, IoT, モバイル時代のデータベース、Apache Cassandraを学ぼう
[db tech showcase Tokyo 2015] E35: Web, IoT, モバイル時代のデータベース、Apache Cassandraを学ぼう
datastaxjp
Ähnlich wie これがCassandra
(20)
Cassandraバージョンアップ&移設
Cassandraバージョンアップ&移設
Elasticsearch as a Distributed System
Elasticsearch as a Distributed System
MapR アーキテクチャ概要 - MapR CTO Meetup 2013/11/12
MapR アーキテクチャ概要 - MapR CTO Meetup 2013/11/12
事例で学ぶApache Cassandra
事例で学ぶApache Cassandra
cassandra調査レポート
cassandra調査レポート
Guide to Cassandra for Production Deployments
Guide to Cassandra for Production Deployments
Jvm operation casual talks
Jvm operation casual talks
Boston Viridis - Carxeda EnergyCore SoC (ARM Cortex A9) based cluster applian...
Boston Viridis - Carxeda EnergyCore SoC (ARM Cortex A9) based cluster applian...
Meetup 2104 my_homenutanixce_mizuta
Meetup 2104 my_homenutanixce_mizuta
Hadoopのシステム設計・運用のポイント
Hadoopのシステム設計・運用のポイント
Db tech showcase 2016
Db tech showcase 2016
Bind 9.8 feature overview
Bind 9.8 feature overview
GPUアクセラレータと不揮発性メモリを考慮したI/O性能の予備評価
GPUアクセラレータと不揮発性メモリを考慮したI/O性能の予備評価
ビッグデータ×IoT時代のデータベースのアーキテクチャとメカニズムの比較
ビッグデータ×IoT時代のデータベースのアーキテクチャとメカニズムの比較
CPUの同時実行機能
CPUの同時実行機能
BOSTON Viridis for Hadoop by ELSA Japan
BOSTON Viridis for Hadoop by ELSA Japan
Windows Azure の中でも動いている InfiniBand って何?
Windows Azure の中でも動いている InfiniBand って何?
DNSキャッシュサーバ チューニングの勘所
DNSキャッシュサーバ チューニングの勘所
20171122 altair converge2017publish
20171122 altair converge2017publish
[db tech showcase Tokyo 2015] E35: Web, IoT, モバイル時代のデータベース、Apache Cassandraを学ぼう
[db tech showcase Tokyo 2015] E35: Web, IoT, モバイル時代のデータベース、Apache Cassandraを学ぼう
これがCassandra
1.
これがCasandra またの名を 鬼の哭くシステム
2.
今日話すこと • 2013年からのCassandraとの戦いの日々と 愚痴を淡々と語るだけです 過度な期待はしないでください
3.
システム構成 • Node数:97台 • サーバスペック 機器:Dell
R410、R420 メモリ:64GB CPU:16コア、24コア HDD:600GBx4 (RAID-10) 600GBx2(RAID-1)+SSD 512GB(RAID-0) • クラスタ数:1 • Cassandraのバージョン:1.1.5-2(独自バージョン) • KeySpace数:8 • ColumnFamily数:156
4.
運用状況とか Cluseter Writes Request:
32000/sec Cluseter Reads Request : 58000/sec 1 nodeあたりのデータロードサイズ 約200~230GB
5.
Cassandraの設定 • レプリケーションファクタ:3 データを配置するノード数の合計 • 一貫性レベル:QUORUM レプリカのあるノードの過半数から応答があった「最新」のデータ を返す •
ヒープ:8GB 8GBより少ないほうがよいらしい http://www.datastax.com/docs/1.1/operations/tuning#heap-sizing
6.
運用でよく使うコマンド ・nodetool compact 特定のkey space
やcolumn familyに対してcomapctionを実 行 ・nodetool repair 障害復旧時等にデータの修復を実行 ・nodetool cleanup tokenレンジが変わった際に不要なデータを削除する為に 実行 ・nodetool removetoken 停止中のノードをクラスタから取り除く
7.
バックアップ • nodetool snapshotで取得 •
8時間毎の差分スナップショットをローカ ルに保存 • 1-3-7…のNodeのスナップショットは バックアップサーバに定期コピー
8.
ここからは主に2013年に入ってか らあったことを語ります
9.
1月 ・CPU8コアサーバを24コアサーバに筐体交換(6台) → 筐体交換でデータの修復するためにrepair祭り → repairかけているNodeとその前後Nodeのデータが肥大しまく る (2~3倍くらいに膨れ上がる) 主に特定の1つのcolumn
familyが激増 ・肥大しまくっているデータをなんとか小さくしないとやばい 状態 → メジャーCompactionすれば容量が減ることが判明 → メジャーCompaction祭り ※このころのrepairは5時間くらいで終わっていた ※このころはメジャーCompactionは8時間くらいで終わっていた ※肥大しても1台あたりのロードデータは200GBくらいだった 肥大してない場合は100GB以下
10.
2月 2/8 85号機障害 → SSDがオフライン現象発 生 2/15 89号機障害 → SSDがオフライン現象発 生 →
HDDのみの筐体に変更 2/24 85号機障害 → SSD死亡 → HDDのみ筐体に変更 2/7 86号機障害 → SSDがオフライン現象発 生 → removetokenに3時間くら い 2/12 90号機障害 → SSDが死亡 → HDDのみの筐体に変更 2/16 86号機障害 → SSDがオフライン現象発
11.
2月 • バックアップサーバ(17TB)にスナップショット退避しまくってい たら容量が足らなくなる → 50TBのサーバ借りて助かる •
repairする→余計なデータ増えた状態 →メジャーコンパクションすれば消えたけど、その前に近隣ノードが 障害 →復帰して周囲が余計なデータ持っている状態でrepair →また余計なデータ増えるの繰り返しで1Nodeのロードデータが 700GB超えた。。。>< (特にでかいのは特定の1つだけ。本来はロードデータ100~200GB程 度のはずなのに。。) とにかく特定の1つだけがでかい。。 特定の1つだけのSSTableの容量が800GB近くある。。><
12.
2月 • 86-90レンジのノード全部のディスク容量が90%超えに。。>< 1回あたりの差分スナップショットの容量が300~400GBくらいに。。。>< (通常は数GBくらいなのに。。) • 86-90間のノードで同時並列でとにかくメジャーCompactionかけまくる メジャーCompaction祭り開催 ついでにCleanupもかけまくる ※このころはこのオペやっても問題なかった。。 •
87号機の特定の1つだけのメジャーCompactionが2日たっても終わらない現象発 生。。。 (他Nodeだとだいたい10時間くらいかかる。。) • 全台再起動やったらレンテンシがちょいちょい跳ねる現象発生。。。 • 実は特定の1つだけの過去データが消えてなかったことが判明。。 本来であれば1カ月以前のデータは自動で消えているはずだった。。orz アプリ側を修正してもらって、過去データはバッチで徐々に消してもらう。。。
13.
3月 • 1回暴れた以外は平和だった • 毎月恒例の全台再起動はやはりレンテンシ上 がる。。orz 1-4-7...の順番で1順やり 2-5-8...の順番で2順目やっていく方式 1順目は大丈夫なのに、2順目以降でレイテンシ がはねる。。。
14.
4月 04/01 89号機障害 → ボードとかのHW障害 → 筐体変更して復活 repairかけたら100GB増加する 処理終わるのに7時間かかる とにかくrepairしたら容量問題にぶちあたる。。。 04/04 86号機障害 →
SSD死亡 → HDDのみ筐体に変更
15.
4月 04/11 89号機、repair実行 → メモリリークで死亡 死ぬ前もモリモリFullGCしまくり FullGC入っても6GB超のメモリが開放されていない現象発生。。。 ここからFullGC祭りがはじまる。。 82号機障害(R410) → SSD死亡 バグフィックスしたパッチあてたバージョンに差し替えはじめ る (アプリ側に作ってもらった独自バージョン。世の中に出回っ てない)
16.
4月 04/16 89号機 → パッチあてたバージョンでもrepairで死亡 04/18 89号機が明らかにおかしなデータを持っている感じだった ので89号機のデータ消し去って、クラスタに組み込みなお す。 repairかける(翌日障害のトリガーになる)。
17.
4月 04/19 → 88号機応答なし障害 full gcで死亡 ※82号機で同じオペレーションしても障害はなかった 今度は90号機が応答なくなったので、再起動。。orz 87号機障害 →
SSD死亡 → HDDに差し替え 88号機が最後のR420+SSDとなる。。。
18.
4月 04/20 → 1:03 88号機メモリリークで障害 →
7:57 88号機メモリリークで障害 → 11:43 88号機メモリリークで障害 全部87号機のrepairがトリガー。。。 ヒープを 12GBにして回避する → 23:14 88号機障害(SSD死亡)→ HDDに変更 04/23 → 89号機メモリリークで障害 メジャーCompactionでふっとぶ。。。 4/24 → 87号機メモリリークで障害 メジャーCompactionでふっとぶ。。。
19.
4月 原因切り分け(特定レンジの問題なのかクラスタ全体の問題な のか)のため 63号機をデータ消して、クラスタに組み込みなおし、障害頻発 するレンジと同じオペレーション(repairやComapction)やって みる → 問題はおきなかった → メモリリークは後半レンジ特有問題と判明 あとついでにSSDからHDDに変更しておいた 全台をバージョンアップして再起動 ヒープも全台戻す (8GBより少ないほうがよいらしいので)
20.
5月 05/07 90号機メモリリークで障害 cleanupでふっとぶ。。 87号機(R420)を97号機(R410)と差し替えてみたが、メモリリーク 発生 OSと機種特有の問題ではないことがわかった。。 toke-1でJoinさせてからremoveをやったが、remove時間は変わらず。。 orz ノード障害への対処の推奨方法はtoken-1で新NodeをJoinさせてから障 害NodeをRemoveするのがよいらしい http://wiki.apache.org/cassandra/Operations_JP#A.2BMM4w.2FDDJlpxbszB4 MG5b.2FlHm- 97号機をrepair。。。(翌日障害のトリガーとなる。。。)
21.
5月 05/08 88,89号機メモリリークで障害 再起動しても復旧せず ヒープを12GBにして再起動で復旧 05/09-10 83-90の間に予備機7台をクラスタにJoinさ せてデータを分散させる
22.
今後 • バージョンアップする(1.2系へ) • クラスタを分割(でかいCFが負荷高いの で他に逃がしたい) •
検証(障害頻発環境を再現させてバー ジョンアップ等で改善するかと か。。。)
23.
Cassandraとの付き合い方 ・JIRAを読む! https://issues.apache.org/jira/browse/CASSANDRA 自分が使っているバージョンがどんな地雷踏む可能性があるか把握 しておくこと ・ソースを読む! ソースコードがマニュアルです ・なんかあったら再起動! 大抵これで直ります^^/ ・とにかく祈る! 暴れないように日々祈りをささげる
24.
最後に一言
25.
あなたはそれでも Cassandraを使いますか?
Jetzt herunterladen