本当にあったHadoopの恐い話Blockはどこへきえた？ （Hadoop / Spark Conference Japan 2016 ライトニングトーク発表資料）

本当にあったHadoopの恐い話Blockはどこへきえた？ （Hadoop / Spark Conference Japan 2016 ライトニングトーク発表資料）

1. 1. Copyright © 2016 NTT DATA Corporation Hadoop/Spark Conference Japan 2016 ライトニングトーク 2016年2月8日 株式会社ＮＴＴデータ 山下 真一 本当にあったHadoopの恐い話 Blockはどこへきえた？
2. 2. 2Copyright © 2016 NTT DATA Corporation トラブルはいつも金曜日 夏の暑い日、いつもどおり出社した私に一本の電話が... ははーん。またサーバが多数故障したの？と質問すると... なんと！問題は深刻だった。。。 HDFSに保存していたブロックが消えました… 特にサーバは故障していませんし DataNodeも切り離されていません
3. 3. 3Copyright © 2016 NTT DATA Corporation 何はともあれ、まずはログ 消えたブロックの一覧はNameNodeのWeb画面で確認できる。 この情報からNameNodeのログを調べた。消えたブロックを追いかけて追いかけて。。。 (調査対象 : トラブル発生日から直近1か月分のHDFS関連のログ) すると分かったことは３点。 1. 事象発生前に、メンテ中だったDataNodeを組み込んだ。組み込んだDataNodeはメ ンテ前のブロックを保持していた。 2. DataNodeのログには、NameNodeからのブロック削除指示の後、再度ブロックを追 加するようなメッセージが出力されている。特にNameNodeから追加指示は飛んで いないので、何故？ 3. DataNodeでの当該ブロックの削除は、指示を受けた2時間後に完了している、何 故？ 矛盾を抱えつつも、ログの出力内容＋Hadoopソースコードから事象を組み立てた。
4. 4. 4Copyright © 2016 NTT DATA Corporation おさらい : HDFSのレプリケーションについて  HDFSのブロックは、設定されたレプリケーション数を維持する ように動作する 1. 設定されているレプリケーション数よりも少ない状態の場合 → レプリケーション数に達するまで作成 2. 設定されているレプリケーション数よりも多い状態の場合 → レプリケーション数に達するまでレプリカ削除 今回の動作は、2. に関連する動作に着目。
5. 5. 5Copyright © 2016 NTT DATA Corporation Hadoop内部の動作 - DataNodeのブロックを削除する流れ１ DataNode deleteBlock ブロック 管理情報 対象ブロック情報を ブロック管理情報 から除去 DataNodeが扱っている ブロック一覧をメモリ上 で記録 remove ブロック削除 用スレッド 対象ブロックの 実データ削除指示 Block × 削除 非同期で削除
6. 6. 6Copyright © 2016 NTT DATA Corporation Hadoop内部の動作 - DataNodeの定期的なタスク DataNode deleteBlock ブロック 管理情報 remove remove ブロック削除 用スレッド 対象ブロックの 実データ削除指示 Block × 削除 削除に時間が掛かる (処理・IOネックなどが原因) 実データ チェックスレッド check 再登録再登録 定期的に実行 (別名: DirectoryScanner) 消したはずのブ ロック情報が再 び管理される
7. 7. 7Copyright © 2016 NTT DATA Corporation Hadoop内部の動作 - DataNodeの定期的なタスク DataNode ブロック 管理情報 remove remove ブロック削除 用スレッド 対象ブロックの 実データ削除指示 Block × 削除 Directory Scanner check 再登録再登録 ブロック情報 報告スレッド 定期的に実行 (別名: BlockReport) 管理情報 チェック ブロック情報を NameNodeに送信 消したはずのブ ロック情報が NameNodeに 送信される
8. 8. 8Copyright © 2016 NTT DATA Corporation 誤ったブロック情報がHadoopクラスタ全体に伝播する NameNodeイベント (ブロック管理情報) DataNode1 DataNode2 DataNode3 DataNode4 実体 管理 情報 実体 管理 情報 実体 管理 情報 実体 管理 情報 1 超過レプリカにより DataNode4に削除指示 ○ ○ ○ ○ ○ ○ ○ ○ 2 DN4で問題発生、再度超過レ プリカ、DN2に削除指示 ○ ○ ○ ○ ○ ○ × ○ 3 DN2で問題発生、3度超過レ プリカ、DN1に削除指示 ○ ○ × ○ ○ ○ × ○ 4 DN1で問題発生、4度超過レ プリカ、DN3に削除指示 × ○ × ○ ○ ○ × ○ 5 DN3で問題発生、5度超過レ プリカ、DN4に削除指示 × ○ × ○ × ○ × ○ 6 DN4 BlockReport × ○ × ○ × ○ × × 7 DN1 BlockReport × ○ × × × ○ × × 8 DN3 BlockReport × × × × × ○ × × 9 DN2 BlockReport × × × × × × × × 10 MissingBlock状態 × × × × × × × ×
9. 9. 9Copyright © 2016 NTT DATA Corporation Hadoopの非同期処理の不十分な実装が引き起こした問題… レプリカが全消失 ↓ 高負荷状態（CPU・ディスク）が 長時間続いていたため発生しやすかった (ブロック削除に2時間掛かった点はまさにこれ) (※ この事象起因でレプリカ全消失までいかなくても、一時的にレプリカ 数が不足したブロックもある)
10. 10. 10Copyright © 2016 NTT DATA Corporation 安心してください はいってますよ！ ではこの問題は未だに発生するのか？ HDFS-6833 Apache Hadoop 2.7.1～ HDP 2.3～ CDH 5.5～ ※ベースは2.6系だがBackport済 ※ Hadoop1系(例: CDH3など)では発生しません。
11. 11. 11Copyright © 2016 NTT DATA Corporation まとめ  Hadoop = サーバのリソースを使い倒すことが前提の構成 • でも、高負荷状態は、いろいろな問題を引き起こしやすい • でも、大量データを扱うと、いろいろな問題を引き起こしやすい  問題は発生することを前提とした、運用スタイルを整えること • HDFS上データが欠損しても再生成できる仕組み(、または割り切ること) • ログ精査、リソース情報の取得  あまり、サーバをいじめないでくださいね。 • サーバスペックに応じた、やさしい設定・リソース割り当て • 無邪気なアプリケーションは、まずは手元の環境＆少量データで確認してね！  バージョン選定は大切 • 問題の改修は、新しいバージョン優先 • 根が深い問題は中々改修されづらい＆バックポートされにくい
12. 12. Copyright © 2011 NTT DATA Corporation Copyright © 2016 NTT DATA Corporation