Hadoop Summit 2012

Sho Shimauchi, Cloudera@shiumachi

お前誰よ？• Sho Shimauchi ( @shiumachi )• Cloudera 株式会社カスタマーオペレー

ションズエンジニア• 問い合わせ担当

Hadoop Summit

• サンノゼで開催された、世界最大の Hadoop イベントの一つ

• 今年は 2,200 人参加

何聞いてきたの？• プラットフォーム周り中心 (YARN, HDFS

HA, HBase …)• 今日はこれらのスライドを元

に、 Hadoop/HBase の現状と今後について紹介します

APACHE HADOOP MAPREDUCE: WHAT'S NEXT?

Apache Hadoop MapReduce: What's Next?

• スピーカー : Arun Murthy (Hortonworks)• MapReduce1 から MapReduce2(YARN) 、そ

して今後の開発予定について語ったセッション

Hadoop 1.x MapReduce

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

タスク同時実行 )

YARN

• Yet Another Resource Negociator• ターゲット– 6,000 - 10,000 ノード– 100,000 以上のタスクの同時実行– 10,000 ジョブの同時実行

• hadoop-2.0.0-alpha で使用可能• 性能は倍以上

今後の予定• メモリ以外のリソースアロケーション

MAPREDUCE-4327• プリエンプション MAPREDUCE-3938• cgroup などを使った Container アイソレー

ション MAPREDUCE-4334• HBase の YARN 対応 HBASE-4329, HBASE-4047• プラガブルソート MAPREDUCE-4039,

MAPREDUCE-2454• プラガブルシャッフル MAPREDUCE-4049

まとめ• YARN は「汎用」分散処理基盤に向けて一

歩踏み出したもの• 今までの Hadoop からさらに先に進んで

いる• これからの進化に要注目！

IMPROVING HBASE AVAILABILITY AND REPAIR

Improving HBase Availability and Repair

• スピーカー Jonathan Hsieh, Jeff Bean(Cloudera)

• HBase の可用性にフォーカスしてしゃべったセッション

• コプロセッサ (0.92 で採用 ) の話はないです

HBase

• フォールトトレラント– コンポーネントに障害が発生しても、データ

の損失なく復旧できること• 高可用性– コンポーネントに障害が発生しても、データ

の損失なく高速に復旧できること

ゴール : ダウンタイムを短くする !

HBase のダウンタイム

計画停止

障害停止

HBase 障害の内訳

設定ミス44%

要パッチ12%

HW/NW 障害16%

メタデータ障害28%

Conservative First!

• 不安定な機能は使わないでください• 非推奨の構成・設定・運用はしないでくださ

い• HBase を使って冒険してもいいですが

HBase で冒険しないでください

HBase 0.92 + Hadoop 2.0

• HDFS HA による高可用性の確保• 分散ログスプリッティングによるリカバ

リーの高速化– 100 ノードの場合、 9 時間が 5.4 分 (100 倍 )– ダウンタイムの削減＝可用性の向上

HBase 0.96 + Hadoop 2.x ( 計画 )

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

まとめ• HBase は一貫性と可用性の両立を目指し

て進化中• 一方で運用はまだまだ課題が多い• 対策– Conservative First! 用法をよく守って正しく使

いましょう– HBase 本読みましょう ( もうすぐ日本語版出

る )– お金あるならサポート買ってね！

HDFS NAMENODE HIGH AVAILABILITY

信頼性、保守性、可用性• reliability 信頼性 = MTBF/(1 + MTBF)– MTBF: 平均故障間隔– 1ヶ月に 1回壊れるより 1 年に 1回の方が信頼性が高い

• maintainability 保守性 = 1 / (1 + MTTR)– MTTR: 平均復旧時間– 素早く復旧する方が保守性が高い

• availability 可用性 = MTTF / MTBF– MTTF: 平均故障時間– MTBF = MTTF + MTTR– 信頼性と保守性が高いと可用性も高い

信頼性• データの信頼性– 10 クラスタ、 20,000 ノード上の 3.29億ブ

ロックのうち 19 ブロックがロスト (2009 年 )• ※同一ファイルのブロックが全てロストする確率

はほぼ 0

– 1700万ブロック中 1 ブロック (約 4PB)–原因となったバグは既に修正済み

信頼性は十分高い

可用性• 18ヶ月で、 25 クラスタの間で 22回の障

害– 1 クラスタあたり年間 0.58回の障害– HA が役に立っただろうと考えられるのはうち

8回の障害 (0.23回分 )• 計画停止– 設定変更のたびに再起動– アップデート時も当然再起動

保守性• NN起動時間 : 通常 1-2 分、大クラスタだ

と 15 分– 計画停止するたびにこれだけの時間停止する→MTTR増える ( 保守性下がる )

– 日本で主流の Heartbeat + DRBD も、この部分は回避できてない

• DN の保守性– 大クラスタ : 1 日 1DN に障害発生、ディスク

はもっと高頻度– 3ヶ月に 1回の割合で一斉に補修・入れ替え

HDFS HA のデザイン• NN 外からのサービス監視とリーダー選出– ZKFC と Zookeeper– マニュアルフェイルオーバなら ZK 不要

• Act と Standby 両方にブロックレポート送信–再起動時のブロックレポート収集が必要ない

• クライアントサイドもフェイルオーバに対応• edits のみ共有ストレージに置く必要がある–将来的に ZooKeeper (BookKeeper) で管理する予

定 (HDFS-3077)

まとめ• HDFS HA はかなり可用性を上げる• 障害対策はもちろん、 HDFS のアップグ

レードや設定変更時の再起動にも有効