リペア時間短縮にむけた取り組み@Yahoo! JAPAN #casstudy

2.7K Views

June 12, 17

スライド概要

第37回Cassandra勉強会 https://casstudy.connpass.com/event/57701/ で発表した資料です。

profile-image

2023年10月からSpeaker Deckに移行しました。最新情報はこちらをご覧ください。 https://speakerdeck.com/lycorptech_jp

シェア

またはPlayer版

埋め込む »CMSなどでJSが使えない場合

関連スライド

各ページのテキスト
1.

リペア時間短縮にむけた取り組み @Yahoo! JAPAN ヤフー株式会社 データ&サイエンスソリューション統括本部 データプラットフォーム本部 小島 夏海 1

2.

お前誰? • • • • 2 小島 夏海 Cassandra 歴 9ヶ月 社内向けプラットフォームの開発・運用 学生時代の専門はHCI(主にVR)

3.

発表について • 何か素晴らしいことをしてリペアがめっちゃ 速くなった!という内容の発表ではないです • とりあえずなんとかなったけど、 もっといい方法がないか知りたいので みなさんのご意見を聞きたいと思ってます 3

4.

アジェンダ • モチベーション • 何をして速くしたか • リペアのオプション • Subrange Repair 4

5.

参考資料 • Real World Repairs • https://www.slideshare.net/DataStax/realworld-repairs-vinay-chella-netflixcassandra-summit-2016 • nodetool repair • http://docs.datastax.com/en/cassandra/3. 0/cassandra/tools/toolsRepair.html 5

6.

モチベーション 6

7.

SLAが満たせない… • 2DC 全36台のクラスタでリペアが7時間ほど • 1台 約12分 (420 36 12) • 深夜の内に終わらせたいので7時間は長すぎる 素早くリペアを回したい 7

8.

環境 • • • • 8 CPU : 2CPU 1.80GHz メモリ : 128GB DISK : SSD 400GB x2発 RAID0*1vol Cassandra 3.0.9 • 2DC 3RF • LeveledCompaction • データのディスク専有率 : 約30%

9.

どうやって速くしていったか 9

10.

どうやって速くするか • streaming 周りの設定 • compaction 周りの設定 • nodetool repairのオプション 10

11.

どうやって速くするか • streaming 周りの設定 • 速度を出しすぎると他サービスに 影響があるので 400MB/s に設定 • compaction 周りの設定 • 大きな値にした状態ではピーク時の リクエストが処理仕切れない • nodetool repairのオプション 11

12.

どうやって速くするか • streaming 周りの設定 • compaction 周りの設定 • nodetool repairのオプション 12

13.

リペアで設定できるもの • • • • • • リペアのアルゴリズム : インクリメンタル シーケンシャル or パラレル : パラレル プライマリレンジかどうか : false ジョブスレッド数 : 1 リペアするDCの範囲 : 全体 データセンタを並列でリペアするか : false ref : http://docs.datastax.com/en/cassandra/3.0/cassandra/tools/toolsRepair.html 11

14.

2.1系までのリペア • 2.1系までのリペアはフル・リペアで シーケンシャルがデフォルト • 弊社ではこれにプライマリオプションを つけて運用 DC1 12 DC2

15.

3.0系の設定 • インクリメンタル、パラレルがデフォルト • 今回のクラスタも3.0系なので、この設定 DC1 15 DC2

16.

なぜprオプションを外したか インクリメンタルリペアに プライマリオプションをつけて実行 : ノード incremental primary ○ DC1 16 ○ 3系ではプライマリオプションをつけて 並列でリペアを実行すると失敗する

17.

リペア動作確認 : 条件1 マルチDC環境にて1DCの 1台のみ nodetool repair -full このrackだけ nodetool repair 実行 { name : nkojima age : 26} DC1 17 : ノード incremental parallels ✕ ○ primary ✕ RF : 3 DC2 { name : nkojima age : 25}

18.

