第10回Hadoopソースコードリーディングで発表した資料です。 2012年6月に開催されたHadoop Summit の参加レポートで、YARN、HBase、HDFS HA などのセッションを紹介しています。

1. Hadoop Summit 2012
Sho Shimauchi, Cloudera
@shiumachi

2. お前誰よ？
• Sho Shimauchi ( @shiumachi )
• Cloudera 株式会社カスタマーオペレーショ
ンズエンジニア
• 問い合わせ担当

3. Hadoop Summit
• サンノゼで開催された、世界最大の
Hadoop イベントの一つ
• 今年は2,200 人参加

4. 何聞いてきたの？
• プラットフォーム周り中心(YARN, HDFS HA,
HBase …)
• 今日はこれらのスライドを元に、
Hadoop/HBase の現状と今後について紹介
します

5. APACHE HADOOP MAPREDUCE:
WHAT'S NEXT?

6. Apache Hadoop MapReduce: What's Next?
• スピーカー: Arun Murthy (Hortonworks)
• MapReduce1 から MapReduce2(YARN)、そ
して今後の開発予定について語ったセッ
ション

7. Hadoop 1.x MapReduce
• ご存知 MapReduce
• 非常に安定、 Enterprise Ready
• 以下の点で課題
– map/reduce間でのタスクスロットの共有
– 非MapReduce アルゴリズムのサポート
– スケーラビリティ(Max 4,000ノード、 40,000
タスク同時実行)

8. YARN
• Yet Another Resource Negociator
• ターゲット
– 6,000 - 10,000 ノード
– 100,000 以上のタスクの同時実行
– 10,000 ジョブの同時実行
• hadoop-2.0.0-alpha で使用可能
• 性能は倍以上

9. 今後の予定
• メモリ以外のリソースアロケーション
MAPREDUCE-4327
• プリエンプション MAPREDUCE-3938
• cgroup などを使った Container アイソレー
ション MAPREDUCE-4334
• HBase の YARN 対応 HBASE-4329, HBASE-4047
• プラガブルソート MAPREDUCE-4039,
MAPREDUCE-2454
• プラガブルシャッフル MAPREDUCE-4049

10. まとめ
• YARNは「汎用」分散処理基盤に向けて一
歩踏み出したもの
• 今までの Hadoop からさらに先に進んでい
る
• これからの進化に要注目！

11. IMPROVING HBASE AVAILABILITY
AND REPAIR

12. Improving HBase Availability and Repair
• スピーカー Jonathan Hsieh, Jeff
Bean(Cloudera)
• HBase の可用性にフォーカスしてしゃべっ
たセッション
• コプロセッサ(0.92で採用)の話はないです

13. HBase
• フォールトトレラント
– コンポーネントに障害が発生しても、データ
の損失なく復旧できること
• 高可用性
– コンポーネントに障害が発生しても、データ
の損失なく高速に復旧できること
ゴール: ダウンタイムを短くする!

14. HBase のダウンタイム
計画停止
障害停止

15. HBase 障害の内訳
メタデータ障
害
28% 設定ミス
44%
HW/NW障害
16%
要パッチ
12%

16. Conservative First!
• 不安定な機能は使わないでください
• 非推奨の構成・設定・運用はしないでく
ださい
• HBase を使って冒険してもいいですが
HBase で冒険しないでください

17. HBase 0.92 + Hadoop 2.0
• HDFS HA による高可用性の確保
• 分散ログスプリッティングによるリカバ
リーの高速化
– 100ノードの場合、9時間が5.4分(100倍)
– ダウンタイムの削減＝可用性の向上

18. HBase 0.96 + Hadoop 2.x (計画)
• 計画停止時間の削減
• オンラインスキーマ変更 HBASE-1730
• ローリングアップデート
– バージョン間互換性が必須
• HBase のバージョン間互換性 HBASE-5305
• HDFS のバージョン間互換性 HADOOP-7307

19. まとめ
• HBase は一貫性と可用性の両立を目指して
進化中
• 一方で運用はまだまだ課題が多い
• 対策
– Conservative First! 用法をよく守って正しく使
いましょう
– HBase 本読みましょう(もうすぐ日本語版出る)
– お金あるならサポート買ってね！

20. HDFS NAMENODE HIGH
AVAILABILITY

21. 信頼性、保守性、可用性
• reliability 信頼性 = MTBF/(1 + MTBF)
– MTBF: 平均故障間隔
– 1ヶ月に1回壊れるより1年に1回の方が信頼性が高
い
• maintainability 保守性 = 1 / (1 + MTTR)
– MTTR: 平均復旧時間
– 素早く復旧する方が保守性が高い
• availability 可用性 = MTTF / MTBF
– MTTF: 平均故障時間
– MTBF = MTTF + MTTR
– 信頼性と保守性が高いと可用性も高い

22. 信頼性
• データの信頼性
– 10クラスタ、20,000ノード上の3.29億ブロッ
クのうち19ブロックがロスト(2009年)
• ※同一ファイルのブロックが全てロストする確率
はほぼ0
– 1700万ブロック中1ブロック(約4PB)
– 原因となったバグは既に修正済み
信頼性は十分高い

23. 可用性
• 18ヶ月で、25クラスタの間で22回の障害
– 1クラスタあたり年間0.58回の障害
– HAが役に立っただろうと考えられるのはうち
8回の障害(0.23回分)
• 計画停止
– 設定変更のたびに再起動
– アップデート時も当然再起動

24. 保守性
• NN起動時間: 通常1-2分、大クラスタだと
15分
– 計画停止するたびにこれだけの時間停止する
→MTTR増える(保守性下がる)
– 日本で主流のHeartbeat + DRBD も、この部分
は回避できてない
• DNの保守性
– 大クラスタ: 1日1DNに障害発生、ディスクは
もっと高頻度
– 3ヶ月に1回の割合で一斉に補修・入れ替え

25. HDFS HAのデザイン
• NN外からのサービス監視とリーダー選出
– ZKFC と Zookeeper
– マニュアルフェイルオーバならZK不要
• ActとStandby両方にブロックレポート送信
– 再起動時のブロックレポート収集が必要ない
• クライアントサイドもフェイルオーバに
対応
• edits のみ共有ストレージに置く必要があ
る
– 将来的に ZooKeeper (BookKeeper)で管理する予
定(HDFS-3077)

26. まとめ
• HDFS HA はかなり可用性を上げる
• 障害対策はもちろん、HDFSのアップグ
レードや設定変更時の再起動にも有効