Suche senden
Hochladen
これがCassandra
•
82 gefällt mir
•
95,053 views
Takehiro Torigaki
Folgen
Melden
Teilen
Melden
Teilen
1 von 25
Jetzt herunterladen
Downloaden Sie, um offline zu lesen
Empfohlen
Redisの特徴と活用方法について
Redisの特徴と活用方法について
Yuji Otani
分散システムについて語らせてくれ
分散システムについて語らせてくれ
Kumazaki Hiroki
マルチテナントのアプリケーション実装〜実践編〜
マルチテナントのアプリケーション実装〜実践編〜
Yoshiki Nakagawa
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行
Kohei Tokunaga
こわくない Git
こわくない Git
Kota Saito
コンテナの作り方「Dockerは裏方で何をしているのか?」
コンテナの作り方「Dockerは裏方で何をしているのか?」
Masahito Zembutsu
Where狙いのキー、order by狙いのキー
Where狙いのキー、order by狙いのキー
yoku0825
マルチテナント化で知っておきたいデータベースのこと
マルチテナント化で知っておきたいデータベースのこと
Amazon Web Services Japan
Weitere ähnliche Inhalte
Was ist angesagt?
Docker Compose 徹底解説
Docker Compose 徹底解説
Masahito Zembutsu
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
mosa siru
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行
Akihiro Suda
トランザクションをSerializableにする4つの方法
トランザクションをSerializableにする4つの方法
Kumazaki Hiroki
ヤフー社内でやってるMySQLチューニングセミナー大公開
ヤフー社内でやってるMySQLチューニングセミナー大公開
Yahoo!デベロッパーネットワーク
新入社員のための大規模ゲーム開発入門 サーバサイド編
新入社員のための大規模ゲーム開発入門 サーバサイド編
infinite_loop
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
pospome
MongoDBが遅いときの切り分け方法
MongoDBが遅いときの切り分け方法
Tetsutaro Watanabe
DockerとPodmanの比較
DockerとPodmanの比較
Akihiro Suda
BuildKitによる高速でセキュアなイメージビルド
BuildKitによる高速でセキュアなイメージビルド
Akihiro Suda
本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話
Kumazaki Hiroki
Fluentdのお勧めシステム構成パターン
Fluentdのお勧めシステム構成パターン
Kentaro Yoshida
MHA for MySQLとDeNAのオープンソースの話
MHA for MySQLとDeNAのオープンソースの話
Yoshinori Matsunobu
Docker Compose入門~今日から始めるComposeの初歩からswarm mode対応まで
Docker Compose入門~今日から始めるComposeの初歩からswarm mode対応まで
Masahito Zembutsu
ARM CPUにおけるSIMDを用いた高速計算入門
ARM CPUにおけるSIMDを用いた高速計算入門
Fixstars Corporation
Akkaとは。アクターモデル とは。
Akkaとは。アクターモデル とは。
Kenjiro Kubota
導入から 10 年、PHP の trait は滅びるべきなのか その適切な使いどころと弱点、将来について
導入から 10 年、PHP の trait は滅びるべきなのか その適切な使いどころと弱点、将来について
shinjiigarashi
暗号技術の実装と数学
暗号技術の実装と数学
MITSUNARI Shigeo
root権限無しでKubernetesを動かす
root権限無しでKubernetesを動かす
Akihiro Suda
単なるキャッシュじゃないよ!?infinispanの紹介
単なるキャッシュじゃないよ!?infinispanの紹介
AdvancedTechNight
Was ist angesagt?
(20)
Docker Compose 徹底解説
Docker Compose 徹底解説
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行
トランザクションをSerializableにする4つの方法
トランザクションをSerializableにする4つの方法
ヤフー社内でやってるMySQLチューニングセミナー大公開
ヤフー社内でやってるMySQLチューニングセミナー大公開
新入社員のための大規模ゲーム開発入門 サーバサイド編
新入社員のための大規模ゲーム開発入門 サーバサイド編
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
MongoDBが遅いときの切り分け方法
MongoDBが遅いときの切り分け方法
DockerとPodmanの比較
DockerとPodmanの比較
BuildKitによる高速でセキュアなイメージビルド
BuildKitによる高速でセキュアなイメージビルド
本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話
Fluentdのお勧めシステム構成パターン
Fluentdのお勧めシステム構成パターン
MHA for MySQLとDeNAのオープンソースの話
MHA for MySQLとDeNAのオープンソースの話
Docker Compose入門~今日から始めるComposeの初歩からswarm mode対応まで
Docker Compose入門~今日から始めるComposeの初歩からswarm mode対応まで
ARM CPUにおけるSIMDを用いた高速計算入門
ARM CPUにおけるSIMDを用いた高速計算入門
Akkaとは。アクターモデル とは。
Akkaとは。アクターモデル とは。
導入から 10 年、PHP の trait は滅びるべきなのか その適切な使いどころと弱点、将来について
導入から 10 年、PHP の trait は滅びるべきなのか その適切な使いどころと弱点、将来について
暗号技術の実装と数学
暗号技術の実装と数学
root権限無しでKubernetesを動かす
root権限無しでKubernetesを動かす
単なるキャッシュじゃないよ!?infinispanの紹介
単なるキャッシュじゃないよ!?infinispanの紹介
Ä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