リペア動作確認 : 条件1 結果 : nodetool repair -full を実行していない : ノード incremental parallels primary ノードのデータも修正された ✕ ○ ✕ RF : 3 { name : nkojima age : 26} DC1 18 DC2 { name : nkojima age : 26}

19.

リペア動作確認 : 条件2 マルチDC環境にて1DCでのみ nodetool repair -full -pr : ノード incremental parallels こちらのDCだけ nodetool repair実行 DC1 19 { name : nkojima age : 26} ✕ DC2 ○ primary ○ RF : 3 { name : nkojima age : 25}

20.

リペア動作確認 : 条件2 結果 : リペアを実行していないノードの データは修正されず incremental ✕ : ノード parallels primary ○ ○ RF : 3 DC1 20 { name : nkojima age : 26} DC2 { name : nkojima age : 25}

21.

ここまでのまとめ • pr オプションをつけておらず、RF3で3rackの 場合は1rackでだけnodetool repairすればいい • 弊社の場合 • 2.1系までは pr オプションで運用していたので、 全体でリペアをしていく必要があった • 3系では pr オプションをやめたので、 全台で nodetool repair コマンドを実行する 必要はなかった 21

22.

リペアを実行するノード数の変化 before : nodetool repair after : nodetool repair rack2 rack2 rack1 rack3 DC1 DC1 rack1 rack2 rack3 rack1 rack3 rack1 rack2 無駄に実行していたリペアを削減 rack2 rack1 rack3 rack1 rack2 22 rack3 DC2 DC2 rack1 rack2 rack3 rack3 rack1 rack2 rack3

23.

Subrange Repair 23

24.

Subrange Repair • 通常のリペアと同じようにリペアをする • リペアする範囲を実行時に指定する 24

25.

Subrange Repair • 通常のリペアと同じようにリペアをする • リペアする範囲を実行時に指定する 25 トークンレンジ図 例 : 赤い箇所をnode1が担当している場合 • 通常のリペアの場合 : 赤い箇所すべてが一つの nodetool repair の対象になり、順番にリペアが実 行される • Subrange Repairの場合 : nodetool repair を実行 する時に、リペアする箇所の範囲を指定すること で一つづつリペアを実行する

26.

リペアの並列実行 • 通常のリペアでは最大で job threads は最大で4 • Subrange Repair を並列で実行すれば job threads は 1 range に対して最大で4 Normal Repair All Range job threads : 4 26 Subrange Repair Range1 job threads : 4 Range3 job threads : 4 Range2 job threads : 4 Range4 job threads : 4

27.

どうやっているか • nodetool repairコマンドを実行している ノードの概要 トークンレンジ取得 Subrange Repair プロセス Subrange Repair プロセス Repair 管理プロセス Subrange Repair プロセス Subrange Repair プロセス 27

28.

実行結果 • 取り組み前 → 7時間 • 取り組み後 → 2時間35分 28

29.

実施したことまとめ • 無駄に実行していたリペアを削除 • nodetool repairを実行する台数が36 → 6 • リペアの並列数を上げることで処理時間を短縮 • Subrange Repair を4並列で実行 29

30.

現状の問題点 • Subrange Repair の管理をしている ノードの負荷が高い 31

31.

どうして負荷が高くなっているのか • スレッド管理で負荷がかかっている トークンレンジ取得 Subrange Repair プロセス Subrange Repair プロセス Repair 管理プロセス Subrange Repair プロセス Subrange Repair プロセス 32

32.

複数台でリペアを動かして負荷を分散させる node1 トークンレンジ取得 Subrange Repair プロセス Subrange Repair プロセス Repair 管理プロセス node2 Subrange Repair プロセス Subrange Repair プロセス トークンレンジ取得 32

33.

まとめ • リペア時間の短縮を実施 • 7時間 → 2時間半 • 無駄に実行していたリペアを削除 • リペアの並列数を上げることで 処理時間を短縮 33