Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
運用中システムにおける6億レコードのデータ移行に関する課題と解決
Search
CassandraCommunityJP
October 17, 2017
Technology
0
300
運用中システムにおける6億レコードのデータ移行に関する課題と解決
Cassandra Summit Tokyo 2017
CassandraCommunityJP
October 17, 2017
Tweet
Share
More Decks by CassandraCommunityJP
See All by CassandraCommunityJP
Azure Managed Instance for Apache Cassandra
cassandracommunityjp
0
200
Cassandra on Kubernets- K8ssandra
cassandracommunityjp
0
540
Transaction Management on Cassandra
cassandracommunityjp
0
300
Cassandraの活用とその事例
cassandracommunityjp
0
450
Microsoft Azureを基盤としたライフサイエンス業界事例でのCassandra / DataStax Enterpriseの活用
cassandracommunityjp
0
200
Microsoft Azure で実現する Cassandra とその活用事例
cassandracommunityjp
0
320
Troubleshooting Apache Cassandra
cassandracommunityjp
0
310
Cassandra Summit Tokyo 2017 Keynote
cassandracommunityjp
0
380
Aaron Morton
cassandracommunityjp
0
64
Other Decks in Technology
See All in Technology
ISUCONに強くなるかもしれない日々の過ごしかた/Findy ISUCON 2024-11-14
fujiwara3
8
870
いざ、BSC討伐の旅
nikinusu
2
780
Terraform CI/CD パイプラインにおける AWS CodeCommit の代替手段
hiyanger
1
240
個人でもIAM Identity Centerを使おう!(アクセス管理編)
ryder472
3
220
ドメインの本質を掴む / Get the essence of the domain
sinsoku
2
150
SSMRunbook作成の勘所_20241120
koichiotomo
2
150
Making your applications cross-environment - OSCG 2024 NA
salaboy
0
190
適材適所の技術選定 〜GraphQL・REST API・tRPC〜 / Optimal Technology Selection
kakehashi
1
470
Lambdaと地方とコミュニティ
miu_crescent
2
370
Lexical Analysis
shigashiyama
1
150
rootlessコンテナのすゝめ - 研究室サーバーでもできる安全なコンテナ管理
kitsuya0828
3
390
Can We Measure Developer Productivity?
ewolff
1
150
Featured
See All Featured
Automating Front-end Workflow
addyosmani
1366
200k
10 Git Anti Patterns You Should be Aware of
lemiorhan
654
59k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
109
49k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
280
13k
Site-Speed That Sticks
csswizardry
0
25
Dealing with People You Can't Stand - Big Design 2015
cassininazir
364
24k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
26
1.4k
Statistics for Hackers
jakevdp
796
220k
Making Projects Easy
brettharned
115
5.9k
Speed Design
sergeychernyshev
25
620
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
47
2.1k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
25
1.8k
Transcript
Copyright (c) NIPPON TELEGRAPH AND TELEPHONE WEST CORPORATION 2017 Copyright
(c) NTT COMWARE CORPORATION 2017 運用中システムにおける 6億レコードのデータ移行に関する課題と解決 2017年10月5日 西日本電信電話株式会社 佐分利 伸 御手洗 剛 永田 尚志 NTTコムウェア株式会社 祖田 心平 1 Cassandra Summit Tokyo 2017
Copyright (c) NIPPON TELEGRAPH AND TELEPHONE WEST CORPORATION 2017 Copyright
(c) NTT COMWARE CORPORATION 2017 本日の流れ • 自己紹介 • 担当システムの概要 • データ移行の要件 • 採用したデータ移行方式 • 発生した問題と対処内容 • 所感 2
Copyright (c) NIPPON TELEGRAPH AND TELEPHONE WEST CORPORATION 2017 Copyright
(c) NTT COMWARE CORPORATION 2017 自己紹介(Co-author) • 佐分利 伸、御手洗 剛、永田 尚志 • IoT関連ビジネスのサービス創造と具現化、システムの方式 検討・設計、開発・維持管理を担当 Cassandraを活用したシステムの開発・維持経験:約1年 3
Copyright (c) NIPPON TELEGRAPH AND TELEPHONE WEST CORPORATION 2017 Copyright
(c) NTT COMWARE CORPORATION 2017 自己紹介(Reporter) • 祖田 心平(そだ しんぺい) スマートホーム、IoT関連のアプリケーション開発を担当 Cassandra歴約1年 • NTTコムウェア株式会社 NTT-G向けのシステム開発(SI)が中心事業 一般向けの事業も拡大中 4
Copyright (c) NIPPON TELEGRAPH AND TELEPHONE WEST CORPORATION 2017 Copyright
(c) NTT COMWARE CORPORATION 2017 ログデータ蓄積・解析システムの概要 5 • IoTサービスにおけるログデータを蓄積・解析するシステム • IoTデバイスのログ蓄積にCassandraを利用 Cassandra クラスタ (5ノード構成) RDB デバイスからの ログデータを蓄積 デバイスの管理情報・ ログデータの集計結果等 集計結果の参照 Hadoop MapReduce 項目ごとに毎時/毎日 集計を実施 システム管理者 デバイス管理者 ログデータの 送信 IoTデバイス ログデータ蓄積・解析システム ログデータの ダウンロード
Copyright (c) NIPPON TELEGRAPH AND TELEPHONE WEST CORPORATION 2017 Copyright
(c) NTT COMWARE CORPORATION 2017 データ移行が必要になった経緯 6 ダウンロード機能でユーザ個別の情報を取り扱うため、 蓄積用ColumnFamilyに主キーの追加が必要となった Row key :時間情報(時まで) Primary key : 時間情報(msまで) Primary key : デバイス識別情報 Column : 収集データ Row key :時間情報(時まで) Primary key : ユーザ識別情報 Primary key : デバイス識別情報 Primary key : 時間情報(msまで) Column : 収集データ ALTER TABLEでは主キーの変更ができないため、同キースペースに ColumnFamily(CF)を新規作成し、旧から新CFへデータを移行した データ加工 新CF ×29 新CF ×29 新CF×29 旧CF×29 旧CF×29 旧CF×29
Copyright (c) NIPPON TELEGRAPH AND TELEPHONE WEST CORPORATION 2017 Copyright
(c) NTT COMWARE CORPORATION 2017 移行要件 7 1. 提供中のサービスに影響を及ぼさない 移行対象のログデータは参照のみのため運用中でも移行可能 デバイスのログデータは24時間絶え間なく送られてくる 運用中の作業はサービスに影響が出ない程度の負荷にとどめる 2. 新規カラムには1レコードずつ適切な値を設定する RDBからデバイス情報に紐づくユーザ情報を取得してセット Row key=2016-01-01T00:00 ユーザ識別情報=yyy デバイス識別情報=xxx Time=2016-01-01T00:00:00.000 収集データ デバイスID ユーザID xxx yyy RDB 新CF
Copyright (c) NIPPON TELEGRAPH AND TELEPHONE WEST CORPORATION 2017 Copyright
(c) NTT COMWARE CORPORATION 2017 データ移行の方針 8 1. 新アプリケーションに入替えて、アクセス先ColumnFamily を変更 2. データ移行ツールを作成し、運用中にデータを加工しつつ 徐々にログデータを移行 APサーバ IoTデバイス 旧CF×29 新CF ×29 旧CF×29 旧CF×29 新CF ×29 新CF ×29
Copyright (c) NIPPON TELEGRAPH AND TELEPHONE WEST CORPORATION 2017 Copyright
(c) NTT COMWARE CORPORATION 2017 データ移行の方針 9 1. 新アプリケーションに入替えて、アクセス先ColumnFamily を変更 2. データ移行ツールを作成し、運用中にデータを加工しつつ 徐々にログデータを移行 APサーバ IoTデバイス 旧CF×29 新CF ×29 旧CF×29 旧CF×29 新CF ×29 新CF ×29 APの入替え アクセス先CFの変更
Copyright (c) NIPPON TELEGRAPH AND TELEPHONE WEST CORPORATION 2017 Copyright
(c) NTT COMWARE CORPORATION 2017 データ移行の方針 10 1. 新アプリケーションに入替えて、アクセス先ColumnFamily を変更 2. データ移行ツールを作成し、運用中にデータを加工しつつ 徐々にログデータを移行 APサーバ IoTデバイス 旧CF×29 新CF ×29 データ移行ツール (データの加工) 旧CF×29 旧CF×29 新CF ×29 新CF ×29
Copyright (c) NIPPON TELEGRAPH AND TELEPHONE WEST CORPORATION 2017 Copyright
(c) NTT COMWARE CORPORATION 2017 データ移行ツールの設計指針 11 1. 低負荷 全件SELECT等の高負荷な処理は実行しない 2. 高速 旧ColumnFamilyのログデータはエンドユーザの利用に 影響が発生するため、なるべく早く移行を終わらせる 3. リトライ可能 問題が出て移行を中断した場合、移行できなかった箇所が わかるようにする リトライ時は同じデータを2度処理しない
Copyright (c) NIPPON TELEGRAPH AND TELEPHONE WEST CORPORATION 2017 Copyright
(c) NTT COMWARE CORPORATION 2017 データ移行ツールの方式案 12 案1:Hadoop MapReduceを利用 旧CF×29 旧CF×29 旧CF×29 新CF ×29 新CF ×29 新CF ×29 Mapper Mapper Mapper … Reducer Row key毎に処理を分割 新カラムに値をセット 新CFに1レコードずつINSERT 旧CFから1レコードずつDELETE →試験走行で2ヶ月分(約2,400万件)を移行したところ、 MapReduceのジョブがタイムアウトで失敗するため不採用 (Mapperへ処理を分割する際の内部的な全件SELECTが原因) 29ジョブ
Copyright (c) NIPPON TELEGRAPH AND TELEPHONE WEST CORPORATION 2017 Copyright
(c) NTT COMWARE CORPORATION 2017 データ移行ツールの方式案 13 案2:CQLを実行するJavaプログラムをバッチ起動 旧CF×29 旧CF×29 旧CF×29 新CF ×29 新CF ×29 新CF ×29 Thread Thread Thread … 20スレッド×29バッチ →試験走行で2ヶ月分(約2,400万件)を移行したところ、 約14分で移行完了できたため一旦採用 1Row key分SELECT 新カラムに値をセット 新CFに1レコードずつINSERT 旧CFから1レコードずつDELETE ※各ノードのスペック CPU:24コア システムメモリ:96GB ヒープサイズ:8GB
Copyright (c) NIPPON TELEGRAPH AND TELEPHONE WEST CORPORATION 2017 Copyright
(c) NTT COMWARE CORPORATION 2017 •負荷を下げるための工夫 • 移行対象データの範囲を設定ファイルで定義可能にした →CF毎+対象期間でバッチ起動時刻をずらすことで負荷を分散 データ移行ツールの方式案 14 migration.start.time=2016-01-01T00:00 migration.end.time=2016-01-31T23:00 ログデータの日時がRow key 1時間分のログデータが1Rowに対応 →1か月分のログデータは744Row 2017/06/03 08:31:40.850,[INFO ],ROWキー件数:2016-05-31T04:00:00.000=0 #at -f migration_cf1_201601.sh 07:10 September 22 17 #at -f migration_cf1_201602.sh 08:10 September 22 17 #at -f migration_cf2_201601.sh 09:10 September 22 17 •データ移行完了の判断 • Row key毎にレコード数を計測するカウントツールを作成 • カウントツールの実行結果が0件となったら移行完了と判断 設定ファイルの記述例 バッチの起動コマンド例 カウントツールのログ
Copyright (c) NIPPON TELEGRAPH AND TELEPHONE WEST CORPORATION 2017 Copyright
(c) NTT COMWARE CORPORATION 2017 •ツールの実行イメージ データ移行ツールの検討 15 旧CF Row Key:2016-01-01T00:00 Row Key:2016-01-31T23:00 … 新CF Row Key:2017-05-31T23:00 … Row Key:2017-05-01T00:00 …
Copyright (c) NIPPON TELEGRAPH AND TELEPHONE WEST CORPORATION 2017 Copyright
(c) NTT COMWARE CORPORATION 2017 •ツールの実行イメージ データ移行ツールの検討 16 旧CF 新CF Row Key:2016-01-01T00:00 Row Key:2016-01-31T23:00 … Row key単位で SELECT→加工→INSERT→DELETE Row Key:2017-05-31T23:00 … Row Key:2017-05-01T00:00 …
Copyright (c) NIPPON TELEGRAPH AND TELEPHONE WEST CORPORATION 2017 Copyright
(c) NTT COMWARE CORPORATION 2017 •ツールの実行イメージ データ移行ツールの検討 17 旧CF 新CF Row Key:2016-01-01T00:00 Row Key:2016-01-31T23:00 … … Row key単位で SELECT→加工→INSERT→DELETE Row Key:2017-05-01T00:00 … Row Key:2017-05-31T23:00 対象期間でプロセスを分割 エラー発生時はプロセスを中断
Copyright (c) NIPPON TELEGRAPH AND TELEPHONE WEST CORPORATION 2017 Copyright
(c) NTT COMWARE CORPORATION 2017 •ツールの実行イメージ データ移行ツールの検討 18 旧CF 新CF Row Key:2016-01-01T00:00 Row Key:2016-01-31T23:00 … … Row key単位で SELECT→加工→INSERT→DELETE Row key毎にCOUNT(*)を実行 残りのデータ件数を把握 Row Key:2017-05-01T00:00 … Row Key:2017-05-31T23:00 対象期間でプロセスを分割 エラー発生時はプロセスを中断
Copyright (c) NIPPON TELEGRAPH AND TELEPHONE WEST CORPORATION 2017 Copyright
(c) NTT COMWARE CORPORATION 2017 データ移行のスケジュール 19 約2,400万件が14分という検証結果と、 サービス稼働中の負荷傾向を鑑みてスケジューリング 1日目 • 1CF 約2.5億件を18プロセスで1時間おきにツール実行 2日目 • 2CF 約2.7億件を18プロセスで1時間おきにツール実行 3日目 • 11CF 約3600万件を12プロセスで1時間おきにツール実行 4日目 • 15CF 約640万件を15プロセスで1時間おきにツール実行
Copyright (c) NIPPON TELEGRAPH AND TELEPHONE WEST CORPORATION 2017 Copyright
(c) NTT COMWARE CORPORATION 2017 データ移行の実行結果 20 1日目 • 1CF 約2.5億件を18プロセスで1時間おきにツール実行 →移行中断が9プロセス、カウント中断が6プロセス 2日目 • 2CF 約2.7億件を18プロセスで1時間おきにツール実行 →移行中断が13プロセス、カウント中断が2プロセス 3日目 • 11CF 約3600万件を12プロセスで1時間おきにツール実行 →移行は全て成功、カウント中断が3プロセス 4日目 • 15CF 約640万件を15プロセスで1時間おきにツール実行 →すべて成功 完了率 50% 完了率 50%
Copyright (c) NIPPON TELEGRAPH AND TELEPHONE WEST CORPORATION 2017 Copyright
(c) NTT COMWARE CORPORATION 2017 データ移行時に発生したエラー 21 ① ReadTimeoutException, WriteTimeoutException com.datastax.driver.core.exceptions.ReadTimeoutException: Cassandra timeout during read query at consistency QUORUM (2 responses were required but only 1 replica responded) • 複数スレッドで読み書き処理を行なった結果、ノードの負荷が上昇 →過半数を超えるノードでFullGCやコンパクションが重なることで CQL実行時にタイムアウトが発生 データ移行 ツール Cassandra#1 Cassandra#2 Cassandra#3 Cassandra#4 Cassandra#5 カウント ツール Row Key指定SELECT 1レコードINSERT Row Key指定COUNT(*)
Copyright (c) NIPPON TELEGRAPH AND TELEPHONE WEST CORPORATION 2017 Copyright
(c) NTT COMWARE CORPORATION 2017 データ移行時に発生したエラー 22 ② NoHostAvailableException com.datastax.driver.core.exceptions.NoHostAvailableException: All host(s) tried for query failed (tried: localhost/127.0.0.1:9042 (com.datastax.driver.core.Oper ationTimedOutException: [localhost/127.0.0.1:9042] Operation timed out)) • 移行処理で想定以上にエラーが発生したため、旧CFに多くデータが 残った状態でCOUNT(*)文を発行する状況となった • 旧CFに連続的にDELETEを発行したためTombstoneが肥大化 →クラスタへのアクセス要求でタイムアウトが発生 移行ツール Cassandra#1 Cassandra#2 Cassandra#3 Cassandra#4 Cassandra#5 COUNT ツール Row Key指定SELECT Row Key指定COUNT(*)
Copyright (c) NIPPON TELEGRAPH AND TELEPHONE WEST CORPORATION 2017 Copyright
(c) NTT COMWARE CORPORATION 2017 データ移行ツールの改善 23 • スレッド数を削減 • エラー発生時はインターバル(5分)をおいてリトライ • 対象期間でのプロセス分割を廃止 →1CF1プロセスで全期間のデータを移行 旧CF×29 旧CF×29 旧CF×3 新CF ×29 新CF ×29 新CF ×3 Thread Thread … 12スレッド×3プロセス 1Rowキー分SELECT 新カラムに値をセット 1レコードずつINSERT+DELETE エラー発生時はリトライ 移行完了までループ
Copyright (c) NIPPON TELEGRAPH AND TELEPHONE WEST CORPORATION 2017 Copyright
(c) NTT COMWARE CORPORATION 2017 データ移行ツール(改善後)の実行イメージ 24 旧CF Row Key:2016-01-01T00:00 Row Key:2016-01-31T23:00 … 新CF Row Key:2017-05-31T23:00 … Row Key:2017-05-01T00:00 …
Copyright (c) NIPPON TELEGRAPH AND TELEPHONE WEST CORPORATION 2017 Copyright
(c) NTT COMWARE CORPORATION 2017 データ移行ツール(改善後)の実行イメージ 25 旧CF 新CF Row Key:2016-01-01T00:00 Row Key:2016-01-31T23:00 … Row Key単位で SELECT→加工→INSERT→DELETE Row Key:2017-05-31T23:00 … Row Key:2017-05-01T00:00 …
Copyright (c) NIPPON TELEGRAPH AND TELEPHONE WEST CORPORATION 2017 Copyright
(c) NTT COMWARE CORPORATION 2017 データ移行ツール(改善後)の実行イメージ 26 旧CF 新CF Row Key:2016-01-01T00:00 Row Key:2016-01-31T23:00 … … Row Key単位で SELECT→加工→INSERT→DELETE Row Key:2017-05-01T00:00 … Row Key:2017-05-31T23:00 … エラー発生時は5分間待機 Row Key単位でリトライ (正常終了するまで)
Copyright (c) NIPPON TELEGRAPH AND TELEPHONE WEST CORPORATION 2017 Copyright
(c) NTT COMWARE CORPORATION 2017 データ移行ツール(改善後)の実行イメージ 27 旧CF 新CF Row Key:2016-01-01T00:00 Row Key:2016-01-31T23:00 … … Row Key単位で SELECT→加工→INSERT→DELETE Row Key:2017-05-01T00:00 … エラー発生時は5分間待機 Row Key単位でリトライ (正常終了するまで) Row Key:2017-05-31T23:00 プロセス終了=データ移行完了 →カウントツールは廃止
Copyright (c) NIPPON TELEGRAPH AND TELEPHONE WEST CORPORATION 2017 Copyright
(c) NTT COMWARE CORPORATION 2017 データ移行の実行結果(2回目) 28 ColumnFamily 残っていた レコード数 処理時間 ReadTimeout Exception回数 WriteTimeout Exception回数 1日目のCF 2万Row 1.3億件 15:34:25 8 3 2日目のCF① 2万Row 8,500万件 3:29:02 0 0 2日目のCF② 2万Row 4,600万件 2:04:32 14 0 • エラーは発生したが最終的に約21時間で残りのデータ移行が完了 • エラー発生時は5分間待機しリトライすることで対象の処理が 正常終了した クラスタの負荷が上がらないように1CFずつ順番に移行ツールを実行
Copyright (c) NIPPON TELEGRAPH AND TELEPHONE WEST CORPORATION 2017 Copyright
(c) NTT COMWARE CORPORATION 2017 所感 29 • 小規模データセットを利用した試験走行で良好な結果であっても、 本番で問題が発生する →Cassandraの効率的な処理方法を考える エラーが発生した場合のリカバリ方法を事前に準備する • Row key指定であってもCOUNT(*)の処理は重い →COUNT(*)処理が不要な方式にする COUNT(*)処理を行う前にTombstoneの保持期間を短くする 今後の検討すべき方式 • Apache Sparkの利用 データ移行処理における有効性をMapReduceと比較したい • cassandra-unloader+SSTableWriter+sstableloaderの利用 ディスク容量が必要となるが、性能面での優位性を確認したい
Copyright (c) NIPPON TELEGRAPH AND TELEPHONE WEST CORPORATION 2017 Copyright
(c) NTT COMWARE CORPORATION 2017 最後に 30 • これからデータ移行を検討される方の参考に なれば幸いです • データ移行経験者の方はお話聞かせてください ご静聴ありがとうございました Apache Cassandraは、 Apache Software Foundation の登録商標または商標です。 その他、記載されている会社名、商品名等は各社の商標または登録商標である場合があります。